Exportieren (0) Drucken
Alle erweitern

Skalierbarkeit, du schöne Skalierbarkeit...

Veröffentlicht: 15. Dez 2001 | Aktualisiert : 19. Jun 2004

Von Dino Esposito

Auf dieser Seite

Skalierbarkeitsvorteile
Der Wachstumsfaktor
Aufwärtsskalieren
Ausskalieren
Wie SQL Server 2000 ausskaliert ist
Partitionierte Sichten
Ausskalieren in der Praxis
Also aufwärtsskalieren oder ausskalieren?
Skalierbarkeit ist der richtige Weg
Der Dialog: ADO mit der Goldkante?

Vor vielen, vielen Jahren, als ich noch ein kleiner, schüchterner Programmierer war, bedeutete jede Gelegenheit, einmal in das Nervenzentrum des Projektmanagements hineinzuschnuppern, das höchste Glück für mich. Ob ich nun offiziell zu Meetings auf oberster Ebene eingeladen war oder "mit offenen Lauschern" unter dem Tisch saß – jahrelang vernahm ich unablässig das Wort Skalierbarkeit als ewigen Widerhall in den Sitzungsräumen. "Wie erhöhen wir die Skalierbarkeit?", "Ist der Ansatz, den Sie verfolgen, skalierbar genug?" und "Wir brauchen viel mehr Skalierbarkeit in der mittleren Ebene."

Skalierbarkeit, du schöne Skalierbarkeit... Aber was ist Skalierbarkeit eigentlich?

Was immer es auch ist – ich für meinen Teil hätte mir bei dem Skalierbarkeitsproblem immer nur die Aufmerksamkeit anderer Leute zu diesem Thema ins Gedächtnis gerufen. Die Dinge ändern sich, und auch im Projektmanagement bleibt eben alles anders.

Ich kann mich auch daran erinnern, das Wort "Skalierbarkeit" in vielen Lehrbüchern gesehen zu haben, wo es geradezu überbordend verwendet wurde, um vorzugeben, der Autor wüsste etwas von den Prinzipien und Techniken von verteilten Systemen. "Bei einem guten Entwurf ist die Skalierbarkeit ein entscheidender Faktor."

Skalierbarkeit, du schöne Skalierbarkeit... Aber, noch einmal, was ist Skalierbarkeit eigentlich?

In jüngster Zeit habe ich festgestellt, dass das Adjektiv skalierbar zum bevorzugten Werkzeug avanciert ist, um die Features beliebiger Softwaretechnologien für verteilte Umgebungen zu beschreiben. Ich habe mir also eingeredet, dass es meiner Karriere förderlich wäre, wenn ich meiner eigenen Skalierbarkeit mehr Aufmerksamkeit schenken würde. Und da liegt der Hase im Pfeffer. Was bedeutet Skalierbarkeit letztendlich? Und im Kontext der modernen Datenbankserver und -hardware, was bedeutet es dort?

Skalierbarkeitsvorteile

Abstrakt gesagt glaube ich, dass es zwei Möglichkeiten gibt, um ein System mit dem "lebenswichtigen" Attribut der Skalierbarkeit aufzuwerten. Bei der ersten Möglichkeit wird das System auf logische Weise auf der Entwurfsebene optimiert. Sie betrachten das System losgelöst von irgendwelchen Softwaretools oder Infrastrukturelementen und bauen es dann mit Hardware auf. Praktisch ausgedrückt heißt das, dass Sie die Engpässe und kritischen Ressourcen minimieren, während Sie, wann immer es geht, die natürliche Parallelität der Tasks nutzen.

Bei der zweiten Möglichkeit wird genau entgegengesetzt gehandelt. Sie bevorzugen die integrierten Features eines bestimmten Software/Hardware-Mixes und ordnen Ihren Lösungen und Ihrer Kreativität eine untergeordnete Rolle zu. Im Grunde überlassen Sie den Tools, die Sie für die Behandlung der Skalierbarkeit und Interoperabilität ausgewählt haben, die Verantwortung für diese Tasks.

Nebenbei bemerkt wird die zweite Möglichkeit schon seit Jahren verwendet. Sie stammt aus der Zeit vor dem Internet, als sich die Menschen vorwiegend um Aspekte wie Leistung und Stabilität gekümmert haben und den Aspekt der Skalierbarkeit weitgehend ignorierten. (Und dieser Aspekt ist bei fehlender Reichweite der Internetkonnektivität tatsächlich ein geringes Problem.)

Vor Jahren führte das begrenzte Angebot an bezahlbaren integrierten Lösungen mit vielfältigen Features dazu, dass sich die Leute hauptsächlich auf den Entwurf konzentrierten und peinlichst genau auf die Datenbankstruktur und die Rechenkosten der verschiedenen Datenbankoperationen achteten.

Diese hardwareunabhängige Vision der Skalierbarkeit scheint heute überwunden. Die Verfügbarkeit von relativ günstiger und leistungsstarker Hardware verbannt Aspekte wie Optimierung und Entwurfseffizienz auf die hinteren Ränge in der Prioritätenliste des globalen Projektmanagements.

Eine goldene Regel der Rechenkomplexität besagt, dass nur die schnellsten Algorithmen die Vorteile von schneller Hardware zu nutzen wissen. Rufen Sie sich diese Regel in Erinnerung, wenn es um Skalierbarkeit geht.

Der Wachstumsfaktor

Im Allgemeinen bezieht sich Skalierbarkeit auf die Fähigkeit eines Systems, seine mittlere Leistung bei wachsender Zahl von Clients beizubehalten, oder sogar zu steigern. Skalierbarkeit wirkt so als sauberes, einfaches, schlüssiges Konzept.

Skalierbarkeit kann jedoch auch abstrakt sein. Leider ist Skalierbarkeit keine Eigenschaft eines Systems, die Sie programmtechnisch zu- oder abschalten oder direkt steuern können. Im Gegenteil: Skalierbarkeit ist ein Systemattribut, das sich aus der Kombination aller anderen Attribute, dem Gesamtentwurf und der Implementierung sowie dem gewählten Interaktionsmodell ergibt.

Der interne Grad an Skalierbarkeit eines verteilten Systems kann nicht einfach mit einem Monitor oder einem Analysetool gemessen werden. Andererseits gibt es eine Vielzahl von Implementierungsfaktoren (z.B. Verfügbarkeit von kritischen Ressourcen, Engpässe beim Entwurf, langwierige und doch notwendige Tasks sowie die exzessive Serialisierung von Operationen), die in gewisser Weise einen Indizienbeweis für begrenzte Skalierbarkeit darstellen.

Ohne Belastungstests des Systems in einem echten Produktionsszenario können Sie jedoch nicht sagen, ob ein bestehendes System ausreichend skalierbar ist oder nicht.

Skalierbarkeit bezieht sich in gewissem Maße auf die Leistung und ist kein Thema, wenn das System gut konzipiert ist und sinnvollen und durchdachten Schemas folgt.

Es ist erstaunlich zu sehen, wie ein unsichtbares Systemattribut wie die Skalierbarkeit immer wieder zum Sündenbock für alle Leistungsineffizienzen gemacht wird, die in einem System auftreten können. Entwerfen Sie Ihre Komponenten so, dass Sie den Rechenkosten der Operationen hinreichend Rechnung tragen. Damit fahren Sie immer gut, egal, wie sich Ihr System in der Zukunft weiterentwickeln wird.

Skalierbarkeit ist immer ein Faktor, der auch das Wachstum eines Systems beeinflusst. Mit anderen Worten, ein System, das wachsen muss, ist ein System mit einer aktuellen Leistung, die nicht die erwartete Anzahl von Benutzern befriedigt. Wie verbessern Sie die Leistung eines solchen Systems auf struktureller Ebene? Einfach gesagt – mit leistungsstärkerer Hardware oder mit einer besseren Kombination von Hard- und Software.

Diese beiden Möglichkeiten werden heutzutage mit bestechenderen und vermarktbaren Ausdrücken belegt. Der Ansatz, der sich auf die Hardware konzentriert, wird als Aufwärtsskalieren bezeichnet. Der schwierigere Ansatz des Hard- und Softwaremixes wird Ausskalieren genannt.

Wenn Sie das Wachstum Ihres Systems steuern möchten, sollten Sie dafür sorgen, dass Sie entweder aufwärtsskalieren oder ausskalieren. Stellen Sie aber auf jeden Fall sicher, dass Sie die Skalierbarkeit des Systems beibehalten.

Skalierbarkeit, du schöne Skalierbarkeit... Ist dies einfach die Definition, die am besten passt?

Aufwärtsskalieren

Das Aufwärtsskalieren eines Systems bedeutet im Grunde, dass Sie das ganze Drum und Dran in ein neues und leistungsstärkeres Hardwaresystem migrieren. Sobald das neue System einsatzbereit ist, erstellen Sie eine Sicherheitskopie der Tabellen und Anwendungen und gehen online. Die Auswirkungen auf die vorhandene Code- und Systemverwaltung sind minimal.

Glauben Sie jedoch nicht, dass Sie auf dem Weg zum Aufwärtsskalieren auf Rosen laufen. Das Aufwärtsskalieren hat eine negative Seite mit einigen Aspekten, die eine nähere Betrachtung erfordern. Zunächst hat ein System, das aufwärtsskaliert, einen Single Point of Failure (SPOF) und unterliegt evtl. einigen Beschränkungen bezüglich der Hardware. Durch das Aufwärtsskalieren wird die Verarbeitungsleistung des Servers mehr beansprucht, da ein leistungsstärkerer Computer verwendet wird. Auch wenn uns dies heutzutage noch in weiter Ferne scheint, hat das Wachstum der Verarbeitungsleistung einer einzelnen Hardwareeinheit einen physikalisch begrenzten oberen Schwellwert, der eines Tages erreicht sein wird.

Außerdem kommen bei Erreichen dieses oberen Grenzwerts enorme Kosten auf uns zu, sowohl beim Zeitfaktor (es kann Jahre dauern, bis die Technologie eine Verdoppelung der Leistung ermöglicht), bei den Preisen und, nicht zuletzt, beim Energieverbrauch und Büroraum.

Wenn wir uns dies klar machen, ist das Aufwärtsskalieren auf weite Sicht die erste Option, die berücksichtigt werden sollte, denn sie hat die geringsten Auswirkungen auf die vorhandene Struktur.

Ausskalieren

Durch das Ausskalieren wird die Verarbeitungsleistung des Systems als Ganzes erhöht, und nicht nur die Leistung der einzelnen Verarbeitungseinheit, die als Server fungiert. Ein ausskaliertes System ist von Natur aus modular und wird durch eine Gruppe von Computern gebildet. Das Ausskalieren eines solchen Systems bedeutet, dass dem Netzwerk ein oder mehrere Computer zusätzlich hinzugefügt werden.

In einer ausskalierten stark partitionierten Umgebung sollten Sie einem abstrakteren und hardwareunabhängigeren Konzept für die Verarbeitungsleistung folgen. Die gesamte Verarbeitungsleistung ist die Summe der physischen Verarbeitungsgeschwindigkeiten der Computer, die durch die knotenübergreifenden Daten- und Anwendungspartitionen verzweigt werden.

Durch das Ausskalieren sind dem Wachstum eines Systems keine Grenzen gesetzt. Das ist zum jetzigen Zeitpunkt extrem vorteilhaft. Es erfordert jedoch sehr viele Neuentwürfe und Reimplementierungen. Ein System, das anhand einer Einzelserverlogik konzipiert wurde, muss komplett neu durchdacht und umstrukturiert werden, um die Anforderungen des Ausskalierens umsetzen zu können.

Sie müssen festlegen, wie die Daten über mehrere DBMS-Server partitioniert werden. Der Anwendungspfad zu den Daten muss durch ordnungsgemäße Ausführungspläne sorgfältig optimiert werden. Für die Feinabstimmung des Systems während seiner Lebensdauer ist eine gute, proaktive und häufige Analyse der Benutzeraktivität entscheidend.

Zu diesem Preis erhalten Sie ein nahezu unendliches System, dem Sie in der mittleren Ebene und in der Datenebene Verarbeitungsressourcen hinzufügen können, um der steigenden Anzahl von Benutzern und Arbeitsauslastungen gerecht zu werden.

Für ein skalierbares System ist es nicht entscheidend, wie hoch die Anzahl von erwarteten Benutzern sein kann. Vielmehr gilt es zu berücksichtigen, wie schnell diese Anzahl wachsen wird. Das relative Wachsen der Zahlen ist viel wichtiger als absolute Zahlen.

Der Entwurf eines Systems für ein eher konstantes Publikum von 100 Mio. Benutzern ist viel einfacher als die Erstellung eines Systems für 100 Benutzer, deren Anzahl sich aber schon morgen vervielfachen kann. Daraus abgeleitet erklärt sich, dass der Bedarf an Skalierbarkeit besonders stark in branchenführenden E-Commerce/Web-Anwendungen ist, weil diese Systemfamilien einem bedeutenden plötzlichen Anstieg der Benutzerzahlen ausgesetzt sind.

Wie SQL Server 2000 ausskaliert ist

Mit der Gewissheit, dass ein Aufwärtsskalieren relativ einfach zu implementieren und zumindest bei geringen Datenmengen und Benutzerzahlen relativ günstig ist, stellt das Ausskalieren die bei weitem interessanteste und reizvollste Technologie vom Standpunkt der Software aus dar. Mit Hilfe von handelsüblichen Softwareprodukten, die in der Back-End-Ebene arbeiten, erzielen Sie einen angemessenen Ausskalierungsgrad.

Ein Ausskalierungsmodell ist z.B. das Clusteringmodell in COM+ und Windows 2000. Alle Server in der Geschäftsebene besitzen identische Kopien der COM+-Komponenten. Der Windows 2000-Dienst NLB (Network Load Balancing; Netzwerklastenausgleich), der im Hintergrund ausgeführt wird, leitet neue Anfragen je nach einzelner Arbeitsauslastung an die Komponenten weiter.

Aus der Sicht der Anwendung sehen Sie eine einzige Entität – die Gruppe der COM+-Komponenten. Sie verfassen Code für diese Komponenten, ohne dabei die Anzahl der verschiedenen Server zu beachten, auf denen diese laufen, missachten dabei auch die Rolle des zugrunde liegenden Lastenausgleichdienstes. Ein Ausskalieren ist hier so einfach wie das Hinzufügen eines neuen voll konfigurierten Windows 2000 Server mit dem richtigen installierten Befehlsset.

In diesem Clusteringmodell kooperieren zwei klar voneinander abgegrenzte Entitäten: die Komponenten der Anwendung und der Lastenausgleichdienst des Systems. Ein solches Modell kann nicht so leicht auf die Datenebene angewendet werden. Tatsächlich ist es so, dass Sie nur eine Softwareentität haben – das DBMS (Datenbank-Managementsystem).

SQL Server 2000 unterstützt ein anderes Clusteringmodell, die sog. verbundenen Server. Das Netzwerk macht eine Gruppe von Servern für die Anwendungen sichtbar, auf denen der SQL Server ausgeführt wird. All diese öffentlichen Instanzen von SQL Server sind autonom, sie werden unabhängig voneinander verwaltet, und sie haben unterschiedliche Tabellen und sogar unterschiedliche Einstellungen.

Der wichtigste Aspekt einer DBMS-Arbeitsauslastung sind die Daten. Anwendungen sind primär für die gleichmäßige Verteilung von Daten über mehrere Server verantwortlich. Der eigenständige SQL Server 2000 besitzt die integrierte Fähigkeit, aktualisierbare Sichten von Daten zu unterstützen, die physisch über mehrere Server partitioniert sind.

Sie können z.B. entscheiden, dass sich die Tabellen über die multiplen Instanzen von SQL Server erstrecken sollen, die im Netzwerk verfügbar sind. Sie können diese Daten bei Bedarf zusammenfließen lassen. Dazu verwenden Sie partitionierte Sichten, spezielle Arten von Sichten, die eine besondere Unterstützung von der SQL Server 2000-Laufzeitversion genießen.

Partitionierte Sichten

Partitionierte Sichten gelten für verbundene Tabellen, insbesondere für kritische Tabellen, die sich über zwei oder mehr Server erstrecken. Verbundene Tabellen werden mit Hilfe eines Prozesses erstellt, den wir als horizontales Partitionieren bezeichnen. Dabei wird eine vorhandene Tabelle in einen Verbund kleinerer Tabellen aufgeteilt. In Anwendungsbegriffen ausgedrückt, erscheint eine verbundene Tabelle wie eine einfache Blockmodellsicht.

Indem die Mitgliedstabellen auf mehrere Computer verteilt werden, wird die Arbeitsauslastung ausgeglichen. Sie haben dasselbe Format wie die ursprüngliche Tabelle, aber jede enthält nur einen Bruchteil der Zeilen. Mitgliedstabellen können einen beliebigen Namen haben. Wir empfehlen jedoch, den Mitgliedstabellen denselben Namen wie dem Original zu geben, um die Speicherorttransparenz zu wahren.

Die Bestandteile bildenden Tabellen werden normalerweise so ausgelegt, dass sie gleich große Abschnitte von Daten enthalten. Die Unterscheidung erfolgt anhand eines eindeutigen, nichtaktualisierbaren Primärschlüssels. Wenn Sie Integrität und Konsistenz beibehalten möchten, müssen Sie zudem sicherstellen, dass kein Datensatz dupliziert wird. Das bevorzugte Tool hierfür ist eine CHECK-Einschränkung in jeder Mitgliedstabelle. In der Spalte für die Partitionierung sind keine NULL-Werte zulässig. Außerdem darf sie keine berechnete Spalte sein.

Eine partitionierte Sicht ist eine Standardsicht mit verteilten SELECT-Anweisungen, die auf strukturgemäß identische Tabellen angewendet werden und die Daten mit Hilfe von UNION ALL-Klauseln zusammenführen.

CREATE VIEW MeineSicht AS 
   SELECT * FROM Server1.Datenbank.Besitzer.MeineTabelle 
UNION ALL 
   SELECT * FROM Server2.Datenbank.Besitzer.MeineTabelle 
UNION ALL 
   SELECT * FROM Server3.Datenbank.Besitzer.MeineTabelle 
UNION ALL 
   SELECT * FROM Server4.Datenbank.Besitzer.MeineTabelle 

Diese verteilte Sicht muss auf einem der beteiligten Server erstellt werden. Jeder Server muss für die anderen Server als Verbindungsserver sichtbar sein. Vorzugsweise sollte die Option Verzögerte Schemagültigkeitsprüfung für diese Server auf True gesetzt sein. Dieses Attribut bestimmt, ob das Schema von verknüpften Remotetabellen auf Gültigkeit geprüft wird. Wenn Sie es auf True setzen, überspringt SQL Server die Gültigkeitsprüfung, was zu besseren Ergebnissen führt. In diesem besonderen Fall hat dies keine unerwünschten Nebeneffekte.

Partitionierte Sichten wurden das erste Mal in SQL Server 7.0 eingeführt. In SQL Server 2000 sind sie mit einigen wesentlichen Verbesserungen zu einem wichtigen Tool zum Ausskalieren von Systemen geworden.

Partitionierte Sichten in SQL Server 2000 können aktualisiert und über den Abfrageoptimierer so angepasst werden, dass der Bedarf einer serverübergreifenden Verarbeitung reduziert wird. Eine verbundene Tabelle hat den entscheidenden Vorteil, dass die Arbeitsauslastung zwischen verfügbaren Servern ausgeglichen wird. Das ist offensichtlich ein Vorteil, solange ein Server die zugewiesenen Tasks lokal bewältigen kann.

Eine partitionierte Sicht ist unter den folgenden Bedingungen aktualisierbar:

  • Sie wird aus den Ergebnissen von einzelnen SELECT-Anweisungen erstellt, die per UNION ALL-Klausel zusammengeführt werden.

  • Jede SELECT-Anweisung wirkt an einer einzelnen Tabelle (d.h., es ist kein JOIN zulässig).

  • Die Tabelle ist eine lokale oder verknüpfte Tabelle.

  • Die Tabelle enthält keine Timestampspalte.

Auf eine verknüpfte Tabelle muss über die folgenden Möglichkeiten verwiesen werden: den voll gekennzeichneten Namen (Server, Datenbank, Besitzer, Tabelle), die OPENROWSET-Funktion oder die OPENDATASOURCE-Funktion.

Die Anweisungen INSERT, UPDATE und DELETE, die Sie an einer aktualisierbaren partitionierten Sicht ausführen, müssen erst einer Reihe von Einschränkungen unterzogen werden, bevor diese effektiv werden. Sie können z.B. keine neuen Zeilen einfügen, wenn die Tabelle eine Identitätsspalte enthält. Sie müssen alle Spalten angeben, auch solche, die eine DEFAULT-Einschränkung haben. Aktualisierungen und Löschungen sind nicht zulässig, wenn die Sicht eine Selbstverknüpfung ist oder mit einer der anderen Mitgliedstabellen verknüpft ist.

Ausskalieren in der Praxis

Das Clusteringmodell, das von SQL Server 2000 bereitgestellt wird, ist nicht für alle Benutzer zugeschnitten. Es wurde besonders für High-End-OLTP-Unternehmenssysteme und aggressive Webanwendungen entwickelt.

Damit es effektiv ist, müssen Daten partitioniert werden. Außerdem müssen die Partitionen einem logischen Schema folgen. Alle Detaildaten müssen sich auf ein und demselben Server befinden, und die Daten müssen sich für ein logisches Aufteilen eignen.

Ein genaues Verständnis der Datenzusammenhänge ist unverzichtbar. Darüber hinaus sollte sich die Form der Daten mit der Zeit nicht wesentlich verändern. Und wenn Sie wissen, dass die Form sich ändert, sollten Sie die zukünftige Form im Voraus kennen und die Partitionen entsprechend planen.

Die Existenz der Detaildaten auf dem gleichen Knoten ist lebenswichtig; andernfalls verlieren Sie schnell durch Wartezeiten des Netzwerks, was Sie zuvor durch eine umsichtige Lastenausgleichstrategie eingespart haben.

Wenn Sie die Datenpartitionierung abgeschlossen haben, haben Sie nur die Hälfte des Weges zurückgelegt (auch wenn Sie unglaublich erfolgreich und clever dabei waren). Und tatsächlich bleibt Ihnen die Aufgabe überlassen, die Daten in einen entsprechenden Cluster zu verschieben und Sicherungs- und Überwachungslösungen einzurichten.

Eine Ausskalierungstechnologie zu implementieren, ist definitiv kompliziert und ein Ansatz, der einen größeren Eingriff durch den Benutzer verlangt als das Aufwärtsskalieren. Entwurfsprobleme summieren sich zu Hindernissen bei der Praktikabilität, z.B. dem Fehlen spezieller Tools zum Verwalten von Ausskalierungsclustern als einzelne Entitäten. Einige dieser Tools sollen mit der nächsten Version von SQL Server, Codename 'Yukon', ausgeliefert werden.

Das Ausskalieren als Skalierbarkeitsmethode sieht vielversprechend und reizvoll aus; das Aufwärtsskalieren einzelner Server ist jedoch in den meisten Fällen immer noch der sicherste Weg.

Also aufwärtsskalieren oder ausskalieren?

Es ist eine Tatsache, dass ein Webdienst der dritten Generation problematische Anforderungen in Bezug auf Hardware haben kann. Im Prinzip müssen Sie nur eine Frage lösen: Soll ich aufwärtsskalieren oder ausskalieren?

Mit dem Aufwärtsskalieren verbessern Sie mit der Zeit die Leistung eines einzelnen Hardwaresystems. Mit dem Ausskalieren bringen Sie Ihr System weiter in den Bereich einer stetig wachsenden Serverfarm, d.h. einem Verbund kleinerer Einzelsysteme.

Ein System, das aufwärtsskaliert wird, ist fehleranfälliger, von Natur aus weniger stabil und über einem bestimmten Schwellwert nicht mehr aufrüstbar. Es kann auch kostenintensiver sein (vergl. Energieverbrauch, Platz und Preis). Andererseits ist das Aufwärtsskalieren eines Systems genauso einfach und problemlos wie das Durchführen einer Sicherungs- und Wiederherstellungsprozedur.

Ein System, das aufwärtsskaliert wird, ist von Natur aus stabiler, erweiterbar und insgesamt kostengünstiger, auch wenn die Verwaltung einer einzigen Arbeitsstation immer unproblematischer ist, als mit Dutzenden oder Hunderten von Computern umgehen zu müssen.

Die Liste der Vor- und Nachteile ist jedoch in gewisser Weise relativ und absolut projektspezifisch.

Aufwärtsskalieren oder ausskalieren, das hängt ganz von der Natur des Systems ab. Ausskalieren ist sicher empfehlenswert, solange Sie eine einzelne Instanz von SQL Server haben, die möglicherweise auf einem separaten Multiprozessorcomputer ausgeführt wird und über die Ihre Datenzugriffsanforderungen abgewickelt werden. Dies ist übrigens das Skalierbarkeitsmodell, das Webfarmen zugrunde liegt.

Das Ausskalierungsmodell der Webfarm ist jedoch nur eine Möglichkeit der Betrachtung von horizontaler Skalierbarkeit. Wenn Sie große Mengen gleichzeitiger Daten verarbeiten müssen (z.B. ein OLTP-System), benötigen Sie evtl. mehrere kooperierende Server, um das alte Motto divide et impera ("teile und herrsche!") umzusetzen. In diesem Fall müssen Ihre Daten richtig reorganisiert sein. Das ist eine riesige Menge Arbeit, die nicht willkürlich angegangen werden darf. Bevor Sie sich für ein solches Projekt engagieren, sollten Sie sicherstellen, dass Ihr System für einen solchen Quantensprung bereit ist. Das heißt, stellen Sie sicher, dass es als OLTP-System betrachtet werden kann.

Allgemein gilt: Während das Ausskalieren vielversprechend aussieht, sollte das Aufwärtsskalieren immer als Erstes angestrebt und nur dann verworfen werden, wenn ein guter Grund vorliegt.

Skalierbarkeit ist der richtige Weg

Trotz der ganzen Theorie, die die Technologien der Aufwärts- und Ausskalierung umgibt, gibt es einige echte Fakten:

  • Bei der Skalierbarkeit dreht sich alles um die Komplexität von Computeroperationen (Rechenkomplexität) und weniger um die Leistung.

  • Das Aufwärtsskalieren mit Hardware oder das Ausskalieren mit Hilfe von speziellen Datenbankdiensten sollte nur in Betracht gezogen werden, wenn Sie bereits einen guten Kompromiss zwischen der optimalen Rechenkomplexität der Tasks und dem Implementierungsaufwand erzielt haben.

Ich weiß jedoch, dass die Verwendung schnellerer Hardware immer besser ist als die Verbesserung von Algorithmen, die Optimierung von Abfrageausführungsplänen und die Identifizierung und Beseitigung von Engpässen. Außerdem hilft dies bei der Einhaltung von Abgabefristen!

Der Dialog: ADO mit der Goldkante?

Mein Chef fragte mich neulich: "Was ist der Unterschied zwischen ADO und ADO.NET?" Ich habe ihm geantwortet, dass ADO.NET wieder so eine Datenzugriffsschicht ist, die wir bald verwenden werden, aber ihre Vor- und Nachteile noch gar nicht richtig ausgelotet haben. Ich stelle fest, dass ADO-Code in .NET funktioniert, aber Dein "ADO mit der Goldkante?"-Artikel ließ mich ein bisschen an dieser Gewissheit zweifeln ;-)

Ich stimme zu, dass es auf den ersten Blick schwierig ist, sich ADO.NET nicht als "wieder so eine Datenzugriffsschicht" vorzustellen. Auf den zweiten Blick liegen die Dinge aber etwas anders. ADO.NET ist und bleibt der einzig empfehlenswerte einzuschlagende Weg für datenbehandelnde Anwendungen, die unter .NET ausgeführt werden.

In den vergangenen Jahren habe ich gesehen, wie Leute plötzlich in eine ADO-Manie verfielen und für ADO ihren optimierten und feinabgestimmten RDO-Code fallen ließen. Sie erzielten alle möglichen Resultate – nur keine außergewöhnlichen. Aber nur das arme ADO, das ins Rennen geschickt wurde, bekennt sich des Hochverrats schuldig.

Ich sehe schon, dass das arme ADO.NET irgendwann zum Sündenbock bei gescheiterten Migrationsprojekten abgestempelt wird. Kein Code ist perfekt, aber Systemcode ist beinahe immer besser als mein Code, Dein Code, unser aller Code. Damit hätte die RDO-ADO-Aktualisierung in Frage gestellt werden können. Warum Code antasten, der gut funktioniert, um von ODBC auf OLE DB und ein reichhaltigeres Objektmodell umzusatteln?

Mit ADO.NET wird alles anders. ADO.NET ist erste Wahl, wenn Sie sich für .NET als Serverplattform entscheiden. ADO.NET ist die erste Klassenbibliothek, bei der Sie speziell mit Daten arbeiten müssen.

Technisch ausgedrückt können Sie zwar bei ADO bleiben, aber Sie würden einen hohen Preis beim Marshalling von .NET in COM zahlen. ADO.NETs Schlüsselvorteil ist, dass Sie es erst studieren, dann damit in einer kontrollierten Umgebung arbeiten und schließlich mit der echten Codierung für das tägliche Brot beginnen können. Wie viele Leute haben das gemacht, als sie auf ADO umstiegen?

ADO.NET ist angesichts der heutigen, webzentrierten Welt ein angemesseneres Modell als ADO. Gleichzeitig wurde das Objektmodell von ADO.NET so weit wie möglich auf ADO-Konzepte ausgerichtet (wo nötig und wo zu empfehlen). Für den Wechsel zu ADO.NET sollten Sie jetzt beginnen. Ihre Lernkurve wird sich in kürzester Zeit verbessern. Entwickler müssen nicht allzu viele Konzepte erlernen, um ADO.NET zu verwenden.

Sie müssen allerdings ihre Denkstrukturen in ADO "zurücksetzen" und sich mit dem neuen Modell auch gedanklich beschäftigen. ADO.NET ist alles andere als "wieder so eine Datenzugriffsschicht". Sie müssen keine Entscheidung zwischen ADO und ADO.NET treffen. Viel wichtiger ist die Entscheidung, ob Sie die .NET-Plattform verwenden möchten.

Links zu verwandten Themen

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2015 Microsoft