SQL Server: максимальное количество строк в таблице - PullRequest
69 голосов
/ 17 апреля 2009

Я разрабатываю программное обеспечение, которое хранит много данных в одной из таблиц базы данных (SQL Server версии 8, 9 или 10). Допустим, в эту таблицу вставляется около 100 000 записей в день. Это около 36 миллионов записей в год. Из-за боязни потерять производительность я решил каждый день создавать новую таблицу (таблицу с текущей датой в названии), чтобы уменьшить количество записей в таблице.

Не могли бы вы сказать мне, была ли это хорошая идея? Есть ли предел записей для таблиц SQL-сервера? Или вы знаете, сколько записей (в большей или меньшей степени) можно сохранить в таблице, прежде чем производительность значительно снизится?

Ответы [ 12 ]

83 голосов
/ 07 октября 2010

Вот некоторые из спецификаций максимальной емкости для SQL Server 2008 R2

  • Размер базы данных: 524 272 терабайта
  • Базы данных на экземпляр SQL Server: 32 767
  • Файловых групп в базе данных: 32,767
  • файлов в базе данных: 32,767
  • Размер файла (данных): 16 терабайт
  • Размер файла (журнал): 2 терабайта
  • строк в таблице: ограничено доступным хранилищем
  • Таблиц на базу данных: Ограничено количеством объектов в базе данных
36 голосов
/ 04 марта 2014

У меня есть таблица из трех столбцов с более чем 6 миллиардами строк в SQL Server 2008 R2.

Мы запрашиваем его каждый день, чтобы составлять ежеминутные диаграммы системного анализа для наших клиентов. Я не заметил каких-либо падений производительности базы данных (хотя тот факт, что она увеличивается ~ 1 ГБ каждый день, делает управление резервными копиями немного более сложным, чем хотелось бы).

Обновление июль 2016

Row count

Мы сделали это до ~ 24,5 миллиардов строк до того, как резервные копии стали достаточно большими, чтобы мы решили усечь записи старше двух лет (~ 700 ГБ, хранящихся в нескольких резервных копиях, в том числе на дорогих лентах). Стоит отметить, что производительность не была значительным мотиватором в этом решении (то есть, он все еще работал отлично).

Для тех, кто пытается удалить из SQL Server 20 миллиардов строк, я настоятельно рекомендую эту статью . Соответствующий код на случай, если ссылка умрет (подробное объяснение см. В статье):

ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO

BEGIN TRY
    BEGIN TRANSACTION
        -- Bulk logged 
        SELECT  *
        INTO    dbo.bigtable_intermediate
        FROM    dbo.bigtable
        WHERE   Id % 2 = 0;

        -- minimal logged because DDL-Operation 
        TRUNCATE TABLE dbo.bigtable;  

        -- Bulk logged because target table is exclusivly locked! 
        SET IDENTITY_INSERT dbo.bigTable ON;
        INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
        SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
        SET IDENTITY_INSERT dbo.bigtable OFF;
    COMMIT
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK
END CATCH

ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO

Обновление ноябрь 2016

Если вы планируете хранить столько данных в одной таблице, не делайте этого. Я настоятельно рекомендую вам рассмотреть разбиение таблиц (вручную или со встроенными функциями, если вы используете Enterprise Edition). Это делает удаление старых данных так же просто, как усечение таблицы один раз в неделю (месяц / месяц и т. Д.). Если у вас нет Enterprise (а у нас его нет), вы можете просто написать скрипт, который запускается раз в месяц, удаляет таблицы старше 2 лет, создает таблицу следующего месяца и создает динамическое представление, объединяющее все разделы. столы вместе для удобства запросов. Очевидно, что «раз в месяц» и «старше 2 лет» должны быть определены вами исходя из того, что имеет смысл для вашего варианта использования. Удаление непосредственно из таблицы с десятками миллиардов строк данных а) займет ОГРОМНОЕ количество времени и б) заполнит журнал транзакций сотни или тысячи раз.

32 голосов
/ 17 апреля 2009

Трудно дать общий ответ на это. Это действительно зависит от ряда факторов:

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

и т.д.

Как ответили в другом месте здесь, 100 000 в день и, следовательно, на таблицу излишне - я бы рекомендовал ежемесячно или еженедельно, возможно, даже ежеквартально Чем больше у вас таблиц, тем больше будет кошмар обслуживания / запроса.

19 голосов
/ 17 апреля 2009

Я не знаю ограничения на число строк, но я знаю таблицы с более чем 170 миллионами строк. Вы можете ускорить его, используя многораздельные таблицы (2005+) или представления, которые соединяют несколько таблиц.

18 голосов
/ 17 апреля 2009

Я не знаю конкретно MSSQL, но 36 миллионов строк невелики для базы данных предприятия - при работе с базами данных мэйнфреймов 100 000 строк звучат для меня как таблица конфигурации: -).

Хотя я не большой поклонник некоторых программного обеспечения Microsoft, это не Access, о котором мы здесь говорим: я предполагаю, что они могут справиться с довольно существенными размерами баз данных с помощью своих корпоративных СУБД.

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

5 голосов
/ 07 октября 2010

У нас есть таблицы в SQL Server 2005 и 2008 с более чем 1 миллиардом строк (30 миллионов добавляются ежедневно). Я не могу представить, как спускаюсь в гнездо крыс, чтобы каждый день разбивать его на новый стол.

Гораздо дешевле добавить соответствующее дисковое пространство (которое вам все равно нужно) и оперативную память.

4 голосов
/ 22 апреля 2009

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

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

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

3 голосов
/ 07 октября 2010

Мы переполнили целочисленный первичный ключ один раз (что составляет ~ 2,4 миллиарда строк) в таблице. Если есть ограничение на число строк, вы вряд ли когда-либо достигнете всего лишь 36 миллионов строк в год.

2 голосов
/ 22 апреля 2009

Вы можете заполнять таблицу, пока у вас не будет достаточно места на диске. Для повышения производительности вы можете попробовать перейти на SQL Server 2005, а затем разбить таблицу и разместить части на разных дисках (если у вас есть конфигурация RAID, которая действительно может вам помочь). Разбиение возможно только в корпоративной версии SQL Server 2005. Пример разметки можно посмотреть по этой ссылке: http://technet.microsoft.com/en-us/magazine/cc162478.aspx

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

Надеюсь, это помогло ...

0 голосов
/ 07 сентября 2012

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...