Производительность Cassandra: меньше строк с большим количеством столбцов и больше строк с меньшим количеством столбцов

Question

Мы оцениваем, можем ли мы перенести из SQL SERVER в cassandra для OLAP. По внутренней структуре хранения мы можем иметь широкие ряды. Нам почти нужно получить доступ к данным по дате. Нам часто приходится обращаться к данным в диапазоне дат, поскольку у нас есть финансовые данные. Если мы используем дату в качестве ключа раздела для поддержки фильтра по дате, мы получаем меньше строк с огромным количеством столбцов. Будет ли это препятствовать производительности, если у нас есть миллионы столбцов для одного ключевого ключа в будущем, когда мы обрабатываем миллионы транзакций каждый день.

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

Нужна производительность проницательности, чтобы продолжить в любом направлении

Answer 1

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

• Убедитесь, что вы не достигаете 2 миллиард столбцов в любом случае
• Вся широкая строка хранится на одном и том же узле: она должна быть помещена на диск. Кроме того, если у вас есть несколько дат, к которым обращаются чаще, чем другие даты (например, сегодня), вы можете создавать точки доступа на узле, который хранит данные за этот день.
• Очень большие ряды могут повлиять на производительность: Аарон Мортон из The Last Pickle имеет интересную статью об этом: http://thelastpickle.com/blog/2011/07/04/Cassandra-Query-Plans.html Это несколько старый, но я считаю, что концепции по-прежнему актуальны.

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