Заточення баз даних сервера sql - що робити із загальними даними / нешаровими даними

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

Зараз ми хочемо розширити базу даних, щоб гарантувати, що ми можемо впоратися з ростом компанії та майбутніми навантаженнями.

Ми вирішили, які конкретні дані слід оприлюднити. Це підмножина нашої бази даних, яка широко використовується.

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

Я бачу два варіанти обробки цих загальних / універсальних даних:

1) дизайн 1 - розміщення загальних / універсальних даних у зовнішній базі даних. Усі записи будуть відбуватися тут. Потім ці дані будуть реплікуватись вниз до кожного фрагмента, що дозволить кожному фрагменту прочитати ці дані та внутрішнє приєднання до цих даних у програмах t-sql.

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

побоювання щодо дизайну №1

1) Проблеми з транзакціями: Якщо у вас виникне ситуація, коли ви повинні записати або оновити дані в осколку, а потім записати / оновити загальну / універсальну таблицю в 1 збереженому примірнику, наприклад, ви більше не зможете це зробити легко. Дані тепер існують на окремих екземплярах і базах sql. Можливо, вам потрібно буде задіяти MS DTS, щоб побачити, чи можна вписати ці записи в транзакцію, оскільки вони знаходяться в окремій базі даних. Ефективність викликає занепокоєння, і можливі переписування можуть бути залучені для програм, які записують у фрагменти та загальні дані.

2) втрата референтної цілісності. Неможливо зробити референтну цілісність міжбазової бази даних.

3) Перекодування великих областей системи, щоб вона могла записувати загальні дані в нову універсальну базу даних, але читати загальні дані з фрагментів.

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

побоювання щодо дизайну №2

У дизайні №2 кожен фрагмент отримує власний екземпляр усіх загальних / універсальних даних. Це означає, що весь код, який приєднується до або оновлює загальні дані, продовжує працювати / працювати так, як це відбувається сьогодні. Команда розробників вимагає дуже мало перекодування / переписування. Однак ця конструкція повністю залежить від реплікації злиття, щоб синхронізувати дані між усіма фрагментами. dbas є висококваліфікованими і дуже стурбовані тим, що реплікація злиття може не впоратися з цим, і якщо злиття реплікації не вдасться, що відновлення після цього відмови не є великим і може вплинути на нас дуже негативно.

Мені цікаво дізнатися, чи хтось пішов з дизайном варіант №2 Мені також цікаво дізнатись, чи переглядаю 3-й чи 4-й варіант дизайну, який я не бачу.

наперед дякую.

Ваше питання було зосереджено на цьому:

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

Коли ви робите заточування, і у вас є дані, які повинні бачити всі фрагменти, ви повинні класифікувати ці дані з кількома атрибутами:

Чи часто змінюється? У своїх прикладах ви перерахували Інвентар, Співробітник та Користувач. Зазвичай інвентар змінюється дуже швидко, але записи співробітників змінюються лише періодично (скажімо, кілька сотень оновлень на день).

Скільки затримок може терпіти кожен осколок?Незважаючи на те, що Інвентар може постійно змінюватися, ти зазвичай можеш допустити велику кількість затримок (хвилин чи навіть годин) на такому столі. Якщо ви продаєте унікальні предмети з дуже обмеженою кількістю, яку ви ніколи не зможете відновити (подумайте, оригінальні твори мистецтва), тоді ви взагалі не поділяєте ці дані - ви лише запитуєте оригінальну базу даних. Однак у більшості інтернет-магазинів ви не продаєте кожен товар кожного дня, і все одно збираєтеся швидко перезаряджати речі, тому вам не потрібні справжні підрахунки запасів. Насправді, у більшості випадків вам потрібен лише прапор на складі, який дорівнює 0 або 1, і центральний процес оновлює цей прапор. Таким чином, вам не доведеться проштовхувати кожну частину підрахунку елементів до кожного осколка. Дані працівника або користувача, з іншого боку,

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

Це оригінальні дані чи скопійовані?Ще один спосіб подумати над цим питанням: що вам потрібно зробити резервну копію та як часто? Зазвичай у середовищі з великим обсягом різкості, ви хочете, щоб резервні копії були максимально швидкими та мінімальними. (Зрештою, вам потрібно захистити кожен вузол, і ви хочете, щоб усі фрагменти не переходили на DR в той самий момент часу - не мати деяких фрагментів з новими даними, ніж інші.) Це означає, що розділені дані та не- заштриховані дані повинні знаходитись у повністю окремих базах даних, навіть якщо вони знаходяться на одному сервері. Можливо, мені знадобляться постійні резервні копії журналу транзакцій моїх фрагментованих (оригінальних) даних, але мені може не знадобитися взагалі створювати резервну копію нешарпованих даних. Мені, мабуть, простіше просто оновити таблицю «Співробітники» або «Користувачі» з єдиного джерела істини, а не створити резервну копію на кожному фрагменті. Якщо всі мої дані знаходяться в одній базі даних,

Тепер щодо ваших проблем:

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

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

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

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

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

На високому рівні типовим способом розміщення даних (або горизонтальним поділом) є розподіл таблиць транзакцій та реплікація таблиць рівня майстерного рівня. Як і більшість технологічних рішень, це, звичайно, вирішує один набір проблем і створює цілий новий набір проблем ... але ми до цього всі звикли, чи не так? ;-)

Я б хотів запитати, чи найкраще рішення для цього є SQLServer. Чи навантаження більше схожа на OLTP, чи більше схожа на DW / BI?

Ура, Дейв Сіск

Можливий 3-й варіант. Використовуючи реляційне заточування (замість загострення чорної скриньки), ви маєте змогу шматувати та розповсюджувати всю свою базу даних. Оскільки вона побудована за традиційною реляційною моделлю даних, база даних знає, які дані зберігаються на яких серверах, і, отже, де їх знайти, тому всі ваші дані можна вважати "загальними / універсальними". Перевірте dbShards як можливість полегшити весь процес загострення.