В настоящее время у нас есть база данных SQL Server 2000 с одной таблицей, содержащей данные для нескольких пользователей. Данные имеют ключ memberid, который является целочисленным полем. Таблица имеет кластеризованный индекс по memberid.
В таблице сейчас около 200 миллионов строк. Индексирование и обслуживание становятся проблемами. Мы обсуждаем разделение таблицы на одну таблицу для каждой пользовательской модели.
Это означало бы, что в итоге мы получим очень большое количество таблиц, потенциально, вплоть до 2 147 483 647, учитывая только положительные значения.
Мои вопросы:
Есть ли у кого-нибудь опыт установки SQL Server (2000/2005) с миллионами таблиц?
Каковы последствия этой архитектуры в отношении обслуживания и доступа с использованием Query Analyzer, Enterprise Manager и т. Д.
Каковы последствия наличия такого большого количества индексов в экземпляре базы данных?
Все комментарии приветствуются.
Спасибо
Изменить: я не согласен с переносом этого вопроса на Serverfault. Это вопрос, связанный с программированием.
Несколько мыслей здесь:
1) Не делай этого. Шутки в сторону. Миллионы столов были бы кошмаром и, скорее всего, вызовут гораздо больше проблем, чем решат.
2) Если вы действительно хотите разбить таблицу на несколько таблиц, вам не нужно использовать их так много. В зависимости от вашего оборудования я ожидаю, что 50 миллионов строк не будут проблемой, поэтому вы можете разделить свои данные на 4 таблицы.
3) Что бы я сделал, если бы это было возможно, так это обновился до SQL Server 2005 или 2008 и использовал разделение таблиц. Это позволит вам разделить данные в таблице. Не идеальное решение, но намного лучше, чем миллионы таблиц.
Чтобы ответить на ваши конкретные вопросы, я бы сказал, что маловероятно, что SQL Server может обрабатывать такое количество таблиц в одном экземпляре, и если он может иметь одну таблицу на запись, то анализатор запросов и т. Д. Будет довольно бесполезным.
Быстрое добавление: с сайта Microsoft:
Объекты базы данных включают все таблицы, представления, хранимые процедуры, расширенные хранимые процедуры, триггеры, правила, значения по умолчанию и ограничения. Сумма количества всех этих объектов в базе данных не может превышать 2 147 483 647.
http://msdn.microsoft.com/en-us/library/aa933149(SQL.80).aspx
Довольно удивительно, что это ТОЧНО тот номер, который вы указали ... Хммм ...
Ведение индекса должно осуществляться на основе существующей фрагментации, а не вслепую. С кластеризованным столбцом IDENTITY вам не о чем беспокоиться. SQL Fool's скрипт дефрагментации поможет.
200 миллионов строк - это не так уж много и пока не стоит разбивать ИМХО из-за накладных расходов на запросы, многих имен таблиц, требующих динамического SQL и т. Д. Если у вас нет крошечного окна обслуживания, возможно
У нас есть около 6 миллионов строк в день, вставленных, FWIW в одной таблице.
Боль хуже, чем выигрыш, основанный на предоставленной вами информации.
Разделение на такое количество таблиц - кошмар, и его совсем не рекомендуется. Среди других сложностей подумайте о сложности, необходимой для добавления нового пользователя - нужно ли динамически создавать новую таблицу?
Ответ - просто лучшая индексация, специально разработанная для запросов, которые вы используете. Поскольку вы не детализировали эти вопросы, я не могу дать вам конкретных рекомендаций.
В общем, тем не менее, мы поддерживаем многие базы данных с таблицами такого размера, и да, это может быть проблемой, но это определенно возможно.
если ты делать решите там реализовать разделы, использовать другой способ разделения данных (возможно, текущие данные по сравнению со старыми данными) и разумно небольшое количество разделов. Имейте в виду, что если вы сделаете это «вручную» (вместо использования функции разделения SQL 2005+), то все запросы к этим разделенным таблицам, вероятно, придется перепроектировать.
Изменить: в конкретном ответе на одну часть вашего вопроса, да, Enterprise Manager / Query Analyzer может начать делать очень плохие вещи, когда у вас огромное количество таблиц. У нас были плохо спроектированные БД с тысячами таблиц, и вы даже не можете развернуть папку «Таблицы» в древовидном представлении, не дожидаясь ДОЛГОГО ВРЕМЕНИ, чтобы она перечислила их все.
Один на пользователя кажется излишним и грубым для вашей кодовой базы. Вам более или менее придется использовать динамический SQL в любой хранимой процедуре, которая использует эти таблицы, что определенно усложняет вашу жизнь и будущую разработку и тестирование. (Я говорю по опыту - у нас были очень сложные таблицы, которые мы создавали ежедневно; все взаимодействия с этими таблицами были динамическим SQL.)
Не зная требований приложений, использующих эти данные, могли бы вы перенести старые данные в архив или таблицу / таблицы истории?
Для SQL 2k5 / 2k8 вы можете использовать секционированные таблицы, которые также могут помочь и абстрагировать несколько таблиц от ваших запросов и приложений. Есть некоторые проблемы с секционированными таблицами, но здесь они могут сработать для вас.
С таким объемом вам придется провести какое-то конкретное прототипирование и тестирование, поскольку нет универсального ответа.
Похоже, разделение таблиц - это лучший вариант. Однако вам понадобится как минимум SQL Server 2005.
Вот хорошая статья на эту тему, чтобы вы начали Кимберли Трипп Статья MSDN
Я бы пересмотрел дизайн.
Вы говорите, что он кластеризован по memberid, но это может привести к разделению страниц (и фрагментации) при добавлении данных. Лучше сгруппировать по возрастающей суррогатной идентичности (и иметь уникальный индекс, возможно, даже первичный ключ, на бизнес-ключе, который будет включать memberid).
В качестве альтернативы, даже если не кластеризация, у вас должен быть уникальный индекс для memberid и уникальная часть оставшихся столбцов, поскольку это звучит так, как будто у вас есть несколько строк на член. Индекс только для memberid вряд ли будет покрывать.