Какие большие ограничения следует ожидать от связанных SQL-серверов?

Наш продукт основан на Microsoft SQL Server. В настоящее время мы используем три базы данных и всегда разворачиваем их на одном экземпляре SQL Server.

Три базы данных - это OLTP, OLAP и аудит. База данных OLAP содержит массивные входящие данные о EOD как из OLTP, так и из аудита, используя перекрестные запросы к базе данных.

Вопросов

Если бы мы развернули эти три базы данных на трех отдельных экземплярах Standard Edition на одном физическом сервере и связали их вместе с помощью функции связанного сервера SQL Server:

1. Насколько прозрачным это будет для кода приложения? Сколько изменений я должен ожидать?
2. Входящие данные в OLAP составляли строки 50–100 тыс., Полезная нагрузка 200–500 МБ на EOD. Какое падение производительности следует ожидать?
3. Какие еще большие ограничения мне следует ожидать?

Фон

В настоящее время мы представляем наш потенциально первый клиент с более чем 500 одновременными пользователями.

Мы разрабатываем спецификацию сервера, которая включает 64 ядра и 256 ГБ оперативной памяти. Чтобы SQL Server использовал все эти обильные ресурсы, клиент должен будет купить Enterprise Edition, который для SQL Server 2016 доступен только для лицензирования на уровне ядра.

Мы опасаемся, что только стоимость лицензирования (64 x 7400 долларов США) приведет к их снижению. Поэтому я подумываю разделить базу данных на три экземпляра Standard Edition и связать их вместе, надеясь, что функция связывания будет прозрачна для кода приложения.

Насколько прозрачным это будет для кода приложения? Сколько изменений я должен ожидать?

Не прозрачный вообще. Ожидайте серьезных изменений.

Вы должны быть готовы к очень существенному снижению производительности.

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

Удаленные запросы имеют заслуженную репутацию из-за низкой производительности и плохого выбора плана оптимизатором. Операторы, которые изменяют данные (удаляют, вставляют, обновляют, объединяют), являются особенно склонными, так как базовая модель часто является курсором.

Если вам никогда не требуется выполнять специальные запросы между экземплярами, вы можете вручную настроить каждый сохраненный запрос для приемлемой производительности, но это большая работа, и успех ни в коем случае не гарантируется.

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

При всем этом основная идея кажется гораздо более сложной, чем она того стоит. Укажите оборудование, которое будет работать в рамках ограничений Standard Edition; или, если клиенту требуется более высокая производительность, выберите больший сервер и используйте Enterprise Edition.