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


80

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

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


33
«Программисты тратят огромное количество времени на размышления или беспокойство о скорости некритичных частей своих программ, и эти попытки повышения эффективности на самом деле имеют сильное негативное влияние, когда рассматриваются отладка и обслуживание. Мы должны забыть о небольшой эффективности, например 97% случаев: преждевременная оптимизация является корнем всех зол. Однако мы не должны упускать наши возможности в этих критических 3% ». Knuth 1974
Мэтью Лок

Ответы:


36

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

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

и т.п.

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


13
Я хотел бы еще раз усилить «более серьезный кошмар обслуживания / запросов» - по личному опыту я бы избегал разбиения на таблицы, как чумы.
Дэниел Джеймс Брайарс

92

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

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

22
Я подозреваю, что если у вас будет более 9 223 372 036 854 775 807 строк, вы столкнетесь с проблемами (максимальный размер a bigint)
Мартин Смит

11
Вы когда-нибудь вычисляли количество лет, которое потребовалось бы, чтобы достичь этого количества строк при 100000 строках в день, упомянутых OP?
Erwin Smout

75
Публикация для ленивых: 252 695 124 лет.
NotMe 06

18
@NotMe Не оживлять и придираться, но у меня 252695124297 лет. (Иногда мне жаль, что я не из тех ленивых людей, о которых вы упомянули)
philthyfool

4
@philthyfool Один день високосного года - огромная разница. Я получаю 252,522,163,911. Кроме того, это были совершенно хорошие минуты моей жизни, и я не могу вернуться к ним сейчас.
Suamere

53

У меня есть таблица из трех столбцов с чуть более чем 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 лет» должны быть определены вами в зависимости от того, что имеет смысл для вашего варианта использования.


14
До 10,5 миллиардов, все еще пыхтит. Только не пытайтесь выполнить COUNT (). ;)
Дэн Бечард

6
Прошел год, у нас 16,5 миллиардов строк. Мы только что добавили дополнительный источник данных, поэтому теперь он растет немного быстрее. Мы также переместили эту базу данных в отдельный экземпляр SQL, чтобы позволить нам выделить память, не перегружая другие базы данных на сервере. Я все еще могу нанести на график любую точку данных за любой 24-часовой период за последние 3 года менее чем за секунду. Нашим аналитикам это нравится.
Дэн Бечард,

Я знаю, что это было давно, но не могли бы вы сказать мне, на каком оборудовании вы использовали эту базу данных? Очень любопытно, поскольку у нас есть таблица из 5 миллиардов строк, которые растут на 1 миллиард в год, и ik хотел бы узнать, не станет ли это проблематичным в будущем
Jeroen1984

3
@ Jeroen1984 Это виртуальная машина, работающая на хосте Hyper-V ProLiant DL360e Gen8 с двумя процессорами Intel (R) Xeon (R) CPU E5-2430. У виртуальной машины 38 ГБ статически выделенной оперативной памяти и некоторое количество виртуальных процессоров, о которых я не помню.
Дэн Бечард

19

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


19

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

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

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


5

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

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


4

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

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

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


3

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


2

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

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

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


0

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


2
Не уверен, что это действительно ответ.
Эндрю Барбер,

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

Я выполнил этот запрос и получил такой результат. У меня есть таблица UrlCategories в моей базе данных. Итак, что означает этот результат? Название TableRows L10_TableRows UrlCategories 7 0.85
Адитья Бокаде,

-4

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


4
Не уверен, как это ответ на заданный вопрос.
Эндрю Барбер,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.