#sql #sql-server #database #performance #azure-sql-database
#sql #sql-сервер #База данных #Производительность #azure-sql-database
Вопрос:
Я настраиваю базу данных SQL Azure для загрузки около 1 млн строк в день.
Я планирую загрузить все данные в одну таблицу со следующей структурой:
TAG_NAME | START_DATETIME | END_DATETIME | READING | READING_UOM | INTERVAL_SECS (computed column)
Каждый (TAG_NAME, START_DATETIME, END_DATETIME) уникален. Итак, возможен следующий случай:
TAG_NAME | START_DATETIME | END_DATETIME | READING | READING_UOM | INTERVAL_SECS (computed column)
X | 2020-01-01 01:00:00 | 2020-01-01 02:00:00 | 9.8 | m3 | 3600
X | 2020-01-01 01:00:00 | 2020-01-02 02:00:00 | 232.1 | m3 | 90000
Я планирую создать индексы для TAG_NAME, START_DATETIME и END_DATETIME.
Оттуда я буду создавать представления. Например, представление, которое извлекает все показания за месяц для тегов X, Y и Z.
Затем другое представление, которое извлекает минутные показания для тегов X, Y и D.
И так далее..
Итак, мой вопрос в том, влияет ли загрузка всего в одну таблицу на производительность? Должен ли я разделить входные данные на таблицы «минута», «час», «месяц» и т. Д.?
Комментарии:
1. Я не вижу, где в вашей таблице находятся «минута», «час» и «месяц». Можете ли вы прояснить вопрос.
2. С точки зрения дизайна эта таблица не выглядит так, как будто ее нужно нормализовать. Однако в вашем примере не отображается уникальное значение для tag_name и т. Д. Вы хотите сказать, что tag_name и т. Д. Представляют идентификатор? Если это так, да, вы можете увидеть улучшения производительности, поместив их в отдельную таблицу. Уменьшенное хранилище, более узкие внешние ключи (потому что вы можете превратить его в искусственный ключ) — все это должно повысить производительность.
3. Меняются ли все данные с одного дня на следующий? В противном случае было бы значительное повышение производительности при импорте только измененных или добавленных строк
4. @GordonLinoff Это измерения, которые имеют начало и конец. Некоторые из них длятся минуту, другие — месяц, другие — случайное время. Поэтому я мог загружать их в разные таблицы в зависимости от продолжительности измерения.
5. @GrantFritchey Все теги уникальны и хранятся в другой таблице вместе с ресурсом, которому они принадлежат, UOM по умолчанию и другими свойствами тегов. Я использую TAG_NAME в качестве ключа, чтобы другие люди, которые могут захотеть изучить эту таблицу, могли ее понять. Является ли снижение производительности при использовании длинного ключа слишком плохим?
Ответ №1:
Как сказал @Grant Fritchey, чем длиннее ключ, тем меньше строк хранится на странице, поэтому тем больше глубина индекса. Когда индекс становится слишком большим, это влияет на производительность.
- Из-за быстрого роста данных, я думаю, вам следует разделить таблицу фактов на несколько таблиц, таких как активная таблица и таблица исторического архива, различать по годам.
- Вы можете рассмотреть возможность использования индексов columnstore для сжатия данных и повышения производительности запросов.
Ответ №2:
Я бы использовал таблицу измерений даты, настроенную с любыми конкретными столбцами, которые могут вам понадобиться для нарезки и группировки ваших данных. Если вам нужны только номера года, месяца и дня, то это все, что нужно для измерения даты. Но, если вам нужны часы, минуты, недели, кварталы или что-то еще, вы также можете включить эти столбцы в таблицу измерений даты.
Индексирование по измерению даты выполняется легко и быстро, поскольку количество строк невелико.
Тогда ваша приведенная выше таблица фактов будет иметь отношения FK к таблице измерений даты для ваших START_DATETIME и END_DATETIME.