Cassandra — это распределенная, децентрализованная, масштабируемая и высокодоступная база данных с широкими столбцами. В терминах теоремы CAP Кассандра означает AP (доступность и устойчивость к разделению). Это означает, что Cassandra предпочитает, чтобы все клиенты могли находить данные даже в тех случаях, когда не все узлы доступны, и работала должным образом при возникновении частичного сбоя сети. Однако это также означает, что согласованность данных может быть нарушена в пользу доступности и устойчивости разделов — пользователи увидят данные, но на какое-то время они могут оказаться устаревшими. Cassandra разработана для достижения высокой пропускной способности и более быстрых операций записи. И именно жертвование согласованностью позволяет Cassandra быть высокодоступной. По умолчанию Cassandra спроектирована так, чтобы быть в конечном итоге согласованной, а это означает, что она может не обеспечивать строгую согласованность. Это делает Cassandra подходящей для приложений, где согласованность не является критическим требованием. Однако Cassandra можно настроить для обеспечения строгой согласованности, хотя это может повлиять на производительность. Cassandra, будучи базой данных NoSQL, не поддерживает соединения таблиц, внешние ключи или возможность добавлять столбцы, отличные от первичного ключа, в предложении WHERE во время запроса. Эти ограничения следует принять во внимание, прежде чем использовать Cassandra. Кассандра Строительные блоки : Столбец представляет пару ключ-значение и служит основной единицей структуры данных. Столбец : действует как контейнер для столбцов, на которые ссылается первичный ключ. Row : служит контейнером для таблиц, охватывающих один или несколько узлов Cassandra. Keyspace : контейнер пространств ключей внутри Cassandra. Кластер : относится к компьютерной системе, на которой работает экземпляр Cassandra. Узел может быть физическим хостом, экземпляром машины в облаке или даже контейнером Docker. Узел Как Кассандра хранит данные Cassandra хранит данные как семейство столбцов. Он служит контейнером для столбцов, на которые ссылается первичный ключ. Строка семейства столбцов включает в себя несколько столбцов с ключом и значением, причем ключ строки служит первичным ключом: Семейство столбцов может хранить разный набор столбцов для каждого ключа строки: Cassandra не хранит столбцы с нулевыми значениями, что помогает сэкономить значительное пространство для хранения. Что такое первичный ключ в Кассандре? однозначно идентифицирует каждую строку таблицы. В Cassandra первичный ключ состоит из двух частей: Первичный ключ В Cassandra ключ раздела определяет, какой узел хранит данные, а ключ кластеризации определяет, как данные хранятся внутри узла. Например, рассмотрим таблицу с . Этот первичный ключ состоит из двух частей, представленных двумя столбцами: PRIMARY KEY (city_id, event_id) 1. служит ключом секции. Это означает, что данные будут секционированы на основе поля , в результате чего все строки с одинаковым будут храниться на одном узле. city_id city_id city_id 2. действует как ключ кластеризации. Внутри каждого узла данные организованы и хранятся в отсортированном порядке на основе столбца . event_id event_id Ключи кластеризации определяют порядок хранения данных внутри узла. Можно иметь несколько ключей кластеризации, и любые столбцы, перечисленные после ключа раздела, называются столбцами кластеризации. Столбцы кластеризации определяют порядок, в котором данные организованы на узле. Каждая строка с ключом раздела = «Париж» будет храниться в одном и том же узле, упорядоченном по значению столбца event_id. Разделение данных «из коробки» Cassandra обеспечивает секционирование данных на основе , чтобы уменьшить задержку в операциях чтения/записи и увеличить пропускную способность системы, когда объем данных, хранящихся в базе данных, становится большим. последовательного хеширования в Cassandra отвечает за решение о том, как данные распределяются по кольцу согласованного хеширования. Когда данные вставляются в кластер Cassandra, разделитель применяет алгоритм хеширования к . Результат этого алгоритма хеширования определяет диапазон, в который попадают данные, и определяет узел, на котором данные будут храниться. Разделитель ключу раздела Координаторный узел В Cassandra каждый узел знает о назначениях токенов других узлов через , что позволяет любому узлу обрабатывать запросы для диапазона любого другого узла. Таким образом, клиент может подключиться к любому узлу, чтобы инициировать запросы на чтение или запись. протокол сплетен Узел, который получает запрос, называется и может быть любым узлом в кластере. Если ключ не принадлежит диапазону координатора, запрос перенаправляется репликам, ответственным за этот диапазон. координатором Репликация Cassandra реплицирует данные на нескольких узлах, чтобы обеспечить высокую доступность. Каждый узел в Cassandra служит репликой для определенного диапазона данных. Распределяя несколько копий данных по разным репликам, Cassandra позволяет другим репликам обрабатывать запросы для этого диапазона данных в случае, если один узел недоступен. Две настройки будут влиять на процесс репликации: Коэффициент репликации определяет, сколько узлов будут хранить копии одних и тех же данных. В кластере с коэффициентом репликации 3 каждая строка будет храниться на трех разных узлах. Каждое пространство ключей в Cassandra может иметь свой коэффициент репликации. В Cassandra первая реплика назначается узлу, владеющему диапазоном, на основе хеша ключа раздела. Остальные реплики затем размещаются на последовательных узлах по часовой стрелке. Cassandra использует две стратегии репликации, чтобы определить, какие узлы будут отвечать за реплики: Простая стратегия репликации В этой стратегии первая реплика размещается на узле, определенном разделителем, а последующие реплики размещаются на последующих узлах по часовой стрелке. Эта стратегия репликации применима только для одного кластера центра обработки данных. Стратегия топологии сети Чтобы обеспечить устойчивость к полной потере данных, дополнительные реплики в одном центре обработки данных размещаются путем перемещения по часовой стрелке по кольцу до достижения первого узла в другом центре обработки данных. Такое расположение помогает смягчить влияние одновременных сбоев, которые обычно происходят в одном центре обработки данных из-за проблем с питанием, охлаждением или сетью. Когда дело доходит до конфигураций с несколькими центрами обработки данных, вам следует учитывать стратегию топологии сети. Этот подход позволяет указать различные коэффициенты репликации для каждого центра обработки данных, позволяя контролировать количество реплик, размещаемых в каждом конкретном месте. Когда использовать Кассандру Cassandra превосходно работает в приложениях, требующих обработки больших объемов данных и отдающих приоритет доступности данных, а не их согласованности. : Он хорошо подходит для 1. . Cassandra — идеальный выбор для сред IoT, поскольку она может обрабатывать огромные объемы данных, генерируемых устройствами и датчиками. Его распределенная архитектура позволяет управлять географически рассредоточенными крупномасштабными данными. Приложения Интернета вещей (IoT) 2. Приложения, работающие с данными временных рядов, такие как метрики, системы мониторинга и данные телеметрии, извлекают выгоду из эффективных операций записи Cassandra и горизонтальной масштабируемости. Эти возможности имеют решающее значение для хранения и управления большими объемами данных с отметками времени. Данные временных рядов. 3. . Cassandra предлагает высокую пропускную способность и доступ к данным с низкой задержкой, что делает его подходящим для веб- и мобильных платформ с большой базой пользователей, генерирующих значительные объемы данных. Сюда входят платформы социальных сетей, игровые приложения и сайты электронной коммерции. Веб-приложения и мобильные приложения 4. . Cassandra поддерживает обработку больших данных в реальном времени, что делает ее ценным выбором для приложений, требующих немедленного анализа больших наборов данных. Примеры включают механизмы рекомендаций и системы обнаружения мошенничества. Аналитика больших данных в реальном времени 5. . Предприятия с большими распределенными наборами данных могут использовать Cassandra в качестве решения для хранения данных. Его способность реплицировать данные в нескольких центрах обработки данных обеспечивает высокую доступность и аварийное восстановление. Распределенные хранилища данных 6. . Высокая пропускная способность Cassandra по записи и чтению делает ее хорошо подходящей для систем обмена сообщениями, которые обрабатывают большие объемы данных, таких как регистрация событий, контрольные журналы или очереди сообщений. Системы обмена сообщениями 7. . Приложения, требующие персонализированной доставки контента в большом масштабе, такие как системы управления контентом, выигрывают от скорости и масштабируемости Cassandra при доставке индивидуального контента большому количеству пользователей одновременно. Системы персонализации и управления контентом 8. : поддержка Cassandra нескольких центров обработки данных делает ее отличным выбором для приложений, требующих географически распределенных данных. Это обеспечивает доступ к данным с низкой задержкой в разных регионах и обеспечивает высокую отказоустойчивость. Географически распределенные приложения Когда не следует использовать Кассандру Хотя Apache Cassandra является мощным и масштабируемым, он может подходить не для каждого приложения или варианта использования. Он менее подходит для приложений с большим количеством транзакций, сложных запросов и сценариев, требующих строгой согласованности или быстрого изменения схемы. В таких случаях более подходящими могут оказаться традиционные системы управления реляционными базами данных (СУБД) или другие решения NoSQL. Вот несколько сценариев, в которых Кассандра может : оказаться не оптимальным выбором : сложность Cassandra и требования к ресурсам могут быть чрезмерными для небольших проектов или приложений с ограниченными наборами данных. Более простые решения для баз данных могут стать более экономичной и управляемой альтернативой. Мелкомасштабные проекты : Cassandra не полностью поддерживает свойства ACID (атомарность, согласованность, изоляция, долговечность). Если вашему приложению требуются сложные транзакции, обычно встречающиеся в банковских или финансовых системах, лучше подойдет традиционная СУБД. Транзакционные системы, требующие свойств ACID . Если ваше приложение сильно зависит от объединений, подзапросов или сложных агрегатов, Cassandra может оказаться не самым подходящим выбором. Он предназначен для быстрой записи и чтения, но не для сложной обработки запросов. Объединение тяжелых запросов и агрегатов : Cassandra обеспечивает итоговую согласованность, которая может не подходить для случаев использования, требующих строгой согласованности для каждой операции чтения и записи. Данные со строгими требованиями к согласованности . Хотя Cassandra хорошо работает в распределенных средах с несколькими узлами, она может быть не оптимальным выбором для развертываний с одним узлом или небольшим кластером, требующих чтения и записи с низкой задержкой. Чтение и запись с низкой задержкой в одном кластере : Cassandra не оптимизирована для хранения больших двоичных объектов (BLOB-объектов), таких как изображения или видео. Другие решения хранения лучше подходят для эффективной обработки больших двоичных объектов. Хранилище BLOB-объектов . Возможности запросов Cassandra ограничены по сравнению с полноценными базами данных SQL. Он не очень подходит для приложений, которые в значительной степени полагаются на специальные запросы и отчеты. Приложения, требующие специальных запросов В Cassandra дизайн таблиц тесно связан со способом доступа к данным, при этом особое внимание уделяется шаблонам запросов, а не исключительно отношениям между объектами данных. Это отличается от подхода в РСУБД, где проектирование схемы основано на принципах нормализации. . Если ваше приложение требует частых изменений в схеме базы данных, управление схемой Cassandra может быть менее гибким по сравнению с традиционными системами RDBMS или другими решениями NoSQL. Быстрая эволюция схемы . Хотя Cassandra хорошо подходит для рабочих нагрузок с большим объемом записи и доступа к данным в реальном времени, она может быть не самым подходящим выбором для сценариев хранения данных, требующих сложных запросов, объединения и анализ исторических данных. Приложения хранилищ данных, которые включают в себя сложные запросы, соединения и анализ исторических данных Краткое содержание В этой статье представлен обзор Cassandra, хорошо масштабируемой и распределенной базы данных с широкими столбцами. Cassandra разработана с учетом приоритета доступности и устойчивости к разделам, что делает ее подходящей для приложений, где согласованность не является критическим требованием. Он поддерживает высокую пропускную способность и более быстрые операции записи. Строительные блоки Cassandra включают столбцы, строки, пространства ключей, кластеры и узлы. Столбцы представляют пары ключ-значение, строки действуют как контейнеры для столбцов, на которые ссылается первичный ключ, пространства ключей служат контейнерами для таблиц, охватывающих несколько узлов, кластеры содержат пространства ключей, а узлы относятся к компьютерным системам, на которых работают экземпляры Cassandra. Cassandra хранит данные в семействах столбцов, которые представляют собой контейнеры для столбцов, на которые ссылается первичный ключ. Секционирование данных достигается за счет последовательного хеширования, что позволяет сократить задержку и увеличить пропускную способность. Разделитель распределяет данные по кольцу согласованного хэша, а узел-координатор обрабатывает запросы на чтение и запись. Cassandra обеспечивает репликацию для обеспечения высокой доступности. Реплики данных хранятся на нескольких узлах, что гарантирует возможность обработки запросов репликами, если узел становится недоступным. Факторы и стратегии репликации определяют количество реплик и узлов, ответственных за них. Хотя Cassandra предлагает такие преимущества, как масштабируемость и высокая доступность, у нее есть ограничения. Он не поддерживает соединения таблиц, внешние ключи или возможность добавлять столбцы, отличные от первичного ключа, в предложении WHERE во время запроса. В целом, Cassandra — это мощное решение для баз данных для хорошо масштабируемых приложений, особенно тех, которые отдают приоритет доступности и устойчивости к разделению, а не строгой согласованности. Есть несколько интересных аспектов Кассандры, о которых я расскажу в своей следующей статье. , чтобы не пропустить! Подпишитесь на меня Ваше здоровье!
