¿Qué grandes limitaciones debo esperar de los servidores SQL vinculados?

Nuestro producto está basado en Microsoft SQL Server. Actualmente, estamos utilizando tres bases de datos y siempre las hemos implementado en una instancia de SQL Server.

Las tres bases de datos son OLTP, OLAP y auditoría. La base de datos OLAP tiene datos entrantes masivos en EOD tanto de OLTP como de auditoría, utilizando consultas cruzadas de bases de datos.

Preguntas

Si tuviéramos que implementar estas tres bases de datos en tres instancias separadas de Standard Edition dentro de un único servidor físico, y unirlas usando la función de Servidor Vinculado de SQL Server:

1. ¿Qué tan transparente será para el código de la aplicación? ¿Cuánto cambio debo esperar?
2. Los datos entrantes a OLAP ascendieron en 50k-100k filas, 200-500MB de carga útil por EOD. ¿Cuánta caída de rendimiento debo esperar?
3. ¿Qué otras grandes limitaciones debo esperar?

Antecedentes

Actualmente estamos lanzando nuestro potencialmente primer cliente con más de 500 usuarios concurrentes.

Estamos redactando una especificación de servidor, que incluye 64 núcleos y 256 GB de RAM. Para que SQL Server utilice todos esos recursos abundantes, el cliente tendría que comprar Enterprise Edition, que para SQL Server 2016 solo está disponible en licencias por núcleo.

Tememos que solo el costo de la licencia (64 x $ 7400) los reducirá. Así que estoy pensando en dividir la base de datos en tres instancias de Standard Edition y vincularlas, esperando que la función de vinculación sea transparente del código de la aplicación.

¿Qué tan transparente será para el código de la aplicación? ¿Cuánto cambio debo esperar?

No es transparente en absoluto. Esperar cambios importantes.

Debe estar preparado para una degradación muy sustancial del rendimiento.

La consulta distribuida (el marco para servidores vinculados) utiliza un modelo OLEDB general, sea cual sea el servidor en el otro extremo. Es cierto que un objetivo de SQL Server puede ofrecer información más completa (metadatos, estadísticas, etc.), pero el resultado aún no está tan integrado o capaz como una operación nativa de base de datos cruzada.

Las consultas remotas tienen una merecida reputación de rendimiento lento y malas opciones de plan por parte del optimizador. Las declaraciones que cambian datos (eliminar, insertar, actualizar, fusionar) son particularmente propensas ya que el modelo básico suele ser el de un cursor.

Si nunca necesita realizar consultas ad-hoc entre instancias, es posible que pueda ajustar manualmente cada consulta almacenada para obtener un rendimiento aceptable, pero esto es mucho trabajo y el éxito no está garantizado de ninguna manera.

Para las operaciones a granel a través del ejemplo, que sería mucho mejor usar operaciones de bienes a granel ( bcp, BULK INSERT, SSIS ... etc.) Entre los casos que el uso de los servidores vinculados.

Dicho todo esto, la idea básica parece mucho más problemática de lo que vale para mí. Especifique el hardware que funcionará dentro de las limitaciones de Standard Edition; o, si el cliente requiere un mayor rendimiento, obtenga un servidor más grande y use Enterprise Edition.