Дизайн великої таблиці SQL


17

У мене є загальне питання щодо дизайну таблиць (ів) SQL Server 2008. Наразі у нас є стіл, який становить понад 600 ГБ і зростає приблизно на 3 ГБ на день. Ця таблиця має відповідні обмеження, але вона стає основною перевіркою під час запуску запитів і саме через її розмір. Питання полягає в тому, чи слід розділити таблицю на кілька таблиць за роком і місяцем (це відповідатиме тому, як інші відділи розбивають свої великі набори даних) чи слід використовувати розділ, вбудований у SQL Server. Здається, що для використання розділів потрібно менше змін коду. З того, що я читав під час розподілу, ви все ще просто запитуєте одну таблицю, і сервер обробляє, як отримати дані. Якби ми пройшли маршрут декількох таблиць, нам доведеться обробляти витягування даних з кількох таблиць.


1
Чи потрібно зробити якісь оптимізації: занадто широкі типи даних, перекриваються або невикористані індекси тощо?
gbn

Можливо, я ще не дивився повз індекси для інших оптимізацій. Чи є у вас рекомендації?
HunterX3

Відповіді:


11

"Ця таблиця має відповідні обмеження, але вона стає основною перевіркою при запуску запитів"

Сам розділ не допомагає виконати запит, якщо SQL Server не зможе усунути розділи під час запуску запиту. Ваш пункт WHERE повинен відповідати тому, як ви розділите. Ми отримуємо лише одне поле, яке буде використано як поле для розбиття, тому якщо це поле не включено до вашого пункту WHERE, ви все одно, можливо, скануєте всю таблицю, незважаючи на розділи.

"і саме через його розмір."

Розмежування може полегшити певні операції технічного обслуговування, але все ж є речі, які ми не можемо робити на основі розділу «за розділом». Якщо технічне обслуговування індексу та оновлення статистики створюють проблеми, вам краще розділити дизайн на архівну таблицю та оновлену в реальному часі таблицю. Коли вам потрібно періодично переміщувати дані з живої таблиці в таблицю архіву, ви робите це, перебудовуйте індекси зі 100% -ним коефіцієнтом заповнення, оновлюйте статистику при повному скануванні, а потім встановлюйте її групу файлів лише для читання. Розбиття файлів може допомогти при завантаженні архівних таблиць - але розділення живої таблиці може не робити. (Я викидаю тут кілька вдосконалених концепцій так, ніби це швидко і просто, але я просто замальовую тут деякий фон.)

"Здається, що для використання розділів потрібно менше змін коду."

Сорта свого роду - це виглядає так на перший погляд, але чим більше ви потрапляєте в нього, у вас є такі варіанти, як розділені види. Ви можете перейменувати існуючу таблицю, поставити її на її місце, а потім можете внести власні зміни в основні таблиці (і додати кілька таблиць), не змінюючи додаток.

Тут я писав більше про підводні камені перегородки:

http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/


3
Улюблена цитата з цієї статті, безумовно, "Функції розділів та схеми легко спроектувати неправильно".
Марк Сторі-Сміт

7

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

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

Якщо характер ваших даних змінюється від місяця до місяця, року в рік, перегляди з розділеними розмірами також можуть допомогти. Уявіть, що роздрібний продавець, який постійно змінював свої лінійки продуктів, таким чином, щоб мати незначну послідовність у діапазоні продуктів Product.ProductId, що застосовується з року в рік. За допомогою єдиної таблиці замовлення / замовлення та, отже, єдиної гістограми статистики статистика мало запропонує оптимізатору запитів. Таблиця на рік (Order_2010, Order_2011, OrderLine_2010, OrderLine_2011), розподілена за місяцем та поєднана з переглядами з розділеними параметрами (Order, OrderLine), надасть більш детальну та потенційно корисну статистику для оптимізатора.

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

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

Продуктивність, як правило, є номером 1, тому що люди дивляться на розділення. Особисто я вважаю, що поліпшення часу відновлення є рівною або більшою користю, ніж VLDB. Знайдіть трохи часу, щоб зрозуміти часткову доступність та відновлення по частинах, перш ніж розпочати роботу, оскільки це може вплинути на ваш підхід.

Якщо у вас не ідеальний, але нечастий процес надсилання резервних копій по мережі, можливо, ви будете шукати 3-годинного часу відновлення ваших поточних 600 Гб. Через рік, коли ви провалили 1,5 ТБ, у вас виникла проблема.


1
+1 Для "статистики стовпців ведуться лише за столом", і я хотів би, щоб я міг ще +1 для посилань на Кімберлі та Кендра.
Метт M

1

Як ви вже сказали, у вас є два варіанти:

  1. Використовуйте кілька таблиць
  2. Використовуйте розділення

За допомогою 1 ви можете створити ПЕРЕГЛЯД, який об'єднує всі ці таблиці разом, і просто оновити його, щоб включити новостворені таблиці. Я вважаю це справді способом емуляції розподілу. До плюсів цього методу слід віднести не потребує Enterprise Edition SQL Server.

За допомогою 2 ви можете вирівняти свої покажчики до ваших розділів та вирівняти свої розділи в іншому сховищі. Після того, як ви налаштуєте функцію розділу та схему розділів, це робиться для вас, коли ви розділяєте або об’єднуєте розділи. До плюсів цього методу входить не вимагати ручного переміщення записів до нової таблиці. Оскільки функція розбиття та схема розділів це для вас. Крім того, як ви вже говорили, для доступу до даних мало що змінюється код.

Якщо у вас є Enterprise Edition, я б точно переглянув розділ. Незважаючи на те, як складно це виглядає, це насправді не так вже й погано. Якщо ні, то розділення для вас навіть не є варіантом.

Створення розподілених таблиць

Зміна розділених таблиць

Проектування розділів для управління підмножинами даних

Сподіваюся, це допомагає,

Метт


0

З вашого запитання ви, здається, зберігаєте історичні дані (журнали), і ваше обмеження, здається, виходить із швидкості запитів, а не з питань зберігання. Для мене розділ не допоможе.

Якщо ви говорите, що маєте належні індекси, чи включає він індекс у полі дати? Я мав хороші результати, використовуючи індекс на транскрупцію (часова мітка, день) з Postgres. Потім ви повинні переконатися, що всі запити вибираються в день перед будь-якими іншими маніпуляціями. Будьте уважні, часова мітка з полем часового поясу не піддається індексації (оскільки вона "рухається" залежно від часового поясу), тому вам потрібна "фіксована" часова марка, щоб її індексувати.


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