Данные временных рядов в Кассандре, пространство ключей в месяц вместо одного пространства ключей?

Question

У нас есть тысячи датчиков, которые производят данные временных рядов измерений, которые мы хотим сохранить в Кассандре. В настоящее время мы храним ~500 миллионов записей в день, в следующий раз эта сумма будет расти в 5-10 раз.

В основном мы работаем с самыми последними данными измерений. Старые данные измерений едва читаются.

• Мы в основном читаем из самых современных измерений (например, одна неделя),
• более старые измерения (т. е. возраст менее месяца) читаются очень редко (десять раз в неделю),
• очень старые измерения (т. е. возраст 1-6 месяцев) читаются очень редко (один раз в месяц),
• измерения старше 6 месяцев считаются холодными, т.е. никогда не считываются.

В качестве стратегии уплотнения мы используем DTCS. Установка ttl не является опцией, потому что нам нужно хранить данные измерений для целей архивирования.

Я пока не уверен, как бороться с тем, что "старые данные почти холодные".

Обновление: чего я хочу избежать: наличие 20 ТБ в моем кластере Cassandra, где используются 18 ТБ, скажем, только один раз в год, если вообще. Я не хочу платить за 18 ТБ, которые не нужны. Установка ttl не является опцией, потому что мы должны иметь возможность читать данные, например, с марта 2013 года (дополнительная плата за такой запрос в порядке). Если мы установим ttl, например, на 6 месяцев, то мы не сможем сделать это должным образом.

В настоящее время мы оцениваем два варианта дизайна и ищем наиболее экономически эффективные:

1. Одно пространство клавиш, с ключом разделения (датчик_ид, дата измерения)
2. Одно пространство ключей в месяц с одним и тем же ключом разделения (sensor_id, measure_date)

(в обоих случаях у нас будет не более 500 тыс. столбцов в строке, в основном менее 100 тыс.)

Недостаток 2. состоит в том, что у нас будет<100 пространств клавиш вместо 1, а сложность при чтении данных увеличится. Преимущество 2. заключается в том, что мы можем снимать / резервировать / удалять / восстанавливать их ежемесячно, что, насколько я понимаю, не может быть легко выполнено, если мы перейдем к варианту 1. Таким образом, нам не нужно изменять размер нашего Кассандра кластер для хранения терабайтов данных, которые на самом деле холодно.

Мой вопрос:2. Является ли 2. разумным вариантом для нашего варианта использования, или это считается анти-паттерном в Кассандре?

Спасибо за помощь!

Answer 1

Как правило, вы не захотите хранить старые холодные данные в отдельном пространстве ключей, так как их будет сложно поддерживать (как вы упоминали). Прямо сейчас вы бросаете вызов очень широким строкам из-за того, как вы разбиваете данные. Вместо этого я хотел бы предложить вам "данные" по месяцам. Это можно сделать, изменив ключ раздела следующим образом:

PRIMARY KEY ((year,month,sensor_id), measurement_date)

Дополнительными скобками являются синтаксис CQL для объявления нескольких столбцов в качестве ключа раздела. Это означает, что вам всегда нужно будет указывать год, месяц и sensor_id для чтения из этой таблицы. Однако помните, что в Cassandra Primary Keys (в отличие от реляционных баз данных) определяют, как ваши данные распределяются по кластеру. Таким образом, эффективно то, что мы делаем, это собираем данные о датчиках по месяцам в отдельной строке. Следовательно, мы в основном достигаем того, о чем вы думали, используя несколько пространств клавиш, но гораздо более дружественным образом для Cassandra и Developer.

Вставить данные в эту таблицу будет довольно просто. Предполагая, что измерение_даты - это timeuuid (в противном случае вы, возможно, перезаписываете данные), вот общий поток, который будет выполнять ваш код:

1. Создать timeuuid (UUIDv1) для текущего времени
2. Из timeuuid получим части года и месяца

3. Затем выполните ваш CQL для INSERT:

   • INSERT INTO time_series (год, месяц,sensor_id, measure_date) VALUES (2016,4,'sensor_id','сгенерированный timeuuid здесь');

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

Поскольку вы записываете 500 тыс. Измерений в день, вам понадобится дополнительно собрать эти данные (см. Выше ответ SO для получения дополнительной информации), поскольку обычно C* начинает работать плохо, когда столбец кластеризации превышает отметку 10 тыс.

Наконец, вы можете прочитать " Оптимизация холодных таблиц SS", поскольку в них содержится полезная информация. Например, вы можете настроить cold_reads_to_omit, чтобы не тратить время на сжатие очень холодных таблиц. Для DTCS вы можете установить max_sstable_age_days, чтобы прекратить сжатие таблиц SS определенного возраста, чтобы сохранить IO на холодных столах.

Обновление: Управление размером хранилища: Если вы хотите использовать только одну таблицу для всего, есть несколько вещей, которые вы можете настроить. Сначала убедитесь, что в таблице используется сжатие (в идеале lz4), затем вы можете снизить коэффициент репликации, что также сэкономит место. Я полагаю, если бы у вас были разные пространства ключей для старых и новых данных, вы могли бы иметь разные RF для каждого, чтобы сэкономить пространство.

Для объема данных, которые вы загружаете и нуждаетесь в архиве, я бы рекомендовал изучить базы данных временных рядов (TSDB), такие как Graphite и InfluxDB. Для ваших целей и задач TSDB будет намного проще в использовании и использовании, чем массирование Cassandra для создания данных временных рядов.

Answer 2

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

Хотя резервное копирование данных с использованием моментальных снимков не работает ежемесячно, как предполагалось, вы, вероятно, можете использовать инкрементное резервное копирование с пользовательским решением, которое будет хранить сбрасываемые sstables в течение одного месяца. Для отбрасывания данных использование TTL по-прежнему будет наиболее распространенным способом обработки данных временных рядов и проверки того, что на диске не хватает места.