precio - Base de datos SQL Azure contra MS SQL Server en la máquina dedicada

sql server azure free (4)

(Descargo de responsabilidad: trabajo para Microsoft, aunque no en Azure o SQL Server).

"Azure SQL" no es equivalente a "SQL Server", y personalmente deseo que ofrezcamos una especie de "servidor SQL alojado" en lugar de Azure SQL.

En la superficie, los dos son los mismos: ambos son sistemas de bases de datos relacionales con el poder de T-SQL para consultarlos (bueno, ambos, bajo la cubierta usan el mismo DBMS).

Azure SQL es diferente en que la idea es que tenga dos bases de datos: una base de datos de desarrollo con un servidor SQL local (idealmente 2012 o posterior) y una base de datos de producción en Azure SQL. Nunca (debería) modificar la base de datos SQL de Azure directamente, y de hecho encontrará que SSMS no ofrece herramientas de diseño (Diseñador de tablas, Diseñador de vistas, etc.) para Azure SQL. En su lugar, diseña y trabaja con su base de datos SQL Server local y crea archivos "DACPAC" (o archivos XML especiales de "cambio", que pueden ser generados por SSDT) que luego modifican su base de datos Azure para que copie su DB de desarrollo. del sistema de "replicación de diseño".

De lo contrario, como habrás notado, Azure SQL ofrece resistencia incorporada, copias de seguridad, administración simplificada, etc.

En cuanto al rendimiento, ¿es posible que le falten índices u otras optimizaciones? También puede observar una latencia ligeramente mayor con Azure SQL en comparación con un servidor SQL local, he visto tiempos de ping (desde una máquina virtual Azure hasta un servidor SQL Azure) de alrededor de 5-10 ms, lo que significa que debe diseñar su aplicación para que sea menos ... hablador o para paralelizar las operaciones de recuperación de datos con el fin de reducir los tiempos de carga de la página (suponiendo que se trata de una aplicación web que está construyendo).

Actualmente estoy ejecutando una instancia de MS SQL Server 2014 (12.1.4100.1) en una máquina dedicada que alquilo por $ 270 / mes con las siguientes especificaciones:

Procesador Intel Xeon E5-1660 (seis núcleos físicos de 3.3 ghz + hyperthreading + turbo-> 3.9 ghz)
64 GB de memoria DDR3 ECC registrada
240GB Intel SSD
45000 GB de transferencia de ancho de banda

He estado jugando con la base de datos SQL de Azure por un momento, y he estado entreteniendo la idea de cambiar a su plataforma. Inicié una base de datos SQL Azure usando su nivel de precios P2 Premium en un servidor V12 (solo para probar cosas), y cargué una copia de mi base de datos existente (desde la máquina dedicada).

Ejecuté varios conjuntos de consultas una al lado de la otra, una contra la base de datos en la máquina dedicada y otra contra la base de datos SQL Azure P2. Los resultados fueron un poco chocantes: mi máquina dedicada superó (en términos de tiempo de ejecución) el DB de Azure por un gran margen cada vez. Típicamente, la instancia de db dedicada terminaría en menos de 1/2 a 1/3 del tiempo que le tomó a Azure db ejecutar.

Ahora entiendo los muchos beneficios de la plataforma Azure. Se administra frente a mi configuración no administrada en la máquina dedicada, tienen una recuperación puntual mejor que la que tengo, el firewall se configura fácilmente, hay geo-replicación, etc., etc. Pero tengo una base de datos con cientos de tablas con decenas a cientos de millones de registros en cada tabla, y algunas veces necesitan consultas en varias combinaciones, etc., por lo que el rendimiento en términos de tiempo de ejecución realmente importa. Me resulta chocante que un servicio de ~ $ 930 / mes tenga un rendimiento similar al de un alquiler de máquina dedicado de $ 270 / mes. Todavía soy bastante nuevo en SQL como un todo, y muy nuevo para los servidores / etc., pero ¿esto no se suma a nadie más? ¿Alguien tiene alguna idea de algo que me falta aquí, o son esas otras características "administradas" de Azure SQL Database que se supone que compensan la diferencia de precio?

En resumen, estoy empezando a superar incluso las capacidades de mi máquina dedicada, y realmente había esperado que la base de datos SQL de Azure fuera una buena pasarela, pero a menos que me falta algo, no lo es. Todavía soy un negocio demasiado pequeño para salir y gastar cientos de miles en alguna otra plataforma.

Alguien tiene algún consejo sobre si me estoy perdiendo algo, o es el rendimiento que estoy viendo en línea con lo que esperarías? ¿Tengo alguna otra opción que pueda producir un mejor rendimiento que la máquina dedicada que estoy ejecutando actualmente, pero que no cuesta en decenas de miles al mes? ¿Hay algo que pueda hacer (configuración / configuración) para mi base de datos SQL de Azure que aumente el tiempo de ejecución? Una vez más, cualquier ayuda se agradece.

EDITAR: Permítanme revisar mi pregunta para aclararla un poco más: lo que veo es un rendimiento en tiempo de ejecución puro, donde un servidor dedicado a $ 270 / mes supera con creces el nivel Azure SQL DB P2 de Microsoft @ $ 930 / mes? Ignore los otros "beneficios" como administrado frente a no administrado, ignore el uso previsto como Azure destinado a producción, etc. Solo necesito saber si me falta algo con Azure SQL DB, o si realmente se supone que debo mejorar MUCHO rendimiento de una sola máquina dedicada.

Existe una alternativa de Microsoft a Azure SQL DB:

"Proporcionar una máquina virtual SQL Server en Azure"

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/

Una explicación detallada de las diferencias entre las dos ofertas: "Entender la base de datos SQL Azure y SQL Server en máquinas virtuales Azure"

https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/

Una diferencia importante entre su SQL Server independiente y SQL DB de Azure es que con SQL DB está pagando altos niveles de disponibilidad, lo que se logra ejecutando varias instancias en diferentes máquinas. Esto sería como alquilar 4 de sus máquinas dedicadas y ejecutarlas en un Grupo de disponibilidad AlwaysOn, que cambiaría tanto su costo como su rendimiento. Sin embargo, como nunca mencionó la disponibilidad, supongo que esto no es una preocupación en su escenario. SQL Server en una VM puede ajustarse mejor a sus necesidades.

Perforación y disponibilidad a un lado, hay varios otros factores importantes a considerar:

Costo total: su costo de alquiler de $ 270 es solo uno de los muchos factores de costo. El espacio, la potencia y la hvac son otros costos físicos. Luego está el costo de la administración. Creo que hay que trabajar cada parche el martes y cuando Windows o SQL Server envían un service pack o una actualización acumulativa. Incluso si no los prueba antes de lanzarlos, aún requiere tiempo y esfuerzo. Si realiza la prueba, existe una segunda máquina y duplica la instancia del producto y la carga de trabajo para la prueba.
Seguridad: se ha escrito MUCHO sobre lo malo, peligroso y arriesgado que es almacenar cualquier dato que le importe en la nube. Personalmente, he visto implementaciones y procesos de seguridad mucho peores con servidores locales (incluso en bancos y agencias federales) que los que he visto con cualquiera de los principales proveedores de la nube (Microsoft, Amazon, Google). Es mucho trabajo corregir las cosas, incluso más trabajar para mantenerlas correctas. Además, puede ver y auditar sus SLA de seguridad (consulte Azure en http://azure.microsoft.com/en-us/support/trust-center/ ).
Escalabilidad: no solo la escalabilidad cruda sino el costo y el esfuerzo de escalar. Azure SQL DB lanzó recientemente la gran edición P11 que tiene 7 veces la capacidad de cálculo del P2 con el que se probó. Escalar hacia arriba y hacia abajo no es instantáneo, sino realmente fácil y razonablemente rápido. La mejor parte es (para mí de todos modos), se puede pasar a una edición más alta cuando ejecuto grandes consultas o reindexe las operaciones y luego vuelvo a bajar para cargas "normales". Esto es difícil de hacer con un servidor SQL normal en metal desnudo: arrendar / comprar una caja realmente grande que se encuentra inactiva el 90% del tiempo o tomarse un tiempo de inactividad para moverse. Ligeramente más fácil si en una VM; puede aumentar la memoria en línea pero aún necesita rebotar la instancia para aumentar la CPU; su base de datos SQL de Azure permanece en línea durante las operaciones de ampliación / reducción de escala.

SQL DB tiene disponibilidad incorporada (que puede afectar el rendimiento), capacidad de restauración de punto en el tiempo y características de DR. Tiene la opción de ampliar / reducir su base de datos en función de su uso para reducir el costo. Puede mejorar el rendimiento de su consulta utilizando la consulta global (datos de fragmentos). SQl DB administra actualizaciones y parches automáticos y mejora en gran medida la historia de la capacidad de administración. Es posible que deba pagar una pequeña prima por eso. El almacenamiento en caché de nivel de aplicación / distribución uniforme de la carga, la degradación en frío, etc. puede ayudar a mejorar el rendimiento de la base de datos y optimizar el costo.