Размер раздела Cassandra и количество разделов при обработке большой части таблицы

Question

У меня есть набор данных в базе данных кассандры, где каждая запись должна обрабатываться один раз в месяц (в основном, ежемесячная подписка). Процесс выполняется каждый день, поэтому данные делятся на 31 части, которые обрабатываются каждый день. Я пытаюсь создать ключ раздела, чтобы избежать фильтрации всего набора данных.

Первое решение - назначить ключ раздела, основанный на дне месяца. Это означает, что у меня есть фиксированное количество разделов (31), которые я могу обрабатывать каждый день. Но проблема в том, что со временем размер данных будет увеличиваться, но количество разделов останется прежним, и я могу столкнуться с проблемами производительности из-за слишком широких строк.

Другое решение состояло бы в том, чтобы вообще не иметь дело с этой проблемой и обрабатывать всю таблицу, используя Apache Spark каждый день (в основном, выбирайте 1/31 данных, используя Spark-фильтрацию). Со временем данные будут увеличиваться, но узлы в кластере также будут увеличиваться, и у меня может быть постоянная производительность. Но все рекомендации против фильтрации данных в Кассандре.

Максимальное количество строк, которое теоретически возможно иметь в этом случае, составляет около 1 млрд.

Какие будут рекомендации?

Answer 1

Как вы подозреваете, планирование всего 31 раздела - очень плохая идея для производительности. Основная проблема заключается в том, что база данных не может масштабироваться: когда RF = 3, будет не более 93 (при маловероятно оптимальных условиях) 93 узлов, которые имеют какие-либо данные, поэтому вы не можете масштабироваться до более крупного кластера. С Scylla (который делит данные далее на ядро) вы не сможете масштабировать кластер за пределы 93 ядер. Вторая проблема заключается в том, что Cassandra не имеет очень эффективной индексации для чтения из огромных разделов, и чтение становится медленнее, когда отдельный раздел становится огромным.

Компромиссом может быть использование не только 31 раздела, но вместо этого - 31 * K для некоторого К. Например, возможно иметь раздел в час, а не в день. Или 100 разделов на каждый день. Вам нужно будет найти способ последовательно решить, какая запись принадлежит какому из этих разделов, но я думаю, что у вас уже есть один (в настоящее время он назначает записи для 31 раздела - все, что вам нужно изменить, - это назначить его 31 * K разделам ). Это просто означает, что каждый день вам нужно сканировать вместо одного раздела K отдельных разделов, но это тривиально.

Наконец, поскольку число «31» относительно мало, у вас есть еще один вариант - использовать 31 отдельную таблицу. Это позволит вам сканировать каждую таблицу отдельно. Я не знаю, какие другие запросы вам нужно выполнить, но если они не должны пересекать границы таблиц, разумным подходом является разбиение на 31 таблицу.