Данные временных рядов в реляционной базе данных?

У меня есть данные временных рядов в реляционной базе данных (postgres). Данные импортируются в базу данных каждые 5 минут, но ввод перезаписывается в течение дня, что означает, что в конце дня есть только 1 запись для этого дня для определенного идентификатора (идентификатор и дата -> составные ПК).

текущий процесс подобен этому -> Данные поступают и оцениваются одинаково 1: 1. (данные поступают в каждую таблицу в том виде, в котором они есть в источнике, существует много избыточности.

3 проблемы:

  • в настоящее время производительность получения данных из базы данных (чтение) высокая (хорошая производительность)

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

  • недостающие данные (игнорировать эту проблему)

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

  • СХД

источник только один, все данные поступают из одного источника. можно ли для него иметь DWH или так как источник всего один, в нем нет необходимости?

Редактировать:

Как я могу оптимизировать эту базу данных?

в настоящее время в базе данных есть только одна схема. Данные поступают и оцениваются одинаково 1:1. писать трудно, так как у нас есть избыточность.

мое решение:

Я хочу создать 3 схемы для этой базы данных.

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

2, входящие данные сохраняются, а данные структурированы в 3NF.

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

Какую проблему вы пытаетесь решить? Спектакль? Потерянная информация? Две другие причины для использования хранилища данных: 1. Загрузка данных в модель данных, которая поддерживает создание отчетов; 2. Запускайте запросы к хранилищу данных, а не к источнику, чтобы остановить нагрузку на исходную (операционную) систему.

Nick.McDermaid 05.12.2022 23:21

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

fmia 06.12.2022 00:45

Пожалуйста, уточните через правки, а не комментарии. Пожалуйста, используйте стандартную орфографию и пунктуацию. Как спросить Справочный центр

philipxy 06.12.2022 02:10

Да, DWH позволяет оптимизировать всю базу данных для анализа (чтения). Я не могу помочь вам с отсутствующими данными, это вопрос инженерии данных, и в вашем вопросе нет подробностей о том, как это реализовано в настоящее время.

Nick.McDermaid 07.12.2022 05:38
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
1
4
86
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Ваша модель с тремя схемами — это именно то, как это делалось на протяжении многих лет.

Схема 1:

Названия: Staging/Landing/Ingestion

Схема соответствует исходной системе, но она очищается и перезагружается для каждого пакета загрузки. Обычно имеет «более свободное» определение схемы, позволяющее импортировать и собирать неверные данные.

Схема 2:

Имена: реплика/ODS/постоянное хранилище данных

Схема 2 никогда не очищается, она постоянна. После загрузки данных этот слой должен выглядеть точно так же, как ваши исходные системы. Данные в схеме 1 каждый раз "объединяются" со схемой 2. Например, в ежедневном цикле загрузки схема 1 содержит только данные за эти дни, а схема 2 содержит всю историю загруженных данных. Справочные данные объединяются по известному первичному ключу. Транзакционные данные могут быть объединены по ключу или могут быть объединены на основе «окна», т. е. удалить данные за последние дни из схемы 2 и загрузить схему 1 в

Некоторым людям нравится иметь «точку во времени», когда они могут воссоздать то, как исходная система выглядит как исторический момент времени. Хотя я никогда не видел, чтобы кто-то этим пользовался.

Схема 3:

Названия: бизнес-уровень/схема «звезда»/уровень отчетности/витрина данных/сематический уровень

Уровень 2, который обычно является копией модели данных OLTP (OLTP оптимизирован для ввода данных). Это преобразуется в модель данных, оптимизированную для отчетности.

Проверенная и проверенная модель данных здесь — схема звезды. Это было вокруг в течение десятилетий. Если вы исследуете какой-либо инструмент отчетности (например, Power BI), вы все скажете, что предпочтительной моделью данных для создания отчетов является схема «звезда». Да, звездообразная схема денормализована и имеет другие преимущества помимо производительности, например, ее легче понять бизнес-пользователю, она поддерживает медленно изменяющиеся размеры и т. д.

Все эти концепции объясняются в Интернете, но если у вас есть какие-либо конкретные вопросы, мы будем рады расширить их.

в настоящее время с одной схемой мы можем считывать данные каждые 5 минут для нашего внешнего программного обеспечения (однако мы также записываем каждые 5 минут в одну и ту же схему и читаем из одной и той же схемы), если я создаю 3 схемы, все еще возможно читать каждые 5 мин? потому что в схеме 3 нам нужно время для передачи данных из промежуточной области в ядро, а затем на бизнес-уровень

fmia 20.12.2022 09:33

Другие вопросы по теме