Nano Hash - криптовалюты, майнинг, программирование

Снижение производительности при размещении всех записей в одной таблице

Я настраиваю базу данных Azure SQL для загрузки около 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.

И так далее..

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

sql database sql-server performance azure-sql-database
01.12.2020

  • Я не вижу, где минуты, часы и месяц в вашей таблице. Можете уточнить вопрос. 01.12.2020
  • С точки зрения дизайна эта таблица не выглядит так, как будто ее нужно нормализовать. Однако в вашем примере не показано уникальное значение для tag_name и т. д. Вы говорите, что tag_name и т. д. представляют собой идентификатор? Если это так, то да, вы можете увидеть улучшения производительности, поместив их в отдельную таблицу. Уменьшенное хранилище, более узкие внешние ключи (потому что вы можете превратить их в искусственный ключ) — все это должно повысить производительность. 01.12.2020
  • Все ли данные меняются день ото дня? В противном случае можно было бы значительно повысить производительность, если бы импортировались только те строки, которые были изменены или добавлены. 01.12.2020
  • @GordonLinoff Это измерения, у которых есть начало и конец. Некоторые из них длятся минуту, другие месяц, третьи случайное время. Таким образом, я мог загрузить их в разные таблицы в зависимости от продолжительности измерения. 01.12.2020
  • @GrantFritchey Все теги уникальны и хранятся в другой таблице вместе с активом, которому они принадлежат, единицей измерения по умолчанию и другими свойствами тегов. Я использую TAG_NAME в качестве ключа, чтобы другие люди, которые могут захотеть изучить эту таблицу, могли ее понять. Слишком ли сильно снижается производительность при использовании длинного ключа? 01.12.2020
  • @ Plato77 Данные в основном не меняются после загрузки, я буду добавлять ~ 1 миллион новых значений в день. 01.12.2020
  • Как долго вы собираетесь хранить данные? Через год у вас будет 365М строк, что будет не быстро. 02.12.2020
  • @ Алекс, минимум 10 лет ... Как вы думаете, использование INT TAG_ID ускорит выполнение запросов? 02.12.2020
  • Чем длиннее ключ, тем меньше строк хранится на странице и тем больше глубина индекса. Да, это повлияет на производительность. Теперь, для любого данного однострочного поиска будет ли CHAR(50) работать хуже, чем INT? Вероятно, недостаточно, чтобы иметь огромное значение. Теперь умножьте это на миллионы строк и миллионы поисковых запросов, даже не говоря о сканировании, и да, огромное влияние. 02.12.2020

Ответы:


1

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

  1. Из-за быстрого роста данных, я думаю, вам следует разделить таблицу фактов на несколько таблиц, таких как активная таблица и таблица исторического архива, различать по годам.
  2. Вы можете рассмотреть возможность использования индексы columnstore для сжатия данных и улучшения производительность запросов.
03.12.2020

2

Я бы использовал таблица измерения даты, настроенная с любыми конкретными столбцами, которые могут вам понадобиться для разделения и группировки ваших данных. Если вам нужны только числа «Год», «Месяц» и «День», то это все, что нужно вашему измерению даты. Но если вам нужны часы, минуты, недели, кварталы или что-то еще, вы также можете включить эти столбцы в таблицу измерения даты.

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

Тогда приведенная выше таблица фактов будет иметь отношение FK к таблице измерения даты для ваших START_DATETIME и END_DATETIME.

03.12.2020
Новые материалы
Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..