Este artículo proviene de un motor de traducción automática.

Data Services de SQL

La base de datos relacional de la plataforma de servicios Azure

David Robinson

Este artículo se basa en una versión preliminar de los servicios de datos de SQL. Toda la información aquí está sujeta a cambios.

Contenido

Ampliar la plataforma de datos SQL para la nube
Arquitectura de SDS
Cliente de servicios de datos SQL
Fondo de Data Services SQL
Tejido de servicios de datos SQL
Conectar a servicios de datos SQL
Creación de aplicaciones que utilizan servicios de datos SQL
Nueva imagen de servicios de datos SQL

En marzo de 2008 en la conferencia anual de MIX, Microsoft anunció servicios de datos de SQL (SDS), su primer almacén de datos para la nube. SDS era un almacén de valor de atributo Entity (EAV) que se puede tener acceso a mediante protocolos de Internet estándar. Incluyen todas las características que esperaría de una oferta basada en nubes, incluida la alta disponibilidad, tolerancia a errores y recuperación de desastres; todo con el motor de Microsoft SQL Server. Aunque el modelo de datos inicial era basado en EAV, las características más relacionales prometidas en MIX empezaron a entregarse en la conferencia Professional Developers Conference en octubre de 2008.

En los meses que seguido, el equipo SDS recopila comentarios esencial de la comunidad de usuario, lo más importante que mientras la oferta de SDS actual proporciona una utilidad de almacenamiento de datos valiosos, no era SQL Server. Los clientes que deseaban era una base de datos relacional ofrecen como un servicio. En marzo de 2009, el equipo de SQL Server anunciado acelera sus planes para ofrecer exactamente y esto se cumple comentarios muy positivos de la comunidad. Microsoft siempre ha proporcionado una plataforma de datos completa y las nuevas capacidades relacionales de SDS con esa tradición. Con SDS, Microsoft SQL Server extiende ahora desde dispositivos de mano con SQL Server CE en el escritorio con SQL Server Express, la empresa con SQL Server (ediciones standard y enterprise) y ahora, en la nube. SDS es la base de datos relacional de la plataforma de servicios de Azure.

El protocolo TDS

El protocolo nativo utilizado por los clientes para comunicarse con Microsoft SQL Server se denomina secuencia de datos tabular o TDS. TDS es un protocolo bien documentado para intercambiar datos con el motor de SQL Server utilizada por los componentes de cliente de Microsoft subyacentes. Incluso hay implementaciones de la licencia pública general (GPL) de TDS que pueden encontrarse en estos Internet.

Ampliar la plataforma de datos SQL para la nube

SDS es la base de datos relacional de la plataforma de servicios de Azure del mismo modo que SQL Server es la base de datos de la plataforma Windows Server. En la oferta inicial, se proporcionan sólo las características de base de datos relacional principales. La investigación que ha realizado el equipo de producto de muestra que la característica actual establece direcciones de aproximadamente el 95 por ciento de Web y las cargas de trabajo departamentales. Cuando examine la marca de SQL Server, el motor de base de datos es sólo una parte de un conjunto mayor de productos. Puesto que SDS utiliza el mismo protocolo de red como el producto en instalaciones, todos los productos auxiliares existentes siguen funcionando. Sino que aunque funcionarán en los productos, se deben ejecutar en instalaciones en su propia red. El equipo de SQL Server planes para habilitar el resto de la pila de SQL Server, en el futuro, para la función en la nube. El resultado final será una experiencia de desarrollo coherente, tanto si dirige la solución Windows Server o Windows Azure. De hecho, el mismo código seguirán funcionando. Todo lo que será necesario es un cambio de la cadena de conexión.

Arquitectura de SDS

Como se mencionó anteriormente, SDS proporciona una base de datos de SQL Server como un servicio de utilidad. Características como alta disponibilidad, tolerancia a errores y recuperación de desastres se generan en. figura 1 proporciona una vista de la arquitectura de SDS. Echemos un vistazo.

Figura 1 arquitectura de servicios de datos SQL

Cliente de servicios de datos SQL

Los servidores de aplicaciones para usuario SDS son los equipos de cara a Internet que expongan el protocolo TDS a través del puerto 1433. En además actúa como puerta de enlace al servicio, estos servidores también proporcionan a algún cliente necesario características, como el aprovisionamiento de cuentas, facturación y supervisión del uso. Lo más importante, los servidores son cargo de las solicitudes de enrutamiento al servidor back-end apropiado. SDS mantiene un directorio que mantiene un seguimiento de dónde en los servidores del back-end de SDS los datos principales y todas las réplicas copia de seguridad están ubicadas. Cuando se conecta a SDS, el cliente busca en el directorio para ver dónde se encuentra la base de datos y reenvía la solicitud a ese nodo específico de back-end.

Características admitidas

En la versión 1, se admitirá SDS

• Tablas, índices y vistas
• Procedimientos almacenados
• Desencadenadores
• Restricciones
• Variables de tabla, tablas temporales de sesión (t #)

Los siguientes son fuera del ámbito de SDS v1

• Transacciones distribuidas
• Consulta distribuida
• CLR
• Service Broker
• Tipos de datos espaciales
• Servidor físico o catálogo DDL y vistas

Fondo de Data Services SQL

Los servidores back-end de SDS, o nodos de datos, son donde reside el motor de SQL Server y es responsable de proporcionar todos los servicios de base de datos relacional que consuma una aplicación. El equipo del producto a menudo se pregunta por qué SDS proporciona sólo un subconjunto de las características del producto de SQL Server en instalaciones. El motivo es que la superficie de característica de SQL Server es extremadamente grande. Una cantidad significativa de ingeniería y pruebas entra en cada área de característica que se expone en SDS para asegurarse de que se refuerza la característica y que datos los del cliente es completamente siloed de todos los otros datos de cliente del SDS. Al proporcionar las características relacionales principales que 95 de dirección por ciento de las aplicaciones departamentales y, el equipo puede obtener el producto al mercado antes. Y dado que SDS es un servicio de Internet, estamos capaces de ser mucho más ágil y ofrecen nuevas características a un ritmo más rápido. A lo largo del tiempo, puede esperar ver la mayoría de las características del producto en instalaciones disponibles en SDS.

El back-end de SDS recibe la conexión de TDS desde el front-end y procesa todas las operaciones CRUD (crear, recuperar, actualizar, eliminar). ¿Qué características son compatibles actualmente? Todo que procedan puede esperar de una base de datos relacional, como se muestra en "Características compatibles".

Tejido de servicios de datos SQL

El tejido SDS está cargo manteniendo el tolerancia a errores y alta disponibilidad del sistema. El tejido desempeña un papel clave en el sistema SDS de detección de errores automático, la recuperación automática y equilibrio de carga en todos los nodos de datos back-end de SDS. En versiones anteriores, hemos tratado cómo SDS mantiene una copia principal de los datos, así como una serie de réplicas de copia de seguridad. El tejido proporciona detección de errores automático de SDS. Si el nodo donde copiar el principal de los datos existe experiencias un error, el tejido automáticamente promueve una de las réplicas de copia de seguridad que el principal y vuelve a enrutar las solicitudes. Una vez el tejido ve que se ha producido la conmutación por error, reconstruye automáticamente la réplica de copia de seguridad en caso de aparecer otro error.

Conectar a servicios de datos SQL

Esta es la parte del artículo donde el equipo SDS espera que colocar a modo de suspensión. El hecho de la cuestión es porque SDS expone el protocolo TDS, todos los clientes existentes como ADO.NET y ODBC que funcionan. Tomemos, por ejemplo, la siguiente cadena de conexión de ADO.NET:

SqlConnection conn = new SqlConnection("Data Source=testserver; Database=northwind;
    encrypt=true; User ID=david; Password=M5DNR0ck5");

Para conectarse a SDS, esa cadena tendría este aspecto:

SqlConnection conn = new SqlConnection("Data
             Source=testserver.database.windows.net; Database=northwind; encrypt=true; 
             User ID=david; Password=M5DNR0ck5");

Todo lo que ha cambiado es donde está ubicado el servidor. Observe que la cadena incluye el parámetro opcional cifrar = true. Este parámetro no es opcional para SDS, que requiere que toda la comunicación a través de un canal SSL cifrado. Si intenta conectarse sin cifrado, el front-end de SDS terminará la conexión. Porque el protocolo TDS, todas sus conocimientos, herramientas y técnicas de desarrollo contra SQL Server todavía aplican. Lo único que es necesario que preocupa es donde se ejecutará la aplicación y su proximidad a los datos.

Creación de aplicaciones que utilizan servicios de datos SQL

Como se mencionó, uno de los principales aspectos que es necesario que ocupa cuando almacene datos en SDS es donde se ejecutará el código de aplicación, si la aplicación sigue una arquitectura "Código cerca" o una arquitectura "Far código".

código cerca Una aplicación código cerca normalmente significa que los datos y el acceso de datos de componentes se hallan en la misma red segmento, por ejemplo cuando tenga la aplicación se ejecute en su red corporativa. En el caso de la plataforma de servicios Azure, significaría que la aplicación en ejecución Windows Azure y los datos que residen en SDS. Cuando la plataforma Azure live posterior este año, tendrá la opción de selección de la región donde se alojará la aplicación, así como la región donde se alojarán los datos. Mientras elige la misma región para ambos, el código de aplicación tendrán acceso a datos dentro del mismo centro de datos, tal como se muestra en la figura 2 .

Figura 2 código cerca de la aplicación

código far Tener acceso cuando la aplicación es una aplicación código far, esto normalmente significa tener los datos y datos a componentes en redes independientes como se muestra en la figura 3 , a menudo con Internet en entre. Internet ha sido un increíble habilitador para empresarial y tecnología, pero desde una perspectiva de acceso a datos, lo suponer algunos desafíos interesantes, dependiendo de la aplicación y su arquitectura.

Figura 3 código extremo de aplicación

Suponga, por ejemplo, que la aplicación proporciona a algún tipo de servicio de archivado de datos a sus clientes. En este escenario, el patrón típico es la escritura de una vez, leer rara vez (o nunca) y latencia no sería demasiado una preocupación.

En el lado voltear, supongamos que la aplicación fue altamente transaccional con muchas lecturas y escrituras por segundo. El rendimiento de este tipo de aplicación sería mala si se estaba ejecutando en su red corporativa y los datos se encuentran en SDS. Caché de algún tipo de datos, quizás el proyecto cuyo nombre en código es "Velocity" puede ayudar, pero como los arquitectos de aplicaciones y los desarrolladores, necesitamos que mirar cada aplicación caso por caso para identificar la mejor arquitectura para propósitos de la aplicación.

Nueva imagen de servicios de datos SQL

SDS es la base de datos relacional de la plataforma de servicios Azure, que estará comercialmente disponible en PDC 09 este noviembre. SDS proporciona actualmente las principales características relacionales que procedan a conocer y encanta de SQL Server. A lo largo del tiempo, las características adicionales se habilitará, así como compatibilidad con para los productos adicionales de la familia de SQL Server, como SQL Server Reporting Services y SQL Server Analysis Services. Ya que se obtiene acceso al SDS a través de TDS, el mismo protocolo de SQL Server, todas la herramientas existentes, bibliotecas de cliente y técnicas de desarrollo siguen funcionando. Espero que leyendo este artículo le han concedido una perspectiva de la nueva imagen del SDS y que puede ver que realmente es una extensión de SQL Server en la nube.

David Robinson es director de programas en el equipo de Data Services de SQL Server en Microsoft. Dedica su tiempo conduciendo nuevas y atractivas características en el producto. También disfruta realizar presentaciones en eventos de la comunidad y obtener comentarios de los clientes en SDS.