Cassandra: Пояснение данных датчика большого объема

Question

Мы рассматриваем возможность перехода нашего приложения временных рядов с SQL Server на Cassandra, поскольку объем данных становится слишком большим для обработки SQL Server. У нас может быть до 100 датчиков, работающих одновременно (иногда в течение целого года, иногда короче, но обычно по меньшей мере 50 из них одновременно), и каждый из них способен передавать до 20 различных измерений на частоте до 60 Гц (потенциально 120 в будущем).

Большинство онлайн-ресурсов (например, DataStax) рекомендуют разделять на «управляемые разделы», что, предположительно, составляет менее 1 000 000 строк (на самом деле, что-то ниже 50 МБ, вероятно, является фактическим показателем). Таким образом, на 1 Гц ставки отчетности, разделение каждого количества датчиков на одну неделе будет производить (7 * 24 * 60 * 60) = 604,800 измерений в раздел:

CREATE TABLE measurements (
    sensor_id  TEXT, 
    quantity  TEXT, 
    start_of_week TIMESTAMP, 
    offset_seconds INT,  -- offset from week start (0..604799) 
    value   FLOAT, 
    PRIMARY KEY ((sensor_id, quantity, start_of_week), offset_seconds) 
) WITH CLUSTERING ORDER BY (offset_seconds DESC) 

Поэтому, естественно, для 60 Гц ставок отчетности я мог бы разделить на час держать его простой и получить (60 * 60 * 60) = 216,000 измерений на раздел. Или несколько часов, конечно.

Однако у меня есть пара неопределенностей в отношении того, как это будет работать на практике.

До сих пор у нас была довольно денормализованная база данных SQL Server, в которой мы бы поместили все 20 значений из одного датчика в одну строку, и сервер смог продолжить работу (хотя с постоянным постоянством процессора ~ 30%), для до 50 устройств (это в основном 3000 рядов в секунду, и мы предполагаем, что SQL Server может max около 10 000 строк/с). Излишне говорить, что это не может масштабироваться вообще, если на каждое устройство добавляются новые количества, и в то же время много пространства теряется для устройств, которые сообщают о менее чем 20 количествах.

Однако, при использовании подхода C *, приведенного выше, количество пар ключей-значений, хранящихся в секунду (предположительно 100 датчиков, 20 измерений, 60 Гц), будет 120 000 в секунду.

1. Возможно ли достичь этого с помощью «базовой» установки 3 узлов? Сколько узлов Кассандры необходимо на практике, для таких ставок вставки?

2. Будет ли перемещать все значения подсетей (60 Гц) для одной величины в один blob улучшить производительность? Это будет означать, что общая скорость ввода будет равна 2 000 blobs, что кажется гораздо более управляемым (и даже размер блоба 240 байтов для 60 значений float32 не кажется таким огромным).

Большую часть времени данные будут отображаться из другой таблицы, которая удерживает предварительно вычисленные мин/макс/среднее агрегаты (пользователь может создать запрос диапазона с полным разрешением в любое время, но и для меньших диапазонов), поэтому наш акцент делается на максимальную пропускную способность записи. Если вы считаете, что любая другая схема может обеспечить лучшую пропускную способность (у меня нет подсказки, возможно, нескольких таблиц/некоторых других стратегий разбиения на разделы/кластеризации), пожалуйста, предложите. Мы даже открыты для перехода на другую базу данных NoSQL, если она может лучше соответствовать нашим требованиям.

Answer 1

Можно ли достичь этого с помощью «базовой» установки 3-х узлов? Сколько узлов Кассандры необходимо на практике, для таких ставок вставки?

120 000 в секунду с кластером из 3 узлов, конечно, возможно, но это зависит от вашего оборудования. Я ожидал бы 20k-30k/sec с обычными экземплярами. Правило большого пальца, которое я придерживаюсь, составляет 4k/sec/core, но его аппаратное и зависящее от нагрузки.

Будет ли перемещение всех значений в секунду (60 Гц) для одного количества в один блок улучшать производительность? Это будет означать, что общая скорость ввода будет составлять 2000 калорий, что кажется гораздо более управляемым (и даже размер блоба 240 байтов для 60 значений float32 не кажется таким огромным).

Да, это поможет увеличить пропускную способность.

Некоторые примечания:

Убедитесь с этим видом загрузки клиент выполняет ваши запросы эффективно или вы можете увидеть узкие места там. Хорошая идея - создание асинхронных вставок и обратное давление на основе запросов на полет. Существует пакетная обработка, но она эффективна только в том случае, если все записи переходят в один раздел. Так что, если у вас есть 60 показаний для второго и вставляют их все в один раздел, быстрее будет делать разблокированный пакет. Записанные партии будут значительно медленнее. Есть точка, что это заканчивается тем, что ухудшается для производительности, но число разных для разных рабочих нагрузок, поэтому может хотеть играть с ним.

Я бы порекомендовал стратегию сжатия временных окон (TWCS) для этой рабочей нагрузки.

В версиях 2.x 100 МБ на раздел - это хороший предел, чтобы попытаться остаться под ним. В более поздних версиях 3.x и будущих выпусках 4.x вы намного безопаснее еще выше (т.е. gb). Тем не менее, разделы по-прежнему являются самыми низкими, поэтому, если они становятся слишком большими, они все равно могут привести к горячим точкам, и это делает вещи вроде ремонта намного менее эффективными. Следите за максимальным/средним размером раздела таблицы при мониторинге.

С offset_seconds, что на самом деле лучше быть полной меткой времени. Когда вы читаете, он проверяет ключи кластеризации min/max против того, что запрашивается, чтобы определить, какой sstable для чтения. Каждый sstable хранит ключ минимальной/максимальной кластеризации для оптимизации временных рядов. Если у вас есть TWCS, и вы запрашиваете диапазон времени, он сможет сузить sstables только до соответствующих. В противном случае это, вероятно, будет включать многие из них, поскольку смещения будут сброшены в каждом ковше и будут перекрываться. Фильтр цветения должен улавливать некоторые из них с разными ключами разделов, но он будет иметь ложные срабатывания и требует проверки фильтров цветения на всех sstables (это делается после выбора из min/max и далек от свободного). Это может показаться немного расточительным для космоса, но это улучшит чтение.