А какие подводные камни нужно избегать? Есть ли какие-то сделки для вас? Например, я слышал, что экспортировать/импортировать данные Cassandra очень сложно, заставив меня задаться вопросом, не помешает ли синхронизация производственных данных с средой разработки.
Кстати, очень сложно найти хорошие уроки на Cassandra, единственное, что у меня http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model, по-прежнему довольно элементарно.
Спасибо.
Для меня главное - решить, использовать ли OrderedPartitioner или RandomPartitioner.
Если вы используете RandomPartitioner, сканирование диапазона невозможно. Это означает, что вы должны знать точный ключ для любой деятельности, ВКЛЮЧАЯ ЧИСТКУ СТАРОГО ДАННЫХ.
Итак, если у вас есть много отбросов, если у вас нет волшебного способа узнать, какие ключи вы вставляете, используя случайный разделитель, вы можете легко "потерять" материал, что вызывает утечку дискового пространства и в конечном итоге будет потреблять все хранилища.
С другой стороны, вы можете запросить упорядоченный разделитель "какие ключи у меня есть в семействе столбцов X между A и B"? - и это вам скажет. Вы можете их очистить.
Однако есть и недостатки. Поскольку Cassandra не выполняет автоматическую балансировку нагрузки, если вы используете упорядоченный разделитель, то, по всей вероятности, все ваши данные попадут в один или два узла, а в других нет, а это значит, что вы будете тратить ресурсы.
У меня нет легкого ответа на этот вопрос, за исключением того, что вы можете получить "лучшее из обоих миров" в некоторых случаях, поставив короткое значение хеша (чего вы можете легко перечислить из других источников данных) в начале вашего ключи - например, 16-битный шестнадцатеричный хэш идентификатора пользователя - который даст вам 4 шестнадцатеричных цифры, за которыми следует любой ключ, который вы действительно хотели использовать.
Затем, если у вас есть список недавно удаленных пользователей, вы можете просто хешировать их идентификаторы и сканирование диапазона, чтобы очистить все, что связано с ними.
Следующий сложный бит - это вторичные индексы - у Cassandra их нет - поэтому, если вам нужно искать X на Y, вам нужно вставить данные под оба ключа или указатель. Аналогичным образом, эти указатели, возможно, придется очистить, когда вещь, на которую они указывают, не существует, но на этой основе нет простого способа запроса материала, поэтому ваше приложение должно просто запомнить.Дел >
И ошибки приложений могут оставлять забытые вами осиротые ключи, и вы не сможете легко их обнаружить, если только вы не напишите сборщик мусора, который периодически сканирует каждый ключ в db (это займет некоторое время - но вы можете сделать это в кусках), чтобы проверить те, которые больше не нужны.
Ничто из этого не основано на реальном использовании, только то, что я выяснил во время исследования. Мы не используем Кассандру в производстве.
EDIT: у Cassandra теперь есть вторичные индексы в туловище.
Это слишком долго, чтобы добавить комментарий, чтобы прояснить некоторые неправильные представления из ответа на список проблем:
Любой клиент может подключиться к любому node; если первый node, который вы выбираете (или вы подключаетесь через балансировщик нагрузки), опускается, просто подключитесь к другому. Кроме того, доступен "жирный клиент" api, где клиент может направить сами записи; пример находится на http://wiki.apache.org/cassandra/ClientExamples
Время, когда сервер не отвечает на запросы, а не зависает бесконечно, - это функция, которую пожелает большинство людей, которые имели дело с перегруженными системами rdbms. Таймаут Cassandra RPC настраивается; если вы хотите, вы можете установить его на несколько дней и вместо этого иметь дело с зависанием на неопределенный срок.:)
Верно, что пока нет поддержки с множеством или усечением, но есть исправления для обоих из них в обзоре.
Очевидно, есть компромисс в поддержании баланса нагрузки между узлами кластера: чем более сбалансированным вы пытаетесь сохранить вещи, тем больше движения данных вы будете делать, что не является бесплатным. По умолчанию новые узлы кластера Cassandra будут перемещаться в оптимальное положение в кольце маркера, чтобы минимизировать неравномерность. На практике это, как было показано, работает хорошо, и чем крупнее ваш кластер, тем менее верно, что удвоение оптимально. Это описано в http://wiki.apache.org/cassandra/Operations
Еще один учебник: http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/.
Есть ли какие-либо сделки для вас? Не обязательно использовать выключатели, но что-то знать
Клиент подключается к ближайшему node, адрес которого он должен знать заранее, все сообщения со всеми другими узлами Cassandra проксимируются через него. а. трафик чтения/записи распределяется неравномерно среди узлов - некоторые узлы проксируют больше данных, чем сами они б. Если node идет вниз, клиент беспомощный, не может читать, не может писать где-нибудь в кластере.
Несмотря на то, что Кассандра утверждает, что "записи никогда не терпят неудачу", они действительно терпят неудачу, по крайней мере, в момент их выступления. Если целевые данные node становятся вялыми, время запроса и запись не выполняются. Есть много причин, по которым node перестает отвечать: сборщик мусора запускает, процесс уплотнения, что угодно... Во всех таких случаях все попытки записи/чтения не выполняются. В обычной базе данных эти запросы стали бы медленными, но в Кассандре они просто терпят неудачу.
Существует многопользовательский режим, но нет мульти-удаления, а один из них не может обрезать ColumnFamily либо
Если в кластер будут введены новые, пустые данные node, часть данных с одного соседнего узла на ключевом кольце будет передана только. Это приводит к неравномерному распределению данных и неравномерной нагрузке. Вы можете исправить это, удваивая количество узлов. Один должен также отслеживать маркеры вручную и выбирать их с умом.
Я думаю, что это заслуживает обновления, поскольку Cassandra 1.2 вышел недавно.
Я использую Cassandra в производстве в течение последних 18 месяцев для социальных игр.
Мое дело в том, что вы должны использовать Cassandra для своих сильных сторон. Поэтому хорошее понимание того, что и как оно делает, необходимо увидеть, какая модель данных использовать или даже определить, является ли другое решение для БД более полезным для вас.
OrderedPartitioner полезен только в том случае, если ваше приложение полагается на запросы диапазона ключей, но вы отказываетесь от одной из самых мощных функций Cassandra для этого: автоматического масштабирования и балансировки нагрузки. Вместо запросов к рядам ключевых строк попытайтесь реализовать те же функции, которые вам нужны, используя диапазоны имен столбцов в одной строке. TL; DR чтение/запись НЕ будет сбалансировано между узлами, использующими это.
RandomPartioner (хеширование md5) и MurmurPartitioner (мурмуровое хеширование, лучше и быстрее) - это то, как ВЫ ДОЛЖНЫ идти, если вы хотите поддерживать большие данные и высокие частоты доступа, Единственное, что вы бросаете, - это ключевые запросы диапазона. Все, что находится в одной строке, все еще находится на одном и том же node в кластере, и вы можете использовать запросы диапазона компаратора и столбцов. TL; DR: ИСПОЛЬЗУЙТЕ ЭТО для PROPER BALANCING, вы ничего не откажетесь от основного.
Вещи, которые вы должны знать о кассандре:
КАССАНДРА СОБЫТИЯ СОВМЕСТНО. 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 и возвращает вам самое последнее, что он мог найти (тот, у которого самая высокая отметка времени, предоставленная клиентом). Таким образом, память, необходимая для node, напрямую зависит от частот записи. В кассандре происходит процесс уплотнения, который заботится о чистке старых мутаций. Cassandra имеет внутренний кеш, который обновляется при чтении с самым последним значением местоположения.
Слияние/сжатие на диске SSTables (структуры данных, которые сохраняют данные) могут быть вызваны чтением, но лучше не рассчитывать на него. Очистка надгробных камней и столбцов с истекшим сроком действия (с использованием функциональных возможностей "время жизни" ) - это другой механизм, управляемый сборщиком мусора (подробнее см. настройку льготного времени GC).
Это приводит меня к последней точке, которую я хочу сделать: убедитесь, что ваши записи и чтение будут сбалансированы в вашем кластере!
Предположим, что все ваши пользователи должны очень часто обновлять одно местоположение.
НЕ НАПРАВЛЯЙТЕ это теоретическое единственное место только к одной строке! Это заставит все ваши записи упасть только на один node в вашем кластере. Если это не сбивает все (потому что у вас есть систопы rockstar), это по крайней мере сильно ухудшит производительность кластера.
Мой совет состоит в том, чтобы записывать ваши записи в несколько разных ключей строк, которые вы будете распространять на всех узлах кластера. Чтобы получить все данные для этого единственного теоретического местоположения, используйте multi_get во всех "подстрочных клавишах".
Пример:
Я хочу иметь список всех активных сеансов http (которые присвоены uuid).
Не сохраняйте все в одной строке строки сеанса. То, что я использую в качестве ключа строки для моего кластера cassandra из 6 узлов:
_sessions.
Затем у меня есть маленький 16 ключей multi_get для извлечения всех активных сеансов, или я все еще могу сказать, активен ли сеанс, просто используя простой get (если я знаю его uuid, конечно).
Если ваш кластер намного больше, вы можете использовать хэш-функцию для генерации ключей ведра.