Идеальные параметры/настройки Cassandra для вставки и чтения потоковых данных

Я вставляю потоковые данные в 2 отдельных пространства ключей с вставкой данных в 2 семейства столбцов (стандартных) в первом пространстве ключей и в 3 семейства столбцов (2 стандартных и 1 счетчик) во втором пространстве ключей.

Скорость вставки данных в эти семейства столбцов хорошо контролируется и работает просто отлично [60% использования ЦП и коэффициент загрузки ЦП около 8-10] с чистой записью. Затем я пытаюсь непрерывно считывать данные из этих семейств столбцов через Pycassa API, в то время как записи выполняются параллельно, и я заметил серьезное снижение производительности записи.

Какие системные настройки рекомендуются для параллельной записи + чтения из двух пространств ключей? В настоящее время каталог данных находится на одном физическом диске с RAID10 на каждом узле.

Оперативная память: 8 ГБ

Размер кучи: 4 ГБ

Четырехъядерный процессор Intel Xeon с частотой 3,00 ГГц

Параллельные записи = Параллельные чтения = 16 (в файле cassandra.yaml)

Модель данных

Keyspace1: я вставляю данные временного ряда с отметкой времени (T) в качестве имени столбца в широкий столбец, в котором хранятся данные за 24 часа в одной строке.

CF1:

    Col1    |   Col2    |   Col3(DateType)  |   Col(UUIDType4)  |

RowKey1

RowKey2

:

:

CF2 (широкое семейство колонок):

RowKey1 (T1, V1) (T2, V3) (T4, V4) ......

RowKey2 (T1, V1) (T3, V3) .....

:

:

Пространство ключей2:

CF1:

    Col1    |   Col2    |   Col3(DateType)  |   Col4(UUIDType)  |   ...  Col10

RowKey1

RowKey2

:

:

CF2 (широкое семейство колонок):

RowKey1 (T1, V1) (T2, V3) (T4, V4) ......

RowKey2 (T1, V1) (T3, V3) .....

:

:

CF3 (семейство счетчиков):

Подсчитывает возникновение каждого события, хранящегося в CF2.

Данные непрерывно считываются из Keyspace 1 и 2, только CF2 (широкие семейства столбцов). Просто повторюсь, чтение и запись происходят параллельно. Количество запрошенных данных постепенно увеличивается с 1 до 8 строковых ключей с помощью multiget, и этот процесс повторяется.


cassandra datastax datastax-enterprise pycassa
person vinay sudhakar    schedule 11.02.2014    source источник
comment
Можете ли вы предоставить подробную информацию о вашей модели данных и о том, что делают операции записи и чтения (особенно чтения)?   -  person Tyler Hobbs    schedule 12.02.2014
comment
Отредактировал исходный запрос с моделью данных.   -  person vinay sudhakar    schedule 12.02.2014
comment
Спасибо. Сначала я пропустил это, но ваш журнал фиксации находится на том же RAID, что и данные? Это может частично объяснить воздействие; проверить диск утилитой. В противном случае взгляните на загрузку ЦП и активность сборщика мусора.   -  person Tyler Hobbs    schedule 13.02.2014
comment
Журнал фиксации и данные находятся на разных физических дисках. Использование диска и дисковая очередь выглядят нормально. Мы уменьшили размер буфера в вызове функции pycassa multiget, и, похоже, она работает нормально! Ставим стресс тест на 24-48 часов, надеюсь продержится. Загрузка ЦП сейчас составляет около 60-70% на всех узлах. Вызов multiget всегда оказывается неэффективным при более высоких степенях параллелизма. Время переписать клиент по-другому!   -  person vinay sudhakar    schedule 13.02.2014
comment
Количество ожидающих операций записи и количество ожидающих сжатий значительно увеличивается на одном конкретном узле, после чего он перестает принимать записи. Влияет ли непрерывное чтение на уплотнение в типичном сценарии смешанной рабочей нагрузки (чтение+запись)? Я использую Кассандру 1.2.3.   -  person vinay sudhakar    schedule 14.02.2014
comment
Единственное влияние, которое это оказывает, заключается в том, что диски (и Cassandra) становятся более загруженными. Я бы обновился до 1.2.15, там много хороших улучшений. Кроме того, если вы считаете, что на этот вопрос дан ответ, не забывайте, что вы можете написать свой собственный ответ и принять его.   -  person Tyler Hobbs    schedule 19.02.2014

Ответы (1)


arrow_upward
0
arrow_downward

Возможные пути решения проблемы:

  1. Увеличено пространство, выделенное молодому поколению, как рекомендовано в этом сообщении блога: http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads

  2. Сделал небольшие обновления схемы и удалил ненужные вторичные индексы. Это уменьшило накладные расходы на уплотнение.

  3. Уменьшено время ожидания записи до 2 с в cassandra.yaml, как было рекомендовано в моем предыдущем посте: streaming-data">Серьезное снижение производительности Cassandra Write при непрерывной потоковой передаче данных

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

person vinay sudhakar    schedule 23.02.2014