¿Cómo se escala SQL Server 2008 o 2012?

8

¿Cómo se escala SQL Server 2008 (o 2012)? Básicamente, entiendo que hay dos opciones:

Aumentar proporcionalmente:

Si la CPU está vinculada, puedo ver claramente pasar de 1 núcleo de CPU a 2 a 4. O si el uso de RAM se dispara, solo agrego más RAM. ¿SQL Server 2008/2012 realmente recoge la holgura y escala de esa manera asumiendo que NO hay cambios en el nivel de la aplicación? Para minimizar la especulación, supongamos que no estoy haciendo algo tonto como grabar ciclos de CPU, hacer combinaciones cruzadas, etc.

Poner a escala:

No está muy claro cómo funcionaría la ampliación. Quiero decir, si agregué otro servidor SQL justo al lado del primero, ¿cómo sabe la consulta en qué servidor ejecutar? ¿Hay algún equilibrador de carga en el frente (y viene con el software SQL Server?)? ¿Implica cambios en el nivel de aplicación para escalar al trabajo? ¿O tengo que fragmentar los datos y tener un código personalizado que llame al servidor de base de datos correcto según la clave de fragmentación de datos?

Agradecería las aportaciones de personas más experimentadas.

sql-server scalability

— DeepSpace101
fuente

10

SQL Server no se escala como tal . Se amplía.

Hay 3 áreas para hacer esto, sujetas a limitaciones de edición

Núcleos de CPU
RAM
Almacenamiento

Y, por supuesto, use una edición superior, por ejemplo, Enterprise

SQL Server no fragmenta y cualquier solución de este tipo (puede buscar soluciones de fragmentación de MySQL) agrega complejidad y sobrecarga a un sistema.

Escalar un servidor (+ nodos en espera / espejo) suele ser bastante sencillo con RAM, SSD, más volúmenes de disco para distribuir E / S, unidades separadas para tempdb y registros, etc.

Además, si encuentra que SQL Server está vinculado a la CPU, generalmente es un diseño y / o índices deficientes y / o consultas mal escritas a menos que tenga una carga masiva.

— gbn
fuente

¡Excelente! ¿Alguna literatura específica de fragmentación de MySQL / tutoriales / enlaces que recomiendas? Espero poder aplicar algunos de esos patrones a SQL Server. Estoy aprendiendo (¡rápido!) Y tú eres todo un recurso !!

— DeepSpace101

1

Y los servidores wintel modernos pueden escalar hasta un hardware bastante de alta especificación. Si tiene que escalar más allá de eso, está cómodamente en territorio VLDB y en un kit costoso y especializado.

— Preocupado por

@Sid, Mover SQL Server a una configuración donde se comparte una sola base de datos en varios servidores físicos no es algo que el nuevo usuario pueda probar. Solo unas pocas personas han podido hacerlo con éxito, ya que es muy complicado y requiere un esquema MUY estable y una comprensión sólida de los patrones de datos dentro de la base de datos (he enseñado clases sobre el tema). Las ideas básicas de otras plataformas son un buen lugar para comenzar, pero las técnicas reales utilizadas son bastante diferentes.

— mrdenny

5

Como dice gbn, SQL realmente no se escala como lo hacen otros RDBM. Sin embargo, hay un aspecto de escalar que muchas personas pasan por alto y es tener siempre un sistema separado para informar.

Nunca permita que se ejecuten informes contra la producción. Construya una base de datos de informes en otro servidor.

Idealmente, su sistema de informes solo contendría datos que los informes necesitan, y estaría estructurado y optimizado de manera diferente a su sistema de producción.

Los datos se enviarían al sistema de informes según sea necesario (es decir, una actualización por goteo por hora de la producción, alimentación diaria, etc.).

Un enfoque rápido y sucio (y altamente ineficiente) es simplemente tener una copia completa de la base de datos de producción en otro servidor. Esta copia se puede mantener a través de copias de seguridad completas, envío de registros de transacciones, duplicación (con instantánea), replicación, etc.

Sin embargo, no recomiendo este enfoque. Las copias de seguridad completas y restauradas toman tiempo, especialmente en bases de datos más grandes. La replicación es complicada y problemática. El envío de registros lo deja con una base de datos de solo lectura. La duplicación con instantáneas puede ser una buena respuesta, pero todavía está atascado con un esquema de producción que no está optimizado para fines de informes.

Un sistema de informes separado es el camino a seguir.

— datagod
fuente

2

Si la CPU está vinculada, puedo ver claramente pasar de 1 núcleo de CPU a 2 a 4. O si el uso de RAM se dispara, solo agrego más RAM. ¿SQL Server 2008/2012 realmente recoge la holgura y escala de esa manera asumiendo que NO hay cambios en el nivel de la aplicación?

Las diferentes ediciones de SQL Server tienen diferentes limitaciones en términos de CPU y memoria que van a usar. Pero aparte de eso, la respuesta es sí: si hay ciclos de CPU vacantes o páginas de memoria disponibles, el servidor generalmente las usará cuando sea necesario, a menos que se configure de otra manera.

¿O tengo que fragmentar los datos y tener un código personalizado que llame al servidor de base de datos correcto?

Básicamente sí. El "escalado horizontal" a menudo se realiza cuando necesita evitar la contención de bloqueo. Si tiene consultas de larga duración con un bloqueo extenso, es posible que desee separarlas de las consultas interactivas "en tiempo real" o los ciclos de actualización de consultas iniciados por los usuarios que operan algún tipo de interfaz y esperan una pronta respuesta. Obviamente, ocuparse de esto requeriría cambios en la aplicación (o al menos cambios en el middleware, si tiene un diseño de 3 niveles).

— syneticon-dj
fuente