Яких великих обмежень слід очікувати від пов'язаних серверів SQL?

Наш продукт базується на Microsoft SQL Server. В даний час ми використовуємо три бази даних і завжди розгортали їх в одному екземплярі SQL Server.

Три бази даних - OLTP, OLAP та аудит. База даних OLAP має масивні вхідні дані про EOD як від OLTP, так і від аудиту, використовуючи крос-запити до бази даних.

Запитання

Якби ми розгорнули ці три бази даних на три окремі екземпляри Standard Edition всередині одного фізичного сервера та з'єднали їх разом за допомогою функції Linked Server SQL Server:

1. Наскільки прозорим він буде до коду програми? Скільки змін я повинен очікувати?
2. Вхідні дані до OLAP складали в 50k-100k рядків, 200-500MB корисного навантаження на EOD. Скільки падіння продуктивності слід очікувати?
3. Яких ще великих обмежень слід очікувати?

Фон

Наразі ми розкриваємо наш потенційно перший клієнт із 500+ одночасно користувачами.

Ми розробляємо специфікацію сервера, яка включає 64 ядра та 256 ГБ оперативної пам’яті. Щоб SQL Server використовував усі ці рясні ресурси, клієнтові доведеться придбати Enterprise Edition, яка для SQL Server 2016 доступна лише в рамках базового ліцензування.

Ми боїмось, що ціна ліцензування сама (64 х 7400 доларів) знизить їх. Тож я думаю розбити базу даних на три екземпляри Standard Edition та з'єднати їх, сподіваючись, що функція зв’язку буде прозорою від коду програми.

Наскільки прозорим він буде до коду програми? Скільки змін я повинен очікувати?

Непрозорий взагалі. Очікуйте великих змін.

Ви повинні бути готові до значної погіршення продуктивності.

Розподілений запит (рамка для підключених серверів) використовує загальну модель OLEDB незалежно від того, на якому сервері трапляється. Це правда, що цільовий сервер SQL може бути в змозі запропонувати більш повну інформацію (метадані, статистику тощо), але результат все ще ніде не є настільки щільно інтегрованим або здатним, як і вбудована система крос-бази даних.

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

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

Для оптових операцій по форсування Наприклад, ви б набагато краще з використанням реальних масових операцій ( bcp, BULK INSERT, SSIS ... і т.д ..) Між екземплярами , ніж при використанні пов'язаних серверів.

Все, що сказано, основна ідея здається набагато більшим клопотом, ніж мені це варто. Вкажіть обладнання, яке буде працювати в рамках обмежень Standard Edition; або, якщо клієнту потрібна більш висока продуктивність, отримати більший сервер і використовувати Enterprise Edition.