Переход с timescaledb на influxdb — как организовать данные? (много точек данных, каждый запрос получает все данные по заданному идентификатору устройства)

В настоящее время я использую базу данных временной шкалы с одной таблицей (timestamp, device_id, group_id, data jsonb). Я рассматриваю возможность перехода на influxdb из-за его возможностей масштабирования. Размер данных: около 10 млн строк.

Схема данных:

  1. Отметка времени (очевидно)
  2. Идентификатор устройства
  3. Идентификатор группы
  4. Данные => от 2 до 30 значений с плавающей запятой

Все записи, сгруппированные по идентификатору группы, располагаются под одним идентификатором устройства. В 99% случаев мне нужно получить все точки данных по идентификатору устройства или идентификатору группы с необязательным ограничением по времени. Не будет необходимости запрашивать одно измерение по заданному периоду. Сохранение - навсегда (удаление только по требованию).

Является ли influxdb хорошим выбором для данных требований? Если да, то как организовать сегменты/теги для такого варианта использования?

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


postgresql timescaledb time-series influxdb
person Mateusz Stefaniak    schedule 03.05.2021    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Мне было бы любопытно, если у вас есть какие-то проблемы с TimescaleDB или, возможно, вы просто не знаете о некоторых его возможностях.

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

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

Есть ли какие-то конкретные проблемы/вопросы, с которыми мы можем помочь?

person Ryan    schedule 03.05.2021
comment
Меня беспокоит размер базы данных. Хранение значений в выделенных столбцах может уменьшить размер базы данных на 30% в PG. Моя схема является гибкой, и в редких случаях, когда мне нужно будет запрашивать некоторые поля базы данных, InfluxDB может быть более эффективной, поэтому ее встроенная модель без схемы (это то, что я читал). - person Mateusz Stefaniak; 04.05.2021