SQL Server: максимальное количество строк в таблице [закрыто]

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

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

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

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

и т.п.

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

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

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

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

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

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

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

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

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). Это делает удаление старых данных таким же простым, как усечение таблицы один раз в неделю (неделю / месяц и т. Д.). Если у вас нет Enterprise (которого у нас нет), вы можете просто написать сценарий, который запускается один раз в месяц, удаляет таблицы старше 2 лет, создает таблицу следующего месяца и восстанавливает динамическое представление, которое объединяет все разделы. таблицы вместе для облегчения запросов. Очевидно, что «один раз в месяц» и «старше 2 лет» должны быть определены вами в зависимости от того, что имеет смысл для вашего варианта использования.

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

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

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

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

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

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

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

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

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

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

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

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

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

Самая большая таблица, с которой я столкнулся в SQL Server 8 в Windows 2003, составляла 799 миллионов с 5 столбцами. Но вопрос о том, является ли это хорошей волей, нужно оценивать по SLA и варианту использования - например, загрузить 50–100000000 записей и посмотреть, работает ли это по-прежнему.

SELECT Top 1 sysobjects.[name], max(sysindexes.[rows]) AS TableRows, 
  CAST( 
    CASE max(sysindexes.[rows]) 
      WHEN 0 THEN -0 
      ELSE LOG10(max(sysindexes.[rows])) 
    END 
    AS NUMERIC(5,2)) 
  AS L10_TableRows 
FROM sysindexes INNER JOIN sysobjects ON sysindexes.[id] = sysobjects.[id] 
WHERE sysobjects.xtype = 'U' 
GROUP BY sysobjects.[name] 
ORDER BY max(rows) DESC

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