Sugerir tradução
 
Outras sugestões:

progress indicator
Sem sugestões.
 O banco de dados relacional da plataforma de se...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este conteúdo foi traduzido automaticamente e pode ser editado pelos membros da comunidade. Para melhorar a qualidade da tradução, clique no link Editar associado à frase que deseja modificar.Mais detalhes estão disponíveis nas Perguntas frequentes do Translation Wiki.
SQL Data Services
The Relational Database of the Azure Services Platform
David Robinson
This article is based on a prerelease version of SQL Data Services. All information herein is subject to change.

This article discusses:
  • SQL Data Platform
  • SQL Data Services Architecture
  • Building Applications that Consume SQL Data Services
This article uses the following technologies:
SQL Data Services
In March of 2008 at the annual MIX conference, Microsoft announced SQL Data Services (SDS), its first data store for the cloud. SDS was an Entity-Attribute-Value (EAV) store that could be accessed using industry standard Internet protocols. It included all the features you would expect from a cloud-based offering, including high availability, fault tolerance, and disaster recovery; all powered by the Microsoft SQL Server engine. Though the initial data model was EAV-based, the more relational features promised at MIX began to be delivered at the Professional Developers Conference in October 2008.
Over the months that followed, the SDS team gathered essential feedback from the user community, most importantly that while the current SDS offering provided a valuable data storage utility, it wasn't SQL Server. What customers wanted was a relational database offered as a service. In March 2009, the SQL Server team announced it was accelerating its plans to offer exactly that, and this was met by overwhelmingly positive feedback from the community. Microsoft has always provided a comprehensive data platform and the new relational capabilities of SDS continue that tradition. With SDS, Microsoft SQL Server now extends from handheld devices with SQL Server CE, to the desktop with SQL Server Express, to the enterprise with SQL Server (both standard and enterprise editions), and now, to the cloud. SDS is the relational database of the Azure Services Platform.
The TDS Protocol
The native protocol used by clients to communicate with Microsoft SQL Server is called Tabular Data Stream, or TDS. TDS is a well-documented protocol that is used by the underlying Microsoft client components to exchange data with the SQL Server engine. There are even General Public License (GPL) implementations of TDS that can be found on thse Internet.

Extending the SQL Data Platform to the Cloud
SDS is the relational database of the Azure Services Platform in the same way that SQL Server is the database of the Windows Server Platform. In the initial offering, only the core relational database features are provided. The research that the product team has done shows that the current feature set addresses about 95 percent of Web and departmental workloads. When you look at the SQL Server brand, the database engine is only one piece of a larger suite of products. Since SDS uses the same network protocol as the on-premises SQL Server product, all the existing ancillary products continue to work. But though the products will function, they must be run on-premises on your own network. The SQL Server team plans to enable the rest of the SQL Server stack, in the future, to function in the cloud. The end result will be a consistent development experience, whether your solution targets Windows Server or Windows Azure. In fact, the same code will continue to work. All that will be required is a connection string change.

SDS Architecture
As mentioned earlier, SDS provides a SQL Server database as a utility service. Features like high availability, fault tolerance and disaster recovery are built in. Figure 1 provides a view of the SDS architecture. Let's take a look.
Figure 1 SQL Data Services Architecture

SQL Data Services Front End
The SDS front-end servers are the Internet-facing machines that expose the TDS protocol over port 1433. In addition to acting as the gateway to the service, these servers also provide some necessary customer features, such as account provisioning, billing, and usage monitoring. Most importantly, the servers are in charge of routing requests to the appropriate back-end server. SDS maintains a directory that keeps track of where on the SDS back-end servers your primary data and all the backup replicas are located. When you connect to SDS, the front end looks in the directory to see where your database is located and forwards the request to that specific back-end node.
Supported Features
In version 1, SDS will support
  • Tables, indexes and views
  • Stored procedures
  • Triggers
  • Constraints
  • Table variables, session temp tables (#t)
The following are out of scope for SDS v1
  • Distributed transactions
  • Distributed query
  • CLR
  • Service Broker
  • Spatial data types
  • Physical server or catalog DDL and views

SQL Data Services Back End
The SDS back-end servers, or data nodes, are where the SQL Server engine lives, and it is in charge of providing all the relational database services that an application will consume. The product team is often asked why SDS provides only a subset of the features found in the on-premises SQL Server product. The reason for this is that the feature surface area of SQL Server is extremely large. A significant amount of engineering and testing goes into each feature area that is exposed in SDS, to ensure that the feature is hardened and that a customer's data is completely siloed from all the other SDS customer data. By providing the core relational features that address 95 percent of Web and departmental applications, the team could get the product to market sooner. And, because SDS is an Internet service, we are able to be much more agile and provide new features at a faster pace. Over time, you can expect to see most of the features in the on-premises product available in SDS.
The SDS back end receives the TDS connection from the front end and processes all CRUD (Create, Retrieve, Update, Delete) operations. What features are currently supported? Everything you have come to expect from a relational database, as listed in "Supported Features."

SQL Data Services Fabric
The SDS fabric is in charge of maintaining the fault tolerance and high availability of the system. The fabric plays a key role in the SDS system of automatic failure detection, self-healing and load balancing across all the SDS back-end data nodes. Earlier on, we discussed how SDS maintains a primary copy of your data as well as a series of backup replicas. The fabric provides SDS automatic failure detection. If the node where the primary copy of your data exists experiences a failure, the fabric automatically promotes one of the backup replicas to primary and reroutes the requests. Once the Fabric sees that the failover has occurred, it automatically rebuilds the backup replica in case another failure should occur.

Connecting to SQL Data Services
This is the part of the article where the SDS team hopes I put you to sleep. The fact of the matter is that because SDS exposes the TDS protocol, all the existing clients like ADO.Net and ODBC just work. Take, for example, the following ADO.Net connection string:
SqlConnection conn = new SqlConnection("Data Source=testserver; Database=northwind;
    encrypt=true; User ID=david; Password=M5DNR0ck5");
To connect to SDS, that string would look like this:
SqlConnection conn = new SqlConnection("Data
             Source=testserver.database.windows.net; Database=northwind; encrypt=true; 
             User ID=david; Password=M5DNR0ck5");
All that's changed is where the server is located. Note that the string includes the optional parameter encrypt=true. This parameter is not optional for SDS, which requires that all communication be over an encrypted SSL channel. If you try to connect without encryption, the SDS front end will terminate the connection. Because of the TDS protocol, all your existing knowledge, tools and techniques developing against SQL Server still apply. The only thing you need to be concerned about is where your application will run and its proximity to the data.

Building Applications that Consume SQL Data Services
As previously mentioned, one of the main things you need to be concerned with when storing data in SDS is where your application code will run—whether your application follows a "Code Near" architecture or a "Code Far" architecture.
Code Near A Code Near application typically means that your data and your data access components are located on the same network segment, for example when you have your application running on your corporate network. In the case of the Azure Services Platform, it would mean having your application running in Windows Azure and your data residing in SDS. When the Azure platform goes live later this year, you will have the option of picking the region where your application will be hosted as well as the region where your data will be hosted. As long as you choose the same region for both, your application code will be accessing data within the same datacenter, as shown in Figure 2.
Figure 2 Code Near Application
Code Far When your application is a Code Far application, this typically means having your data and data access components on separate networks as shown in Figure 3, often with the Internet in between. The Internet has been an incredible enabler for business and technology, but from a data-access perspective, it does pose some interesting challenges, depending on your application and its architecture.
Figure 3 Code Far Application
Suppose, for example, that your application provided some sort of data archival service to your customers. In this scenario, the typical pattern is write once, read seldom (or never), and latency would not be too much of a concern.
On the flip side, suppose your application was highly transactional with many reads and writes per second. The performance of this type of application would be poor if it was running on your corporate network and the data was located in SDS. Some sort of data cache, perhaps the project code-named "Velocity" might help, but as application architects and developers, we need to look at each application on a case-by-case basis to identify the best architecture for the application's purposes.

New Face of SQL Data Services
SDS is the relational database of the Azure Services Platform, which will be commercially available at PDC 09 this November. SDS currently provides the key relational features you have come to know and love from SQL Server. Over time, additional features will be enabled, as well as support for additional products in the SQL Server family, such as SQL Server Reporting Services and SQL Server Analysis Services. Because SDS is accessed over TDS—the same protocol as SQL Server—all the existing tools, client libraries and development techniques continue to work. I hope that by reading this article you have been given a glimpse of the new face of SDS, and that you can see that it is truly an extension of SQL Server in the cloud.

David Robinson is a Senior Program Manager on the SQL Server Data Services team at Microsoft. He spends his time driving new and compelling features into the product. He also enjoys doing presentations at community events and getting feedback from customers on SDS.

Serviços de dados SQL
O banco de dados relacional da plataforma de serviços Azure
David Robinson
Este artigo se baseia em uma versão de pré-lançamento do serviços de dados SQL. Todas as informações aqui contidas estão sujeitas a alterações.

Este artigo discute:
  • Plataforma de dados SQL
  • Arquitetura de serviços de dados SQL
  • Criando aplicativos que utilizar serviços de dados SQL
Este artigo utiliza as seguintes tecnologias:
Serviços de dados SQL
Em março de 2008 na conferência anual MIX, a Microsoft anunciou SDS (Serviços de dados do SQL), seu primeiro armazenamento de dados da nuvem. SDS era um armazenamento de valores de atributo de entidade (EAV) que pode ser acessado usando protocolos de Internet padrão da indústria. Ele incluído todos os recursos que você espera de uma oferta cloud-based, incluindo alta disponibilidade, tolerância a falhas e recuperação de desastres; tudo funciona com o mecanismo do Microsoft SQL Server. Embora o modelo de dados inicial era baseada em EAV, os recursos mais relacionais prometidos no MIX começaram a ser entregue na Professional Developers Conference em outubro de 2008.
Nos meses seguido, a equipe SDS reunidas essencial comentários da comunidade do usuário, mais importante que, enquanto a oferta SDS atual fornecido um utilitário de armazenamento de dados valiosos, não era o SQL Server. O que os clientes queriam era um banco de dados relacional oferecido como um serviço. Em março de 2009, a equipe do SQL Server anunciou ele foi acelerar seus planos para oferecer exatamente isso e isso foi atendido por predominantemente positivos comentários da comunidade. A Microsoft forneceu sempre uma plataforma de dados abrangente e os novos recursos relacionais de SDS continuar essa tradição. Com SDS, Microsoft SQL Server agora estende de dispositivos portáteis com SQL Server CE para a área de trabalho com o SQL Server Express, para a empresa com o SQL Server (edições Empresarial e padrão) e agora, a nuvem. SDS é o banco de dados relacional da plataforma de serviços Azure.
O protocolo TDS
O protocolo nativo usado por clientes para se comunicar com o Microsoft SQL Server é chamado de fluxo de dados tabular ou TDS. TDS é um protocolo bem documentado, que é usado pelos componentes do cliente Microsoft subjacentes para trocar dados com o mecanismo do SQL Server. Ainda há implementações GPL (licença pública geral) de TDS podem ser encontradas no thse Internet.

Estender a plataforma de dados SQL para a nuvem
SDS é o banco de dados relacional da plataforma de serviços Azure da mesma forma, SQL Server é o banco de dados da plataforma Windows Server. No oferta inicial, somente os recursos de banco de dados relacional principais são fornecidos. A pesquisa a equipe de produto fez mostra que o recurso atual definir endereços cerca de 95 por cento dos departamentos cargas de trabalho e da Web. Quando você examinar a marca do SQL Server, o mecanismo de banco de dados é apenas uma parte de um conjunto maior de produtos. Como SDS usa o mesmo protocolo de rede como o produto SQL Server no local, todos os produtos auxiliares existentes continuam a trabalhar. Mas que os produtos funcionarão, eles devem ser executados no local em sua própria rede. Planos de equipe do SQL Server permitir que o restante da pilha do SQL Server, no futuro, função na nuvem. O resultado final será uma experiência de desenvolvimento consistente, se sua solução destinos Azure Windows ou Windows Server. Na verdade, o mesmo código continuará a funcionar. Tudo o que será necessário é uma alteração de seqüência de caracteres de conexão.

SDS arquitetura
Como mencionado anteriormente, SDS fornece um banco de dados do SQL Server como um serviço de utilitário. Recursos como alta disponibilidade, tolerância a falhas e recuperação de desastres são criados. a Figura 1 fornece uma exibição da arquitetura SDS. Vamos dar uma olhada.
Figura 1 arquitetura de serviços de dados SQL

SQL Data Services front-end
Os servidores de front-end SDS são as máquinas com a Internet que expõem o protocolo TDS pela porta 1433. Além atuando como o gateway para o serviço, esses servidores também fornecem alguns clientes necessário recursos, tais como provisionamento de contas, cobrança e monitoramento de uso. O mais importante é que os servidores estão no encarregado de solicitações de roteamento para o servidor back-end apropriado. SDS mantém um diretório que mantém controle sobre onde nos servidores de back-end SDS seus dados principais e todas as réplicas backup estão localizadas. Quando você se conectar a SDS, o front-end procura no diretório para ver onde seu banco de dados está localizado e encaminha a solicitação para esse nó específico de back-end.
Recursos com suporte
Na versão 1, SDS oferecerá suporte
  • Tabelas, índices e modos de exibição
  • Procedimentos armazenados
  • Disparadores
  • Restrições
  • Variáveis de tabela, tabelas de sessão temp (t #)
A seguir estão fora do escopo SDS v1
  • Transações distribuídas
  • Consulta distribuída
  • CLR
  • Service Broker
  • Tipos de dados espaciais
  • Servidor físico ou catálogo DDL e modos de exibição

Serviços de dados SQL back-end
Servidores de back-end SDS, ou nós de dados, são onde reside o mecanismo do SQL Server e ele é responsável por fornecer todos os serviços de banco de dados relacional que um aplicativo consumirá. A equipe de produto é freqüentemente solicitada por SDS fornece apenas um subconjunto dos recursos encontrados no produto no local do SQL Server. O motivo para isso é que a superfície de recurso do SQL Server é extremamente grande. Uma quantidade significativa de engenharia e testar entra em cada área de recurso que é exposta no SDS, para garantir que o recurso está protegido e que dados de um cliente é completamente siloed de todos os outros dados da cliente SDS. Fornecendo os principais recursos relacionais que 95 % do endereço de Web e aplicativos departamentais, a equipe foi possível obter o produto no mercado mais cedo. E, como SDS é um serviço de Internet, estamos capazes de ser muito mais ágil e fornecer novos recursos em um ritmo mais rápido. Com o passar do tempo, você pode esperar ver a maioria dos recursos no produto no local disponível em SDS.
O back-end SDS recebe a conexão de TDS de front-end e processa todas as operações CRUD (Create, recuperar, atualizar, excluir). Quais recursos têm suporte no momento? Tudo que chegar esperar de um banco de dados relacional, conforme listado em "Recursos de suporte".

Tecido de serviços de dados SQL
Tecido SDS é responsável por manter a tolerância a falhas e alta disponibilidade do sistema. O tecido desempenha um papel chave no sistema de detecção de falha automática, AutoCorreção e balanceamento de carga entre todos os nós de dados back-end SDS de SDS. Anteriormente no, discutimos como SDS mantém uma cópia primária de seus dados, bem como uma série de backup de réplicas. O tecido fornece SDS de detecção de falha automática. Se o nó onde o primário copiar dos dados existe experiências uma falha, o tecido promove uma das réplicas backup para primário automaticamente e redireciona as solicitações. Depois que o tecido vê que ocorreu o failover, ele automaticamente recria a réplica de backup no caso de falha outra deve ocorrer.

Conexão com serviços de dados SQL
Isso é a parte do artigo onde a equipe SDS espera que colocá-lo no modo de suspensão. O fato da questão é que porque SDS expõe protocolo TDS, todos os existentes clientes como ADO.NET e ODBC apenas funcionam. Veja, por exemplo, a seguinte seqüência de conexão ADO.NET:
SqlConnection conn = new SqlConnection("Data Source=testserver; Database=northwind;
    encrypt=true; User ID=david; Password=M5DNR0ck5");
Para conectar-se a SDS, essa seqüência teria esta aparência:
SqlConnection conn = new SqlConnection("Data
             Source=testserver.database.windows.net; Database=northwind; encrypt=true; 
             User ID=david; Password=M5DNR0ck5");
Tudo o que mudou é onde o servidor está localizado. Observe que a seqüência de caracteres inclui o parâmetro opcional criptografar = true. Este parâmetro não é opcional para SDS, que requer que todas as comunicações de ser por um canal SSL criptografado. Se você tentar conectar-se sem criptografia, o front-end SDS terminará a conexão. Devido a de protocolo TDS, todos os seus conhecimentos existentes, ferramentas e técnicas de desenvolvimento no SQL Server ainda se aplicam. A única coisa que você precisa se preocupar sobre é onde seu aplicativo será executado e sua proximidade aos dados.

Criando aplicativos que utilizar serviços de dados SQL
Conforme anteriormente mencionado, uma das principais coisas que você precisa se preocupar ao armazenar dados em SDS é onde o código do aplicativo será executado — se seu aplicativo segue uma arquitetura de "Código ao" ou uma arquitetura de "Código agora".
código ao Um código ao aplicativo normalmente significa que os dados e seu acesso a dados componentes estão localizados na mesma rede segmento, por exemplo quando você tiver o aplicativo que esteja executando em sua rede corporativa. No caso da plataforma de serviços Azure, ele significa ter seu aplicativo em execução no Windows Azure e seus dados residentes em SDS. Quando a plataforma Azure fica live posteriormente neste ano, você terá a opção de separação a região onde seu aplicativo será hospedado, bem como a região onde seus dados serão hospedados. Contanto que você escolha a região mesma para ambos, seu código de aplicativo estarão acessando dados no mesmo Data Center, como mostrado na Figura 2 .
Figura 2 código ao aplicativo
código agora Quando seu aplicativo é um aplicativo de código agora, isso normalmente significa ter seus dados e componentes de acesso em redes separadas como mostrado na Figura 3 , geralmente com a Internet entre. A Internet tem sido um incrível ativador para negócios e tecnologia, mas da perspectiva de acesso a dados, ele representar alguns desafios interessantes, dependendo do seu aplicativo e sua arquitetura.
Figura 3 código aplicativo far
Suponha, por exemplo, que seu aplicativo fornecido algum tipo de serviço de arquivamento de dados para seus clientes. Nesse cenário, o padrão típico é gravação uma vez, leia raramente (ou nunca) e latência não seria muito uma preocupação.
Por outro lado, suponha que seu aplicativo foi altamente transacional com muitas leituras e gravações por segundo. O desempenho desse tipo de aplicativo seria ruim se ele estava sendo executado em sua rede corporativa e os dados foi localizados no SDS. Cache de algum tipo de dados, talvez o projeto cujo codinome é "Velocidade" pode ajudar, mas como os desenvolvedores e arquitetos de aplicativo, precisamos examinar cada aplicativo caso a caso para identificar a melhor arquitetura para fins do aplicativo.

Nova aparência do serviços de dados SQL
SDS é banco de dados relacional da plataforma de serviços Azure, que disponíveis comercialmente no PDC 09 este novembro. SDS atualmente fornece os recursos relacionais chaves que chegar a conhecer e adorar do SQL Server. Com o passar do tempo, recursos adicionais serão habilitados, bem como suporte para produtos adicionais da família SQL Server, como SQL Server Reporting Services e SQL Server Analysis Services. Porque SDS é acessado através de TDS — o mesmo protocolo como o SQL Server — todas as ferramentas existentes, bibliotecas de cliente e técnicas de desenvolvimento continuem a funcionar. Espero que lendo este artigo você recebeu uma amostra da face nova de SDS e que você pode ver que realmente é uma extensão do SQL Server na nuvem.

David Robinson é um gerente de programas sênior na equipe do SQL Server Data Services da Microsoft. Ele passa seu tempo dirigindo novos e interessantes recursos no produto. Ele também gosta de fazer apresentações em eventos da comunidade e obtenção de comentários de clientes em SDS.

Page view tracker