Конструкция БД: повышает ли производительность наличие двух таблиц (одна оптимизирована для чтения, другая для записи)?

Question

Я думаю о проблеме проектирования БД.

Например, я проектирую этот веб-сайт stackoverflow, где у меня есть список вопросов.

Каждый Вопрос содержит определенные метаданные, которые, вероятно, не изменятся. Каждый Вопрос также содержит определенные данные, которые будут постоянно изменяться (Дата последнего просмотра, Всего просмотров ... и т. Д.)

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

OR

Было бы лучше хранить все в одном столе.

Я не уверен, так ли это, но при обновлении блокируется ли ROW?

Answer 1

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

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

А что касается блокировок на уровне строк, это зависит от механизма хранения - некоторые используют блокировку на уровне строк, а некоторые используют блокировки таблиц.

Answer 2

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

Ваш rdbms ваш друг, а не ваш противник.

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

Я бы посмотрел на кэширование ваших результатов либо локально с помощью кэширования Asp.net, либо с использованием MemCached.

Answer 7

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

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