Давление сокоординатора с использованием запроса IN для одного ключа раздела с 9000 записей размером 4 МБ на размер раздела

Question

У меня 1000 разделов на таблицу, cust_id - ключ раздела, а bucket_id и timestamp - ключи кластера. Каждый час записывается одна запись bucket_id и timestamp для каждого cust_id.

• Каждый день будет записываться 24 * 1 = 24 строки на раздел.
• Один год около 9000 записей на раздел.
• Размер раздела составляет около 4 МБ.

---> 20 узлов Cassandra кластер один D C и RF = 3

Я хочу выбрать случайные пять сегментов для данных за последние 90 дней, используя запрос IN.

select cust_id,bucket_id,timestamp from customer_data where 
   cust_id='tlCXP5oB0cE2ryjgvvCyC52thm9Q11KJsEWe' and 
   bucket_id IN (0,2,5,7,8)  
   and timestamp >='2020-03-01 00:00:00' and 
   timestamp <='2020-06-01 00:00:00';

Пожалуйста, подтвердите, вызывает ли этот подход какие-либо проблемы с давлением координатора и таймаутами запроса? Сколько данных может хранить координатор и возвращать данные без каких-либо проблем?

Как (внутренне) IN-запрос сканирует записи на Cassandra? Пожалуйста, предоставьте какое-нибудь подробное объяснение.

Если я выполню такой же запрос для 10-ти миллионов клиентов, влияет ли это на давление координатора? Увеличивает ли это вероятность получения ошибки тайм-аута при чтении?

Answer 1

Может быть трудно получить окончательный ответ да / нет на эти вопросы - в них есть некоторые неизвестные. Например, какая версия Cassandra, какой объем памяти выделен, например, какие диски используются для данных, какая стратегия сжатия используется для таблицы, какой уровень согласованности вы используете для чтения данных и т. Д. c.

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

Относительно клиентов 10Mil - в вашем запросе вы выбираете по ключу раздела, поэтому запрос обычно отправляется реплике напрямую (если вы используете подготовленные заявления). Чтобы избежать проблем, вы не должны делать IN для столбца ключа раздела (cust_id в вашем случае) - если вы делаете запросы для отдельных клиентов, драйвер будет распределять запросы по всему кластеру, и вы избежите повышенного давления на узлы-координаторы .

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

Answer 2

Пожалуйста, попробуйте задать один вопрос на вопрос.

Что касается того, сколько может обрабатывать узел-координатор, Алекс прав в том, что этому способствуют несколько факторов.

• Размер набора результатов.
• Куча / ОЗУ доступна на узле-координаторе.
• Согласованность сети между узлами.
• Конфигурация хранилища (вращение, SSD, NFS и т. Д.) 1053 *).

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

Как (внутренне) IN-запрос сканирует записи на Cassandra? Пожалуйста, предоставьте любое подробное объяснение.

Исходя из вашего описания, определение первичного ключа должно выглядеть следующим образом:

PRIMARY KEY ((cust_id),bucket_id,timestamp)

Данные будут сохраняться на диске по разделам и сортироваться по ключам кластера, подобным этому (при условии возрастания в bucket_id и убывания в timestamp:

cust_id                                bucket_id timestamp
'tlCXP5oB0cE2ryjgvvCyC52thm9Q11KJsEWe' 0         2020-03-02 04:00:00
                                                 2020-03-01 22:00:00
                                       1         2020-03-27 16:00:00
                                       2         2020-04-22 05:00:00
                                                 2020-04-01 17:00:00
                                                 2020-03-05 22:00:00
                                       3         2020-04-27 19:00:00
                                       4         2020-03-27 17:00:00
                                       5         2020-04-12 08:00:00
                                                 2020-04-01 12:00:00

Cassandra читает файлы SSTable в этом порядке. Важно помнить, что Cassandra читает последовательно с диска. Когда запросы вынуждают его выполнять случайное чтение, именно тогда вещи могут начать становиться немного медленнее. Путь чтения имеет структуры, такие как смещения разделов и фильтры Блума, которые помогают ему выяснить, какие файлы (и где внутри них) содержатся данные. Но в пределах раздела ему нужно будет сканировать ключи кластеризации и выяснить, что пропустить и что вернуть.

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

По крайней мере, вы заставляете его оставаться на одном узле, указав ключ раздела. Но вам придется проверить, сколько координатор может вернуть, прежде чем вызвать проблемы. В общем, я бы не стал указывать двойные цифры элементов в предложении IN.

С точки зрения оптимизации доступа к файлам, у Джона Хаддада (сейчас Apple) есть статья great о это: Apache Cassandra Performance Tuning - Сжатие со смешанными рабочими нагрузками В нем основное внимание уделяется настройкам сжатия таблиц (а именно chunk_length_in_kb) и есть несколько полезных советов о том, как повысить производительность доступа к данным. В частности, раздел «Как данные читаются» представляет особый интерес:

Мы извлекаем куски из SSTables, распаковываем их и возвращаем их клиенту .... Во время пути чтения весь кусок должен быть прочитан и распакован. Мы не можем выборочно читать только те байты, которые нам нужны. Результатом этого является то, что если мы используем блоки 4K, мы можем получить только чтение 4K с диска. Если мы используем куски 256 КБ, нам нужно прочитать все 256 КБ.

Смысл этого ^, относящийся к вашему вопросу, состоит в том, что, пропуская (используя IN), координатор, скорее всего, будет читать данные что он не вернется.