Высокая задержка чтения в cassandra

Я использую cassandra 2.1.12 в кластере из трех машин, каждая из которых имеет 32 ГБ ОЗУ и 4 ядра (на Amazon AWS).

Я использую всю конфигурацию cassandra по умолчанию.

Я использую его для анализа событий на своем веб-сайте (данные временных рядов), имея ежедневные данные около 1 ГБ с коэффициентом репликации 3.

Мои данные выросли примерно до 85 ГБ на каждой машине, теперь задержка чтения составляет около 4.5 s (4000 ms).

Мои строки редко обновляются. Итак, я не использую уплотнение LevelOrder. И мои записи работают хорошо с задержкой около .03ms

Отредактировано:

Вот определение ColumnFamily:

CREATE TABLE TimeSeriesData(
logyear int,
logmonth int,
logdate int,
logdatetime timestamp,
cookie text,
sessionid text,
...
PRIMARY KEY (logyear, logmonth, logdate, logdatetime, cookie)
) WITH CLUSTERING ORDER BY (logmonth ASC, logdate ASC, logdatetime ASC, cookie ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';

Идя по моему ключу раздела, который в настоящее время является logyear. Итак, все мои данные будут в одном разделе. Сказав, что разделитель отвечает за распределение групп строк (по ключу раздела) между узлами в кластере.

В этом случае это будет один единственный узел или нет?

Кроме того, почему задержка чтения была очень низкой, несмотря на чтение данных из одного раздела?

Может ли один SSTable иметь несколько разделов и наоборот?

Я использую org.apache.cassandra.dht.RandomPartitioner.
Кроме того, каким должен быть ключ незанятого раздела для семейства столбцов, как указано выше, с инкрементными данными 1 ГБ в день.


person deenbandhu    schedule 15.07.2016    source источник
comment
пожалуйста, добавьте уровень согласованности и дамп трассировки. Это может помочь другим   -  person undefined_variable    schedule 15.07.2016
comment
Я добавил больше деталей. Не могли бы вы взглянуть на это.   -  person deenbandhu    schedule 18.07.2016


Ответы (1)


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

Наиболее вероятным объяснением является высокий уровень сбора мусора из-за плохой модели данных. Тем не менее, вы дали нам очень мало, чтобы продолжать.

Посмотрите на nodetool cfstats — соответствуют ли задержки в cfstats тем задержкам, которые вы видите? Какой максимальный размер раздела?

person Jeff Jirsa    schedule 15.07.2016
comment
если это проблема высокой сборки мусора, то я думаю, что моя запись также повлияла бы, но это не так. - person deenbandhu; 15.07.2016
comment
моя статистика cf теперь показывает задержку чтения около 23481 мс Минимальные байты сжатого раздела: 43388629 Максимальные байты сжатого раздела: 158683580810 Средние байты сжатого раздела: 19049359054 - person deenbandhu; 15.07.2016
comment
У вас неправильная модель данных — эти размеры разделов неразумны, и, честно говоря, я шокирован тем, что вы вообще можете что-то читать. - person Jeff Jirsa; 15.07.2016
comment
так как контролировать размер этих разделов - person deenbandhu; 15.07.2016
comment
Вам нужно прочитать о моделировании данных в Cassandra - вам нужно будет перераспределить нагрузку по разделам - person Jeff Jirsa; 15.07.2016
comment
Наличие года в качестве ключа раздела означает, что все ваши данные за данный год поступают на узлы RF (3 узла), но все они хранятся в одном логическом блоке (разделе/строке). Причина его медленности заключается в том, что внутри cassandra выполняет некоторые неидеальные вещи, такие как десериализация индекса для всей строки, когда вы читаете любую из них — с ОГРОМНЫМИ строками время, необходимое для десериализации этого индекса, увеличивается (и это создает мусор JVM, который вызывает паузы). Вы должны ограничить свои разделы несколькими сотнями мегабайт (менее миллиона записей), если вы не используете 3.6 или выше. - person Jeff Jirsa; 18.07.2016
comment
Спасибо за объяснение. Я также хотел бы знать, есть ли какая-либо связь между SStables и разделом, например, может ли один SSTable иметь несколько разделов и наоборот? заранее спасибо - person deenbandhu; 19.07.2016
comment
Я читал о моделировании данных, которое в основном сосредоточено на двух целях: 1. Сохранить размер раздела около 100 МБ и попытаться прочитать как можно более низкий раздел для одного запроса. теперь в моем случае мои ежедневные данные составляют около 1 ГБ, поэтому мне нужно разделить с каким-то другим сегментом, чтобы ограничить размер раздела, и во время извлечения мне нужно прочитать данные за весь день в одном запросе, поэтому какую модель данных я должен применить здесь - person deenbandhu; 19.07.2016
comment
Совет сохранить размер раздела около 100 МБ гораздо важнее, чем совет получить как можно больше данных за один запрос. Соблюдайте правило малого размера раздела, и тогда при необходимости вы сможете выполнять несколько запросов на данные одновременно/асинхронно из вашего приложения. Используйте встроенную функцию fetchSize/server-side-paging, чтобы не читать больше, чем необходимо, и просто загружайте данные с сервера по мере их использования. - person Jeff Jirsa; 19.07.2016
comment
Спасибо за такую ​​большую помощь. Я изменил модель данных, теперь каждый раздел будет иметь 100-150 МБ данных. Я создал новую таблицу для предстоящих данных. Есть ли какой-нибудь элегантный способ восстановить старые данные и вставить их в новую таблицу P.S. моя таблица имеет структуру, отличную от предыдущей - person deenbandhu; 20.07.2016