Стратегия разделения Cassandra для систем с перекошенным трафиком - PullRequest
Новая
       35

Стратегия разделения Cassandra для систем с перекошенным трафиком

0 голосов
/ 29 ноября 2018

Пожалуйста, потерпите немного дольше описания проблемы.Я новичок в мире Cassandra и пытаюсь перенести свой текущий продукт с уровня данных на основе Oracle на Cassandra.

Для поддержки запросов диапазона я создал сущность, как показано ниже: 

create table if not exists my_system.my_system_log_dated(
  id uuid,
  client_request_id text,
  tenant_id text,
  vertical_id text,
  channel text,
  event text,
  event_type text,
  created_date date,
  primary key((created_date, tenant_id, vertical_id, channel, event), 
  event_type, client_request_id, id)
) with clustering order by (created_date desc);

Теперь я натолкнулся на несколько документов / ресурсов / блогов, в которых упоминается, что я должен сохранить свой разделразмер менее 100 мб для оптимально работающего кластера.С объемом трафика, который моя система обрабатывает в день для определенных комбинаций ключа разделения, я никак не могу сохранить его менее 100 МБ с указанным выше ключом разделения.

Чтобы исправить это, я ввел новый фактор под названиемbucket_id и думал о том, чтобы присвоить ему значение часа дня для дальнейшего разбиения разделов на более мелкие куски и хранения их менее 100 МБ (хотя это означает, что мне нужно сделать 24 чтения, чтобы обслуживать детали трафика в течение одного дня, но я в порядке снекоторая неэффективность в чтениях).Вот схема с идентификатором сегмента 

 create table if not exists my_system.my_system_log_dated(
  id uuid,
  client_request_id text,
  tenant_id text,
  vertical_id text,
  channel text,
  event text,
  bucket_id int,
  event_type text,
  created_date date,
  primary key((created_date, tenant_id, vertical_id, channel, event, 
  bucket_id), event_type, client_request_id, id)
) with clustering order by (created_date desc);

Даже при этом пара комбинаций выходит за пределы более 100 мб, в то время как весь другой объем удобно лежит в пределах диапазона.

С учетом этой ситуацииУ меня есть следующие вопросы:

  1. Абсолютно ошибочно ли иметь несколько ваших разделов, выходящих за пределы ограничения в 100 МБ?
  2. Хотя с еще меньшим объемом, скажем, 15-минутное окно, я получаю всекомбинации ключей разделов до 100 МБ, но это также создает сильно перекошенные разделы, а это означает, что объемные комбинации ключей разделов увеличиваются до 80 МБ, а оставшиеся один раз значительно меньше 15 МБ.Это что-то, что отрицательно скажется на производительности моего кластера?
  3. Есть ли лучший способ решения этой проблемы?

Вот еще некоторая информация, которая, по моему мнению, может быть полезна:

  • Средний размер строки для этого объекта составляет около 200 байтов
  • Я также рассматриваю фактор подтверждения будущей нагрузки, равный 2, и оцениваю удвоенную нагрузку.
  • Пиковая нагрузкадля конкретной комбинации ключ раздела составляет около 2,8 миллиона записей в день
  • . В той же комбинации час пик трафика составляет около 1,4 миллиона записей
  • , а в окне 15 минут - около 550 000 записей..

Заранее спасибо за ваш вклад !!

1 Ответ

0 голосов
/ 30 ноября 2018

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

  1. Нет, это не жесткий предел, и на самом деле, он может быть слишком низким, учитывая усовершенствования оборудования за последние несколько лет.Я видел разделы 2 ГБ и 5 ГБ (хотя они могут причинить вам много головной боли при выполнении ремонта), но это крайние случаи.Не подходи к этим ценностям.В итоге, если вы не уйдете выше этих 100 МБ, все будет в порядке.Если у вас есть как минимум 15 ГБ оперативной памяти, используйте G1GC, и вы отлично справляетесь.
  2. Равномерное распределение по размерам разделов важно для поддержания сбалансированной загрузки данных по всему кластеру, а также для того, чтобы выВы уверены, что ваши запросы будут иметь среднюю задержку (поскольку они будут считывать приблизительные данные одинакового размера), но это не то, что само по себе создаст проблемы с производительностью.
  3. Подход выглядит хорошо, но если это временной ряд, который, я думаю, учитывает то, что вы сказали, то я рекомендую вам использовать TWCS (стратегию сжатия временного окна) в my_system.my_system_log_dated.Проверьте, как настроить эту стратегию сжатия, потому что установленное вами временное окно будет очень важным.
...