PostgreSQL - хранить данные нескольких субъектов в реальном времени

Сценарий:

  1. Я пытаюсь создать веб-страницу мониторинга операций корабля в реальном времени.
  2. У меня 1000-10000 судов в эксплуатации
  3. Все корабли отправляют данные в БД в режиме реального времени, 24 часа - в течение 30 дней
  4. Каждые новые вставленные данные имеют размер 1 строка X 100 столбцов.
  5. При загрузке веб-страницы все исторические данные выбранного корабля будут загружены и визуализированы.
  6. Последняя строка таблицы данных корабля в реальном времени будет запрошена и получена на веб-странице для обновления экрана в реальном времени.
  7. У каждого корабля есть свои данные не в реальном времени, такие как размеры корабля, груз, обслуживающий персонал и т. д.

До сих пор я думал о создании новой схемы для каждого корабля. Что-то вроде этого:

public_schema
ship1_schema
ship2_schema
ship3_schema
  |--- realtime_table
  |--- cargo_table
  |--- dimensions_table
  |--- attendants_table
ship4_schema
ship5_schme

Является ли это хорошим способом хранения данных отдельных кораблей в реальном времени и получения их на веб-сервере? Какие еще способы посоветуете?

Что касается временных рядов, я уже использую расширение PostgreSQL под названием Timescale DB. Мой вопрос скорее о хранении данных временных рядов, если у меня много кораблей. Это хорошая идея, чтобы различать данные RT каждого корабля при построении новой схемы?

++ Я новичок в PostgreSQL, и некоторые советы, которые я получил от других людей, были для меня слишком сложными... Я был бы очень признателен, если бы вы предложили какой-то метод, кратко объяснив, что это такое


postgresql timescaledb real-time
person Eric Kim    schedule 25.09.2018    source источник
comment
Я бы рекомендовал не использовать схему для каждого корабля, а хранить их в одной таблице.   -  person Laurenz Albe    schedule 25.09.2018
comment
@LaurenzAlbe Я тоже думал об этом, но когда я извлекаю исторические данные корабля, не займет ли это гораздо больше времени, когда исторические данные состоят из миллионов строк, поскольку я добавляю одно дополнительное условие для запрос?   -  person Eric Kim    schedule 25.09.2018
comment
Если вы обращаетесь к данным по индексу, размер таблицы не влияет на скорость.   -  person Laurenz Albe    schedule 25.09.2018

Ответы (2)


arrow_upward
2
arrow_downward

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

  • таблица_реального_времени
  • cargo_table
  • размеры_таблица
  • дежурный_стол

С этого момента, если вы считаете, что ваши данные достигнут большого объема, у вас есть следующие варианты.

  1. Создайте индексы для полей, которые важны для запросов, для этого очень полезен планировщик запросов Postgres.

  2. В последней версии Postgres реализовано разделение таблицы на основе критериев, которые вы указали без необходимость использовать наследование таблиц.**

Поскольку вам понадобятся оперативные данные на веб-странице, вы можете использовать команду Listen. для Postgres для получения данных с корабля (если у вас нет другого способа отправки этих данных на веб-сервер, например веб-сокетов)

person Bill Togkas    schedule 25.09.2018

arrow_upward
1
arrow_downward

Добавим сюда немного цвета — если вы уже используете расширение TimescaleDB, вам не нужно использовать секционирование таблицы, так как TimescaleDB сделает это за вас автоматически.

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

person Diana Hsieh    schedule 03.10.2018