SQL Server: максимальна кількість рядків у таблиці [закрито]


80

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

Не могли б ви сказати мені, чи це була гарна ідея? Чи існує обмеження записів для таблиць SQL-сервера? Або ви знаєте, скільки записів (більше чи менше) можна зберегти в таблиці до того, як продуктивність значно знизиться?


33
"Програмісти витрачають величезну кількість часу, думаючи про швидкість некритичних частин своїх програм або турбуючись про них, і ці спроби підвищення ефективності насправді мають сильний негативний вплив при розгляді налагодження та обслуговування. Слід забути про малу ефективність, сказати про 97% випадків: передчасна оптимізація - корінь усього зла. Проте ми не повинні втрачати свої можливості в цих критичних 3% ". Knuth 1974
Matthew Lock

Відповіді:


36

Важко дати загальну відповідь на це. Це насправді залежить від ряду факторів:

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

тощо

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


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 рядків / день, згаданий ОП?
Erwin Smout

75
Розміщення цього для ледачих: 252 695 124 роки.
NotMe

18
@NotMe Не для того, щоб відроджувати і нітрохи, але я отримав 252695124297 років. (Іноді я бажаю, щоб я був із лінивого населення, про якого ви згадали)
philthyfool

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

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 мільярд на рік, і я хотів би з’ясувати, чи це починає ставати проблематичним у майбутньому
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 мільйонів рядків в одній таблиці. Поки ви тримаєте свої індекси в порядку, все повинно бути добре. Головне - мати купу пам’яті, щоб індекси не потрібно було міняти на диск.

З іншого боку, це залежить від того, як ви використовуєте дані, якщо вам потрібно зробити багато запитів, і його малоймовірні дані будуть потрібні, які охоплюють кілька днів (тому вам не потрібно буде приєднуватися до таблиць), це буде швидше розділити його на кілька таблиць. Це часто використовується в таких додатках, як управління промисловим процесом, де ви можете читати значення на прикладних 50000 приладах кожні 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-100 000 000 записів і перевірити, чи все ще це працює.


2
Не впевнений, що це насправді відповідь взагалі.
Andrew Barber

-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
Aditya Bokade

-4

Розділіть таблицю щомісяця. Це найкращий спосіб обробляти таблиці з великим щоденним напливом, будь то оракул або MSSQL.


4
Не знаю, як це відповідь на конкретне запитання.
Andrew Barber
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.