Максимальна ємність таблиці в SQL Server 2008


11

У мене є додаток, який щорічно вставляє в таблицю більше 1 мільярда рядків. Ця таблиця містить деякі varcharта bigintстовпці та один стовпчик крапки.

1 мільярд рядків складається з даних історії, які зберігаються з метою відстеження. Тож мені було цікаво, чи буде обмеження ємності таблиці, якщо я продовжуватиму цю структуру відповідно до цієї статті MSDN про максимальний розмір таблиці .

Чи розмір файлу даних, згаданий у цьому посиланні, відноситься до групи файлів даних таблиці?


@marc_s дякую, що це зробив. не соромтеся приєднатися до нас у The Heap, де, серед іншого, ми привертаємо колективну увагу до них
— JNK

Який максимальний розмір кожного ряду?
— Нік Чаммас

Відповіді:


6

Практичного обмеження немає, крім місця на диску. Я прочитав таблицю, з якою ви повністю пов'язані, і перевірив її.

Якщо вам потрібно перевищити 16 ТБ, вам потрібно кілька файлів (проста процедура).


Я думаю, що цього можна досягти, розділивши таблицю та змусивши розділити використовувати різні групи файлів, якщо я маю рацію?
— GAP

1
Це навіть не потрібно. Просто додайте новий файл (до існуючої групи файлів). SQL Server почне заповнювати всі файли рівномірно. Якщо один файл більше не може рости, він просто виросте інший файл.
— usr

2

таблиця на сервері sql 2008 може обробляти велику кількість записів, і як згадував @usr, це залежить від місця на диску, але рекомендується, якщо у вашій таблиці є багато рядків і вона продовжує рости, ви використовуєте http://partnet.microsoft. com / en-us / library / dd578580 (v = sql.100) .aspx

Коли таблиця бази даних зростає до сотень гігабайт або більше, завантажувати нові дані, видаляти старі дані та підтримувати індекси може ускладнюватися

більше інформації про це

http://msdn.microsoft.com/en-us/library/ms190787.aspx

і як його реалізувати http://blog.sqlauthority.com/2008/01/25/sql-server-2005-database-table-partitioning-tutorial-how-to-horizontal-partition-database-table/


Потрібно бути дуже обережним щодо розділення. Функцію та ключ потрібно ретельно продумати, а також випадок використання. Логічне поле для розбиття ніколи не може використовуватися в жодному із запитів, які б знищили продуктивність.
— JNK

Правда, але мільярди рядків в одній таблиці також призведе до ефективності, також існує можливість розбиття даних ур у багатьох таблицях, наприклад, окрема таблиця на кожен рік, і якщо ви хочете переглянути всі дані, ви можете використовувати перегляд, але на принаймні, видалення та оновлення будуть швидшими для кожної таблиці
— AmmarR

вставки на величезній таблиці не обов’язково повільні, це залежить від клавіш та індексів. Я щомісяця завантажую близько 30м рядків у таблицю, що містить 700м існуючих рядків, і ми не робимо жодного розділення. Я намагався розділити, але це спричинило більше проблем, ніж вирішило. Це насправді питання, якщо ви хочете його перевірити.
— JNK

Я думав про переміщення моїх даних історії в окрему таблицю та створення перегляду об'єднання, щоб вони могли використовуватись додатком, коли потрібна історія запитів + ​​останні дані, що становить приблизно менше 25% запитів, які у мене є в системі. Чи буде це ефективніше, ніж мати кілька файлів даних або розділити таблицю на основі стовпця, який позначає дані як останні? Від операцій вводу-виводу, які будуть ефективнішими? сумніваюся, що це буде однаково з точки зору IO в обох рішеннях.
— GAP

будь-який підхід, який ви застосовуєте, має свої найкращі практики, які можуть зробити це добрим чи поганим, я маю на увазі, якщо у вас є багато таблиць, ваш запит буде складним, і його буде важко підтримувати, якщо у вас є одна таблиця і ви використовуєте розділ таблиці, є різні роздуми, наприклад ваше видання sql повинно бути корпоративним тощо. Наявність багатьох файлів даних рекомендовано для кращих операцій
— вводу-

0

Можливо, вигляд з розділеним номером спрацює.

Стаття MSDN із використання розділеного перегляду :

Розділені представлення дозволяють розділяти дані у великій таблиці на менші таблиці членів. Дані розподіляються між таблицями-членами на основі діапазонів значень даних в одному з стовпців. Діапазони даних для кожної таблиці-членів визначаються в обмеженні CHECK, зазначеному в стовпці розділення. Потім визначається вид, який використовує UNION ALL для об'єднання вибору всіх таблиць-членів в один набір результатів. Коли оператори SELECT, що посилаються на представлення даних, задають умову пошуку в стовпці розділу, оптимізатор запитів використовує визначення обмежень CHECK для визначення того, яка таблиця-член містить рядки.

Я не впевнений, чим він відрізняється від Розділеної таблиці, про яку AmmarR надав інформацію у своїй відповіді.

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