Перемещение от Influx до Postgres, нужны советы

Question

Я использовал Influx для хранения данных временных рядов. Это здорово, когда это сработало, а затем примерно через месяц он прекратил работать, и я не мог понять, почему. (Совместимо с этим выпуском https://github.com/influxdb/influxdb/issues/1386)

Возможно, Influx будет великолепным в один прекрасный день, но сейчас мне нужно использовать что-то более стабильное. Я думаю о Postgres. Наши данные поступают от многих датчиков, каждый датчик имеет идентификатор датчика. Так что я думаю о структурировании наших данных, как это:

(рк), SensorId (строка), время (временная метка), значение (с плавающей точкой)

Наплыв построен для данных временных рядов, так что, вероятно, имеют некоторые встроенная оптимизация. Нужно ли мне самостоятельно делать оптимизацию, чтобы сделать Postgres эффективным? В частности, у меня есть следующие вопросы:

1. Influx имеет такое понятие «серия», и это дешево для создания новой серии. Поэтому у меня была отдельная серия для каждого датчика. Должен ли я создать отдельную таблицу Postgres для каждого датчика?

2. Как настроить индексы для быстрого выполнения запросов? Типичный запрос: выберите все данные для sensor123 за последние 3 дня.

3. Должен ли я использовать метку времени или целое число для столбца времени?

4. Как установить политику хранения? Например. удалите данные, которые старше одной недели автоматически.

5. Будет ли шкала Postgres горизонтально? Могу ли я настроить кластеры ec2 для репликации данных и балансировки нагрузки?

6. Могу ли я опустить в Postgres? Я читал в некоторых статьях, что я могу использовать date_trunc. Но кажется, что я не могу date_trunc его до определенного интервала, например. 25 секунд.

7. Любые другие оговорки, которые я пропустил?

Заранее благодарен!

Обновления Хранение столбца времени как целого целого выполняется быстрее, чем сохранение его как метки времени. Я делаю что-то неправильно?

хранить его в качестве временной метки:

postgres=# explain analyze select * from test where sensorid='sensor_0'; 

Bitmap Heap Scan on test (cost=3180.54..42349.98 rows=75352 width=25) (actual time=10.864..19.604 rows=51840 loops=1) 
    Recheck Cond: ((sensorid)::text = 'sensor_0'::text) 
    Heap Blocks: exact=382 
    -> Bitmap Index Scan on sensorindex (cost=0.00..3161.70 rows=75352 width=0) (actual time=10.794..10.794 rows=51840 loops=1) 
     Index Cond: ((sensorid)::text = 'sensor_0'::text) 
Planning time: 0.118 ms 
Execution time: 22.984 ms 

postgres=# explain analyze select * from test where sensorid='sensor_0' and addedtime > to_timestamp(1430939804); 

Bitmap Heap Scan on test (cost=2258.04..43170.41 rows=50486 width=25) (actual time=22.375..27.412 rows=34833 loops=1) 
    Recheck Cond: (((sensorid)::text = 'sensor_0'::text) AND (addedtime > '2015-05-06 15:16:44-04'::timestamp with time zone)) 
    Heap Blocks: exact=257 
    -> Bitmap Index Scan on sensorindex (cost=0.00..2245.42 rows=50486 width=0) (actual time=22.313..22.313 rows=34833 loops=1) 
     Index Cond: (((sensorid)::text = 'sensor_0'::text) AND (addedtime > '2015-05-06 15:16:44-04'::timestamp with time zone)) 
Planning time: 0.362 ms 
Execution time: 29.290 ms 

хранения его в большой целое число:

postgres=# explain analyze select * from test where sensorid='sensor_0'; 


Bitmap Heap Scan on test (cost=3620.92..42810.47 rows=85724 width=25) (actual time=12.450..19.615 rows=51840 loops=1) 
    Recheck Cond: ((sensorid)::text = 'sensor_0'::text) 
    Heap Blocks: exact=382 
    -> Bitmap Index Scan on sensorindex (cost=0.00..3599.49 rows=85724 width=0) (actual time=12.359..12.359 rows=51840 loops=1) 
     Index Cond: ((sensorid)::text = 'sensor_0'::text) 
Planning time: 0.130 ms 
Execution time: 22.331 ms 

postgres=# explain analyze select * from test where sensorid='sensor_0' and addedtime > 1430939804472; 


Bitmap Heap Scan on test (cost=2346.57..43260.12 rows=52489 width=25) (actual time=10.113..14.780 rows=31839 loops=1) 
    Recheck Cond: (((sensorid)::text = 'sensor_0'::text) AND (addedtime > 1430939804472::bigint)) 
    Heap Blocks: exact=235 
    -> Bitmap Index Scan on sensorindex (cost=0.00..2333.45 rows=52489 width=0) (actual time=10.059..10.059 rows=31839 loops=1) 
     Index Cond: (((sensorid)::text = 'sensor_0'::text) AND (addedtime > 1430939804472::bigint)) 
Planning time: 0.154 ms 
Execution time: 16.589 ms 

Answer 1

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

Для запроса, описанных в q2, индекс на столбце recorded_at должен работать (время является SQL зарезервирована ключевым словом, так что лучше избегать, что в качестве имени)

Вы должны использовать TIMESTAMP WITH TIME ZONE в свое время тип данных.

Удержание зависит от вас.

Postgres имеет различные варианты для осколков/репликации. Это большая тема.

Не уверен, что я понимаю вашу цель для # 6, но я уверен, что вы можете что-то понять.