У нас есть postgres db с плагином timescaledb для хранения данных датчиков на основе времени в гигабайтах и постоянно растущих. В БД есть две таблицы с индексами, внешними ключами и всем, что касается классической БД для базы данных клиентов или чего-то еще. Вопрос в том, какие существуют параметры производительности, позволяющие повысить производительность вставки и производительность запросов.
Данные датчика состоят из идентификатора датчика, отметки времени и значения с плавающей запятой. Идентификатор датчика, в свою очередь, состоит из идентификатора и цепочки хлебных крошек, обычно длиной около 50 символов, но иногда может быть немного длиннее. Вставка этой крошки в таблицу для данных датчика приведет к значительному увеличению размера таблицы. Поэтому идентификатор датчика находится в отдельной таблице.
Таблица данных датчика имеет внешний ключ к таблице идентификатора датчика и указатель на идентификатор и время датчика.
Вставки происходят очень часто со многих тысяч устройств каждую секунду. Так что производительность вставки важна. Данные датчика никогда не изменяются, и удаление не происходит, кроме как для очистки старых данных. Немногие пользователи время от времени выполняют запросы для исследования данных датчика. Приложение периодически выполняет запросы, чтобы выяснить, изменились ли текущие и предыдущие данные датчика.
Вопрос теперь в том, как оптимизировать базу данных для этого варианта использования. Одна идея состоит в том, чтобы удалить внешние ключи, чтобы улучшить производительность вставки. Я не уверен, действительно ли это не влияет на производительность запросов. База данных датчиков имеет уникальное ключевое ограничение на идентификатор датчика и время. Проблема в том, что существующие индексы необходимы для запросов и, следовательно, не могут быть удалены.
Любые идеи о том, как настроить вещи для этого сценария.