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

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

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

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


cassandra datastax-java-driver cql3
person 107    schedule 19.06.2015    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

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

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

person medvekoma    schedule 19.06.2015
comment
Спасибо за ваш комментарий. достижение предела в 2 миллиарда столбцов очень маловероятно. Возможно, широкий ряд не помещается на конкретный диск. Кассандра не обрабатывает такой случай, когда строка не помещается на диске. Он должен передавать данные на другой узел, так как выбор узла для сохранения строки является решением внутреннего механизма хранения. - person 107; 19.06.2015
comment
Разделение данных в Cassandra управляется ключом раздела: с помощью простого и быстрого алгоритма хэширования Cassandra идентифицирует узел, содержащий данные. В этом отношении широкий ряд является единым целым, он не разбивается на узлы. Со временем попробуйте ввести другие поля в ключ раздела (например, идентификатор финансового продукта, год или даже месяц, если это имеет смысл). - person medvekoma; 23.06.2015
comment
Если алгоритм хеширования идентифицирует узел, на котором строка не может поместиться или поместиться изначально, но по мере того, как широкая строка в конечном итоге увеличивается, то передает ли cassandra строку на какую-либо другую машину или нет? - person 107; 23.06.2015
comment
Cassandra не разделяет строки между узлами, вся строка размещается на одном узле (сейчас не говоря о репликации). Механизм передачи не реализован, так как это значительно снизит производительность. Вы можете прочитать эту статью для получения более подробной информации о секционировании и репликации: datastax.com/resources /tutorials/partitioning-and-replication - person medvekoma; 24.06.2015