Я проектирую базу данных PostgreSQL, которая принимает показания от многих сенсорных источников. Я провел много исследований в области дизайна, и мне нужен свежий материал, чтобы помочь мне выбраться из этого колеи.
Для ясности, я не ищу помощи , описывающей источники данных или любые связанные метаданные. Я специально пытаюсь выяснить, как лучше хранить значения данных (в конечном итоге различных типов).
Основная структура входящих данных выглядит следующим образом:
- Для каждого устройства регистрации данных имеется несколько каналов.
- Для каждого канала регистратор считывает данные и прикрепляет их к записи с отметкой времени
- Разные каналы могут иметь разные типы данных, но обычно достаточно float4.
- Пользователи должны (через функции базы данных) иметь возможность добавлять различные типы значений, но эта проблема вторична.
- Регистраторы и каналы также будут добавлены через функции.
Отличительной особенностью этого макета данных является то, что у меня есть много каналов, связывающих точки данных с одной записью с отметкой времени и номером индекса.
Теперь, чтобы описать объем данных и общие шаблоны доступа:
- Данные будут поступать примерно для 5 регистраторов, каждый с 48 каналами, за каждую минуту.
- Общий объем данных в этом случае составит 345 600 чтений в день, 126 миллионов в год, и эти данные необходимо постоянно читать как минимум в течение следующих 10 лет.
- В будущем будет добавлено больше регистраторов и каналов, возможно, с устройств разных типов, но, надеюсь, с аналогичным представлением хранилища.
- Общий доступ будет включать в себя запросы одинаковых типов каналов во всех регистраторах и объединение временных меток регистратора. Например, получить канал 1 из logger1, канал 4 из logger2 и выполнить полное внешнее соединение для logger1.time = logger2.time.
Я должен также упомянуть, что каждая временная метка регистратора является чем-то, что может изменяться из-за настройки времени, и будет описана в другой таблице, показывающей чтение времени сервером, считывание времени регистратора, задержку передачи, настройку часов и результат скорректированное значение часов. Это произойдет для набора записей / временных отметок регистратора в зависимости от поиска. Это моя мотивация для RecordTable ниже, но в остальном пока это не вызывает особого беспокойства, поскольку я могу ссылаться на строку (регистратор, время, запись) откуда-то, которая изменит временные метки для связанных данных.
Я рассмотрел довольно много вариантов схемы, самый простой из которых напоминает гибридный подход EAV, где сама таблица описывает атрибут, поскольку большинство атрибутов будет просто реальным значением, называемым «значением». Вот базовый макет:
RecordTable DataValueTable
---------- --------------
[PK] id <-- [FK] record_id
[FK] logger_id [FK] channel_id
record_number value
logger_time
Учитывая, что logger_id, record_number и logger_time уникальны, я полагаю, что я использую здесь суррогатные ключи, но, надеюсь, мое оправдание экономии места здесь имеет смысл. Я также рассмотрел добавление идентификатора PK в DataValueTable (вместо PK, являющегося record_id и channel_id), чтобы ссылаться на значения данных из других таблиц, но я пытаюсь сопротивляться желанию создать эту модель "тоже гибкий »пока. Однако я хочу начать получать данные в ближайшее время, и мне не нужно менять эту часть, когда позже необходимо добавить дополнительные функции или данные с другой структурой.
Сначала я создавал таблицы записей для каждого регистратора, а затем таблицы значений для каждого канала и описывал их в другом месте (в одном месте), с представлениями для их соединения, но это было просто "неправильно", потому что я повторял одно и то же много раз. Я думаю, что я пытаюсь найти счастливую среду между слишком большим количеством таблиц и слишком большим количеством строк, но разделение больших данных (DataValueTable) кажется странным, потому что я бы, скорее всего, разделил на channel_id, поэтому каждый раздел имел бы одинаковое значение для каждой строки. Кроме того, разделение в этом отношении потребует немного усилий для переопределения условий проверки в основной таблице каждый раз, когда добавляется канал. Разделение по дате применимо только к RecordTable, что на самом деле не нужно, учитывая, насколько оно будет относительно небольшим (7200 строк в день с 5 регистраторами).
Я также рассмотрел использование вышеупомянутого с частичными индексами на channel_id, поскольку DataValueTable будет расти очень большим, но набор идентификаторов каналов останется небольшим, но я действительно не уверен, что это будет хорошо масштабироваться через много лет , Я провел некоторое базовое тестирование с фиктивными данными, и производительность только такова, и я хочу, чтобы он оставался исключительным по мере роста объема данных. Кроме того, некоторые выражают озабоченность по поводу очистки и анализа большой таблицы и работы с большим количеством индексов (в данном случае до 250).
На небольшом примечании я также буду отслеживать изменения в этих данных и учитывать аннотации (например, птицу, потрескавшуюся на датчике, чтобы эти значения были отрегулированы / помечены и т. Д.), Так что держите это в задней части вашего не забывайте о дизайне здесь, но сейчас это отдельная проблема.
Некоторые сведения о моем опыте / техническом уровне, если они помогают понять, откуда я родом: я являюсь аспирантом CS и регулярно работаю с данными / базами данных в рамках своего исследования. Однако мой практический опыт в разработке надежной базы данных для клиентов (это часть бизнеса), которая обладает исключительной долговечностью и гибким представлением данных, несколько ограничен. Я думаю, что моя главная проблема сейчас заключается в том, что я рассматриваю все аспекты подхода к этой проблеме, вместо того чтобы сосредоточиться на ее решении, и я не вижу перед собой «правильного» решения.
Итак, в заключение, я думаю, это мои основные запросы для вас: если вы сделали что-то подобное, что сработало для вас? Каковы преимущества / недостатки я не вижу различных конструкций, которые я предложил здесь? Как вы могли бы спроектировать что-то подобное, учитывая эти параметры и шаблоны доступа?
Я буду рад предоставить разъяснения / подробности, где это необходимо, и заранее благодарю за то, что вы классные.