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

В настоящее время мы исследуем 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);

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

Источник

2 ответа

Согласно учебному пособию, если мы выберем в качестве единственного раздела weather_station_id, строка будет исчерпана. т.е. 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)

Надеюсь, поможет!

Источник

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

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

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

  • Еще один небольшой совет: Кассандра не похожа на MySQL. Это денормализованная база данных. Это означает: не грязно сохранять ваши данные более одного раза. Это означает: для вас важно запрашивать ваши данные за год, также важно запрашивать ваши данные за час, за день года или за sensor_id, вы можете создавать семейства столбцов с другим ключом раздела и порядком ключей parimary. Можно дублировать ваши данные. Cassandra оптимизирована для производительности записи, а не для чтения. Это означает: часто лучше записывать данные в правильном порядке, чем читать их в правильном порядке. В Cassandra 3.0 появилась новая функция, называемая материализованными представлениями, для автоматического дублирования. И если вы думаете: оооо, я дублирую необходимое хранилище. Помните: хранение действительно дешево. Можно купить десять жестких дисков по 1 ТБ. Это ничего не стоит. Производительность важна.

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

Источник
Другие вопросы по тегам