Cassandra Wide Vs Skinny Rows для больших колонок

Question

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

Это распадается на
100 комплектов ключей
150000 ключей в наборе
4KB данных на ключевых

С точки зрения производительности записи я лучше использовать
1 строку для каждого набора с 150,000 ключей в строке
10 строк на наборе с 15000 ключей в строке
100 строк на наборе с 1500 ключей в строке
1000 строк в наборе с 150 ключей в строке

Других переменным рассмотреть, мои данные истекают через 24 часов, так что я использую TTL = 86400 для автоматизации EXPIRATION

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

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 ряд 150000 ключей в строке: 14 Мбит
10 строк 15000 ключей в строке: 15 Mbps
100 строк 1500 ключей в строке: 18 Mbps
1000 строк 150 ключей в строке: 11 Mbps

Answer 1

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

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

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

Answer 2

Вы» d лучше использовать 1 строка за комплект с 150 000 столбцов в строке. Использование TTL - это хорошая идея для процесса автоматической очистки.