Які об'єктивні фактори вказують, що настав час впровадити реплікацію SQL Server?

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

• Це ускладнює зміни схеми
• Це заважає нашому автоматизованому серверу інтеграції / побудови
• Схоже, це ускладнює реалізацію управління джерелами SQL

Моє запитання : Коли ви знаєте, що настав час піти з тиражуванням у світлі цих недоліків? Як ви вирішите, чи додаткова складність виправдовує виграш?

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

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

Реплікацію слід розглянути під час проектування програми. Якщо у вас є географічно розподілена робоча сила / база користувачів, наявність регіональних баз даних та центральних баз даних може мати сенс. Від'єднані бази даних на ноутбуках можуть "синхронізуватися", коли вони нарешті з’єднаються з мережею (подумайте, торговий персонал у дорозі).

Що стосується цілей звітування, то реплікація НЕ є відповіддю. Більшість проблем із ефективністю роботи в звітному середовищі пов'язані з тим, що звіти складаються в системі, яка налаштована для онлайнової обробки транзакцій (OLTP).

Реплікація для цілей звітування - це просто переміщення ваших даних OLTP на інший сервер, але зберігання тієї самої непривітної структури звітів. По суті, ви кидаєте більше обладнання на вирішення проблеми і збільшуєте витрати на обслуговування, але для незначних вигод.

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

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

Оскільки це варте, ми виявили, що реплікація може бути корисною в подібній ситуації, оскільки автори звітів можуть "володіти" індексами в реплікуваній базі даних. Це дало нам можливість покращити ефективність запитів, додавши індекси, які розробники додатків ніколи не затвердили у виробництві через їх негативний вплив на ВСТАВКИ та ОНОВЛЕННЯ.

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

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