Cassandra Wide Vs Skinny Rows для больших столбцов

Мне нужно вставить 60 ГБ данных в кассандру в день.

Это разбивается на
100 наборов ключей
150 000 ключей за комплект
4 Кбайт данных на ключ

С точки зрения производительности записи мне лучше использовать 1 строка в наборе с 150 000 клавиш в строке
10 строк в наборе с 15 000 клавиш в строке
100 строк в наборе с 1 500 ключами на строку

1000 строк в наборе с 150 ключами на строку

Еще одна переменная, которую следует учитывать, мои данные истекают через 24 часа, поэтому я использую TTL = 86400 для автоматизации истечения срока действия

Более подробные сведения о моей конфигурации:

CREATE TABLE stuff (
  stuff_id text,
  stuff_column text,
  value blob,
  PRIMARY KEY (stuff_id, stuff_column)
) WITH COMPACT STORAGE AND
  bloom_filter_fp_chance=0.100000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=39600 AND
  read_repair_chance=0.100000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'tombstone_compaction_interval': '43200', 'class': 'LeveledCompactionStrategy'} AND
  compression={'sstable_compression': 'SnappyCompressor'};

Сведения о шаблоне доступа:
Значение 4KB представляет собой набор из 1000 4 байтовых поплавков, упакованных в строку.

Типичный запрос потребует случайного выбора 20-60 из этих поплавков.

Первоначально эти поплавки хранятся в одной и той же логической строке и столбце. Логическая строка здесь представляет собой набор данных в данный момент времени, если все они записаны в одну строку с 150 000 столбцов.

С течением времени некоторые данные обновляются, в пределах логической строки в наборе столбцов будет обновляться случайный набор уровней внутри упакованной строки. Вместо обновления на месте новые уровни записываются в новую логическую строку в сочетании с другими новыми данными, чтобы избежать перезаписи всех данных, которые все еще действительны. Это приводит к фрагментации, поскольку теперь необходимо получить доступ к нескольким строкам, чтобы получить этот набор значений 20-60. Теперь запрос будет обычно считываться из одного столбца в 1-5 разных строк.

Метод тестирования Я написал 5 выборок случайных данных для каждой конфигурации и усреднил результаты. Ставки были рассчитаны как (Bytes_written/(время * 10 ^ 6)). Время измерялось в секундах с точностью до миллисекунды. Pycassa использовался как интерфейс Cassandra. Использовался оператор партии Pycassa. Каждая вставка вставляет несколько столбцов в одну строку, размеры вставки ограничены до 12 МБ. Очередь размывается до 12 МБ или меньше. Размеры не учитывают служебные данные строк и столбцов, а также данные. Источник данных и приемник данных находятся в одной сети в разных системах.

Записать результаты Имейте в виду, что в игре есть ряд других переменных из-за сложности конфигурации Cassandra.
1 строка 150 000 ключей в строке: 14 Мбит/с
10 строк 15 000 ключей в строке: 15 Мбит/с
100 строк 1,500 ключей в строке: 18 Мбит/с
1000 строк 150 клавиш в строке: 11 Мбит/с

Ответ 1

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

Широкая строка (1 строка для каждого набора): это может быть лучшим решением, поскольку оно предотвращает одновременное попадание нескольких узлов одновременно, а также со вторичными индексами или составными именами столбцов, вы можете быстро фильтровать данные в соответствии с вашими потребностями. Это лучше всего, если вам нужно получить доступ к одному набору данных для каждого запроса. Однако выполнение слишком большого количества мультигетов в широких рядах может увеличить давление памяти на узлах и ухудшить производительность.
Тощий ряд (1000 строк в наборе): С другой стороны, широкая строка может вызвать чтение горячих точек в кластере. Это особенно актуально, если вам нужно сделать большой объем запросов для подмножества данных, который существует полностью в одной широкой строке. В таком случае тощий ряд будет распределять ваши запросы более равномерно по всему кластеру и избегать горячих точек. Кроме того, по моему опыту, "более тонкие" ряды имеют тенденцию лучше себя вести с помощью мультигетов.

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

Ответ 1

Ответ 2