Разработка схемы реляционной базы данных для хранения метрик

Question

Рассматривая систему, которая имеет следующие характеристики:

• Хранит данные / метрики временных рядов, собранные с нескольких датчиков / входов.
• Точки данных (метрики) собираются из множества различныхсистемы в разное время.
• Каждая из этих метрик, как правило, представляет собой одну точку данных (например, температура и влажность не сообщаются одновременно, а скорее индивидуально и будут иметь разную временную метку)
• типы собираемых показателей со временем будут расширяться - система открыта, и со временем будут поддерживаться дополнительные входные данные (например, сегодня мы собираем температуру, влажность и процессор, завтра может быть добавлен датчик, который контролирует СО2 и ОЗУ).
• Сводка всех метрик для данного временного сегмента должна быть получена с помощью запроса, и это, вероятно, будет наиболее распространенным сценарием запроса.

Я могу придумать три способа моделирования этого.

1.Широкая таблица - с таблицей для каждой категории (покрыта)

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

2.Узкая таблица - с таблицей по метрике (покрыта)

Примечания: Для хранения новых метрик требуется новая таблица

3.Типизированная таблица (не охватывается) - с одной таблицей метрик (не охватывается)

Примечания. Для хранения новых показателей просто требуется новая строка в таблице metricType, никаких изменений схемы.Озабоченный влиянием на производительность из-за размера чанка, хотя группировка по временному интервалу по всем метрикам не потребует объединений и, следовательно, может быть быстрее?

Мне было интересно, если кто-нибудь может прокомментировать илипредставленные варианты указывают мне на некоторые контрольные показатели производительности, которые включают 3, а также 1 и 2, или вообще дают какие-либо рекомендации относительно пригодности каждого подхода.Я планирую провести свои собственные эксперименты на этом, и я опубликую результаты, когда они будут сделаны, но любое понимание на этом этапе будет с благодарностью получено.:)

Обратите внимание, не предлагайте решение nosql, я знаю варианты в этом месте и оцениваю этот вариант отдельно

Answer 1

1 предложение

"Широкая таблица"

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

"Узкая таблица"

Нет ошибок, но нормализация еще не завершена.

«Типизированная таблица»

Это полный, «лучший» из трех ваших сценариев.Но он рассматривает проблему через узкую линзу и в полной изоляции от контекста, в котором существует проблема.Таким образом, это является ошибкой по причинам, отличным от тех, о которых вы спрашиваете.

2 Проблема

1. Первая проблема состоит в том, что вы сравниваете три вещи, которые не являются сопоставимыми,не разумно равны друг другу.

2. Вторая проблема заключается в том, что EAV - это аромат месяца, и многие привлекают его.Тем не менее, он имеет серьезные проблемы и требует дополнительного набора таблиц «метаданных», если он должен быть реализован с некоторой целостностью данных.Дело в том, что EAV не нужен.

3 Решение

Типы собираемых метрик со временем будут расширяться - система будет открыта и дополнительнавходы будут поддерживаться с течением времени (например, сегодня мы собираем температуру, влажность и процессор, завтра может быть добавлен датчик, который контролирует СО2 и ОЗУ).

Это на самом деле прямая проблема реляционной базы данных, котораярешается с помощью совершенно обычного реляционного дизайна, который обеспечивает полную силу отношений;Реляционная целостность;и скорость (которой не будут обладать другие конструкции).

Предостережение

Но есть несколько предостережений, потому что то, что продается как "реляционный"не реляционный.

1. Избавьтесь от полей Record ID, они не реляционные.

   • Record IDs уменьшите вашу схему до стиля 1970-х годов. ЗаписьСистема хранения файлов (для удобства расположена в контейнере SQL).
   • Record IDs не обеспечивают уникальности строк, что требуется для реляционной модели .
   • Кроме того, им требуется одно дополнительное поле и один дополнительный индекс на файл.

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

3. Это ошибка, связанная с проблемами производительности на данном этапе (моделирования).Сначала поймите правильно.Во-вторых, сделай это быстро.Не переворачивайте предписанную последовательность.

4. Реляционные ключи обеспечивают значение, а также реляционную целостность (которая является логической и отличается от ссылочной целостности, которая является физическим средством SQL).Этот адрес является контекстом, в котором существует объект.

   • A Sensor не существует изолированно (кроме случаев, когда он находится в упаковке на полке в магазине ... но даже тогда, он существует в контексте инвентаря магазина)
   • Актив Sensor существует только в контексте объекта, в котором он находится.Вы не предоставили никакой информации относительно этого.Давайте назовем вещь Article общей меткой.
   • Далее, Article требует ограничения метрики, измеряемой датчиком (с целью выхода за пределы допустимого диапазона).аварийные сигналы и т. д.), а не сам датчик.(Датчик может иметь диапазон, который является другим.)
   • Аналогично, Sensor существует в Location, который является вторым вектором.В противном случае Article существует в Location, а ключ статьи содержит Местоположение.Я смоделировал последнее.

Модель данных

Вот решение: Модель данных датчика

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

• Он удовлетворяет требованиям как OLTP, так и OLAP (Dimension-Fact).
  • Если вы предоставите больше контекста, мы можем точно его смоделировать.Это может занять некоторое время туда-сюда.
• Оно ограничено предоставленной информацией.
  • Я взял MetricType и SensorType как синонимы.
  • Article отображается как Зависит от (существует внутри) Location, поочередно они могут быть отдельными векторами.В любом случае, Article и Location вместе квалифицируются Sensor.
  • Поскольку SensorSerialNo уникально (AK2), следовательно, Reading(SensorSerialNo, DateTime) уникально.Индекс не требуется.Однако, если есть много запросов только по Reading через SensorSerialNo, такой индекс повысит производительность.

• Пожалуйста, не стесняйтесьзадавать вопросы, а я отвечу.

• Для тех, кто совсем новичок в IDEF1X, см. Введение IDEF1X .

• Для тех, кто знаком с IDEF1X и хочет только освежиться, см. Анатомия IDEF1X .

4 Производительность

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

Тем не менее я отвечу на ваши заявленные опасения.

• Например.ClusteredIndex для предписанного Reading PK будет:
  • Обслуживать большинство запросов, большинство измерений (за исключением запросов, которые используют SensorSerialNo отдельно , в случае которых я предложил дополнительный индекс)
  • Обслуживать все транзакции OLTP и обеспечивать максимальный параллелизм, поскольку Sensors распределены по реальному миру: по Locations и по статьям`.
• Принимая во внимание, что индекс для Record ID гарантирует HotSpot для каждого INSERT.Отлично подходит для создания тупиков.

Бенчмарк

У меня есть сто или около того эталонов для таких структур данных, которые были собраны за последние четыре десятилетия для использования в OLTP и OLAP.Большинство моих клиентов - банки (подумайте: показания датчиков очень похожи на цены акций, которые меняются в течение дня; несколько векторов (измерений); миллиарды строк).Банки очень строго соблюдают конфиденциальность, поэтому я не могу публиковать тесты как есть, и их редактирование потребует времени и усилий.

У меня есть один тест для очень похожих требований, который является публичным.Фактически, это было включено в Ответ на вопрос о временном ряду, но искатель попросил модераторов обрезать его (это смущает Oracle).Вот Сводка теста производительности для теста Sybase ASE против Oracle 10.2 для фиксированного DDL (данные временного ряда) и заполненности.

Наконец, необходимые структуры и код достаточно просты для вас.запустите свой собственный тест.

5 Ответ на другие ответы

Комментарии Ре Невилла:

Однако, если вам также придется отвечать на вопросы типа "в какой день былПроцессор выше 30%, а влажность ниже 3% в течение более 3 часов ", с вашей моделью EAV становится действительно трудно работать.Эти запросы быстро станут действительно трудными для написания и понимания - каждый критерий превращается как минимум в 1 самосоединение.

Отмечая, что его комментарии касаются EAV, но это может означать, что он в равной степени относится к темеТаблица (обычная таблица реляционной базы данных (не EAV) Reading) в данном случае, поскольку она касается типа запроса (а не концепции EAV против концепции реляционных):

• Объявление делаетнеприменимо к реляционным таблицам (вполне может относиться к EAV; масса проблем возникла из-за идентификаторов записей; и т. д.)

• Пока у вас есть

  1. подлинная схема реляционной базы данных (как я уже предлагал) и
  2. подлинная платформа SQL (не притворяется "sql", которая не соответствует, но обманным образом использует имя), и
  3. вы понимаете IN и NOT IN, и как сравнивать Наборы в SQL

• ... такие запросы просты длякод.

6 Ответы на вопросы (в комментариях)

есть ли у вас ссылки на record_id, являющиеся антиреляционными, я не верюВы на секунду, но мне интересно узнать больше о том, почему этот анти-шаблон так распространен.

Ссылки

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

Вам не нужны ссылки, потому что нечего «обсуждать», и любые «дискуссии», которые вы можете прочитать, не соответствуют вышеупомянутому пункту.

Единственным авторитетом является великий доктор Э. Ф. Кодд, а я его ученик.Все авторы всех книг и учебников (да, образование тоже разрушается), утверждающие, что речь идет о реляционной модели, кроме Кодда, на самом деле являются ложными, они о внедрении систем регистрации записей в стиле 1970-х годов и анти-реляционных (нет реляционной силы; нет реляционной целостности; нет реляционной скорости).С 1970 года они совершили ошибку, пытаясь вписать RM в свое мышление RFS 1970-х годов, вместо того, чтобы выпустить его и принять мышление RM.И они провели последние ПЯТЬ ДЕСЯТИЛЕТИЙ, подкрепляя это, даже оправдывая это «математическими определениями»;17 «реляционные алгебры»;42 ненормальные "нормальные формы".Все полностью анти-реляционные.И они ссылаются друг на друга, поэтому их публикуют.

Вторая проблема заключается в том, что такие сайты, как SO, основаны на популизме.Популярный ответ не самый лучший или правильный ответ.Для этого вам нужен авторитет (очень страшный для популистов) и объективная, абсолютная истина (правда не меняется, она постоянна).(Люди любят свои относительные или субъективные «истины», которые все время меняются).

1. Поэтому вам нужно только одно, авторитетное определение, оригинальная статья, Relationalмодель .

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

2. Вам нужно извлечь из этого, что:

   • Реляционный ключ «составлен из данных» (мой перефразировать к нескольким записям, которые являются слоями в RM), что является Логическим
   • , что суррогаты (а)не только вопреки этому определению, (б) они являются до-реляционной парадигмой, то есть физическими указателями, той самой вещью, которую заменяет РМ, и (в) явным образом запрещены.* Очень важно, вам нужно понимать не только определение Реляционного Ключа, но и почему и почему.

   • Например.что он преодолевает проблемы импорта / экспорта, которые есть в системах на основе указателей.

   • Например.временное определение (семантическое; 8 букв; страшное).

3. Следовательно, нет никаких аргументов, никаких «споров», которые можно было бы иметь.

   • Любой, кто идет против этого, является анти-реляционным.Не потому, что я так говорю, а потому, что это противоречит доказанным фактам и единой власти.
   • Я назвал явные технические преимущества правильного использования RM (Relational Power; Relational Integrity; Relational Speed), но расширение этого требует значительных усилий
   • Следствие НЕ соблюденияRM означает, что вы не получаете (а) ни одного из преимуществ, И (б) вы получаете полный набор проблем, которые были у систем до-реляционных записей в 1970 году, И (в) надуманных «решений», предоставленных «академиками»которые никогда не работали.

4. Если вам нужно расширить те преимущества РМ, которые, конечно, вам нужно понять в некоторой степени, потому что каждый из них очень глубокои очень важно, лучшее, что я могу предоставить, это.Как вы можете себе представить, это битва, в которой я должен сражаться за каждый Ответ, связанный с этой темой, поэтому за многие годы я опубликовал изрядную сумму во многих Ответах.

   • Перейти кв моем профиле выберите «Все ответы» и прочитайте все, которые относятся к этой теме.

Почему этот анти-паттерн так распространен?

Короткий ответ: люди любят свое невежество, свои субъективные «истины» и будут бороться изо всех сил, чтобы защитить его.Они быстро принимают и повторяют любое оправдание того, чтобы остаться прежним.Изучение чего-то, что является изменением парадигмы от того, что они знают, очень страшно, потому что это угрожает их комфортному невежеству и разоблачает это таким, какое оно есть на самом деле.Им придется признать, что то, что они написали для ПЯТИ ДЕСЯТИЛЕТИЙ, неправильно.Вот почему популизм процветает.В неведении.

Немного более длинный ответ такой.Просто посмотрите на интернет.В старые времена для любого конкретного предмета у нас был один источник, один абсолютный авторитет: например.купите Британскую энциклопедию;проведите все свое детство, пожирая это.Постоянная правда.Честная историяНо теперь любой, у кого есть клавиатура и два пальца плюс немного соединительной ткани (мозг не требуется), может оставлять сообщения.Как мгновенный «авторитет».Сеть переполнена (а) поверхностными ответами (анти-тезис «Теперь это ответ») (б) во многих вариантах (с), за которые проголосовали из-за популизма (d), которые далеко не правильныеили полный ответ.Звуковые фрагменты, которые могут быть легко поняты населением.Очень немногие хотят глубины полного ответа.

Даже когда устанавливается своего рода авторитет (например, wiki; SO), его легко подорвать, потому что буквально миллионы людей меняются и меняются,и изменить записи (правда не меняется, поэтому, пока что-то меняется, это не правда).В основном для обслуживания своих политических позиций;их идеологии;их переписывание истории, чтобы сделать прошлое неправильным (это не было, это уже произошло), и настоящее безумие "хорошо".

Окончательный ответ таков.Академическая зависть.Потребовалось целое десятилетие, чтобы реляционная модель Кодда была понята и принята.И даже тогда, только немногими.IBM и Бриттон-Ли (ставшая Sybase) внедрили RM Кодда в духе и слове.(Корпорация цифрового оборудования сделала то же самое, но они больше не существуют.) Те «ученые», которые, казалось, работали с Коддом, оказались на самом деле против него (в силу доказательств).Они ненавидели тот факт, что сами не придумали это, что один человек придумал первую настоящую модель со звуком;логично;математический, фундаментальный, в комплекте с реляционной алгеброй.Все интегрировано.Все требования дня (например, проблема Билла материалов) ответили.Это выдержало испытание временем: пять десятилетий и ничего не было добавлено или изменено.

Обычно они ложно заявляют: «Но Кодд не определил то или это, поэтому здесь я определяю это ...».Таким образом, они придумали свой собственный RA.Сейчас их 17, все неактуально.И ненормальные "нормальные формы", чтобы возвышать фрагментированные биты их систем регистрации записей, чтобы казаться "реляционными".Теперь у них 42, все не имеет значения.И много книг, утверждающих, что они «реляционные», но, по доказанным фактам, анти-реляционные.Каждый «академик» стремится укрепить свою «академическую» позицию против всех остальных.

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

Вот почему я снова говорю, идите к единственному Органу.Ничего не читайте из антирелигиозной толпы, потому что это уменьшит ваше понимание РМ (в лучшем случае) или отравит ваш разум (в худшем случае).

Одно уточнение

Если вы исследуете реляционный PK (например) Location.Location, это может показаться странным.Это %Code или %ShortName, то есть данные, которые пользователь фактически использует.Обычно от 4 до 6 символов, максимум 12. В отличие от длинного Name, который должен существовать и который является альтернативным ключом.И, конечно же, это определенно не какое-либо число (которое не является данными, не то, что использует пользователь).Пользователям тоже нравятся их короткие формы.Очевидно, используйте любой международный стандарт, если таковой существует.

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

• Например.для Security, которая является компанией, котирующейся на фондовой бирже, в Америке это будет TickerSymbol, в Австралии ASXCode.Код ISO, ISINCode, является AlternateKey.

• Для городов используйте один из стандартов географического местоположения: ISO;FIPS;и т. д. (я использую статоиды, потому что они существовали задолго до других, но те дни сочтены).В худшем случае используйте код аэропорта.

---

Что вы считаете подлинным sql?Sql Server, Postgres, MySQL, оракул Я думаю, все будет?

Нет.Я имею в виду любую платформу, которая фактически соответствует опубликованному стандарту SQL и поэтому может фактически поддерживать реляционные таблицы;Реляционная обработка множеств;и ACID транзакции.

• Это автоматически исключает бесплатное программное обеспечение / vapourware / nowhere / "open source", для которого биты написаны 10 000 разработчиков по всей вселенной, без каких-либо руководящих принципов.Например.нет транзакций ACID или структур, которые требуются для него, которые требуются в каждом сегменте кода.Слишком поздно, чтобы вставить это сейчас, потому что это потребует 100% переписать, и не дай бог ... Архитектура сервера.

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

Если масштабируемость или производительность (высокая пропускная способность; высокая параллелизм; низкаязадержка), тогда Архитектура сервера является наиболее важным.Опять же, это исключает бесплатное программное обеспечение и Oracle, поскольку у них нет Архитектуры, они получают операции для выполнения всех функций, которые обычно выполняет сервер баз данных.

Проверьте это Сравнение Oracle сАрхитектура Sybase .

• То же самое относится к PostGres NON sql и другим бесплатным программам.PooGres (ублюдок, сын полного провала Ingres) классно захватывает себя под давлением, с множеством проблем с блокировками и очень низким параллелизмом.

High-End, Коммерческий, SQL-совместимый
Что-то вроде 5% рынка, но 95% рынка финансовых услуг и автоматизации.Великолепная архитектура, безнадежный маркетинг.

• Sybase ASE
• IBM DB2

Коммерческий, SQL-совместимый
Легко наиболееобщий.Хорошая архитектура (изначально украденная у Sybase), а затем «прогрессирующая» в обычном безумном стиле MS.

• MS SQL Server
  Боль в использовании;массы над головой;плохо интегрируется с различными надстройками и необходимыми приложениями.
  (Я поставляю системы только в Sybase или DB2, заказчик может перевести это на MS.)

Коммерческий,Несовместимый с SQL
Безнадежная архитектура, отличный маркетинг.

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

  • Например.в бенчмарке временных рядов весь смысл был в том, что Oracle захватывает себя, когда запрашивается подзапрос, поэтому он должен использовать «встроенное представление».То, что, как утверждал ОП, было таким же быстрым, как и подзапрос (избегая того факта, что он требует гораздо больше кода, и кодер должен выйти за пределы реляционного мышления).То, что тест оказался забавно ложным, в каждом протестированном сценарии (Oracle был в 3–4,8 раз медленнее, чем Sybase в COUNT(), в 26–36 раз медленнее в SUM()
  • ... и подзапрос (Sybase 2,1 секунды) пришлось прекратить после 120 минут .
  • Например, Oracle не соответствует ACID транзакциям, иРазработчики обходят это препятствие до некоторой степени, но Phantom Updates и Lost Updates (технические термины) просто не предотвращаются. Если обходные пути написаны неправильно, целые строки (UPDATES или INSERTS теряются).
  • Все, что относится к следующему ...

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

• Например, «проверка отложенных ограничений»; ENUMs;и т.д.
• Им не хватает основ SQL-совместимости.Анс.Например.нет подлинных транзакций ACID.

Далее, как объяснено выше, нулевая архитектура.Это приводит к тому, что системы прекрасно работают при одноразовом использовании и с треском проваливаются при любом порядке давления параллелизма или масштабируемости.

Из-за несоответствия требованиям SQL, типичных для мошенников и воров, они принимаютстарается опубликовать уведомление о соответствии на каждой странице в руководстве по командам.(Только одна декларация соответствия в начале руководства - это все, что требуется.) Конечно, пропущенные команды просто отсутствуют, так что, черт возьми, у них нет декларации о соответствии.

• PostGres NON sql
  Худшая часть сточных вод, которую мне приходилось исследовать со времен Энгра.Искренне любимый «академической» толпой, просто потому, что он был нацарапан таким же «академиком».
  5 пользователей макс., Или имел дело с проблемами параллелизма (просто бегло взгляните на проблемы, о которых сообщалось в SO).

• My NON sql
  На голову выше PoS, но все еще в этой категории.

  • Двигатель InnoDB заметно лучше вотдел производительности, но далеко не на уровне Sybase / DB2 (все еще нет подлинной архитектуры сервера).Никакой передышки в отделе несоблюдения SQL.

Резюме

• Вы получаете то, за что платите,

  • Архитектура сервера, наиболее заметная производительность в каждом сценарии.
  • Соответствие SQL, тщательно продумано и реализовано во всех применимых сегментах кода.
  • Последнее, но не менее важное, Поддержка.

• Что бы вы ни выбрали, помните, что при переносе его на другую платформу ваш код SQL потребует полной проверки и изменения, поскольку «разновидности» SQL (или NON-sql) очень разные.Поэтому выбирайте осторожно с учетом долгосрочной реализации.

Answer 2

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

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

Вариант 3 На мой взгляд, мне подходит, поскольку он готов к расширению источников данных и поддерживает чистоту и аккуратность данных.

Answer 3

Действительно, способ 3 является своего рода EAV-моделированием в реляционном хранилище, включая временные метки в ключе EAV.

+---------+            +-----+            +-------------+
| Sensors | -- 1:M --< | EAV | >-- M:1 -- | Value kinds |
+---------+            +-----+            +-------------+

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

Если запросы не требуют объединений, но их необходимо сгруппировать по времени, кластерный индекс в столбце timestamp обеспечивает производительность.

Однако любые запросы с объединениями (т. Е. Сравнение значений разных датчиков) рискованно снижают производительность.Решением может быть отдельное хранилище OLAP для собранных данных EAV.

Answer 4

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

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

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

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

Я хотел бы предложить другую вещь.Вы также можете рассмотреть возможность создания отдельной таблицы, которая будет содержать агрегированные данные.Например, если вашей системе требуются агрегированные данные, вы можете подумать о том, чтобы поместить данные в денормализованном стиле в отдельную таблицу, в которой можно хранить агрегированные значения для определенной временной шкалы, чтобы вы могли удалить данные из исходной таблицы, которые уже были обработаны.,Я имею в виду базу данных OLAP , в которую вы могли бы обратиться.

Answer 5

Это в значительной степени зависит от типов запросов, которые вам нужно выполнить.Я думаю, что производительность может быть не самой большой проблемой, если, как вы говорите,

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

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

Если ваши запросы действительно просто «показывают данные за временной диапазон», ваш вариант 3 ( дизайн сущности / атрибута / значения ) наиболее эффективен с точки зрения усилий по разработке.,

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

Альтернативные конструкции потребовали бы внешних объединений для каждой таблицы.С точки зрения производительности это не так уж и сложно, но управление схемой и связанными запросами было бы проблематично.

Однако, если вам также придется отвечать на вопросы типа «в какой день процессор был выше 30%, а влажность быланиже 56% в течение более 3 часов ", ваша модель EAV становится действительно трудной для работы .Эти запросы быстро станут действительно трудными для написания и понимания - каждый критерий превращается как минимум в 1 самостоятельное соединение.