Übersetzung vorschlagen
 
Andere Vorschläge:

progress indicator
Keine anderen Vorschläge
MSDN Magazin > Home > Ausgaben > 2009 > MSDN Magazin August 2009 >  Die relationale Datenbank Azure Services-Plattf...
Inhalt anzeigen: Englisch mit deutscher ÜbersetzungInhalt anzeigen: Englisch mit deutscher Übersetzung
Dies sind maschinell übersetzte Inhalte, die von den Mitgliedern der Community bearbeitet werden können. Sie können die Übersetzung verbessern, indem Sie auf den jeweils zum Satz gehörenden Link "Bearbeiten" klicken.Mithilfe des Dropdown-Steuerelements "Inhalt anzeigen" links oben auf der Seite können Sie zudem bestimmen, ob nur der englische Originaltext, nur die deutsche Übersetzung oder beides nebeneinander angezeigt werden.
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.

SQL Data Services
Die relationale Datenbank Azure Services-Plattform
David Robinson
Dieser Artikel basiert auf einer Vorabversion von SQL Data Services. Alle Informationen in diesem Dokument aufgeführte unterliegt ändern.

In diesem Artikel werden die folgenden Themen behandelt:
  • SQL-Datenplattform
  • SQL Data Services-Architektur
  • Erstellen von Anwendungen, die SQL-Dienste verwenden
In diesem Artikel werden die folgenden Technologien verwendet:
SQL Data Services
Im März von 2008 auf der jährlichen MIX-Konferenz kündigte Microsoft SQL Data Services (SDS), dessen erste Datenspeicher für die Wolke. SDS war eine Entität Attributwert (EAV) Informationsspeicher, der Branche standard-Internetprotokolle zugegriffen werden konnte. Sie enthalten alle Funktionen, die von einer wolkenbasierte Angebot, einschließlich hohe Verfügbarkeit, Fehlertoleranz und Notfallwiederherstellung zu erwarten; alle powered by Microsoft SQL Server Engine. Obwohl das anfängliche Datenmodell EAV-basierten war, begann die weitere relationalen Funktionen am MIX Zugesagtes bei der Professional Developers Conference im Oktober 2008 geliefert werden sollen.
In den Monaten gefolgt SDS-Team erfasst grundlegende Feedback aus der Benutzercommunity, wichtiger, die während das aktuelle Angebot SDS die ein wertvoller Datenspeicherung Dienstprogramm bereitgestellt, es war nicht SQL Server. Was Kunden wollten, wurde eine relationale Datenbank als ein Dienst angeboten. Im März 2009 angekündigt SQL Server-Team wurde es seine Pläne, genau diese bieten beschleunigen, und dies wurde durch die extrem positives Feedback aus der Community erfüllt. Microsoft hat immer eine umfassende Datenplattform bereitgestellt und die neuen relationalen Funktionen von SDS weiterhin die Tradition. Mit der SDS erweitert Microsoft SQL Server jetzt von mit SQL Server CE, handheld-Geräte, auf dem Desktop mit SQL Server Express, für das Unternehmen mit SQL Server (Standard und Enterprise Edition) und nun der Wolke. SDS ist die relationale Datenbank der Azure Services-Plattform.
Das TDS-Protokoll
Das systemeigene Protokoll von Clients mit Microsoft SQL Server zu kommunizieren, verwendet wird als Tabular Data Stream oder TDS bezeichnet. TDS ist eine gut dokumentierten Protokoll, das von den zugrunde liegenden Microsoft Client-Komponenten zum Datenaustausch mit dem SQL Server-Datenbankmodul verwendet wird. Es gibt sogar Allgemein Public License (GPL) Implementierungen von TDS, die auf Thse Internet gefunden werden kann.

Erweitern Sie SQL-Datenplattform, die Wolke
SDS ist die relationale Datenbank der Azure Services-Plattform auf dieselbe Weise, die SQL Server die Datenbank der Windows Server-Plattform ist. In das erste Angebot werden nur die Kernfeatures relationalen Datenbank bereitgestellt. Recherchieren, die das Produktteam durchgeführt hat gezeigt, dass die aktuelle Funktion Adressen über 95 Prozent der Websites und Abteilungen Arbeitsauslastungen festlegen. Wenn Sie sich die SQL Server-Marke ansehen, ist das Datenbankmodul nur ein Teil einer größeren Suite von Produkten. Da SDS dasselbe Netzwerkprotokoll wie das Produkt auf Räumlichkeiten SQL Server verwendet, weiterhin funktionieren alle vorhandenen Zusatzkomponenten Produkte. Aber Obwohl die Produkte funktionieren Sie müssen ausgeführt werden auf Räumlichkeiten in Ihrem eigenen Netzwerk. SQL Server-Team plant, den Rest des dem SQL Server-Stapel, in der Zukunft Funktion in der Wolke aktivieren. Das Endergebnis werden eine konsistente Entwicklungsumgebung, ob Ihre Lösung Windows Server- oder Windows Azure abzielt. Der gleiche Code weiterhin funktionieren oder nicht. Alle, die erforderlich sind ist eine Verbindung Zeichenfolge Änderung.

SDS-Architektur
Wie bereits erwähnt, bietet SDS eine SQL Server-Datenbank als ein Dienstprogramm-Dienst. Features wie hohen Verfügbarkeit, Fehlertoleranz und Notfallwiederherstellung werden in erstellt. Abbildung 1 bietet einen Überblick über die SDS-Architektur. Werfen wir einen Blick.
Abbildung 1 SQL-Webdienstarchitektur

SQL-Datendienste Front-End
SDS-Front-End-Server sind die internetseitigen-Computer, die das TDS-Protokoll über Port 1433 offen legen. Zusätzlich zu den als des Gateway für den Dienst, stellen diese Server einige erforderlichen Debitor auch bereit, z. B. Kontobereitstellung, Rechnungs- und Verwendung zu überwachen. Wichtiger ist, sind die Server für Routinganforderungen an den entsprechenden Back-End-Server verantwortlich. SDS unterhält ein Verzeichnis, die verfolgen, wo auf den SDS-Back-End-Servern Ihre primären Daten und alle Replikate der Sicherung gespeichert werden. Wenn Sie eine Verbindung mit SDS herstellen, sucht das front-End in das Verzeichnis, wo sich die Datenbank befindet, und leitet die Anforderung zu diesem bestimmten Back-End-Knoten.
Unterstützte Funktionen
In Version 1 unterstützen SDS
  • Tabellen, Indizes und Ansichten
  • Gespeicherte Prozeduren
  • Trigger
  • Einschränkungen
  • Table-Variablen Sitzung temporäre Tabellen (# t)
Im folgenden sind außerhalb des Gültigkeitsbereichs für SDS v1
  • Verteilte Transaktionen
  • Verteilte Abfrage
  • CLR
  • Service Broker
  • Räumliche Datentypen
  • Physischer Server oder Katalog DDL und Ansichten

SQL-Datendienste Backend
Die SDS-Back-End-Server oder Datenknoten, sind, in denen das SQL Server-Modul befindet, und ist verantwortlich der Bereitstellung alle relationalen Datenbank Dienste, die eine Anwendung genutzt wird. Das Produktteam wird häufig gefragt warum SDS nur eine Teilmenge der Features im Produkt SQL Server auf Räumlichkeiten bietet. Der Grund dafür ist, dass die Feature-Oberfläche von SQL Server sehr groß ist. Eine beträchtliche Engineering und Testen wechselt in den einzelnen Featurebereiche, das in SDS, um sicherzustellen, dass das Feature abgesichert ist und, dass Daten eines Kunden vollständig von allen der anderen SDS Debitor siloed werden ausgesetzt ist. Bereitstellen von relationalen Kernfeatures, Adresse 95 Prozent der Webanwendungen und Abteilungsebene Anwendungen, konnte das Team das Produkt schneller Markteinführung erhalten. Und da SDS einen Internetdienst ist, wir werden viel flexibler und neue Features schneller Geschwindigkeit bereitstellen können. Im Laufe der Zeit können Sie die meisten Features im Produkt auf Räumlichkeiten in SDS erwarten.
Die SDS Back-End die TDS-Verbindung vom front-End empfängt und verarbeitet alle (erstellen, abrufen, Update, DELETE) CRUD-Operationen. Welche Funktionen werden derzeit unterstützt? Alles, was Sie kommen, erwarten aus einer relationalen Datenbank wie "unterstützte Features.

SQL Data Services Fabric
Die SDS-Fabric ist für die Verwaltung der Fehlertoleranz und hohe Verfügbarkeit des Systems zuständig. Der Stoff spielt eine wichtige Rolle im System SDS automatische Fehlererkennung, Selbstreparaturfunktion und Lastenausgleich auf allen Knoten die SDS-Back-End-Daten. Früher auf erörtert wie SDS einer primären Kopie Ihrer Daten sowie eine Reihe von Sicherung Replikate verwaltet. Der Stoff bietet automatische Fehlererkennung SDS. Wenn der Knoten, die Ihre Daten, wobei die primäre Kopie Erfahrungen vorhanden ist, ein Fehlers den Stoff automatisch fördert eine der Sicherung zu primären Replikate und leitet die Anforderungen. Nachdem der Fabric erkennt, dass das Failover aufgetreten ist, erstellt es automatisch Sicherung Replikat Fall, dass ein anderer Fehler auftreten sollten.

Verbinden mit SQL-Dienste
Dies ist der Teil des Artikels, in denen das SDS-Team ich Sie hofft in den Ruhezustand versetzen. Die Tatsache die Frage ist, SDS das TDS-Protokoll macht alle vorhandenen Clients wie ADO.NET und ODBC nur funktionieren. Betrachten Sie z. B. die folgende Verbindungszeichenfolge ADO.NET: 
SqlConnection conn = new SqlConnection("Data Source=testserver; Database=northwind;
    encrypt=true; User ID=david; Password=M5DNR0ck5");
Zum Herstellen einer Verbindung mit SDS würde die Zeichenfolge wie folgt aussehen: 
SqlConnection conn = new SqlConnection("Data
             Source=testserver.database.windows.net; Database=northwind; encrypt=true; 
             User ID=david; Password=M5DNR0ck5");
Geändert ist, in dem sich der Server befindet. Beachten Sie, dass die Zeichenfolge den optionalen Parameter enthält verschlüsseln = True. Dieser Parameter ist nicht optional für SDS, die erfordert, dass die gesamte Kommunikation über einen verschlüsselten SSL-Kanal sein. Wenn Sie versuchen, ohne Verschlüsselung verbinden wird SDS front-End die Verbindung beendet. Aufgrund der das TDS-Protokoll gelten für alle Ihre vorhandenen Kenntnisse, Tools und Techniken weiterhin für SQL Server entwickeln. Der einzige Unterschied Sie besorgt sein müssen ist, auf dem die Anwendung ausgeführt wird und seine Nähe zu den Daten.

Erstellen von Anwendungen, die SQL-Dienste verwenden
Wie bereits erwähnt, eines der wichtigsten Dinge, Sie beim Speichern von Daten in SDS mit besorgt sein müssen, in dem Ihre Anwendungscode ausgeführt wird, ob Ihre Anwendung eine Architektur "In Code" oder "Viel Code"-Architektur folgt.
Code in Eine Anwendung Code bei bedeutet normalerweise, dass Ihre Daten und der Datenzugriff-Komponenten auf demselben Netzwerk befinden, z. B. segment, wenn Sie Ihre Anwendung auf Ihr Unternehmensnetzwerk ausgeführt haben. Im Fall von Azure Services-Plattform würde dies bedeuten, müssen Ihre Anwendung in Windows Azure und Ihre Daten in SDS ausgeführt. Wenn die Azure-Plattform geht, später in diesem Jahr live, müssen Sie die Option Kommissionierliste die Region, in denen Ihre Anwendung gehostet wird, sowie der Bereich, in denen Ihre Daten gehostet werden. Solange Sie für beide die gleiche Region auswählen, wird Ihr Anwendungscode Daten in demselben Datencenter zugreifen wie in Abbildung 2 dargestellt.
Abbildung 2 Code in Anwendungen
weit-Code Wenn die Anwendung einer Anwendung Code weit ist, zugreifen dies in der Regel bedeutet müssen Daten und Komponenten in separaten Netzwerken wie in Abbildung 3 häufig mit dem Internet zwischen. Das Internet wurde eine unglaubliche Aktivierung für geschäftliche und Technologie, aber aus der Perspektive eines Zugriff auf Daten es einige interessanten Herausforderungen, abhängig von Ihrer Anwendung und seine Architektur darstellen.
Abbildung 3 Code FAR-Anwendung
Genommen Sie an, dass Ihre Anwendung eine Art von Schlüsselarchivierung Datendienst an Ihre Kunden bereitgestellt. In diesem Szenario das typische Muster ist Schreibzugriff einmal lesen selten (oder nie) und Wartezeit nicht würde zu viel Bedeutung.
Genommen Sie an, auf der Seite kippen Ihrer Anwendung sehr transaktional mit viele Lese- und Schreibvorgänge pro Sekunde wurde. Die Leistung für diese Art von Anwendung wäre für schlechte, wenn es in Ihrem Unternehmensnetzwerk ausgeführt wurde und die Daten in SDS befand. Eine Art von Daten zwischenspeichern, vielleicht das Projekt mit dem Codenamen "Geschwindigkeit" helfen kann, aber als Anwendungsarchitekten und Entwickler wir jede Anwendung auf von Fall zu Fall zum Identifizieren der besten Architektur für die Anwendung Zwecke betrachten müssen.

Neue nach der SQL-Dienste
SDS ist der relationalen Datenbank Azure Services-Plattform Dies wird im Handel erhältliche am PDC 09 dieser November. SDS bietet zurzeit Schlüssel relationalen Funktionen, die Sie kommen kennen und schätzen von SQL Server. Im Laufe der Zeit werden zusätzliche Features, sowie Unterstützung für zusätzliche Produkte der SQL Server-Produktfamilie, wie SQL Server Reporting Services und SQL Server Analysis Services aktiviert. Da SDS über TDS zugegriffen wird, das gleiche Protokoll wie SQL Server – alle vorhandenen Tools, Clientbibliotheken und Entwicklungstechniken weiterhin funktionieren. Ich hoffe, dass durch diesen Artikel lesen Sie einen Blick auf die neue Oberfläche SDS zugewiesen wurden und dass Sie sehen können, dass es wirklich eine Erweiterung von SQL Server in der Wolke ist.

David Robinson ist ein leitender Programmmanager im SQL Server Data Services-Team bei Microsoft. Er verbringt seine Zeit Umsetzung neue und überzeugende Features in das Produkt. Er bietet auch Präsentationen bei Community-Ereignissen und Feedback von Kunden auf SDS abrufen.

 

Current Issue

 

 

 

Tip: Click the printer button in your browser toolbar to get the printer friendly version of this article.

 

Page view tracker