Какова лучшая практика в разработке модели данных Cassandra? [закрытый]

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

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

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

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

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

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

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

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

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

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

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

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

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

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

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

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

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

не существует, но нет простого способа делать запросы на этой основе, поэтому ваше приложение должно просто помнить.

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

не существует, но нет простого способа делать запросы на этой основе, поэтому ваше приложение должно просто помнить.

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

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

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

EDIT: теперь у Cassandra есть вторичные индексы в стволе.

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

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

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

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

3. Есть множественное получение, но нет множественного удаления, и нельзя также усечь ColumnFamily

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

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

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

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

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

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