Ваше первое инстинктивное чувство по этому вопросу дизайна SqlServer

Question

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

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

Но один из разработчиков сказал: вам не нужно этого делать, мы просто запросим соединение (по двум таблицам), SqlServer настолько быстр, что вы не видите разницы.

Моя первая реакция была:объединение двух таблиц с записями 8М и 2М не может иметь значения «без разницы».

Каково ваше первое чувство по этому поводу?

РЕДАКТИРОВАТЬ: новые измерения: 400 записей за 5 минут

РЕДАКТИРОВАТЬ 2: возможно, вопрос не так ясен:

первое решение состоит в том, чтобы получить данные из таблицы временных меток и скопировать их в таблицу измерений после вставки записи измерений.В этом случае у нас есть действие, когда запись вставлена ​​И дополнительное (дублированное) значение метки времени.В этом случае мы запрашиваем ОДНУ таблицу только потому, что она содержит все данные.

Второе решение - объединить две таблицы в запросе.

Answer 1

При правильном индексе соединение не будет иметь значения *. Сначала я думал, что, если отчет запрашивает весь набор данных, объединения могут быть на самом деле быстрее, потому что буквально на 6 миллионов меньше временных меток, которые он должен прочитать с диска.

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

Answer 2

Честно говоря, в этом случае вам лучше всего попробовать оба решения и посмотреть, какое из них лучше. Настройка производительности - это искусство, когда вы начинаете говорить о больших наборах данных, и она сильно зависит не только от дизайна вашей базы данных, но и от аппаратного обеспечения и от того, что вы используете для разделения и т. Д. входящие данные. Поскольку у вас так много вставок, скорость вставки имеет решающее значение, и индекс, который вам необходим для поля даты и времени, имеет решающее значение для выбора производительности, поэтому вам действительно необходимо тщательно протестировать это. Не забудьте сбросить кеш при тестировании. И тестируйте несколько раз и, если возможно, тестируйте при типичной загрузке запроса.

Answer 3

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

Answer 4

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

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