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

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

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

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

Обновление. Прошло около полугода с момента создания таблиц. Следуя советам ниже, я создал несколько огромных таблиц. С тех пор я был экспериментировал с индексами и принял решение о кластеризованном индексе в первых двух столбцах (код больницы и код отдела), на котором мы разделили бы таблицу у нас был Enterprise Edition. Эта настройка работала нормально до недавнего времени, как предсказал Галвегян, возникают проблемы с производительностью. Восстановление индекса занимает много времени, пользователи блокируют друг друга, запросы часто занимают больше времени, чем требуется, и для большинства запросов он рассчитывает сначала скопировать соответствующую часть данных в временную таблицу, создать индексы в таблице temp и запустить запрос. Это не так, как должно быть. Поэтому мы рассматриваем возможность покупки Enterprise Edition для использования секционированных таблиц. Если покупка не может пройти, я планирую использовать обходное решение для выполнения разбиения на разделы в стандартной версии.

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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