Cassandra 2.0.2 CQL Long Row Limitation/Performance Impact

Question

Учитывая простую таблицу CQL, в которой хранится идентификатор и Blob, есть ли какие-либо проблемы или влияние на производительность потенциально миллиардов строк?

Я знаю, что с более ранними версиями Cassandra широкие ряды были сложными, но CQL, похоже, побуждает нас отказаться от этого. У меня нет особых требований, чтобы данные группировались вместе или могли фильтроваться в любом порядке. Мне интересно, может ли быть очень много строк в таблице CQL.

Я рассматриваю возможность бинирования моих данных, то есть создание ключа раздела, который является хешем% n идентификатора, и ограничивает данные n-бинами (миллионы?). Прежде чем добавить это накладные расходы, я хотел бы проверить, действительно ли это стоит.

Answer 1

Во-первых, я не думаю, что это правильно.

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

Широкие ряды поддерживаются и хорошо. Есть сообщение от Jonathan Ellis Does CQL support dynamic columns/wide rows?:

Общее недоразумение в том, что CQL не поддерживает динамические столбцы или широкие ряды. Напротив, CQL был разработан, чтобы поддерживать все, что вы можете сделать с моделью Thrift, но сделать ее проще и доступнее.

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

По Аарон Мортон в этом mail thread:

Когда строки получить выше нескольких 10-х МБ вещи могут замедлить, когда они выше 50 Мб они могут быть боль, когда они выше 100MB это предупреждающий знак. И , когда они получают выше 1 ГБ, ну, вы не хотите знать, что происходит тогда.

и позже:

Большие строки займет больше времени, чтобы пройти через уплотнение, как правило, вызывают больше JVM GC и имеют проблемы во время ремонта. См. Комментарии in_memory_compaction_limit_in_mb в файле файла yaml. Во время ремонта мы обнаруживаем различия в диапазонах строк и потока между узлами. Если у вас широкие строки и один столбец - наша синхронизация , мы создадим новую копию этой строки на узле, которая затем должна быть уплотнена. Я видел нагрузку на узлы с очень широкими рядами, спускающимися на 150 ГБ, только на , уменьшая параметры уплотнения.

ИМХО все вещи были равными рядами в немногих 10-х годах работы МВ.

Answer 2

В чате с Аароном Мортоном (последний развод) он указал, что миллиарды строк в таблице не обязательно проблематичны.

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