Что такое лучшая практика при разработке модели данных Cassandra?

Question

И каковы подводные камни, которых следует избегать? Есть ли какие-то сделки для вас? Например, я слышал, что экспортировать/импортировать данные Cassandra очень сложно, заставив меня задаться вопросом, не помешает ли синхронизация производственных данных с средой разработки.

BTW, очень сложно найти хорошие учебники на Кассандре, единственное, что у меня есть http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model, по-прежнему довольно простой.

Спасибо.

Answer 1

Для меня главное - решить, использовать ли OrderedPartitioner или RandomPartitioner.

Если вы используете RandomPartitioner, сканирование диапазона невозможно. Это означает, что вы должны знать точный ключ для любой деятельности, ВКЛЮЧАЯ ЧИСТКУ СТАРОГО ДАННЫХ.

Итак, если у вас есть много отбросов, если у вас нет волшебного способа узнать, какие именно ключи вы вставили для использования, используя случайный разделитель, вы можете легко «потерять» материал, что вызывает дисковое пространство утечки и в конечном итоге потребляет все хранилища.

С другой стороны, вы можете запросить упорядоченный разделитель «какие ключи у меня есть в Column Family X между A и B»? - и это вам скажет. Вы можете очистить их.

Однако есть недостатки. Поскольку Cassandra не выполняет автоматическую балансировку нагрузки, если вы используете упорядоченный разделитель, по всей вероятности, все ваши данные попадут в один или два узла, а в других - нет, а это значит, что вы будете тратить ресурсы.

У меня нет легкого ответа на этот вопрос, за исключением того, что вы можете получить «лучшее из обоих миров» в некоторых случаях, поставив короткое значение хэша (чего-то, что вы можете легко перечислить из других источников данных) в начале ваши ключи - например, 16-битный шестнадцатеричный хэш идентификатора пользователя - который даст вам 4 шестнадцатеричных цифры, за которыми следует любой ключ, который вы действительно хотели использовать.

Тогда, если у вас есть список недавно удаленных пользователей, вы можете просто использовать их идентификаторы и сканирование диапазона, чтобы очистить все, что связано с ними.

Следующий сложный бит - это вторичные индексы - у Cassandra его нет - так что если вам нужно искать X на Y, вам нужно вставить данные под оба ключа или указатель. Аналогичным образом, эти указатели, возможно, придется очистить, когда вещь, на которую они указывают, не существует, но на этой основе нет простого способа запроса материала, поэтому ваше приложение должно просто запомнить.

И ошибки приложений могут оставить осиротевшие ключи, о которых вы забыли, и вы не сможете легко их обнаружить, если только вы не напишите сборщик мусора, который периодически сканирует каждый ключ в db (это происходит взять время - но вы можете сделать это в кусках), чтобы проверить те, которые больше не нужны.

Ничто из этого не зависит от реального использования, только то, что я выяснил во время исследования. Мы не используем Cassandra в производстве.

EDIT: у Cassandra теперь есть вторичные индексы в багажнике.

Answer 2

Другое учебное пособие находится здесь: http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/.

Answer 3

Запланирована ли сделка? Не обязательно иметь дело выключателей, но что-то, чтобы быть в курсе

1. клиента подключается к ближайшему узлу, которые касаются он должен знать заранее, все коммуникации со всей другой Кассандрой узлы проксированными через него. a. трафик чтения/записи распределяется неравномерно среди узлов - некоторые узлы проксируют больше данных, чем сами они принимают b. Если узел идет вниз, клиент беспомощен, не может читать, не может писать где-либо в кластере.

2. Несмотря на то, что Кассандра утверждает, что «пишет никогда не сработает», они терпят неудачу, по крайней мере, в момент их выступления. Если целевой узел данных становится вялым, запрашивать время и записывать сбой. Есть много причин, по которым узел становится невосприимчивым: сборщик мусора запускает, процесс уплотнения, независимо от того, ... Во всех таких случаях все попытки записи/чтения не выполняются. В обычной базе данных эти запросы стали бы медленными, но в Кассандре они просто терпят неудачу.

3. Там будет несколько получить, но нет мульти-удалить и один не может укоротить ColumnFamily либо

4. Если новый, пустой узел данных введите кластер, часть данных из одного соседних узлов на key-ring будет передан только. Это приводит к неравномерному распределению данных и неравномерной нагрузке. Вы можете исправить это, удваивая количество узлов. Один должен также отслеживать токены вручную и выбирать их с умом.

Answer 4

Это было слишком долго, чтобы добавить комментарий, так, чтобы прояснить некоторые неправильные представления из списка-оф-проблем ответить:

1. Любой клиент может подключиться к любому узлу; если первый узел, который вы выбираете (или вы подключаетесь через балансировщик нагрузки), опускается, просто подключитесь к другому. Кроме того, доступен «жирный клиент» api, где клиент может направить сами записи; пример находится на http://wiki.apache.org/cassandra/ClientExamples

2. Сроки, когда сервер не отвечает на запросы, а не зависает на неопределенный срок, является особенностью, которую пожелает большинство людей, которые имели дело с перегруженными системами rdbms. Таймаут Cassandra RPC настраивается; если вы хотите, вы можете установить его на несколько дней и вместо этого иметь дело с зависанием на неопределенный срок. :)

3. Верно, что на данный момент нет поддержки с помощью множества или усечений, но есть исправления для обоих из них в обзоре.

4. Очевидно, существует компромисс в поддержании баланса нагрузки между узлами кластера: чем более сбалансированным вы пытаетесь сохранить вещи, тем больше движения данных вы будете делать, что не является бесплатным. По умолчанию новые узлы кластера Cassandra будут перемещаться в оптимальное положение в кольце маркера, чтобы минимизировать неравномерность. На практике это, как было показано, работает хорошо, и чем крупнее ваш кластер, тем менее верно, что удвоение оптимально. Это покрыто более http://wiki.apache.org/cassandra/Operations

Answer 5

Я думаю, что это заслуживает обновления, так как Cassandra 1.2 вышел недавно.

Я использую Cassandra в производстве в течение 18 месяцев для социальных игр.

Мое изобретение заключается в том, что для его сильных сторон необходимо использовать Кассандру.Поэтому хорошее понимание того, что и как оно делает, необходимо увидеть, какая модель данных использовать или даже определить, является ли другое решение для БД более полезным для вас.

OrderedPartitioner полезен только если ваше приложение полагаться на ключевых запросах диапазона, но вы отказываетесь на одном из самых мощных возможностей Кассандры для этого: автоматического сегментирования и балансировка нагрузки. Вместо запросов к рядам ключевых строк попытайтесь реализовать те же функции, которые вам нужны, используя диапазоны имен столбцов в одной строке. TL; DR чтение/запись НЕ будет сбалансировано между узлами, используя это.

RandomPartioner (md5 хеширования) и MurmurPartitioner (Шумы хеширование, лучше и быстрее) является способом вы должны пойти, если вы хотите, чтобы поддерживать большие данные и частоты высокого доступа. Единственное, что вы бросаете, - это ключевые запросы диапазона. Все, что находится в одной строке, все еще находится на одном узле кластера, и вы можете использовать запросы диапазона компаратора и столбца. TL; DR: ИСПОЛЬЗУЙТЕ ЭТО ДЛЯ СВОБОДНОГО БАЛАНСИРОВАНИЯ, вы не сдадите ничего крупного.

---

Вещи вы должны знать о Кассандре:

Cassandra, в конечном счете соответствует. Cassandra решила торговать Consistency для высокой доступности и отличной разбивки (http://en.wikipedia.org/wiki/CAP_theorem). НО вы можете получить согласованность от cassandra, это все о политике Consistency, когда вы читаете и пишете. Это довольно важная и сложная тема, когда мы говорим об использовании cassandra, но вы можете прочитать об этом подробнее здесь http://www.datastax.com/docs/1.2/dml/data_consistency.

Как правило, (и чтобы это было просто), я читаю и пишу в QUORUM ConsistencyLevel (поскольку в моих приложениях чтение имеет тот же порядок частот, что и записи). Если ваше приложение сильно пишет тяжело, и чтение происходит гораздо реже, то используйте write on ONE и читайте ВСЕ. Или, если ваш вариант использования - наоборот (записи намного реже, чем чтение), вы можете попробовать прочитать ONE и написать на ALL. Использование ANY в качестве уровня консистенции для записей - это не отличная идея, если согласованность - это то, что вы пытаетесь решить, поскольку оно гарантирует, что мутация достигла кластера, но не была написана где угодно. Это единственный случай, когда я получаю записи, которые молча проваливаются на кассандре.

Это простые правила, позволяющие легко начать работу с разработкой cassandra. Чтобы получить как можно больше последовательности и производительности от производственного кластера, вы должны внимательно изучить эту тему и понять ее сами.

Если вам нужна человекочитаемая датамодель со сложными отношениями между сущностями (таблицами), то я не думаю, что Кассандра для вас. MySQL и, возможно, NewSQL могут быть более полезными для вашего использования.

Хорошая вещь, чтобы знать, как, грубо говоря, cassandra сохраняет и считывает данные. Всякий раз, когда вы пишете (удаляет на самом деле запись значения «надгробного камня» в cassandra), система добавит новое значение и отметку времени в новое физическое местоположение.

Когда вы читаете, cassandra пытается вытащить все записи для определенного местоположения key/column_name и возвращает вам самое последнее, что он мог найти (тот, у которого самая высокая отметка времени, предоставленная клиентом). Таким образом, память, необходимая узлу, напрямую зависит от частоты записи. В кассандре происходит процесс уплотнения, который заботится о чистке старых мутаций. Cassandra имеет внутренний кеш, который обновляется при чтении с последним значением местоположения.

Слияние/сжатие на диске SSTables (структуры данных, которые сохраняют данные) могут быть вызваны чтением, но лучше не рассчитывать на него. Очистка надгробных камней и столбцов с истекшим сроком действия (с использованием функциональных возможностей «время жизни») - это другой механизм, управляемый сборщиком мусора (подробнее см. Настройку льготного времени GC).

---

Это приводит меня к последнему пункту, который я хочу сделать: убедитесь, что ваши записи и чтение будут сбалансированы в вашем кластере!

Предположим, что всем вашим пользователям необходимо обновлять одно местоположение очень часто.
НЕ НАПРАВЛЯЙТЕ это теоретическое единственное место только к одной строке! Это заставит все ваши записи упасть только на один узел в вашем кластере. Если это не сбивает все (потому что у вас есть систопы rockstar), это по крайней мере сильно повредит производительности кластера.
Мой совет состоит в том, чтобы хранить ваши записи в достаточно разных клавишах строк, которые будут распространяться на всех узлах кластера. Чтобы получить все данные для этого единственного теоретического местоположения, используйте multi_get во всех «подстрочных клавишах».

Пример:
Я хочу иметь список всех активных сеансов http (которые присвоены uuid). Не сохраняйте все в одной строке «сеанс». То, что я использую в качестве ключа строки для моего кластера cassandra из 6 узлов: _sessions. Затем у меня есть маленький 16 ключей multi_get для извлечения всех активных сеансов, или я все еще могу сказать, активен ли сеанс, просто используя простой get (если я знаю его uuid, конечно). Если ваш кластер намного больше, вы можете использовать хэш-функцию для генерации ключей ведра.