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

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

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

12 62
sql-server database-design

12 ответов:

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

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

etc.

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

31

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

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

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

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

Обновление Июля 2016

Row count

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

28

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

18

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

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

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

15

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

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

5

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

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

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

3

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

3

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

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

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

2

самая большая таблица, с которой я столкнулся на SQL Server 8 на Windows2003, была 799 миллионов с 5 столбцами. Но независимо от того,является ли это хорошей волей,следует измерять по отношению к SLA и случаю использования - например, загрузить 50-100 000 000 записей и посмотреть, работает ли он по-прежнему.

0
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
-1

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

-3