2011-11-28 24 views
6

Antes que nada, déjenme aclarar que no soy de un fondo web, por lo que si no entiendo cómo funciona, no dude en corregirme.Alojamiento normal vs Cloud/Azure y función de SQL Azure vs SQL Server

Digamos que tengo un sitio web que me gustaría alojar en la nube porque

- I don't want to take care of hardware 
- I want to scale my website as needed 

Ahora estoy un poco confundido entre el papel de SQL Server vs papel de SQL Azure en este caso.

normal Alojamiento Web

Cuando pienso en una página web normal, sé que necesito un host/servidor en el que se pretende albergar mi sitio web. El host debe ser compatible con SQL Server. Para el propósito de escalado, tendré que alojar mi sitio web/páginas ASP en varios servidores. Del mismo modo, si quiero ampliar mi SQL Server tendré que alojarlo en varios servidores y me tendré que asegurar de que los datos estén actualizados en todos los servidores a través de algún mecanismo.

nube basado Hosting

Ahora creo que puedo configuración estructura similar en Cloud/Azure también. En caso afirmativo, ¿usaría las capacidades reales de Cloud en este caso?

¿O debería usar SQL Azure en lugar de SQL Server? ¿Qué beneficio obtendré en ese caso? ¿Seguiré siendo responsable de la ampliación y coherencia de los datos? Sé que puedo escalar el sitio web mediante el establecimiento de la cantidad de máquinas virtuales/instancia, pero ¿qué pasa con la ampliación de la base de datos?

Editar Gracias a Florin Dumitrescu la terminología que quería utilizar Scaling Out fue porque yo estoy más preocupado por el rendimiento en lugar de lo grande que es mi base de datos en términos de tamaño. Estoy más preocupado acerca de cómo la base de datos se escalaría entre diferentes servidores/sistemas para acomodar la carga y por lo tanto dar como resultado un mejor rendimiento

+0

Creo que está utilizando incorrectamente la terminología [scale up] (http://en.wikipedia.org/wiki/Scalability#Scale_vertically_.28scale_up.29), cuando en realidad se está refiriendo a [scaling out] (http: //en.wikipedia.org/wiki/Scalability#Scale_horizontally_.28scale_out.29) –

+0

@ Florin Dumitrescu tiene razón, quise ampliar –

Respuesta

3

SQL Azure, como se ha mencionado Yossi, es un a-Service base de datos-como-. Como tal, simplemente solicita que se aprovisione, sucede la magia y tiene una base de datos que se escala de 1GB a 5GB, 10GB, hasta 50GB (que pronto será de 150GB como announced en SQL PASS). Lo bueno de SQL Azure: no tienes que preocuparte por ninguna infraestructura, servidores, licencias, etc. Simplemente conéctate con tu cadena de conexión. SQL Azure está diseñado para ser escalable para manejar una cantidad considerable de inquilinos concurrentes, por lo que no tiene que preocuparse por escalar.

SQL Azure también replica sus datos en el centro de datos para proporcionar un almacenamiento "duradero". Aún necesita diseñar un esquema de recuperación de desastres, en caso de que el centro de datos deje de estar disponible (y puede usar el servicio Data Sync para eso).

En cuanto a su sitio web: a medida que escala varias instancias, cada instancia ejecuta el mismo código y utiliza los mismos recursos. Dando un paso más, puedes mover tu contenido web estático (no cambiante), como imágenes y CSS, al almacenamiento de Blob. Esto tiene varias ventajas sobre el almacenamiento con la propia página web:

  • Posibilidad de activar la red de entrega de contenido, un servicio de canto de almacenamiento en caché en todo el mundo proporcionando un mejor rendimiento para sus usuarios finales
  • menos tensión en sus instancias de servidor web, ya que las solicitudes de esas imágenes ahora se dirigirán a Blob storage, una URL completamente separada de su sitio web
  • Posibilidad de actualizar una imagen o hoja de estilo sin tener que volver a implementar su aplicación; simplemente cargue un archivo nuevo en Blob storage.

Recomiendo encarecidamente el Windows Azure Platform Training Kit, ya que hay laboratorios que lo guían a través de los fundamentos de todo esto, con muestras de código completo también. Esto se actualiza casi todos los meses, manteniéndose sincronizado con las últimas herramientas y SDK de Windows Azure.

+0

Tenga en cuenta que las bases de datos de Sql Azure en realidad no se escalarán infinitamente. Además, detrás de escena, las bases de datos SqlAzure se ejecutan en servidores compartidos. Microsoft no está dando cifras sobre el rendimiento esperado de tales bases de datos, pero es probable que obtenga un rendimiento mucho mejor con un servidor dedicado de premisa mediana. A partir de finales de 2011, Sql Azure Federations estará disponible y ofrecerá una forma de escalar con bases de datos Sql Azure: http://social.technet.microsoft.com/wiki/contents/articles/2281.aspx –

+0

@ Florin: si configura el archivo db para que utilice la edición comercial y el tamaño máximo a 50 GB, la base de datos crecerá automáticamente y se le facturará a diario en el nivel de uso actual (en incrementos de 10 GB). Lo mismo con la edición web si configura el tamaño máximo a 5 GB. A medida que la base de datos crezca y se reduzca más allá de la marca de 1 GB, su facturación diaria se ajustará en consecuencia. –

+0

si con la escala quiere decir aumentar automáticamente el tamaño del disco de la base de datos, entonces estoy de acuerdo con usted. Lo que realmente quise decir fue escalar desde el punto de vista del rendimiento, esa es la carga que puede tomar la base de datos. Lo siento si fui ambiguo sobre eso. –

1

Si está alojando su sitio web en la nube, y necesita una base de datos, entonces SQL Azure es casi seguramente la mejor opción.

SQL Azure es una base de datos como un servicio, por lo que creará su base de datos y trabajará en contra de su código, pero no tiene que preocuparse por la provisión, no hay servidores como tal, todo se está cuidando de.

Desde un punto de aplicación de vista que se ve y se comporta muy parecido a SQL Server, por lo que inicialmente lo único que cambia es la cadena que conecta

1

Como otros casos destacados de SQL Azure le quitan sus preocupaciones sobre la configuración y el cuidado de la infraestructura. Esto es parte de la premisa de Azure en general, que es proporcionar una plataforma en lugar de solo Infraestructura.

El precio que paga por eso son algunas limitaciones en las capacidades (en comparación con el SQL normal). Limitación del tamaño (al menos hasta que Federation esté disponible) y aumento de la latencia (ya que su base de datos no se ejecuta en el mismo servidor de su aplicación)

Microsoft Teched tiene como "SQL Azure Performance and Elasticity Guide" que probablemente deba consultar