Моделирование данных временного ряда Cassandra и ограничение размера раздела

Question

В настоящее время мы изучаем Cassandra как базу данных для большой системы временных рядов.

Я прочитал https://academy.datastax.com/resources/getting-started-time-series-data-modeling о моделировании временных рядов данных в Кассандре.

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

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

Мы хотели бы, чтобы на каждый (weather_station_id, year, day_of_year) была одна строка, то есть новая строка для каждого дня. Однако мы все еще хотим, чтобы ключ раздела был weather_station_id, то есть мы хотим, чтобы все показания для станции находились на одном узле.

В настоящее время мы имеем следующую схему, но я хотел бы получить некоторую обратную связь.

CREATE TABLE weather_station_data (
    weather_station_id int, 
    year int, 
    day_of_year int, 
    time timestamp, 
    sensor_id int, 
    temperature int, 
    humidity int, 
    light int, 
    PRIMARY KEY ((weather_station_id), year, day_of_year, time, sensor_id) 
) WITH CLUSTERING ORDER BY (year DESC, day_of_year DESC, time DESC,  sensor_id DESC); 

В вышеупомянутом документе они используют эту концепцию «предельная разбивка по дате». Однако мне непонятно, является ли дата в их примерах частью ключа раздела.

Answer 1

Согласно руководству, если мы выберем, чтобы weather_station_id был единственным разделом, строка будет исчерпана. i.e C * имеет практическое ограничение в 2 миллиарда колонок на раздел.

Так что ИМО, ваша модель данных плохая.

Однако мне непонятно, является ли дата в их примерах частью ключа раздела.

В учебнике используется

PRIMARY KEY ((weatherstation_id,date),event_time)

Так что, да, они считаются данные, чтобы быть частью ключа секционирования.

Мы хотим, чтобы все показания станции находились на одном узле.

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

select * from weather_station_data where weather_station_id=1234 and year= 2013; select * from weather_station_data where weather_station_id=1234 and year= 2014;

Так следует изменить структуру

PRIMARY KEY ((weather_station_id, year), day_of_year, time, sensor_id)

Надеется, что это помогает!

Answer 2

На мой взгляд, модель datastax на самом деле невелика. Проблема с этой моделью:

• Они используют метеостанцию ​​в качестве ключа раздела.Все строки с одним и тем же ключом разделяются на одном компьютере. Это означает: если у вас есть 10-летние необработанные данные (шаги 100 мс), вы быстро прекратите ограничение кассандры. 10 лет × 365 дней × 24 часа × 60 минут × 60 секунд x 10 (для шагов 100 мс) x 7 столбцов. Предел составляет 2 миллиарда. По моему мнению, вы не будете использовать преимущества cassandra, если будете строить эту модель данных. Вы также можете использовать для каждой метеорологической станции mongo, mysql или другую базу данных.

Лучшее решение: спросите себя, как вы будете запрашивать эти данные. Если вы скажете: я запрашиваю все данные в год, используйте год также в качестве ключа partion. Если вам нужны также данные запроса более одного года, вы можете создать два запроса с другим годом. Это работает, и производительность лучше. (Узким местом может быть только сеть для вашего клиента)

• Еще один пример: Cassandra не похож на mysql. Это денормализованная база данных. Это означает: не рекомендуется сохранять данные более одного раза. Это означает: важно, чтобы вы запрашивали свои данные в год, также важно запрашивать данные в час, в день года или на датчик_ид, вы можете создавать семейства столбцов с разным ключом раздела и порядком подписи по методу parimary. Вы можете дублировать свои данные. Cassandra оптимизирован для производительности записи, а не для чтения. Это означает: часто лучше записывать данные в правильном порядке, а не читать в правильном порядке. В cassandra 3.0 есть новая функция, называемая материализованными видами, для автоматического дублирования. И если вы думаете: Ohhh no, я продублирую необходимое хранилище. Помните: Хранение действительно дешево. Это нормально купить десять жестких дисков с 1tb. Это ничего не стоило. Эффективность важна.

У меня есть один вопрос: можете ли вы объединить свои данные? У Cassandra есть тип столбца, называемый счетчиком. Вы можете создать приложение java/scala, в котором будут объединены ваши данные во время их создания. Для этого вы можете использовать инфраструктуру потоковой передачи: Flink или Spark. (Если вам нужно немного больше, чем только подсчет.). Один сценарий: вы суммируете свои данные за каждый час и день. Вы получили свои данные в своем потоковом приложении. Теперь: у вас есть переменная для почасовых данных. Вы подсчитываете вверх или вниз или что-то еще. Если час заканчивается, вы помещаете эту строку в свою часовую фамилию и ежедневное семейство столбцов. В своей ежедневной семье вы используете счетчик. Надеюсь, вы понимаете, что я имею в виду.