Дизайн базы данных: один огромный стол или отдельные таблицы?

Question

В настоящее время я разрабатываю базу данных для использования в нашей компании. Мы используем SQL Server 2008. В базе данных будут храниться данные, собранные от нескольких клиентов. Целью базы данных является получение совокупных контрольных показателей по нескольким клиентам.

В последнее время я беспокоюсь о том, что один стол, в частности, будет очень большим. Каждый клиент имеет приблизительно 20 000 000 рядов данных, и в базе данных в ближайшее время будет 30 клиентов (если не больше). В этой таблице будет сделано много запросов. Я уже замечаю проблемы с производительностью, и пользователи временно заблокированы.

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

---

Update: Прошло уже около полугода, так как мы впервые создали таблицы. Следуя советам ниже, я создал несколько огромных таблиц. С тех пор я был experimenting with indexes и принял решение о кластеризованном индексе в первых двух столбцах (код больницы и код отдела), на котором мы разделили бы таблицу, если бы у нас была Enterprise Edition. Эта настройка работала нормально до недавнего времени, как предсказал Галвегян, возникают проблемы с производительностью. Восстановление индекса занимает много времени, пользователи блокируют друг друга, запросы часто занимают больше времени, чем требуется, и для большинства запросов он рассчитывает сначала скопировать соответствующую часть данных в временную таблицу, создать индексы в таблице temp и запустить запрос. Это не так, как должно быть. Поэтому мы рассматриваем возможность покупки Enterprise Edition для использования секционированных таблиц. Если покупка не может пройти, я планирую использовать workaround to accomplish partitioning in Standard Edition.

Answer 1

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

Answer 2

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

Answer 3

Таблицы разделов по соображениям производительности называются sharding. Кроме того, схема базы данных может быть более или менее нормализована. Нормализованная схема имеет отдельные таблицы с отношениями между ними, а данные не дублируются.

Answer 4

Я предполагаю, что ваша база данных правильно нормализована. Не должно быть проблем с рассмотрением объема данных, который вы ссылаетесь на одну таблицу в SQL Server; я думаю, что вам нужно сделать, это проверить свои индексы.

Answer 5

Хранилище данных должно быть большим (ключ в названии). Двадцать миллионов строк - это средний по стандартам складирования, хотя шестьсот миллионов можно считать большими.

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

Разделение может быть полезно, особенно если у вас есть четкие демаркации, например, как в вашем случае, ЗАКАЗЧИК. Вы должны знать, что разбиение на разделы может ухудшить производительность запросов, которые пересекают зерно ключа секционирования. Так что это не серебряная пуля.

Answer 6

Если вы находитесь на сервере MS SQL и хотите сохранить одну таблицу, то разбиение на таблицы может быть одним из решений.

Answer 7

Поскольку вы отметили свой вопрос как «datawarehouse», я предполагаю, что вы знаете некоторые вещи о предмете. В зависимости от ваших целей вы можете пойти на звездообразную схему (многомерную модель с фактом и размерностью). Храните все данные быстрого обмена в 1 таблице (по каждому предмету) и данные замедления в таблицах другого измерения/снежинки.

Другой вариант - метод DataVault Дэн Линдштедт. Это немного сложнее, но обеспечивает полную гибкость.

http://danlinstedt.com/category/datavault/

Answer 8

Держите одну таблицу - 20M строк не столь велика, и клиенты не точно вид таблицы, вы можете легко «архив от» и aggrevation поиска нескольких таблиц, чтобы найти клиента не стоит усилий (SQL, вероятно, будет намного эффективнее при поиске по BTREE, чем ваше собственное изобретение)

Однако вам нужно будет изучить проблемы с производительностью и блокировкой - это предотвратит масштабирование вашего db.

Answer 9

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

Answer 10

Partioning - это определенно то, что нужно изучить. У меня была база данных с двумя таблицами. Каждая таблица содержала около 30-35 миллионов записей. С тех пор я объединил это в одну большую таблицу и присвоил хорошие индексы. До сих пор мне не приходилось разбивать эту таблицу, так как она работает, но я продолжаю разграничение. Одна вещь, которую я заметил, по сравнению с тем, когда данные были отложены, и это импорт данных. Сейчас он медленнее, но я могу жить с этим, так как инструмент импорта может быть переписан; o)

Answer 11

Один стол и таблица использования стола.

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

Answer 12

В правильно спроектированной базе данных, это не огромное количество записей, а сервер SQl должен обрабатывать с легкостью.

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

Также изучите текущие запросы, если у вас возникли проблемы с производительностью. Если у вас нет правильной индексации (вы, например, указали поля внешнего ключа?), Запросы будут медленными, если у вас нет sargeable запросов, они будут медленными, если вы используете коррелированные подзапросы или курсоры, они будут медленными. Вы возвращаете больше данных, чем требуется striclty? Если вы выбрали * в любом месте своего производственного кода, избавитесь от него и верните только нужные вам поля. Если вы использовали представления, которые вызывают представления, которые вызывают представления, или если вы использовали таблицу EAV, у вас будут показатели производительности на этом уровне. Если вы позволили фреймворку автоматически генерировать SQl-код, у вас могут возникнуть проблемы с перфорированием. Помните, что Профайлер - ваш друг. Конечно, у вас также может возникнуть проблема с аппаратным обеспечением, для этого количества записей вам понадобится выделенный сервер с хорошим размером. Это не сработает для запуска этого на вашем веб-сервере или в небольшом ящике.

Я предлагаю вам нанять профессиональный dba с опытом настройки производительности. Это довольно сложный материал.Базы данных, требуемые программистами приложений, часто являются плохими исполнителями, когда они получают реальное количество пользователей и записей. База данных ДОЛЖНА быть разработана с учетом целостности данных, производительности и безопасности. Если вы этого не сделали, изменения в их наличии очень тонкие.

Answer 13

Это один плоский стол (нет конкретной модели)? Как правило, в хранилищах данных у вас либо есть нормализованная модель данных (как минимум, третья нормальная форма, как правило, в модели отношения сущности), либо у вас есть размерные данные (метод или вариации Кимбалла - обычно таблицы фактов с соответствующими таблицами измерений в наборе звезды).

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