В этой теме я хотел бы поговорить о том, как это работает. Кассандра ( Кассандра ) — это децентрализованная, отказоустойчивая и надежная база данных «ключ-значение».
Хранилище само позаботится о проблемах доступности.
единственная точка отказа ( единственная точка отказа ), сбой сервера и распределение данных между узлы кластера ( узел кластера ).
Более того, как и в случае с размещением серверов в одном Дата центр ( Дата центр ), так и в конфигурации со множеством дата-центров, разделенных расстояниями и, соответственно, задержками сети.
Надежность означает окончательная согласованность ( конечная согласованность ) данные с возможностью установки уровень сверки данных ( последовательность настройки ) каждого запроса.
NoSQL базы данных обычно требуют большего понимания их внутренней работы, чем SQL .
В этой статье будет описана базовая структура, а в следующих статьях можно будет рассмотреть: CQL и интерфейс программирования; методы проектирования и оптимизации; особенности кластеров, расположенных во многих дата-центрах.
Модель данных В терминологии Cassandra приложение работает с ключевое пространство ( пространство ключей ), что соответствует понятию схемы базы данных ( схема базы данных ) в реляционной модели.
В этом пространстве ключей может быть несколько ключей.
семейства колонн ( семейство колонн ), что соответствует понятию реляционной таблицы.
В свою очередь, семейства столбцов содержат динамики ( столбец ), которые объединяются с помощью ключ ( ключ строки ) В записи ( ряд ).
Колонна состоит из трех частей: имя ( имя столбца ), временные метки ( временная метка ) И ценности ( ценить ).
Столбцы внутри записи упорядочены.
В отличие от реляционной базы данных, здесь нет ограничений на записи (а в терминах базы данных — это строки), содержащие столбцы с такими же именами, как и в других записях.
Семейства колонн могут быть нескольких типов, но в данной статье мы опустим эту деталь.
Также в последних версиях Кассандры появилась возможность выполнять запросы на определение и изменение данных ( ДДЛ , ДМЛ ) с помощью языка ККЛ а также создать вторичные индексы ( вторичные индексы ).
Конкретное значение, хранящееся в Cassandra, идентифицируется:
- Ключевое пространство — это привязка к приложению (предметной области).
Позволяет размещать данные из разных приложений на одном кластере;
- семейство столбцов — это привязка к запросу;
- ключ — привязка к узлу кластера.
Ключ определяет, в какие узлы будут попадать сохраненные столбцы;
- имя столбца — это привязка к атрибуту в записи.
Позволяет хранить несколько значений в одной записи.
По типу данных: пространство ключей и семейство столбцов представляют собой строки (имена); временная метка — 64-битное число; а ключ, имя столбца и значение столбца представляют собой массив байтов.
Также у Кассандры есть концепция типы данных ( тип данных ).
Эти типы могут быть указаны (необязательно) разработчиком при создании семейства столбцов.
Для имен столбцов это называется компаратор ( компаратор ), для значений и ключей — валидатор ( валидатор ).
Первый определяет, какие значения байтов допустимы для имен столбцов и как их упорядочивать.
Второе — какие значения байтов разрешены для значений столбца и ключа.
Если эти типы данных не указаны, то Cassandra сохраняет значения и сравнивает их как байтовые строки ( Байтстип ), поскольку, по сути, они хранятся внутри.
Типы данных:
- BytesType: любые байтовые строки (без проверки).
- AsciiType: строка ASCII.
- UTF8Type: строка UTF-8.
- IntegerType: число произвольного размера.
- Int32Type: 4-байтовое число.
- LongType: 8-байтовое число.
- UUIDТип: UUID 1-й или 4-й тип
- TimeUUIDType: тип UUID 1.
- DateType: 8-байтовое значение временной метки.
- BooleanType: два значения: true = 1 или false = 0.
- FloatType: 4-байтовое число с плавающей запятой.
- DoubleType: 8-байтовое число с плавающей запятой.
- DecimalType: число с плавающей запятой произвольного размера.
- CounterColumnType: 8-байтовый счетчик.
Записанные значения никогда не меняются, новые столбцы просто поступают с новыми значениями.
Запись в Cassandra работает быстрее, чем чтение.
Это меняет подход к проектированию.
Если рассматривать Cassandra с точки зрения проектирования модели данных, то семейство столбцов проще представить не как таблицу, а как материализованный вид ( материализованный вид ) — это структура, которая представляет данные некоторого сложного запроса, но хранит их на диске.
Вместо того, чтобы пытаться как-то собрать данные с помощью запросов, лучше попытаться сохранить все, что может понадобиться для этого запроса, в итоговое семейство.
То есть подходить нужно не со стороны связей между сущностями или связей между объектами, а со стороны запросов: какие поля нужно выбрать; в каком порядке должны идти записи; какие данные, относящиеся к основным, следует запрашивать вместе — все это уже должно храниться в семействе столбцов.
Количество столбцов в записи теоретически ограничено 2 миллиардами.
Это небольшой экскурс, а более подробную информацию можно найти в статье о методах проектирования и оптимизации.
Теперь углубимся в процесс сохранения данных в Cassandra и их чтения.
Распределение данных Рассмотрим, как распределяются данные в зависимости от ключа согласно узлы кластера ( узлы кластера ).
Cassandra позволяет вам установить стратегию распределения данных.
Первая такая стратегия распределяет данные в зависимости от значения md5 ключа — случайный маркер ( случайный разделитель ).
Второй учитывает разрядность самого ключа — порядковый маркер ( байтовый разделитель ).
Первая стратегия по большей части дает больше преимуществ, поскольку вам не нужно беспокоиться о равномерном распределении данных между серверами и тому подобных проблемах.
Вторая стратегия используется в редких случаях, например, при необходимости.
интервальные запросы ( сканирование диапазона ).
Важно отметить, что выбор этой стратегии производится до создания кластера и фактически не может быть изменен без полной перезагрузки данных.
Для распространения данных Кассандра использует метод, известный как последовательное хеширование ( последовательное хеширование ).
Такой подход позволяет распределять данные между узлами и следить за тем, чтобы при добавлении или удалении нового узла объем передаваемых данных был небольшим.
Для этого каждому узлу назначается этикетка ( жетон ), который разбивает набор всех значений ключей md5 на части.
Поскольку в большинстве случаев используется RandomPartitioner, рассмотрим его.
Как я уже говорил, RandomPartitioner вычисляет 128-битный md5 для каждого ключа.
Чтобы определить, в каких узлах будут храниться данные, все метки узлов просто перебираются от наименьшего к наибольшему, и когда значение метки становится больше значения md5 ключа, то этот узел вместе с некоторым количеством последующих узлов (в порядке меток), выбирается для хранения.
Общее количество выбранных узлов должно быть равно уровень репликации ( фактор репликации ).
Уровень репликации устанавливается для каждого пространства ключей и позволяет настраивать избыточность данных ( избыточность данных ).
Прежде чем добавить узел в кластер, вам необходимо присвоить ему метку.
Процент ключей, закрывающих пробел между этой меткой и следующей, определяет, какой объем данных будет храниться на узле.
Весь набор меток кластера называется кольцо ( кольцо ).
Вот иллюстрация, отображаемая с помощью встроенной утилиты инструмент узла кластерное кольцо из 6 узлов с равномерно распределенными метками.
Согласованность данных
Узлы кластера Cassandra эквивалентны, и клиенты могут подключаться к любому из них как для записи, так и для чтения.
Запросы проходят этап согласования, в ходе которого по ключу и маркеру определения, на каких узлах должны располагаться данные, сервер отправляет запросы этим узлам.
Назовем узел, выполняющий согласование - координатор ( координатор ), а узлы, выбранные для сохранения записи с этим ключом, узлы реплик ( узлы реплик ).
Физически координатором может быть один из узлов реплики — это зависит только от ключа, маркера и меток.
Для каждого запроса, как на чтение, так и на запись, можно установить уровень согласованности данных.
Для записи этот уровень будет влиять на количество узлов реплики, от которых будет ожидаться подтверждение об успешном завершении операции (данные записаны) перед возвратом управления пользователю.
Для справки, уровни согласованности следующие:
- ONE – координатор отправляет запросы всем узлам реплики, но, дождавшись подтверждения от первого узла, возвращает управление пользователю;
- TWO — то же самое, но координатор ожидает подтверждения от первых двух узлов, прежде чем вернуть управление;
- THREE — аналогично, но координатор ждет подтверждения от первых трех узлов, прежде чем вернуть управление;
- КВОРУМ — кворум собран: координатор ожидает подтверждения записи от более чем половины узлов реплики, а именно round(N/2)+1, где N — уровень репликации;
- LOCAL_QUORUM — координатор ожидает подтверждения от более чем половины узлов реплики в том же дата-центре, где находится координатор (потенциально на каждый запрос).
Позволяет избавиться от задержек, связанных с отправкой данных в другие дата-центры.
Вопросы работы со многими дата-центрами кратко рассмотрены в этой статье;
- EACH_QUORUM — координатор ожидает подтверждения от более чем половины узлов реплики в каждом дата-центре независимо;
- ALL — координатор ожидает подтверждения от всех узлов реплики;
- ЛЮБОЙ — дает возможность записывать данные, даже если все узлы реплики не отвечают. Координатор ожидает либо первого ответа от одного из узлов реплики, либо сохранения данных с помощью направленная отправка ( намекнул на передачу ) на координаторе.
При чтении уровень согласованности будет влиять на количество узлов реплики, из которых будут выполняться чтения.
Для чтения существуют следующие уровни согласованности:
- ОДИН — координатор отправляет запросы на ближайший узел реплики.
Остальные замечания также рассматриваются в целях показания с коррекцией ( читать ремонт ) с вероятностью, указанной в конфигурации Кассандры;
- TWO — то же самое, но координатор отправляет запросы двум ближайшим узлам.
Выбирается значение, имеющее наибольшую временную метку;
- ТРИ – аналогичен предыдущему варианту, но с тремя узлами;
- КВОРУМ — собран кворум, то есть координатор отправляет запросы более чем половине узлов реплики, а именно round(N/2)+1, где N — уровень репликации;
- LOCAL_QUORUM — в дата-центре, в котором происходит координация, собирается кворум и возвращаются данные с последней временной меткой;
- EACH_QUORUM — координатор возвращает данные после собрания кворума в каждом из дата-центров;
- ALL — координатор возвращает данные после чтения со всех узлов реплики.
Таким образом, можно регулировать задержки чтения, записи и настроить согласованность ( последовательность настройки ), и доступность ( доступность ) каждого типа операции.
По сути, доступность напрямую связана с уровнем согласованности операций чтения и записи, поскольку она определяет, сколько узлов реплики может выйти из строя и при этом эти операции будут подтверждены.
Если количество узлов, от которых получены подтверждения записи, добавленное к числу узлов, с которых происходит чтение, больше уровня репликации, то мы имеем гарантию, что после записи новое значение всегда будет прочитано, и это называется строгая последовательность ( сильная консистенция ).
Без строгой согласованности существует вероятность того, что операция чтения вернет устаревшие данные.
В любом случае смысл со временем распространится между репликами, но после того, как закончится ожидание координации.
Это распределение называется окончательная согласованность ( конечная согласованность ).
Если не все узлы реплики доступны на момент написания, то рано или поздно будут использованы инструменты восстановления, такие как чтение с коррекцией и антиэнтропийное восстановление узла.
Подробнее об этом позже.
Таким образом, при уровне согласованности чтения и записи QUORUM всегда будет поддерживаться строгая согласованность, и будет некоторый баланс между задержкой операций чтения и записи.
При ВСЕХ операциях записи и ОДНОМ чтении будет обеспечена строгая согласованность, а операции чтения будут выполняться быстрее и иметь большую доступность, а это означает, что количество вышедших из строя узлов, для которых чтение все равно будет завершено, может быть больше, чем при использовании КВОРУМА.
Для операций записи потребуются все рабочие узлы реплики.
При записи ОДНОГО, чтении ВСЕХ также будет строгая согласованность, и операции записи будут выполняться быстрее, а доступность записи будет высокой, поскольку достаточно будет только подтвердить, что операция записи произошла хотя бы на одном из серверов, и чтение будет медленнее и потребует всех узлов реплики.
Если приложению не требуется строгая согласованность, то можно ускорить операции чтения и записи, а также повысить доступность, установив более низкие уровни согласованности.
Восстановление данных Cassandra поддерживает три механизма восстановления данных:
- чтение с восстановлением ( читать ремонт ) — при чтении данные запрашиваются со всех реплик и сравниваются после завершения согласования.
Столбец с последней меткой времени будет распространен на узлы, где метки времени устарели.
- направленная отправка ( намекнул на передачу ) — позволяет сохранить информацию об операции записи на координаторе в случае сбоя записи в любой из узлов.
Позже, когда это будет возможно, запись будет повторена.
Позволяет быстро восстановить данные в случае кратковременного отсутствия узла в кластере.
Кроме того, на уровне согласованности ANY позволяет добиться Полная возможность записи ( абсолютная доступность записи ), когда даже все узлы реплики недоступны, операция записи подтверждается и данные сохраняются на узле-координаторе.
- восстановление антиэнтропийного узла ( ремонт антиэнтропийного узла ) — это некий процесс восстановления всех реплик, который необходимо регулярно запускать вручную с помощью команды «nodetool Repair» и позволяет поддерживать количество реплик всех данных, которые, возможно, не были восстановлены первыми двумя способами, при необходимой репликации.
уровень.
Для каждого семейства столбцов существует таблица в памяти, которая позволяет мгновенно запомнить значение.
Технически это хеш-таблица ( хэш-карта ) с возможностью одновременный доступ ( одновременный доступ ) на основе структуры данных, называемой «списки с пропусками» ( пропустить список ).
Журнал закрепления единый на все пространство ключей и сохраняется на диске.
Журнал представляет собой последовательность операций модификации.
Он также распадается на части, когда достигает определенного размера.
Такая организация позволяет сделать скорость записи ограниченной скоростью последовательной записи на жесткий диск и в то же время гарантировать долговечность данных ( долговечность данных ).
Журнал закрепления в случае аварийной остановки узла считывается при запуске службы Cassandra и восстанавливает все таблицы в памяти.
Оказывается, скорость ограничена при последовательной записи на диск, и у современных жестких дисков она составляет около 100МБ/с.
По этой причине рекомендуется перенести журнал закрепления на отдельный диск.
Понятно, что рано или поздно память может переполниться.
Поэтому таблицу в памяти необходимо также сохранить на диск.
Для определения момента сохранения есть ограничение объема памяти, занимаемой таблицами ( memtable_total_spacein_mb ), по умолчанию это ⅓ максимального размера Java кучи ( кучное пространство Java ).
Когда таблицы в памяти заполняют больше этого предела, Кассандра создает новую таблицу и записывает старую таблицу в памяти на диск в виде сохраненная таблица ( Таблица SSTable ).
Сохраненная таблица больше никогда не будет сохранена после создания.
не изменен ( является неизменным ).
При сохранении на диск части журнала закрепления помечаются как свободные, что освобождает дисковое пространство, занимаемое журналом.
Необходимо учитывать, что журнал имеет переплетенную структуру данных из разных семейств столбцов в ключевом пространстве, и некоторые части могут не освобождаться, так как некоторые области будут соответствовать другим данным, все еще находящимся в таблицах в памяти.
В результате каждому семейству столбцов соответствует одна таблица в памяти и определенное количество сохраненных таблиц.
Теперь, когда узел обрабатывает запрос на чтение, ему необходимо запросить все эти структуры и выбрать самое последнее значение по временной метке.
Существует три механизма ускорения этого процесса: фильтрация цветения ( фильтр Блума ), ключевой кэш ( ключевой кэш ) И кэш записей ( кэш записи ):
- Фильтр Блума — это структура данных, которая занимает мало места и позволяет ответить на вопрос: содержится ли элемент, а в нашем случае это ключ, в наборе или нет. При этом если ответ «нет», то это 100%, а если ответ «да», то это, возможно, ложноположительный ответ. Это позволяет сократить количество операций чтения из сохраненных таблиц;
- Кэш ключей поддерживает позицию диска записи для каждого ключа, тем самым уменьшая количество операции позиционирования ( искать операции ) при поиске в сохраненной таблице;
- Кэш записей хранит всю запись, полностью исключая операции чтения с диска.
Тюлень В определенный момент данные в семействе столбцов будут перезаписаны — появятся столбцы, которые будут иметь то же имя и ключ.
То есть возникнет ситуация, когда и старая сохраненная таблица, и новая будут содержать старые и новые данные.
Чтобы гарантировать целостность, Cassandra должна прочитать все эти сохраненные таблицы и выбрать данные с последней меткой времени.
Получается, что количество операций позиционирования жесткого диска при чтении пропорционально количеству хранимых таблиц.
Поэтому, чтобы освободить перезаписанные данные и уменьшить количество сохраняемых таблиц, существует процесс уплотнения ( уплотнение ).
Он последовательно считывает несколько сохраненных таблиц и записывает новую сохраненную таблицу, объединяющую данные по временным меткам.
Когда таблица полностью написана и введена в эксплуатацию, Cassandra может освободить исходные таблицы (таблицы, которые ее сформировали).
Таким образом, если таблицы содержат перезаписанные данные, эта избыточность устраняется.
Понятно, что при такой операции увеличивается объем избыточности — новая сохраненная таблица существует на диске вместе с исходными таблицами, а значит, объем дискового пространства всегда должен быть таким, чтобы можно было выполнить сжатие.
Cassandra позволяет выбрать одну из двух стратегий уплотнения:
- стратегия сжатие сохраненных таблиц по размеру ( уплотнение по размеру ) — эта стратегия уплотняет две таблицы, выбранные определенным образом.
Применяется автоматически, как уплотнение фона ( незначительное уплотнение ) и в ручном режиме, для полное уплотнение ( сильное сжатие ).
Допускает ситуацию, когда ключ встречается во многих таблицах и, соответственно, требует выполнения операции поиска для каждой такой таблицы.
- стратегия уплотнение сохраненных таблиц по уровням ( выровненное уплотнение ) — уплотняет сохраненные таблицы, которые изначально создаются небольшого размера — 5 МБ, группируя их по уровням.
Каждый уровень в 10 раз больше предыдущего.
Более того, есть такие гарантии: 90% запросов на чтение будет приходиться на одну сохраненную таблицу, и только 10% дискового пространства будет использовано для устаревших данных.
В этом случае для выполнения уплотнения под временную таблицу достаточно всего 10-кратного размера таблицы, то есть 50 МБ.
Подробнее читайте в этом статья
Когда в результате чтения получается такое значение, оно пропускается, как будто такого значения никогда не существовало.
В результате уплотнения такие значения постепенно вытесняют устаревшие реальные значения и, возможно, исчезают вовсе.
Если появятся столбцы с реальными данными с еще более новыми метками времени, они в конечном итоге перезапишут эти перезаписанные значения.
Транзакционный Cassandra поддерживает транзакционность на уровне одной записи, то есть для набора столбцов с одним ключом.
Вот как выполняются четыре требования ACID:
- атомарность ( атомарность ) — все столбцы в одной записи либо будут записаны, либо нет за одну операцию;
- последовательность ( последовательность ) — как уже говорилось выше, вместо доступности можно использовать запросы со строгой согласованностью и тем самым выполнить это требование;
- изоляция ( изоляция ) - начиная с версии Cassandra 1.1 появилась поддержка изоляции, когда при записи столбцов одной записи другой пользователь, читающий эту же запись, увидит либо полностью старую версию записи, либо после завершения операции новую версию, а не часть столбцов из одного и часть второго;
- долговечность ( долговечность ) обеспечивается наличием журнала закрепления, который будет воспроизведен и восстановит узел в нужное состояние в случае любого сбоя.
- Страница Apache.org Кассандра.
apache.org
- Документация на datastax.com
-
Зачем Нужна Эмпатия В Мире Технологий
19 Oct, 24 -
«Мамба» Выходит На Ipo
19 Oct, 24
