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

Question

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

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

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

---

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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