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