производительность одной таблицы против объединенной двойной структуры

Question

Это не вопрос использования другого инструмента.Это не вопрос использования другой структуры данных.Это вопрос о ПОЧЕМУ Я вижу то, что вижу - пожалуйста, прочитайте до конца, прежде чем ответить.Спасибо.

ИСТОРИЯ

У меня есть одна таблица с одним условием, записи не удаляются.Вместо этого запись помечается как не активная (для этого есть поле), и в этом случае все поля (кроме идентификаторов и этого поля isActive) считаются неактуальными.

Еще об идентификаторах - есть два поля:

• id - int, первичный ключ, кластеризованный
• name - уникальный, varchar, внешний индекс

Как выполняется обновление, например (Я использую C # / Linq / MSSQL2005): я выбираю запись на основе имени, затем изменяю обязательные поля и фиксирую изменения, чтобы выполнить обновление (UPDATE использует идентификатор, а не имя).

Однако существуетпроблема с хранением.Так почему бы не разбить эту таблицу на двойную структуру - таблицу заголовков (id, name, isActive) и таблицу данных (id, остальные поля).В случае проблем с хранилищем мы можем реально удалить все записи из таблицы данных (для isActive = false).

edit (от Shimmy): заголовок + данные не извлекаются LINQ при соединении.Записи данных загружаются по требованию (и это всегда происходит из-за кода).

комментарий (по постеру): AFAIR соединение отсутствует, поэтому это не имеет значения.Данные для заголовков были загружены вручную.См. Ниже.

Производительность - (моя) теория

Теперь, как насчет производительности?Какой из них будет быстрее?Допустим, у вас есть 10000 записей в обеих таблицах (одна, заголовок, данные), и вы обновляете их одну за другой (все 3 таблицы) - поля isActive и некоторое поле из полей «data».

Мой расчетwas / is:

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

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

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

Результаты

Что бы я ни делал, обновлял, выбирал, вставлял, двойная структура либо немного лучше (скорость), либо на 30% быстрее.И теперь я все озадачен - я бы понял, что если бы я вставлял / обновлял / выбирал только записи заголовка, но в каждом случае записи данных также используются.

Вопрос - почему / как двойная структураможет быть быстрее?

Answer 1

Я думаю, что все сводится к тому, сколько данных выбирается, вставляется и обновляется.

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

INSERT case - аналогично вышеописанному, но связано с записью данных вместо их чтения.

UPDATE case - ваш код обновляет поле «isActive», которое, если я правильно его прочитал, является частью полей «header». В конфигурации с одной таблицей вы заставляете обновлять много строк для каждого изменения «isActive». В конфигурации с двумя таблицами вы обновляете только одну строку заголовка для каждого изменения «isActive».

Я думаю, что это случай преждевременной оптимизации. У меня такое ощущение, что вы поняли, что согласно правилам нормализации данных конфигурация с двумя таблицами была «лучше», но поскольку случай с одной таблицей, казалось, обеспечивал бы лучшую производительность, которую вы хотели использовать в этом проекте. К счастью, вы нашли время, чтобы проверить, что произойдет, и обнаружили, что наблюдаемая производительность не соответствует вашим ожиданиям. ХОРОШАЯ РАБОТА! Хотелось бы, чтобы больше людей уделили время, чтобы проверить подобные вещи. Я думаю, что урок, который нужно усвоить, состоит в том, что нормализация данных - это хорошо.

Помните, что лучшее время для оптимизации чего-либо - НИКОГДА ! Второе лучшее время для оптимизации - это , когда у вас наблюдаются проблемы с производительностью . худшее время для оптимизации - во время анализа.

Надеюсь, это поможет.

Answer 2

Предположение: Sql Server для базы данных.

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

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

Answer 3

Вы смотрели на два плана запроса?Это часто выдает это.

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

Кроме того, блокировки более детализированы -Первое обновление может записать в table1, а затем второе обновление может записать в table1, пока вы заканчиваете table2.