Scale-Out vs. Scale-Up - Skalierung durch Vermehrung statt Verbesserung

Original: http://oracle2mysql.wordpress.com/2007/08/22/12/ Mittwoch, 22. August 2007 19:26
Autor: Ben Krug
Übersetzung: Sebastian Wallroth

Scale-Up versus Scale-Out - Worum geht's?

Grundsätzlich geht es um die Skalierung, das heißt die Verbesserung oder Vergrößerung eines Serversystems um zum Beispiel eine größere Datenmenge oder mehr Zugriffe verarbeiten zu können oder die vorhandenen Daten oder Zugriffe schneller zu bearbeiten. "Scale-Up" und "Scale-Out" sind neue geschaffene Wörter, die sich an den englischen Wörtern "build up", "aufbauen; das Vorhandene verbessern" und "build out", "ausbauen; das Vorhandene erweitern" orientieren.
"Scale-up" oder "Scaling up" ("vertikale Skalierung") bedeutet, Server aufzurüsten oder einen größeren Server einzusetzen, also eine qualitative Veränderung.
"Scale-out" oder "Scaling out" ("horizontale Skalierung") bedeutet, neue Server hinzuzufügen, also eine quantitative Änderung.

Oracle wirbt für beide Methoden. Man soll RAC auf großen Servern oder "Blades" oder "Grids" einsetzen.

MySQL wirbt im Allgemeinen für Scale-Out und die meisten der großen Seiten, die MySQL verwenden setzen auf Scale-Out. Meiner Erfahrung nach und in Einklang mit Jay Pipes exzellentem Blog-Artikel zu diesem Thema ist das teilweise so, weil MySQL nicht so gut vertikal skaliert wie horizontal. (Ein anderer Grund, den Jay erwähnt und der sich auch mit meinen Erfahrung deckt, ist, dass Leute, die eine Oracle-Lizenz kaufen meist auch teure Maschinen bezahlen, um es darauf laufen zu lassen.)

Mit Oracle, egal ob Du vertikal oder horizontal skalierst, wirst Du normalerweise RAC verwenden, was das Aufsetzen von private-Verbindungen und ein Grundsätzliches "alles gemeinsam nutzen" für deine Server bedeutet. Das ist immer noch irgendwie ein vertikales Skalieren der Datenbank, ein Wachsen mit einer bestehenden Anzahl von Servern. (Korrigiere mich, wenn ich falsch liege...)

Mit MySQL neigen die Leute dazu, ihre Datenbanken aufzuteilen, sie in Teile zu "sharden", die in verschiedene Datenbanken auf verschiedenen Servern getan werden. Beispielsweise könntest Du eine kleine globale Datenbank haben, die Informationen darüber enthält, auf welchem Server die Daten eine Benutzers gespeichert sind und dann mehrere "Benutzer"-Datenbanken auf verschiedenen Servern. Deine Datenbank würde im Grunde nach Benutzern in kleinere Datenbanken aufgeteilt sein. (So machen wir das.) Das ist horizontales Skalieren. Wenn Du dann mehr Benutzer kriegst und Du wachsen musst, fügst Du einfach neue Server hinzu.

(Wenn Du auf der anderen Seite eine kleine Datenbank hast - die komplett in den RAM passt - kannst Du MySQLs Clustering-Technologie und die NDB-Speicher-Engine verwenden, um einen Cluster einzurichten, der mehr wie RAC ist. Mit MySQL 5.1 kannst Du das mit Festplatten-basierten Datenbanken machen - aber wieso?) (Lies die Kommentare unten, wenn Du wissen willst, warum...)

Ein anderer Aspekt des horizontalen Skalierens kann sein, MySQLs Replikationstechnologie auf die eine oder andere Art zu verwenden. Du kannst die Master-Master-Replikation einsetzen, um zwei (oder ein paar mehr) Datenbanken aufzusetzen, die im Wesentlichen Kopien voneinander sind und sie synchron miteinander halten. Oder, und das ist üblicher, (und wir machen das so) Du verwendest die Master-Slave-Replikation, um Kopien deiner Datenbanken (shards) zu machen, die Du verwenden kannst, um deine Lese-Zugriffe darauf zu verteilen (und für eine Wiederherstellung im Falle einer Katastrophe: wenn der Master abstürzt - ernenne einen Slave zum neuen Master). Die meisten großen LAMP-Webseiten scheinen das so zu machen.

Zusammenfassend kann man sagen, dass der übliche Ansatz ist, deine Datenbank so zu entwerfen, dass sie in mehrere Shards (Server/Datenbanken) aufgeteilt wird, und Du dann die Replikation verwendest, um Kopien der Shards für weitere Lastverteilung und Verfügbarkeit herzustellen.

Das sagen einige andere Quellen:

Definitionen nach Wikipedias Eintrag zu Skalierbarkeit:

Vertikal skalieren (scale vertically)
Vertikal zu skalieren (scale-up) bedeutet, dass man einem einzelnen Knoten in einem System Ressourcen hinzufügt, typischer Weise gehört dazu das Hinzufügen von CPUs oder RAM zu einem einzelnen Computer. Es kann auch die Erhöhung der Anzahl der laufenden Prozesse, wie zum Beispiel der Erhöhung der Anzahl der Apache-Daemons bedeuten.

Horizontal skalieren (scale horizontally)
Horizontal zu skalieren (scale-out) bedeutet, einem System mehr Knoten hinzuzufügen, wie zum Beispiel das Hinzufügen eines neuen Computers zu einer verteilten Softwareanwendung. Ein Beispiel könnte das horizontale Skalieren von 1 auf 3 Webserver sein.

Nach MySQL: (aus der ersten Seite von "12 Tage des Scale-Out")

Was ist Scale-Out von Datenbanken?

Scale-Out ist eine moderne Rechnerarchitektur, die Organisationen in die Lage versetzt, die Anwendungsleistung und die Skalierbarkeit auf einer inkrementellen, auf die Anforderungen zugeschnittenen Basis zu verbessern, indem mehrere replizierte Datenbankserver auf einer niedrigpreisigen normalen Hardware hinzugefügt werden. Dies steht im Kontrast zu einem Scale-Up-Ansatz, der Organisationen nötigt, eine gewaltige Vorabinvestition in teurere und komplexere Serverhardware und Datenbanklizenzen zu tätigen, um mehr Kapazität hinzuzufügen.

Der exzellente Blog-Artikel von Jay Pipe: Das uneindeutig unklare Duo: Horizontales Skalieren und Vertikales Skalieren

Eine Produktinformation von MySQL: Guide to Cost-effective Database Scale-Out using MySQL (Anleitung für kosteneffektives Scale-Out mit MySQL)

Kommentar von Keith Murphy vom 23. August 2007 1:26

Ich habe ein paar Anmerkungen. Zum einen... MySQL 5.0 hat ein totales RAM-internes Clustering unter Verwendung der NDB-Engine. Mit MySQL 5.1 kann man auf der anderen Seite nur die Indizes im RAM halten. Tatsächlich können die Daten auf der Festplatte gehalten werden.

Warum würdest Du das tun? Nun, vor allem wegen der Verlässlichkeit. Wenn Du mehrere SQL- und Datenknoten hast und sie angemessen konfiguriert sind, dann kann jeder Server abstürzen und der Cluster läuft trotzdem weiter.

Theoretisch erlaubt Dir das, deine Anwendung nach Bedarf zu skalieren. Das ist meines Wissens derzeit eher theoretisch, aber ich bin sicher, dass das weiter besser wird.

Ich führe die Diskussion derzeit auch - Scale-Out vs. Scale-Up. Ja, Scale-Out ist billig(er), weil höherwertige Hardware teurer ist. Aber mehr Server brauchen mehr Leute, um sie zu verwalten (Systemadministratoren) und mehr Datenbankadministratoren, um mit ihnen zu arbeiten. Also fischt man im Trüben, wenn es darum geht, was besser ist.

Es ist wieder und wieder bewiesen worden, das MySQL ausskalieren kann. Nicht so viele Informationen stehen über das Aufskalieren zur Verfügung. Ich habe die Artikel, auf die Du verweist, noch nicht gelesen, aber ich werde es tun. Ich habe gehört, dass MySQL unter Linux ohne viel Effizienzverlust mit ungefähr 64 GB RAM und ungefähr 8 Cores umgehen kann. Das ist eine ganz schön heftige Maschine... eine, die einige kleinere Server ersetzen könnte.

Ein anderes Argument außer den reduzierten Administrationskosten ist, dass manche Anwendungen sich einfach nicht so leicht sharden lassen. In manchen Anwendungen steckt eine so große Komplexität, dass sie das unmöglich macht.

Ich hoffe, einiges davon durchtesten zu können. Ich werde auf jeden Fall darüber bloggen, wenn es so ist.

Kommentar von Matthew Montgomery vom 23. August 2007 4:24

Ich muss dich in einem Punkt korrigieren... Festplatten-basierte Spalten für
NDB-(MySQL-Cluster)-Tabellen sind in Version 5.1 verfügbar.

Siehe: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-disk-data.html

Die NDB-Engine gibt dir die Möglichkeit, auszuskalieren, während Du ein einzelnes logisches Image deiner Daten konservierst, ohne Sharding in deine Anwendung hinein programmieren zu müssen. Außerdem bietet es Hochverfügbarkeit mit synchroner Replikation, Aktivierung eines Ersatzsystems in unter einer Sekunde und automatische Wiederherstellung.