Samstag, 17. November 2007

Architekturen, über die Du dich schon immer gewundert hast: Was man auf der QCon lernen konnte

Original: http://natishalom.typepad.com/nati_shaloms_blog/2007/11/lessons-from--1.html 15. November 2007
Autor: Nati Shalom
Übersetzung: Sebastian Wallroth

Ich bin gerade von QCon in San Francisco zurückgekehrt. Mir hat die Konferenz wirklich gefallen. Die Präsentationen und Panels waren von hoher Qualität. Mir hat auch die Tatsache gefallen, dass es persönlich genug war, um interessante Personen aus der Wirtschaft zu treffen. Mit gefiel insbesondere die Diskussion mit Brian Zimmer von Orbitz, wo man Jini als Teil des Backbones verwendet, wie auch mit Randy Shoup (eBay), der am Freitag eine exzellente Präsentation über die eBay-Architektur gab. Ein "Gut gemacht!" geht an Floyd und Trifork (Aino, Roxanne und der Rest des Teams) für die Organisation dieses Ereignisses.

Im Track "Architekturen, über die Du dich schon immer gewundert hast" präsentierten Second Life, eBay, Yahoo, LinkedIn und Orbitz, wie sie mit den verschiedenen Aspekten ihrer Anwendungen umgehen, wie zum Beispiel der Skalierungsfähigkeit. Es sind einige Lektionen, die ich gelernt habe und die ich gerne teilen möchte.

Diclaimer: Die nachfolgenden Informationen basieren auf Notizen, die ich während der Sitzungen machte. Es handelt sich nicht um detaillerte Berichterstattungen der einzelnen Präsentationen sondern vielmehr um die Zusammenfassungen meiner persönlichen Interpretationen und Schlussfolgerungen. Lesen sie gerne auch die Präsentationen des Tracks "Architekturen. über die Du dich schon immer gewundert hast" im Original.

Der Stack

Dieses Thema scheint ganz schön emotional zu sein, hauptsächlich zwischen dem LAMP- und dem Java-Lager, wie ich erfahren musste, nachdem ich "Warum die meisten hochskalierten Webseiten nicht in Java geschrieben sind" veröffentlicht hatte. Obgleich der LAMP-Stack in im Bereich hochskalierter Webanwendungen sehr populär ist sind die Umgebungen sehr heterogen, insbesondere bei den großen Seiten: Yahoo und eBay natürlich und teilweise gilt das auch für Google und Amazon. Tatsächlich verwendet eine Anwendung von Google GigaSpaces. Eine offensichtliche Erklärung für diese Heterogenität ist der Fakt, dass viele der großen Seiten verschiedene Firmen übernommen und integriert haben, wovon jede ihre eigenen Implementierungsstack mitbrachte.

Es gibt nur einige wenige (LinkedIn, eBay, Orbitz, Yahoo Bix) die Java als ihre Kernsprache verwenden. (Beachte, dass die meisten Anwendungen von Yahoo LAMP als ihre Kern-Stack verwenden. Yahoo Bix ist eine Ausnahme.) Der Linux-Apache-Tomcat-Spring-Hibernate-Stack ist üblich bei den Java verwendenden Seiten. Wenn ich mich recht erninnere verwendet nur eBay den kompletten J2EE-Stack, aber eBay scheint nur einen kleinen Teil von dessen Funktionalität zu verwenden. Second Life hat eine ziemlich ungewöhnliche Architektur: man benutzt dort zumeist C++ und Python und sagte, dass man der Skalierungsfähigkeit wegen zu Web Services und SOA migrieren will. Bei Orbitz verwendet man Jini als Dienste-Framework und hat interessante Dinge mit Spring angestellt, um Jini für seine Entwickler zu vereinfachen. Man hat dort zudem mit Spring Remote-Funktionalität entwickelt, um die Dienste-Interaktion zu vereinfachen.

Integrationstrategie

Integration ist eine große Aufgabe für all diese Seiten, wenn aufgekaufte Firmen integriert werden. Im Falle von eBay und Yahoo hatten die Firmen, die sie gekauft hatten ganz andere Architekturen und in vielen Fällen auch andere Implementierungs-Stacks. Ihre Methode ist, sich nicht in die Implementierungsdetails einzumischen (wenigstens nicht zu Anfang), sondern sich auf eine schnelle Integation zu konzentrieren -- mit dem Endkunden im Blick. Sowohl Yahoo als auch eBay bauten ein allgemeines Framework, um diesen Integrationsanforderungen Genüge zu tun. Großen Aufwand kostete die Ermöglichen eines allgemeinen Benutzeridentifizierungssystems (Single Sign-On) wie auch ein Lastverteilungsschema. Bei eBay wählte man Apache als allgemeines Modul und erweiterte es ein bisschen mit eigenen Modulen. Yahoo baute einen Identifizierungsverwaltungsdienst, der auf Erweiterungsfähigkeit ausgelegt ist. Erweiterbarkeit meint hier die Möglichkeit der Anwendungen ihre eigenen Daten dem Benutzerprofil hinzuzufügen, dass dann für Personalisierung und andere Zwecke verwendet werden kann.

Anwendungsarchitektur

Niemanden wird überraschen, dass diese Anwendungen in einer schichtbasierten Architektur aufgebaut sind. Wenn man dort über Partitionierung spricht, meint man im Allgemeinen die Datenschicht.

Die Datenbankschicht

MySQL ist definitiv die beliebteste Datenbank. Es ist interessant (und überraschend) zu entdecken, wieviele Ressourcen Organisationen wie eBay und Google in die Erweiterung von MySQL gesteckt haben und es erfreut zu sehen, dass sie diese Erweiterungen der MySQl-Gemeinschaft übereignet haben. Nach Dan Pritchett (eBay) kann man eBay Erweiterungen mit MySQL dast dasselbe anstellen wie mit der Datenbank von Oracle. In "Die Zukunft ist wolkig" erfährt etwas man über den Kontext der MySQL-Erweiterungen von Google. Die Oracle-Datenbank wird weiterhin von einigen Seiten genutzt, aber überlicherweise gleichzeitig auch MySQL.

Die meisten Seitenbetreiber sagten, dass sie ihre Daten im Speicher hielten, um den Ein-/Auslese-Overhead der Datenbank zu minimieren. Das tun sie jedoch nur für Szenarios mit überwiegend Leseoperationen. Einer der Vortragenden (ich glaube es war Dan Pritchett) meinte dass der Grund für den begrenzten Gebrauch des Cachings in der Natur der Datenverwendungsmuster liege. Jeder ihrer Server könne jederzeit jedes Datum ohne bestimmte Reihenfolge anfordern. Weil die Datenvolumen mit denen sie es zu tun haben so gewaltig sind, können sie sie nicht komplett im Speicher halten. Die inkonsistenten Datenverwendungsmuster ihrer Anwendungen minimieren das Potenzial der Leistungsgewinne, die im Caching liegen.

Ich denke diese Aussage sollte erneut untersucht werden, weil es auf diesem Gebiet in den letzten Jahren große Fortschritte gegeben hat, die viele der Voraussetzungen ändern, die derzeit hier in Betracht gezogen werden (aber das ist ein anderes Thema). Viele Seiten benutzen Memcached als ihre Cachingschicht. Beispielsweise gibt es in dieser Studie über die Architektur von TypePad Hinweise darauf, dass Memcached verwendet wird, um Zähler, Sets, Status und heavyweight Daten zu speichern.

Benachrichtigungsschicht

Bei der Ermöglichung von Skalierbarkeit gibt es einen Trend weg von synchronen RPC-Amsätzen hin zu asynchroner Kommunikationen (Ich gehe später darauf ein, wenn ich mich der Skalierbarkeit zuwende.) Man könnte glauben, dass JMS überall verwendet wird um diese Anforderung zu erfüllen. Es scheint aber, dass fast jeder Vortragende sagte, dass sie ihren eigenen Banchrichtigungsstack gebaut hätten. Die Gründe scheinen zu sein:
  • Die Anforderungen für effiziente inhaltsbasierte Benachrichtigungen: Der erforderliche Benachrichtigungstyp ist weder direkt Punkt-zu-Punkt noch pub/sub. Er ist mehr assoziativer Natur. Es ist eine häufige Anforderung, dass man erst die Nachricht ansehen und durch sie browsen will, bevor man sich entscheidet, ob man sie auswählen will (und die JMS-Auswahloberfläche ist genau darauf beschränkt)
  • Konsistenz: Um Teilfehler und die Notwendigkeit verteilter Transaktionen zu vermeiden speichert man seine Events in der selben Partition wie die Daten. Auf diese Art kann man sicherstellen, dass die Nachrichten in die selbe PArtition wie die Daten geleitet werden (und vermeidet verteilte Transaktionen)
  • Man konnte diese Schicht basierend auf spezifischen Anforderungen und Semantiken feinjustieren
LinkedIn bezeichnet diesen Benachrichtigungstyp als "Datenbus" - eine sehr passende Bezeichnung.

Das erinnert mich an den ursprünglichen Grund für mein Interesse an JavaSpaces als ich an einem B2B-Exchange arbeitete und ähnliche Anforderungen hatte. JavaSpaces macht genau das. Es bietet beispielsweise einen Datenbus, der sowohl Benachrichtigungen und Daten in einer einzigen konsistenten Implementierung kombiniert.

An Skalierbarkeit nicht erst nachher denken

Ein Botschaft, die während der Konferenz von fast allen Architekten immer wieder verkündet wurde, lautete, dass an Skalierbarkeit nicht erst nachher gedacht werden sollte. Während ich mit dieser Aussage übereinstimme, enthüllten alle Fallstudien auf der QCon eine interessante Tatsache: Die meisten der beschriebenen Seiten wurde ursprünglich nicht aus Skalierbarkeit ausgelegt (es gibt eine berühmte Geschichte, dass eBay als einzelne DLL-Datei gestartet sei). Trotzdem schienen alle in der Lage gewesen zu sein, durche mehrere Zyklen der Erneuerung der Architektur zu gehen, wann immer Skalierbarkeit ein großes Problem wurde. KAnn man daraus etwas lernen?

Meiner Ansicht nach werden , weil heutige Ansätze für Skalierbarkeit einen riesigen Grad an Komplexität aufweisen (nicht zu vergessen, dass viele Entwickler Skalierbarkeit nicht richtig verstehen), Skalierbarkeit und Time-to-Market als zwei sich widersprechende Ziele angesehen. Mit anderen Worten, der Versuch eins davon zu erreichen wird als ein Riskieren des anderen angesehen. Die Lehre könnte darum sein, dass man Skalierbarkeit nicht gleich vom ersten Tage an implementieren muss, sondern, dass man sich bewusst machen muss, was Skalierbarkeit bedeutet. Auch wenn man Kompromisse eingeht, um die Anforderungen der Time-to-Market zu berücksichtigen muss vorausplanen, um zur rechten Zeit umstellen zu können.

Werner Vogel (Amazon CTO) drückte ein ähnliches Gefühl aus als er sagte: "Skaliere später. Es ist soooo schwierig es richtig zu machen, dass manchmal der Aufwand es vorher zu erledigen nicht gerechtfertigt ist. Oder überlasse es jemandem, der die Kenntnisse besitzt und es bereits getan hat ... wie Amazon (denke an S3 - Virtual Disk, etc.)."

Skalierbarkeit -- Wie man es richtig macht

Und hier kommt, worauf Du gewartet hast:
  • Asynchrone ereignisgesteuerte Entwürfe: Vermeide so gut es geht synchrone Interaktion mit der Daten- oder der Geschäftslogikschicht. Stattdessen verwende einen ereignisgesteuerten Ansatz und Workflow
  • Partitionierung/Shards: Man muss das Datenmodell so modellieren, dass es mit dem Partitionerungsmodell zusammenpasst
  • Gleichzeitige Ausführung: Gleichzeitige Ausführung sollte genutzt werden, um so viel wie möglich aus den verfügbaren Ressourcen herauszuholen. Ein guter Platz für gleichzeitige Ausführung ist die Verarbeitung der Benutzeranfragen. In diesem Fall können mehrfache Instanzen der Dienste die Anfragen vom Benachrichtigungsdienst entgegennehmen und sie gleichzeitig ausführen. Ein anderer Anwendungsfall für gleichzeitige Ausführung ist die Verwendung von MapReduce für die Ausführung aggregierter Anfragen auf partitionierter Daten.
  • Replikation (vorwiegend lesender Zugriff): In Szenarios mit vorwiegend lesenden Zugriffen (LinkedIn scheint in diese Kategorie zu fallen) kann Datenbankreplikation helfen, die Lese-Last zu verteilen, indem man Lese-Anfragen zwischen den replizierten Datenbankknoten verteilt
  • Konsistenz ohne verteilte Transaktionen: Das war einer der Hauptpunkte der Konferenz, der auch während eines Panels, an denen ich teilnahm, die Funken sprühen ließ. Ein Argument war, dass man, um Skalierbakeit zu erreichen, die Konsistenz opfern müsse und die Konsistenz in Anwendungen sicherstellen müsse mittels solcher Dinge wie optimistic locking und asynchroner Fehlerbehandlung. Man nimmt außerdem an, dass man Idempotenz im Code abhandeln muss. Meiner Meinung nach erzeugt dieses Softwaremuster zur Verbesserung der Skalierbarkeit zusätzliche Komplexität und ist deshalb fehleranfällig. Während eines anderen Panels behauptete Dan Pritchett, dass es Wege gäbe, diesen Grad von Komplexität zu vermeiden und trotzdem das gleiche Ziel zu erreichen, wie er es in seinem Blogartikel beschreibt.
  • Schiebe die Datenbank in den Hintergrund - Es bestand eine starke Einstimmigkeit darüber, dass die Datenbankengstelle nur behoben werden kann, wenn die Datenbankinteraktionen im Hintergrund stattfinden
Um noch einmal Werner Vogel zu zitieren: "Um zu skalieren: Kein direkter Zugriff mehr auf die Datenbank. Stattdessen ist der Datenzugriff in Diensten eingekapselt (Code und Daten zusammen), mit einer stabilen, öffentlichen Schnittstelle."

Andere Tips
  • Yahoo Bix - entwickelte einen Netzwerk-Sniffer, um Datenbankaufrufe zu überwachen und die Verwendung von Hibernate zu optimieren. Das stellt eines der interessanten Tauschgeschäfte in der Datenbankabstraktionsschicht dar: indem man abstrahiert, was hinter den Kulissen passiert, erlaubt man den Entwicklern sozusagen nichtoptimierten Code zu schreiben. Der Sniffer-Ansatz hilft herauszufinden, was hinter den Kulissen passiert und verwendet diese Informationen, um den Code von Hibernate zu optimieren.
  • LinkedIn - verwendet Lucene (und nicht die Datenbank) für die Indizierung. Wenn man nach einem effizienten Weg sucht, Indizierung und Suche in den Indexen zu betreiben, ist eine Datenbank wahrscheinlich nicht das Mittel der Wahl. Lucene bietet eine viel effizientere Implementierung für diese Zwecke. Ich würde auch empfehlen, Compass zu verwenden. Und hier kommen brandheiße Neuighkeiten: Ich habe gerade von Shay Banon, dem Besitzer des Compass-Projektes erfahren, dass er an einer Lucene-Integration in einen im Speicher geclusterten Index (GigaSpaces nutzend) arbeitet. Das ist sehr spannend, weil das ermöglichen wird, einen Lucene-Index verteilt zu speichern. Es wird außerdem ermöglichen, den Inhalt einer Webseite zu indizieren und eine Google-artige Suchanfrage zu stellen!
Zusammenfassung: Tauschhandel zwischen Komplexität und Time-to-Market

Die für Skalierbarkeit überwiegend verwendeten Softwaremuster führen zu mehr Komplexität. Beispielsweise muss man mit Teil-Fehler-Szenarios umgehen und Idempotenz im Code abhandeln. Das führt zu einem hohenGrad von Komplexität und ist der Hautpgrund, warum die meisten Architekten und Entwickler mit einfacheren Ansätzen beginnen, die nicht sklaierbar sind, wohl wissend, dass sie später einen kompletten Neuentwurf ihrer Anwendung machen müssen, um den Anforderungen gerecht zu werden. Second Life hielt einen ganzen Vortrag zu diesem Thema.

Ich sehe unsere Herausforderung bei GigaSpaces darin, diesen Widerspruch soweit wie möglich zu eleminieren, indem wir Skalierbarkeit zu einfach wie möglich machen, so dass Skalierbarkeitssoftwaremuster von Anfang an einfach implementiert werden können und so dem Geschäft ermöglicht wird auf die erforderliche inkrementelle Art zu wachsen. Das war tatsächlich der Hauptpunkt meiner Präsentation auf der QCon mit dem Titel "Drei Schritte um eine schichtenbasierte Ursprungsanwendung in dynamisch skalierbare Dienste umzuwandeln." Ich werde mehr Details zu diesem Ansatz in zukünftigen Artikeln beschreiben.

Samstag, 10. November 2007

Vertikales UND horizontales Skalieren - ein Kompromiss

Autor: Jeremy Cole
Übersetzung: Sebastian Wallroth

Du wirst bemerkt haben, dass es derzeit eine (überwiegend kultivierte) Debatte über RAID und Skalierung gibt:
Ich möchte einige der - meiner Meinung nach - falschen Vorstellungen über "horizontales Skalieren" aufgreifen, die ich immer wieder gefunden habe und biete meine Erfahrungen und Meinungen an.

Es geht um Kompromisse.

Arbeitszeit ist teuer. Wenn man Operations, IT usw. mit Aufgaben betraut (wie die Wiederherstellung einer Maschine), wenn man ein Problem löst, dass man mit einem Plattentausch in 30 Sekunden erledigen könnte, dann nenne ich das ineffiziente Nutzung menschlicher Arbeitskraft. Nimm keine Abkürzung, wo es keinen Sinn ergibt. Das bezieht sich auf Brians Kommentare über die realen Kosten des defekten 200$-Teils.

Horizontales Skalieren bedeutet nicht, dass man Billighardware benutzt. Ich glaube die Leute treiben das horizontale Skalierungsmodell (über das sie oft nur in veralteten Konferenzpräsentationen lesen) zur sehr auf die Spitze. Sie glauben, horizontales Skalieren bedeute die Verwendung schlechter Hardware aus dem Desktopbereich und kaufen Tonnen davon. Das funktioniert nicht und es ist die Hölle, das auf lange Sicht zu verwalten.

Kompromiss. Einer der Hauptpunkte des horizontales Skalierungsmodells: dimensioniere die physikalische Hardware sinnvoll um den besten Kompromiss zwischen horizontalem und vertikalem Skalieren zu finden. Das ist der Hauptgrund, warum ich nicht glaube, dass RAID nicht von uns geht... Es ist oft einfach der beste und kostengünstigste Weg die Leistung und Verlässlichkeit zu erreichen, die man auf jeder physikalischen Maschine braucht, damit das Skalierungsmodell funktioniert.

Verwende normale Hardware. Oft hört man den Begriff "normale Hardware" im Zusammenhang mit horizontaler Skalierung. Während mistige Hardware durchaus auch normal ist, ist eigentlich gemeint, dass wenn man mit einer low-end $40k-Maschine feststeckt und mit dem Gedanken auf ein Upgrade auf eine $250k- und später vielleicht auf eine $1M-Maschine spielt, man Datenverteilung (data partitioning) und einige, nun ja, $5k-Maschinen verwendet. Es ist keine $1k-1-Festplatte-Mist-Maschine gemeint, wie ich bereits sagte. Was ist nun mit einer "normalen" Maschinen gemeint? Nun, eine Maschine mit standardisierten, üblichen Komponenten, bei der der Preis vom Markt und nicht von einer einzelnen Maschine festgelegt wird. Man verwende normale Hardware mit einem ausgewogenen Preis-Leistungsverhältnis.

Verwende Datenverteilung (Sharding). Ich habe hierüber in meinen vorhergehenden Beiträgen nicht viel geschrieben, weil es eine Art Selbstverständlichkeit ist. Mein Teilnahme am HiveDB-Projekt und meine kürzlichen Vorträge über "Skalierfähige und hochverfügbare Architekturen" auf der MySQL-Konferenz und -Expo sollten genug über meinen Standpunkt zu diesem Thema sagen. Trotzdem will ich ein paar Punkte aus meinen Vorträgen wiederholen: Datenverteilung ist das einzig Wahre, Cache alles und verwende MySQL-Replikation für Hochverfügbarkeit und Redundanz.

Trotzdem. RAID ist preiswert. Ich habe das bereits ein paar Mal gesagt, nur um sicherzustellen, dass man mich richtig versteht: RAID ist ein preiswerter und effizienter Weg um sowohl Leistung als auch Verlässlichkeit von normaler Hardware sicherzustellen. Für die meisten Systeme ist es wegen der IT- und Operationszeit viel teurer Verlässlichkeit auf nicht-RAID-Systemen zu erreichen als auf RAID-Systemen. Ja, andere Komponenten werden kaputtgehen, aber in einem ausreichend großem datenzentrierten System mit guter Serverhardware werden Festplatten zehnmal öfter kaputtgehen als irgendetwas anderes.

Das ist alles. Weitermachen.

Sonntag, 4. November 2007

Das uneindeutig unklare Duo: Horizontales Skalieren und Vertikales Skalieren

Original: http://jpipes.com/index.php?/archives/175-The-Ambiguously-Vague-Duo-Scale-Out-and-Scale-Up.html= 25. Juni 2007 17:30
Autor: Jay Pipes
Übersetzung: Sebastian Wallroth

So, eine Anzahl von Leuten verlangte ein paar mehr Informationen, als in der an CIOs gerichteten MySQL-Marketing-Kampagne von neulich angeboten wurden: "Die zwölf Tage des MySQL Scale-out". Ich wollte einen Blog-Artikel schreiben, der sich der nach Inhalten lechzenden MySQL-Community annimmt, in dem ich diskutiere, was genau der Begriff "scale-out" (horizontales Skalieren) bedeutet.

Vergleiche zwischen horizontalem im Unterschied zu vertikalem Skalieren

Was ist überhaupt Skalieren? Einfach ausgedrückt ist es die Fähigkeit einer Anwendung wachsende Anforderungen an Durchgang, Nutzung und Kapazität zu verkraften. Sowohl horizontale als auch vertikale Skalierungsstrategien dienen der Fähigkeit eines Systems dieses Wachstum zu verkraften. Ich sehe eine Tendenz, auf die auch Jeremy hinwies, die Beziehung zwischen den Strategien zu vereinfachen und die horizontale Skalierungsarchitektur auf ein Podest zu erheben, ohne die Herausforderungen, die mit seiner Implementierung einhergehen wirklich zu verstehen.

Manchmal glaube ich, dass die Leute "scale out" hören und diese Strategie mit einem Ansatz mit Computerclustern verwechseln, bei dem Hunderte von Billigcomputern und große Speicherbänke und Festplatten sich wie ein einziger Computer verhalten. Skalieren bedeutet nicht Computercluster - weder horizontales noch vertikales Skalieren.

Im Allgemeinen bezieht sich der Term "vertikales Skalieren" (Scale-up) auf die Strategie, Kapazität hinzuzufügen, indem man die Kapazität der darunter liegenden Hardware erhöht - man kauft eine größere Kiste mit mehr Prozessoren oder Speicher, um die Anwendung darauf laufen zu lassen. Horizontale Skalierungsansätze auf der anderen Seite kann man sich im Allgemeinen als das Hinzufügen von Kapazität durch das Hinzufügen zusätzlicher Server zur Anwendungsarchitektur vorstellen. Einfach ausgedrückt sind dies die drei wichtigsten Dinge, die meinem Gefühl nach vertikale von horizontale Skalierungsansätzen unterscheiden:

  1. Vertrauen auf Hardware vs. Vertrauen auf Software
  2. Enterprise-Hardware vs. normaler Hardware
  3. Plötzliche vs. schrittweiser Kapazitätssteigerung
  4. Zentralisierte vs. verteilte Anwendungsarchitektur

Vertrauen auf Hardware vs. Vertrauen auf Software

Für Shops mit einem vertikalen Skalierungsansatz ist die Lösung, wenn der Durchsatz der datenbankzentrierten Anwendungen auf der vorhandenen Hardware die Obergrenze erreicht, die Kapazität der Datenbankserver so zu erhöhen, so dass sie mehr Such- und Transaktionsanfragen verkraften können, ohne den Anwendungscode verändern zu müssen. Der fettgedruckte Punkt ist wichtig: indem man die Kapazität der Hardware erhöht, auf der der Datenbankserver läuft, muss man den Anwendungscode überhaupt nicht ändern; das ist natürlich ein Vorteil für die Entwicklungsabteilung, es bedeutet weniger Arbeit für sie!

Tja, aber es gibt eine paar Probleme mit diesem Ansatz, auf die man achten muss, die ich in den Abschnitten über das schrittweise Hinzufügen von Kapazität und gewachsener Anwendungskomplexität hervorhebe.

Enterprise-Hardware vs. normaler Hardware

Wie ich im vorigen Abschnitt beschrieb, bedeutet vertikales Skalieren typischer Weise das Erhöhen der Kapazität durch die Erhöhung der Kapazität der zugrundeliegenden Hardware. Es gibt einen weiteren Punkt: Die Hardware selbst unterscheidet sich bei vertikalen und horizontalen Skalierungsmodellen. Vertikale Modelle tendieren zu "Enterprise-Hardware", während horizontale Modelle zu "normaler Hardware" tendieren. Ich möchte zwei Zitate von Jeremy Cole und Raj Thukral von Pythian hierzu anführen, die meiner Meinung nach etwas Licht auf diesen Unterschied zwischen vertikaler und horizontaler Skalierung werfen.

Zuerst Jeremys Versuch, den Mythos zu widerlegen, dass mit normaler Hardware "superbillige" Hardware gemeint ist. (Die Hervorhebungen stammen von mir.)

Oft hört man den Begriff "normale Hardware" im Zusammenhang mit horizontaler Skalierung. Während mistige Hardware durchaus auch normal ist, ist eigentlich gemeint, dass wenn man mit einer low-end $40k-Maschine feststeckt und mit dem Gedanken auf ein Upgrade auf eine $250k- und später vielleicht auf eine $1M-Maschine spielt, man Datenverteilung (data partitioning) und einige, nun ja, $5k-Maschinen verwendet. Es ist keine $1k-1-Festplatte-Mist-Maschine gemeint, wie ich bereits sagte. Was ist nun mit einer "normalen" Maschinen gemeint? Nun, eine Maschine mit standardisierten, üblichen Komponenten, bei der der Preis vom Markt und nicht von einer einzelnen Maschine festgelegt wird. Man verwendet normale Hardware mit einem ausgewogenen Preis-Leistungsverhältnis.

Ich stimme im höchsten Maße mit Jeremys Einschätzung überein. Standardisierte, übliche Komponenten, die nicht von einer einzelnen Firma kontrolliert werden, sind unlösbar mit dem horizontalen Skalierungsmodell verbunden, wie auch "Enterprise-Hardware" mit vertikalen Skalierungsmodellen verbunden ist. Raj bot mir eine Erklärung in einer Mail, die er mir neulich sandte:

... die meisten Leute, die Oracle zu laufen haben, tendieren dann auch dazu, auf Markenkisten mit vielen Pferdestärken zu setzen. Ich schätze, wenn man sechs Dinger für eine Lizenz bezahlt, dann kann man sich auch eine gute Kiste leisten. Mit MySQL tendiert man im Allgemeinen zu lower-end Hardware der Weißwarenklasse.

Vielleicht hat Raj es auf den Punkt gebracht. Vielleicht hat der Grund, warum vertikale Skalierungsmodelle mit higher-end Maschinen verknüpft sind einfach mit dem Vergleich der Kosten der Software und den Kosten der Hardware zu tun? Schlussendlich liegt es wohl in der Natur des Menschen zu denken, dass je teurer etwas ist, desto mehr es auch von teureren Sachen umgeben sein muss... :-)

Ich denke, dass es einen weiteren Grund gibt: Oracle kann bessere Hardware effizienter nutzen als MySQL. Mehr darüber später...

Kapazität schrittweise hinzufügen?

In einem vertikalen Skalierungsmodell ist es sehr unwahrscheinlich, dass der Anwendung Kapazität schrittweise hinzugefügt wird. Beispielsweise angenommen, dass man eine Anwendung hat, die auf Oracle 10g Enterprise Edition auf einer ordentlichen Sun-Kiste mit 16GB RAM und, nun ja, 4 Prozessoren läuft. Jetzt erreicht man einen Punkt, an dem die Anwendungsleistung leidet, weil Oracle die Hardware bis ins Letzte ausnutzt und mehr Speicher braucht. Man muss also die Leistung verbessern und anstatt irgendwelche Änderungen am Anwendungscode vorzunehmen beschließt man, die Kapazität der Hardware zu erhöhen, indem man einen neuen Sun-Server mit 8 Prozessoren und 32GB RAM anschafft.

OK, jetzt hat man das Leistungsproblem gelöst, weil Oracle jetzt mehr Speicher und mehr Prozessoren zu Verfügung stehen, um die Anfragen zu bearbeiten. Es ist nur eben unwahrscheinlich, dass der neue Server richtig ausgelastet wird und man einen guten Gegenwert für das Geld kriegt, dass man für die neue Hardwarekapazität ausgegeben hat. Angenommen man braucht zwei Jahre, um die Kapazität des ursprünglichen 4 Prozessor/16GB RAM Sun-Servers auszulasten. Man wird etwa ein Jahr oder mehr brauchen, die neue Hardware voll auszulasten. Es ist ja schön und gut, dass man sich für eine Weile keine Sorgen mehr über die Leistung meines Datenbankservers machen muss. Aber es ist im Grunde eine Vergeudung von Hardwareleistungskraft in der Zeit, in der der Durchsatz sich innerhalb des nächsten Jahres erhöht. Die Grafik unten illustriert den Punkt: Hardwarekapazität und Rechenleistung werden vergeudet, während man darauf "wartet", dass die neue Hardware voll ausgelastet wird - wenn das jemals eintritt... Die lila Fläche zeigt die vergeudete Rechnerleistung der Hardware über die Zeit.

Vergeudung von Prozessorleistung beim vertikalen Skalieren
In einem horizontalen Skalierungsmodell wird Hardwarekapazität nicht auf so dramatische Art hinzugefügt. Server mit jeweils weniger Kapazität als die oben beschriebenen vertikalen Skalierungsserver werden der Anwendung mit der Zeit schrittweise, auf gestaffelte und konsistentere Art hinzugefügt. Wenn man eine horizontale Skalierungsstrategie anwendet, um dieselbe Steigerung der Anwendungslast zu bewältigen, wird man Kapazität 13k-Schritten hinzufügen. Wie man sehen kann, ist die lila Fläche, die die vergeudete Rechnerleistung darstellt, deutlich kleiner.

Horizontales Skalieren führt zu geringerer Vergeudung von Prozessorleistung

Der Gewinn der verminderten Vergeudung ist ziemlich offensichtlich. An Stelle einer einmaligen großen Ausgabe für die kräftigere Sun-Kiste verteilen sich die Kosten über die Zeit. Investoren und Vorstände sind froh, wenn Kosten kontrolliert und schrittweise ansteigend sind und das Ausgleichsrisiko der Sofortkosten minimiert ist, falls die Anwendungsbelastung langsamer steigt als erwartet, was zusätzliche Rechenleistung unnötig werden lassen kann.

Angestiegene Komplexität der Anwendung?

Schrittweise ansteigende Kosten und Kapazität führen jedoch zu anderen Aufwänden - insbesondere eine angestiegene Komplexität der Anwendungsarchitektur um die Aufteilung der Anwendungsanfragen der verschiedenen Server unserer Architekturtopologie zu verarbeiten. Es ist aufwändiger mit dieser horizontalen Skalierungsarchitektur umzugehen, sowohl konzeptionell als auch bei der Implementierung. Kenntnis der horizontale Anwendungsskalierungsarchitektur ist notwendig und die Profis, die diese Kenntnisse haben, sind nicht billig.

Die horizontale Skalierungsfähigkeit von MySQL kann nicht mit der von Oracle verglichen werden

Hier ist eine Henne-Ei-Frage für dich. Was war zuerst da: die horizontale Skalierungsarchitektur die MySQL bietet oder das Design von MySQL für horizontales Skalieren? Lustige Frage? Nicht wirklich. So sehr ich MySQL auch liebe, glaube ich doch nicht, dass MySQLs Fähigkeit, eine horizontalen Skalierungsarchitektur zu unterstützen dem Konzept von MySQL bevorzugter horizontaler Skalierungsarchitektur vorausging.

Tatsächlich glaube ich, dass das, was wir heute das "horizontale Skalierungsmodell" nennen - das Modell, für das mit der "Der zwölf Tage der Scale Out"-Kampagne geworben wurde - der Unfähigkeit MySQLs entspringt im gleichen Maße vertikal zu skalieren, wie Oracle das kann.

Schockiert über meine Blasphemie? :-) Musst Du nicht sein. Das ist nur eine Beobachtung, die ich für richtig halte: das horizontale Skalierungsmodell - ein Modell, von dem ich ehrlich glaube, dass es das Skalierungsmodell der Zukunft ist - ist das einzige Modell, mit dem MySQL Erfolg haben kann. MySQLs Architektur und inneren Eigenschaften fehlen in einigen Schlüsselgebieten bestimmte Features, die Oracle vorweisen kann, die ein vertikales Skalierungsmodell für MySQL zu einer überflüssigen Übung machen:

  • Ineffiziente Nutzung mehrerer Prozessoren
  • weniger in der Lage, eine schlecht formulierte Anfrage davon abzuhalten, allen anderen den Tag zu verderben

Wegen dieser Defizite ist der Gewinn durch den Einsatz besserer Hardware bei MySQL geringer als bei Oracle. In einer horizontalen Skalierungsarchitektur werden diese Defizite jedoch gemildert. Das Problem ineffizienter Nutzung mehrerer Prozessoren verschwindet in einem horizontalen Skalierungsmodell fast völlig, weil die Server normaler Weise in einem Mix von einem bis vier Prozessoren auftreten und MySQL lokal auf den Servern läuft. Bei ein bis vier Prozessoren ist die Ineffizienz von MySQL beim Verwalten von zusätzlichen Prozessoren nicht so offensichtlich. Das Problem mit der schlecht formulierten Anfrage, die allen anderen den Tag verderben will ist minimiert, weil die verschiedenen Datenbankserver in der horizontal skalierten Architektur immer nur einen Teil der Anwendungsanfragen bearbeiten. Im Wesentlichen isoliert die horizontale Skalierungsarchitektur schlechte Anfragen bei einer kleinen Anzahl der Benutzer; etwas, was bei einem vertikal skalierten, einzelnen MySQL-Datenbankserver nicht möglich wäre.

Zentralisierte vs. verteilte Anwendungsarchitektur

Der vierte Hauptunterschied zwischen vertikaler und horizontaler Skalierungsarchitektur hat mit der Gesamttopologie der Anwendungen der jeweiligen Strategien zu tun. In vertikalen Skalierungsmodellen tendieren die Anwendungen mehr zu Zentralismus als in horizontalen Skalierungsmodellen. Mit "Zentralismus" meine ich nicht, dass der Anwendungscode selbst auf einem einzelnen Server läuft. Ich meine, dass die Daten allgemein auf einem einzelnen Datenbankserver liegen und dass ein oder mehrere Anwendungsserver sich nach Bedarf zu diesem einzelnen Datenbankserver verbinden.

Mit "verteilt" meine ich, dass die Daten selbst dazu tendieren, auf mehrere "Shards" verteilt zu sein, mit einer oder mehreren Anwendungen, die ihre Anfragen zu einem oder mehreren der Datenbankteile richten. Die Verteilung der Daten über die Datenbankserver kann mit einer selbstgestrickten Lösung oder mit den Verteilungsfeatures von MySQL 5+ erledigt werden.

In beiden Fällen wird das Verteilungsmodell so gewählt, dass die Daten über die Anwendung konsistent und gleichmäßig verteilt werden. Manchmal werden Benutzeraccount-IDs verwendet um die Daten zwischen den verschiedenen Servern aufzuteilen. In anderen Fällen werden Hashing-Funktionen oder Datenbereiche verwendet. Dessen ungeachtet ist es so, dass die horizontale Skalierungsarchitektur die Aufteilung der Daten in einer nicht-zentralisierten, verteilten Topologie fördert.

Viel der zusätzlichen Anwendungskomplexität, über die ich weiter oben schrieb, rührt von dieser Verteilung auf Datenebene her. Zusätzlicher Code ist notwendig, der als Verkehrspolizist die Anfragen zum richtigen Datenspeicher leitet. Zudem ist es tendenziell schwieriger aggregierte Daten zu erhalten, weil Prozesse eingerichtet werden müssen, um Daten aus den einzelnen Shards zur Analyse in ein zentrales Datenwarenhaus zu holen. Ich erachte diesen Nachteil als vernachlässigbar, da auch in vertikalen Skalierungsmodellen Daten oft für Offlineanalysen aus der zentralen Datenbank in ein separates Warenhaussystem gezogen werden.

Aber zusammen mit dieser gestiegenen Komplexität kommen die Vorteile des horizontalen Skalierungsmodells: schrittweise Zunahme der Kapazität und die Möglichkeit, Last auf eine Datenbankserverfarm zu verteilen. Zudem neigt ein horizontales Skalierungsmodell nicht zu Engpässen, da es keinen einzelnen monolithischen Datenbankserver gibt, der als Datenspeicher für die gesamte Anwednung dient.

Montag, 29. Oktober 2007

Ist Sharding dasselbe wie Partitionierung und Föderation?

Original: http://www.royans.net/arch/2007/09/09/sharding-different-from-partitioning-and-federation/ 9. September 2007 12:34
Autor: Royans Tharakan
Übersetzung: Sebastian Wallroth

Dieses Wort "Sharding"... ich höre es immer öfter. Es geht um wie ein Lauffeuer. Theo Schlossnagle, der Autor von "Skalierbare Internetarchitekturen", vertritt die Ansicht, dass ein föderiertes Informationssystem ein Form von Partitionierung und dass Sharding wiederum nichts anderes als eine Form von Partitionierung und Föderation ist. Schlossnagle meint, dass Sharding bereits seit sehr langer Zeit angewandt wird.

Ich bin weder beruflich noch privat Datenbankadministrator. Um also die Unterschiede zu verstehen, habe ich ein bisschen geforscht und ein paar interessante Artikel gefunden.

Das erste Mal hörte ich von "Sharding" im Blog "mySQL DBA" in einem Artikel über einen unorthodoxen Datenbankentwurf (Teil I und Teil II). Hier ist das exakte Zitat:
Teilt man die Benutzerdaten so auf, dass Benutzer A auf dem einen Server
existiert, während Benutzer B auf einem anderen Server existiert, so hält jeder
Server in diesem föderierten Modell einen Splitter (shard) der Daten vor.
Vor ein paar Monaten griff Highscalability.com das Thema Sharding auf und ließ es so aussehen (möglicherweise unabsichtlich) als ob Sharding eigentlich etwas anderes ist als Föderation und Partionierung. Todds Artikel weist darauf hin, dass Flickr Sharding verwendet. Die Suche nach Flickrs Architektur führte mich zu Colin Charles Artikel über das föderierte Informationssystem bei Flickr: Eine Führung durch die Architektur von Flickr, in der er Shards als eine Komponente des föderierten Schlüssels erwähnt. Auch er jedoch nennt Sharding nichts Neues. Zitat:
Schlüsselkomponenten eines föderierten Informationssystems:
  • Shards: Meine Daten werden in meinem Shard gespeichert, aber die Aufzeichnung über eine ausgeführte Tätigkeit steht in deinem Shard. Beispiel: Man macht einen Kommentar in jemandes anderen Blog.
  • Global Ring: Das ist wie DNS, Du musst wissen, wo Du hin musst und wer kontrolliert, wohin Du gehst. Bei jedem Seitenaufruf wird im selben Moment berechnet, wo deine Daten sind.
  • PHP-Logik, um die Shards zu verbinden und die Daten konsistent zu halten (10 Zeilen Code - mit Kommentaren!)

Ausgehend von den Diskussionen in diesem und anderen Blogs scheinen "Shards" eher eine Terminologie zu sein, um Datenfragmente zu beschreiben, die über mehrere Datenbanken hinweg föderiert sind, als eine Architektur an sich. Ich denke, Theo Schlossnagles Argument ist triftig. Wenn jemand anderer Meinung ist, dann würde ich gern davon hören. Eine klarere Definition von Sharding im Unterschied zu Föderation würde ebenfalls sehr hilfreich sein.

Weitere Referenzen zum Thema Shards/Sharding

Was ist Skalierbarkeit?

Original: http://www.royans.net/arch/2007/09/22/what-is-scalability/ 22. September 2007 18:14
Autor: Royans Tharakan
Übersetzung: Sebastian Wallroth

Gefragt, was sie denn mit Skalierbarkeit meinen, sprechen die Leute über Verbesserung der Leistung, Einführung von Hochverfügbarkeit oder sogar über spezielle Technologien oder Protokolle. Tja, Skalierbarkeit ist nichts davon. Versteh' mich nicht falsch. Man muss schon alles über Geschwindigkeit, Leistung, Hochverfügbarkeitstechnologie, Anwendungsplattformen, Netzwerk, etc. wissen. Aber das ist nicht die Definition von Skalierbarkeit.

Einfach ausgedrückt bezeichnet Skalierbarkeit die Möglichkeit, dein bisheriges Geschäft in einem größeren Rahmen zu betreiben. Eine Webanwendung zu skalieren bedeutet, mehr Leuten zu ermöglichen, die Anwendung zu benutzen. Wenn Du nicht erklären kannst, wie Du die Leistung verbesserst, wenn Du mehr Rechner einbindest, dann ist das okay. Und so lange Du skalieren kannst, um eine größer werdende Anzahl von Benutzern zu bedienen, ist es auch okay, manche Dinge nicht zu wissen. Alle anderen lesen bitte weiter.

Derzeit werden zwei Hauptarten der Webseitenskalierung angewandt.

  • "Vertikale Skalierung" - Das Hinzufügen von Ressourcen innerhalb einer logischen Einheit, um die Kapazität zu erhöhen. Ein Beispiel könnte das Hinzufügen von CPUs zu einem existierenden Server sein oder die Erweiterung des Speicherplatzes durch das Hinzufügen von Festplatten zu einer existierenden RAID/SAN-Installation.

  • "Horizontale Skalierung" - Das Hinzufügen mehrere logischer Ressourcen-Einheiten, die dazu gebracht werden, wie eine einzige Einheit zu arbeiten. Die meisten Cluster-Lösungen, verteilten Dateisysteme und Lastverteiler dienen der horizontalen Skalierung.
Alle Komponenten, seien es Prozessoren, Server, Speicherlaufwerke oder Lastverteiler, haben in irgend einer Form einen Verwaltungsüberbau. Wenn Du den skalieren willst, musst Du herausfinden, welcher Anteil der Ressource tatsächlich verwendbar ist. Das Ergebnis wird "Skalierbarkeitsfaktor" genannt. Wenn Du jedesmal 5% Prozessorleistung verlierst, wenn Du deinem System eine weitere CPU hinzufügst, dann beträgt dein Skalierbarkeitsfaktor 0,95. Ein Skalierbarkeitsfaktor von 0,9 bedeutet, dass Du nur 90% deiner Ressourcen verwenden können wirst.

Skalierbarkeit kann basierend auf dem Skalierbarkeitsfaktor weiter unterteilt werden.

  • Wenn der Skalierbarkeitsfaktor beim Skalieren konstant bleibt, nennt man das "lineare Skalierbarkeit".
  • Es kann aber sein, das manche Komponenten nicht so gut skalieren wie andere. Ein Skalierbarkeitsfaktor unter 1,0 wird "sub-lineare Skalierbarkeit" genannt.
  • Obgleich selten, ist es möglich eine bessere Leistung (einen besseren Skalierbarkeitfaktor) zu erhalten, indem man einfach mehr Komponenten hinzufügt (I/O zwischen Festplattenspindeln in einem RAID wird besser, wenn man mehr Spindeln hinzufügt). Das nennt man "supra-lineare Skalierbarkeit".
  • Wenn die Anwendung nicht auf Skalierbarkeit ausgelegt wurde, ist es möglich, dass das System sogar schlechter wird, wenn man es skaliert. Das nennt man "negative Skalierbarkeit".
Wenn Du dringend auf Skalierbarkeit angewiesen bist, dann ist vertikale Skalierung möglicherweise der einfachere Weg (vorausgesetzt, dass dein Kontostand dir das erlaubt). In den meisten Fällen kannst Du, ohne eine Zeile Code zu ändern, deine Anwendung auf einem superteuren 64-CPU-Server von Sun oder HP mit Speicher von EMC, Hitachi oder Netapp installieren und alles wird toll sein. Zu dumm, dass vertikales Skalieren immer teurer wird, je weiter Du es treibst.

Horizontale Skalierung hingegen nötigt dich nicht, immer teurere Server zu kaufen. Sie ist auf Skalierung mit normalen Speicher- und Serverlösungen ausgelegt. Aber horizontale Skalierung ist nicht automatisch billiger. Die Anwendung muss von Grund auf so konzipiert werden, dass einzelne Anwendungen auf mehreren Rechnern laufen können. Die zwei interessantesten Probleme, die die meisten Anwendungen in der Welt der horizontalen Skalierung fürchten müssen sind "Split Brain" und "Hardwareabsturz".

Während unendliche horizontale Skalierbarkeit schwierig zu erreichen ist, ist unendliche vertikale Skalierbarkeit unmöglich. Wenn Du Kapazitäten für eine vorher festgelegte Anzahl von Benutzern aufbaust, kann es weise sein, vertikal zu skalieren. Wenn Du aber eine Webanwendung baust, die von Millionen genutzt werden könnte, dann könnte die Entscheidung für vertikale Skalierung ein teurer Fehler sein.

Aber bei Skalierbarkeit geht es nicht nur um CPU (Rechenleistung). Für eine erfolgreich skalierbare Webanwendung müssen alle Schichten in gleichem Maße skalieren. Das schließt die Speicherschicht (geclusterte Dateisysteme, S3, etc.), die Datenbankschicht (Partitionierung, Federation), die Anwendungsschicht (Memcached, Scaleout, Terracotta, Tomcat Clustering, etc.), die Webschicht, den Lastverteiler, die Firewall und alle anderen ein. Wenn Du zum Beispiel nicht mehrere Lastverteiler einsetzen kannst um deine zukünftige Zugriffslast zu bewältigen, dann ist es wirklich egal, wie viel Geld und Aufwand Du in die horizontale Skalierbarkeit deiner Webschicht gesteckt hast. Deine Zugriffslast wird darauf beschränkt sein, was dein Lastverteiler stemmen kann.

Die Wahl der richtigen Art von Skalierbarkeit hängt davon ab, wie viel Du skalieren und wie viel Du ausgeben willst. Wenn jemand behauptet, es gäbe eine Lösung, die alle Bedürfnisse befriedigt - dann glaube ihm nicht. Und wenn jemand auf der nächsten Party eine Diskussion über "Skalierbarkeit" beginnt, dann frage ihn bitte zuerst, was er denn mit Skalierbarkeit meint.

Referenzen


  1. Cost and Scalability in Vertical and Horizontal Architectures, Implications for Database and Application Layer Deployments, Technical White Paper, Tom Atwood (Sun Microsystems), September 2004 (PDF, englisch)
  2. My Linear Scalability is bigger than yours! Posted at 07:30AM Dec 20, 2006 by Cameron Purdy on /dev/null

Sonntag, 28. Oktober 2007

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.

Wikimedia Architecture

Original: http://highscalability.com/wikimedia-architectureInformationsquellen
Plattform
  • Apache
  • Linux
  • MySQL
  • PHP
  • Squid
  • LVS
  • Lucene für die Suche
  • Memcached für Distributed Object Cache
  • Lighttpd Image Server
Die Fakten
  • 8.000.000 Artikel in mehr als 100 nach Sprachen aufgeteilten Projekten (Englisch, Französisch, Schwedisch, ...)
  • Platz 10 unter den Seiten mit den meisten Zugriffe (Quelle: Alexa)
  • Exponentielles Wachstum: Verdopplung alle 4 bis 6 Monate in Bezug auf Besucher / Zugriffe /Server
  • Bis zu 30.000 HTTP-Zugriffe/Sekunde
  • 3 GBit/Sekunde Datenübertragungsvolumen
  • 3 Datenzentren: Tampa, Amsterdam, Seoul
  • 350 Server; von 1 x P4 bis 2 x Xeon Quadcore; 0,5 bis 16 GB RAM
  • gewartet von etwa 6 Personen
  • 3 Cluster auf 3 Kontinenten
Die Architektur
  • Geografische Lastverteilung, die den Internetbenutzer auf Grundlage dessen IP zum nächstgelegenen Servercluster weiterleitet. Statische Zuordnung der IP-Adressen zu Ländern und damit zu den Clustern.
  • HTTP Reverse-Proxy-Caching mit Hilfe von Squid, gruppiert nach Text für den Wikiinhalt und Medien für Bilder und große unveränderliche Dateien
  • derzeit 55 Squid-Server, plus 20, die auf ihren Einsatz warten
  • 1.000 HTTP-Anfragen/Sekunde pro Server; bis zu 2.500 zu Spitzenzeiten
  • rund 100 bis 250 MBit/Sekunde pro Server
  • rund 40.000 bis 32.000 offene Verbindungen pro Server
  • bis zu 40 GB Festplattencache pro Squid-Server
  • bis zu 4 Festplatten pro Server (1U-Rack-Server)
  • 8 GB RAM; die Hälfte davon wird von Squid belegt
  • Zugriffsraten: 85% Text, 98% Medien, seit CARP verwendet wird
  • PowerDNS bietet die geografische Verteilung
  • In den Haupt- und den regionalen Datenzentren entstehen Text- und Medien-Cluster unter Verwendung von LVS, CARP Squid und Cache Squid. IM Hauptdatenzentrum steht der Medienspeicher.
  • Im sicher zu stellen, dass die letzte Version aller Seiten ausgeliefert wird, werden Annullierungsanfragen an alle Squid-Caches geschickt.
  • Eine zentral verwaltete und synchronisierte Softwareinstallation für Hunderte Wikis.
  • MediaWiki skaliert gut mit mehreren CPUs, deswegen werden Duale Quad-Core-Server angeschafft (8 CPUs pro Box)
  • die Hardware wird sich geteilt; zusätzlich gibt es externen Speicherplatz und Memcached-Aufgaben
  • Memcached wird verwendet, um Bildmetadaten, Parserdaten, Unterschiede, Benutzer, Sessions und Textversionen zu cachen. Metadaten, wie zum Beispiel Artikelversionsgeschichten, Artikelbeziehungen (Links, Kategorien, etc.), Benutzeraccounts und Einstellungen werden in der zentralen Datenbank gespeichert.
  • Die aktuelle Textversion wird in Blobs im externem Speicher gespeichert.
  • Unveränderliche (hochgeladene) Dateien, wie zum Beispiel Bilder, werden getrennt von den anderen Daten auf einem Bilderserver gespeichert - Metadaten (Größe, Typ, etc.) wird in der zentralen Datenbank und Objektcaches gecached.
  • Jedes Wiki hat seine eigene Datenbank (keinen eigenen Server!).
  • Ein Master, viele kopierte Slaves.
  • Die Lesezugriffslast wird zwischen den Slaves verteilt, Schreibzugriffe gehen direkt an den Master.
  • Der Master wird nur für Lesezugriffe verwendet, wenn die Slaves nicht auf dem aktuellsten Stand (lagged) sind.
  • Externer Speicher
    • Der Artikeltext wird in von den anderen Daten getrennten Speicherclustern gespeichert, einfach angehängter Blob-Speicher. Das spart Speicher auf den teuren und unter Last stehenden Zentraldatenbanken für sowieso weithin ungenutzte Daten.
    • Erlaubt die Verwendung magerer Ressourcen auf den Applikationsservern (2 x 250 - 500 GB pro Server)
    • Derzeit werden kopierte Cluster dreier MySQL-Hosts verwendet; das kann sic inder Zukunft zu Gunsten besserer Verwaltbarkeit ändern
Gelernte Lektionen
  • Konzentriere dich auf die Architektur; nicht so sehr auf Verwaltung und nichttechnisches Angelegenheiten.
  • Manchmal ist Caching aufwändiger als Neuberechnung oder ein Blick auf die Datenquelle ... Profiling (Analyse des Laufzeitverhaltens von Software)!
  • Vermeide aufwändige Algorithmen, Datenbankabfragen, etc.
  • Cache jedes Ergebnis, das aufwändig zu berechnen ist und nur zeitweise Gültigkeit hat.
  • Konzentriere dich auf die heißen Stellen im Code (Profiling!).
  • Skaliere, indem Du trennst:
    • Lese- von Schreibzugriffen (Master/Slave)
    • Aufwändige Operationen von einfachen und häufigen Operationen (query groups)
    • Große, häufig besuchte Wikis von kleineren Wikis
  • Verbessere das Caching: temporäre und räumliche Anordnung von Verweisen (memory locality) und Verminderung der Datensatzgröße pro Server
  • Text wird komprimiert und nur die Unterschiede zwischen den Artikelversionen werden gespeichert.
  • Einfach scheinende Bibliotheksaufrufe, wie die Verwendung von stat, um die Existenz einer Datei zu überprüfen, können zu lange dauern, wenn sie geladen werden.
  • Begrenze die Zugriffszeit auf die Festplatten. Je mehr Spindeln, desto besser!
  • Skalierung durch Vermehrung mit normaler Hardware bedeutet nicht, dass man unbedingt Billighardware nehmen muss. Wikipedias Datenbankserver sind heute 16 GB Dual- oder Quad-Core-Kisten mit 6 15.000 RPM SCSI-Festplatten in einer RAID 0-Konfiguration. Es hat sich einfach ergeben, dass dies die optimale Umgebung (Sweet Spot) für Wikipedias Working Set und das Lastverteilungssystem ist. Wikipedia würde kleinere und billigere Systeme verwenden, wenn es Sinn ergeben würde, aber 16 GB ist passend für die Größe des Working Sets und das führt den Rest der Spezifikation dazu, ein System mit so viel RAM zu verlangen. Ganz ähnlich dazu sind die Webserver derzeit 8 Core-Kisten, weil sich heraus stellte, dass das so mit der Lastverteilung gut funktioniert und einen guten PHP-Durchsatz mit einer verhältnismäßig einfachen Lastverteilung ergibt.
  • Es ist viel Arbeit, durch Vermehrung zu Skalieren, und sogar noch mehr, wenn man das System nicht selbst entwirft. Wikipedias MediaWiki wurde ursprünglich für einen einzelnen Masterdatenbankserver geschrieben. Dann wurde die Unterstützung von Slaves hinzugefügt. Dann wurde die Unterteilung nach Sprache/Projekt hinzugefügt. Die Entwürfe von damals haben den Test gut bestanden, obgleich viel Verbesserungsarbeit an neu auftauchenden Engstellen nötig wurde.
  • Jeder, der seine Datenbankarchitektur so entwerfen möchte, dass sie es ihm erlaubt, ohne großen Aufwand von einer Stufe mit nur einer Kiste auf die Stufe der Top 10 oder Top 100 der Webseiten des Internet zu wachsen, sollte damit anfangen, leicht veraltete Daten von Kopien-Slaves verwalten zu lassen, sollte wissen, wie man die Last der Lesezugriffe zwischen den Slaves verteilt und wann immer möglich so entwerfen, dass Datenbrocken (Bündel von Benutzern, Accounts, was auch immer) auf verschiedenen Serven landen können. Man kann das von Anfang an mittels Virtualisierung tun und die Architektur testen, solange man noch klein ist. Es ist VIEL einfacher, als wenn man es erst prüft, wenn sich die Last alle paar Monate verdoppelt.

Dienstag, 23. Oktober 2007

PlentyOfFish Architecture

Original: http://highscalability.com/plentyoffish-architecture
Author: Todd Hoff
Übersetzung: Sebastian Wallroth

PlentyOfFish ist ein äußerst populäres Online-Datingsystem, dass von 45 Millionen Besuchern im Monat überrannt wird und mehr als 30 Millionen Zugriffe pro Tag verzeichnet (500 - 600 Seiten pro Sekunde). Aber das ist nicht der interessanteste Teil der Geschichte. All das wird von einer Person betreut, mit einer Handvoll Servern, mit nur ein paar Arbeitsstunden pro Tag, und dabei 6 Millionen US-Dollar im Jahr mit Google AdSense generierend. Eifersüchtig? Ich bin's jedenfalls. Wie werden all diese Liebesbeziehungen mit nur so wenigen Ressouren hergestellt?

Seite: http://www.plentyoffish.com/

Informationsquellen
Die PlattformDie Fakten
  • PlentyOfFish (POF) hat nur einen Angestellten: den Gründer und CEO Markus Frind
  • POF bringt bis zu 6 Millionen US-Dollar im Jahr mit Google-Werbung bei nur zwei Arbeitsstunden am Tag
  • Mehr als 30 Millionen Zugriffe am Tag (500 - 600 Seiten pro Sekunde)
  • 1,1 Milliarden Seitenaufrufe und 45 Millionen Besucher im Monat
  • POF ist unter den Top 30 Seiten der USA (nach Messungen von Competes Attention), Top 10 in Kanada und Top 30 in Großbritannien
  • 2 Webserver mit Lastverteilern, zwei Quad Core Intel Xeon X5355 @ 2,66 GHz, 8 Gigabyte RAM (etwa 800 MB in Benutzung), zwei Festplatten, Windows x64 Server 2003
  • 3 Datenbankserver. (Über deren Konfiguration liegen keine Daten vor.)
  • Annähernd 64.000 gleichzeitige Verbindungen und 2 Millionen Seitenaufrufe pro Stunde.
  • Die Internetverbindung ist eine 1 GBps-Leitung, von der 200 MBps verwendet werden
  • 1 Terabyte pro Tag kommen von 171 Millionen Bildern, die Akamai ausliefert
  • 6 Terabyte Festplattenspeicher, die Millionen Bilder in Originalgröße vorhalten, die jeden Monat auf die Seite hochgeladen werden.
Was steckt drin
  • Das Einkommensmodell ist es, Google-Werbung zu verwenden. Match.com generiert im Vergleich dazu 300 Millionen US-Dollar im Jahr, vorwiegend über kostenpflichtige Registrierungen. POFs Einkommensmodell ist gerade dabei, sich zu ändern, um mehr Einkommen über die Benutzer zu erzielen. Der Plan ist, mehr Angestellte in Bord zu holen, Sales-Leute einzustellen und Werbung direkt zu verkaufen, statt nur von AdSense abhängig zu sein.
  • Mit 30 Millionen Seitenaufrufen pro Tag kann man mit Werbung gutes Geld verdienen, auch mit nur 3 - 5 Cent pro CPM (Cost-per-million; synonym zu Tausender-Kontakt-Preis, TKP)
  • Akamai wird verwendet, um mehr als 100 Millionen Bilderabfragen pro Tag zu bedienen. Wenn Du acht Bilder hast und jedes 100 Millisekunden braucht, dann redest Du von einer zweiten Last nur durch Bilder. Also ist es sinnvoll auch die Bilder zu verteilen.
  • Mehrere 10 Millionen Bilderabfragen werden direkt von POFs Servern geliefert, aber die Mehrzahl dieser Bilder sind kleiner als 2 Kilobyte und können meistens im RAM gehalten werden.
  • Alles ist dynamisch, nichts ist statisch.
  • Alle rausgehenden Daten sind gzipped, was 30% der CPU-Last erzeugt. Das verlangt eine Menge Rechenleistung auf diesen Servern, aber es vermindert wirklich die Bandbreitenauslastung.
  • Es wird keine Caching-Funktionalität von ASP.NET verwendet, weil die Daten bereits veraltet sind, sobald sie im Cache landen.
  • Keine der vorhandenen Komponenten von ASP.NET werden verwendet. Alles ist von Grund auf selbst programmiert. Nichts ist komplexer als ein einfaches IF...THEN...AND für Schleifen. Immer schön einfach.
  • Lastverteilung
    • IIS begrenzt die Anzahl der Verbindungen willkürlich auf 64.000, so dass ein Lastverteiler hinzugefügt werden musste, um eine riesige Anzahl gleichzeitiger Verbindungen zu bearbeiten. Das Hinzufügen einer zweiten IP um dann Rechnerzuordnungen für Indexpartitionen durch Datenverteilung (round robin DNS) zu verwenden wurde in Betracht gezogen, aber der Lastverteiler erschien besser für eine mehrfache Vorhaltung der Daten und ein einfacheres Hinzuschalten neuer Webserver. Und die Verwendung von ServerIron bot erweiterte Funktionalitäten, wie Bot-Blockierung und Lastverteilung basierend auf weitergeleiteten Cookies, Sessiondaten und IP-Daten.
    • Die Netzwerklastverteilung (network load balancing, NLB) von Windows wurde nicht verwendet, weil es keine "sticky sessions" unterstützt. Um das zu umgehen, kann man den Sessionzustand in einer Datenbank oder in einem gemeinsam genutzten Dateisystem speichern.
    • 8 - 12 NLB-Server können in einer Farm zusammen gefasst werden. Die Anzahl der Farmen ist unbegrenzt. Ein Round-Robin-DNS-Schema kann zwischen den Farmen benutzt werden. So eine Architektur wurde verwendet, um 70 Front-End-Webserver zu ermöglichen, um über 300.000 gleichzeitige Benutzer zu ermöglichen.
    • NLB kennt eine Ähnlichkeitsfunktion, so dass ein Benutzer immer einem bestimmten Server zugeordnet wird, weswegen kein externen Speicherplatz verwendet wird, um den Sessionzustand zu speichern. Wenn der Server abstürzt gehen jedoch die Sessionzustandsdaten verloren und der Benutzer muss sich neu einloggen. Wenn der Sessionzustand auch einen Warenkorb enthält oder andere wichtige Daten, dann ist dieser Lösung wirklich schwach, aber für eine Dating-Seite scheint es Okay zu sein.
    • Man war der Ansicht, dass die Kosten des Speicherns und Gewinnens der Sessiondaten zu teuer ist. Hardwarelastverteilung ist einfacher. Ordne Benutzer einfach spezifischen Servern zu und wenn der Server abstürzt, fordere die Benutzer einfach auf, sich neu einzuloggen.
    • Die Kosten von ServerIron sind jedoch niedriger und es ist einfacher zu benutzen als NLB. Bedeutende Seiten verwenden es für TCP-Verbindungsbündelung (TCP connection pooling), automatische Bot-Erkennung, etc. ServerIron kann weit mehr als Lastverteilung und diese Features sind wegen der niedrigen Kosten sehr attraktiv.
  • Es ist ein großes Problem, einen Adserver auszuwählen. Adserverfirmen wollen mehrere Hunderttausend Dollar pro Jahr und sie wollen Mehrjahresverträge.
  • POF ist dabei die ASP.NET Repeater loszuwerden und statt dessen dieses Append-String-Dings oder response.write zu verwenden. Wenn Du jeden Tag Millionen Seitenaufrufe auslieferst, dann schreib einfach den Code, um es am Bildschirm auszugeben.
  • Der größte Teil der Hardwarekosten stecken in einer SAN. Redundanz im jeden Preis.
  • Das Wachstum kam durch Mundpropaganda. Die Kanadier drehten völlig durch, dann schwappte es nach Großbritannien, Australien und dann in die USA.
  • Datenbanken
    • Eine Datenbank ist die Hauptdatenbank
    • Zwei Datenbanken dienen der Suche. Die Lastverteilung zwischen den Suchservern basiert auf der Art der Suche.
    • Die Leistung wird mit dem Taskmanager überwacht. Wenn sich Spitzen zeigen, wird das untersucht. Übliche Probleme sind Blockierungen in der Datenbank. Es sind immer Datenbankprobleme. Ganz selten sind es Probleme mit .NET. Weil POF die .NET-Bibliothek nicht verwendet, ist es recht einfach, Leistungsprobleme zurückzuverfolgen. Wenn man viele Framework-Schichten verwenden würde, wäare ganz schön hart und frustrierend herauszufinden, wo sich die Probleme verstecken.
    • Wenn Du die Datenbank 20mal pro Seitenaufruf ansprichst, bist du angemeiert, egal was Du versuchst.
    • Trenne Datenbank-Lese- von -Schreib-Zugriffen. Wenn Du nicht viel RAM hast und Du Lese- und Schreib-Zugriffe brauchst, wird das Paging eingeschaltet, was deine Datenbank für Sekunden hängen lassen kann.
    • Versuche eine Nur-Lesen-Datenbank einzurichten, wenn es geht.
    • Denormalisiere die Daten. Wenn Du viel Zeug aus 20 verschiedenen Tabellen holen musst, versuche eine einzige Tabelle zu erstellen, die nur zum Lesen da ist.
    • Einen Tag geht es, aber wenn deine Datenbank ihre Größe verdoppelt, wird sie nicht mehr funktionieren.
    • Mach nur eine Sache im System und es wird alles ganz prächtig laufen. Schreibe in die Datenbank - das geht gut. Lese aus der Datenbank - das geht gut. Mische die Aufgaben und es wird alles durcheinander bringen. Du wirst Locking- und Blocking-Probleme kriegen.
    • Wenn Du an die Grenzen der CPU-Leistung stößt, dann hast Du entweder etwas falsch gemacht oder es ist in höchsten Maße optimiert. Wenn Du die Datenbank in den RAM kriegst, tu es.
  • Der Entwicklungsprozess sieht so aus: Hab eine Idee. Lass sie 24 Stunden online. Das funktioniert in der Hälfte der Fälle. Beobachte die Benutzerakzeptanz, indem Du analysierst, was sie tatsächlich auf deiner Seite machen. Erhöht sich die Anzahl der Nachrichten pro Benutzer? Bleiben sie länger auf deiner Seite? Wenn die Leute es nicht mögen, schalte es ab.
  • Systemabstürze sind selten und von kurzer Dauer. Die größten Probleme sind DNS-Probleme, wenn einige ISP (internet service provider) melden, dass die POF-Seite nicht mehr existiere. Weil die Seite jedoch kostenlos ist, akzeptieren die Leute eine kleine Auszeit. Die Leute bemerken Auszeiten meist gar nicht, weil sie denken, es sei ihr Problem.
  • Das Wachstum von 1 Million auf 12 Millionen Benutzer war ein großer Sprung. POF könnte mit 2 Webservern bis zu 60 Millionen Benutzern skalieren.
  • POF schaut oft bei Mitbewerbern nach neuen Ideen und Features.
  • POF wird Amazons S3 in Betracht ziehen, wenn es geografische Lastverteilung unterstützt.
Gelernte Lektionen
  • Du brauchst keine Millionen Gründerkapital, keine auswuchernde Infrastruktur und kein Haus voller Angestellter um eine Weltklassewebseite zu erschaffen, die einen Strom von Besuchern bewältigt während Du gutes Geld verdienst. Alles was Du brauchst ist eine Idee, die eine Menge Leute anlockt, eine Seiten, die per Mundpropaganda weiterempfohlen wird und die Erfahrung und die Vision, eine Seite aufzubauen, ohne in die typischen Fallen des Handels zu treten. Das war's schon ;-)
  • Bedarf ist die Mutter aller Änderungen
  • Wenn Du schnell wächst, aber nicht zu schnell, dann hast Du die Chance zu wachsen, dich zu ändern und dich anzupassen.
  • RAM löst alle Probleme. Danach wächst man einfach mit größeren Maschinen.
  • Wenn Du startest, dann halte alles so einfach wie möglich. Nahezu alle geben diesen Ratschlag und Markus Frind sagt ganz klar, dass alles was er tut, ganz einfach simpler gesunder Menschenverstand ist. Aber zu finden, was das Einfachste ist, schafft man nicht nur mit gesundem Menschenverstand. Einfache Dinge zu schaffen ist das Ergebnis von Jahren praktischer Erfahrung.
  • Ermögliche einen schnellen Datenbankzugriff und Du wirst keine Probleme haben.
  • Ein wichtiger Grund, warum POF mit so wenig Leuten und so wenig Ausrüstung auskommt ist, dass POF ein Medienverteilernetzwerk (content delivery network, CDN) für die Auslieferung großer, viel genutzter Medien benutzt. Die Verwendung eines CDN könnte die geheime Zutat einer Menge großer Webseiten sein. Markus Frings glaubt, dass es keine einzige Seite unter den Top 100 gibt, die kein CDN benutzen. Ohne ein CDN, glaubt Markus Frings, würde die Ladezeit in Australien wegen all der Bilder bis auf 3 bis 4 Sekunden ansteigen.
  • Werbung auf Facebook bringt fast nichts. Aus 2.000 Klicks wurde nur eine Anmeldung. Mit einem CTR von 0,04% bringt Facebook 0,4 Klicks pro 1.000 Anzeigen oder 0,4 Klicks/CPM. Bei 0,05 USD/CPM = 0,125 USD/Klick; 0,50 USD/CPM = 1,25 USD/Klick; 1 USD/CMP = 2,50 USD pro Klick; 15 USD/CPM = 37,50 USD/Klick
  • Es ist einfach ein paar Millionen Seitenaufrufe mit hohen CPMs zu verkaufen. Es ist VIEL schwerer, Milliarden von Seitenaufrufen mit hohen CPMs zu verkaufen, wie man bei Myspace und Facebook sehen konnte.
  • Das werbegestützte Modell begrenzt deine Einahmen. Du brauchst ab einer bestimmten Größe ein Bezahlmodell. 100 Millionen im Jahr mit einer kostenlosen Seite zu generieren ist praktisch unmöglich, weil Du einen zu großen Markt bräuchtest.
  • Die Anzahl der Seitenaufrufe via Facebook zu erhöhen funktioniert nicht für eine Dating-Seite. Besucher auf Deiner Webseite zu haben, ist viel profitabler. Die meisten Seitenaufrufe auf Facebook kommen von außerhalb der USA und Du musst 0,05 USD/CPM mit Facebook teilen.
  • Co-Req ist eine potenziell große Einkommensquelle. Du bietest dem Benutzer interessante Informationen über andere Produkte an, wenn er sich bei Dir anmeldet.
  • Du kannst nicht immer auf die Benutzer hören. Manche Benutzer wollen immer neue Features haben und andere werden neue Features hassen. Nur ein Teil wird sich beschweren. Analysiere stattdessen, welche Features die Leute auf deiner Seite tatsächlich benutzen.

Montag, 22. Oktober 2007

Digg Architecture

Original: http://highscalability.com/digg-architecture Dienstag, 7. August 2007 01.28
Author: Todd Hoff
Übersetzung: Sebastian Wallroth

Der Traffic, der von Diggs über 1,2 Millionen für ihren Informationshunger berühmten Benutzern generiert wird, kann eine nicht vorbereitete Webseite wegen ihrer CPU-, Speicher und Bandbreitenbeschränkungen kopfüber zum Absturz bringen. Wie kommt Digg mit dieser Last zurecht?

Seite: http://digg.com

Informationsquellen
Plattform
  • MySQL
  • Linux
  • PHP
  • Lucene
  • APC PHP Accelerator
  • MCache
Die Fakten
  • Gestartet Ende 2004 mit einem einzelnen Linux-Server mit Apache 1.3, PHP 4 und MySQL 4.0 mit der Standard-MyISAM Speicherengine
  • Über 1,2 Millionen Benutzer
  • Über 200 Millionen Seitenaufrufe pro Monat
  • 100 Server in mehreren Datenzentren
    • 20 Datenbankserver
    • 30 Webserver
    • einige Suchserver mit Lucene
    • der Rest dient der Mehrfachverfügbarkeit (Redundanz)
  • 30 GB Daten
  • Keine der Skalierungsherausforderungen hatte etwas mit PHP zu tun. Die größten Aufgaben, denen Digg gegenüberstand, hatten alle etwas mit der Datenbank zu tun.
  • Die leichtgewichtige Natur von PHP erlaubte es Digg Berechnungsaufgaben aus der Datenbank nach PHP zu verlagern, um die Skalierung zu verbessern. eBay macht das in radikaler Weise. Sie haben nahezu alle Arbeit aus der Datenbank in die Anwendung verschoben, einschließlich von Joins, einer Operation, die normaler Weise als Job der Datenbank angesehen wird.
Was steckt drin
  • Vorn ein Lastverteiler (load balancer), der die Anfragen an die PHP-Server schickt
  • Eine MySQL-Master-Slave-Installation
    • transaktionslastige Server benutzen die InnoDB-Speicherengine
    • OLAPlastige Server benutzen die MyISAM-Speicherengine
  • Memcached wird für das Caching verwendet
  • Sharding wird verwendet, um die Datenbank in mehrere kleiner zu zerlegen
  • Diggs Anwendungsmuster macht es ihm leicht, zu skalieren. Die meisten Leute sehen sich nur die ersten Seiten an und verlassen Digg dann wieder. Deshalb sind 98% der Datenbankzugriffe bei Digg Lesezugriffe. Mit diesem Schwerpunkt der Arbeiten muss sich Digg keine Gedanken über die komplexe Arbeit des Entwurfs von Schreibzugriffen machen, was es Digg viel einfacher macht, zu skalieren.
  • Digg hatte Probleme mit seinem Speichersystem, weil es Schreibzugriffe als abgeschlossen meldete, die es aber noch nicht waren. Kontroller tun dass, um die gefühlte Leistungsfähigkeit zu erhöhen. Das führt jedoch zu einem gigantischen Leck in der Datenintegrität. Das ist ein wirklich weit verbreitetes Problem und kann schwer zu beheben sein, abhängig von den Hardwaregegebenheiten.
  • Um die Datenbanklast zu verringern, verwendet Digg den APC PHP Accelerator MCache.
  • Man kann PHP mit eine Kombination aus Apaches 2 worker threads, FastCGI und einem PHP Accelerator so konfigurieren, dass es nicht bei jeder Anfrage parst und kompiliert. Beim ersten Laden einer Seite wird der PHP-Code kompiliert, so dass jeder weitere Aufruf viel schneller ist.
Gelernte Lektionen
  • Verbessere MySQL mit der Wahl der richtigen Datenbankengine. Verwende InnoDB, wenn Du Transaktionen brauchst und MyISAM, wenn nicht. Zum Beispiel können Transaktionstabellen auf dem Master MyISAM als Nur-Lesen-Slave verwenden.
  • An einem Punkt ihrer Wachstumskurve konnte Digg nicht mehr durch das Hinzufügen von mehr RAM wachsen, deshalb musste es durch die Architektur wachsen.
  • Die Leute beschweren sich oft über die Langsamkeit von Digg. Das liegt vielleicht eher an Diggs riesigen JavaScript-Bibliotheken als an Diggs zu Grunde liegender Architektur.
  • Ein Weg, wie Digg skaliert, ist, dass es genau bedenkt, welche Anwendung es in seinem System installiert. Digg passt genau auf, damit keine Anwendungen installiert werden, die zuviel CPU-Last erzeugen. Digg verwendet ganz klar eine Standard-LAMP-Architektur, aber ich denke es gibt noch einen interessanten Punkt. Entwickler haben oft eine Riesenmenge cooler Features, die sie installieren wollen. Aber diese Features können eine Infrastruktur lahm legen, wenn die Infrastruktur nicht zusammen mit den Features wächst. Also stelle die Features zurück, bis dein System mit diesen Features umgehen kann. Das könnte man mit Kapazitätsplanung machen, etwas, das Flickr in seinem Skalierungsprozess betont.
  • Glaubst Du, Digg würde, weil es, um seine Infrastruktur nicht zu belasten, neue Funktionen begrenzt, Boden an sich schneller entwickelnde soziale Lesezeichendiesnte verlieren? Vielleicht könnte, wenn Digg seine Infrastruktur einfacher skalieren könnte, es Features schneller hinzufügen, was ihm gegenüber seiner Konkurrenz helfen würde? Andererseits macht es auch nicht viel Sinn, Features nur hinzuzufügen, weil man es kann.
  • In der Datenbankschicht liegen die größten Skalierungs- und Leistungsprobleme, die man finden kann und das unabhängig von der Programmiersprache. Du wirst auf sie treffen, egal ob Du Java, PHP, Ruby oder deine Lieblingssprache verwendest.

Sonntag, 21. Oktober 2007

eBay Architecture

Quelle: http://highscalability.com/ebay-architecture Dienstag 10. Juli 2007
Author: Todd Hoff
Übersetzung: Sebastian Wallroth

Wer hat sich nicht schon mal gewundert, wie eBay das so macht? Eine der größten, meistgeladenen Webseiten in der Welt zu betreiben kann nicht einfach sein. Und der Untertitel einer Präsentation verrät, dass die Erschaffung eines solchen Monsters wahre Ingenieurskunst verlangt: "Finde die Balance zwischen Seitenstabilität, Erneuerungsrate, Geschwindigkeit und Kosten".
Du kannst eBay vielleicht nicht nachmachen und dein System so skalieren, wie eBay seins skaliert, aber aus den Aufgaben und die möglichen Lösungen kann man lernen.

Seite: http://www.ebay.com

Informationsquellen
Plattform
  • Java
  • Oracle
  • Websphere, Servlets
  • Horizontales Skalieren
  • Sharding
  • Eine Mischung aus Windows und Linux
Was steckt drin?

Diese Informationen wurden aus Johannes Ernsts Blog übernommen.

Die Fakten
  • Pro Tag werden 26 Milliarden SQL-Abfragen durchgeführt und es werden 100 Millionen Artikel zum Verkauf vorgehalten
  • 212 Millionen registrierte Benutzer, 1 Milliarde Fotos
  • 1 Milliarde Seitenaufrufe pro Tag, 105 Millionen Produktdaten, 2 Petabyte Daten, durchschnittlich 100 Millionen API-Aufrufe pro Tag
  • etwa 35facher Anstieg an Seitenaufrufen, versandten E-Mails und Bandbreite von Juni 1999 bis zum dritten Quartal 2006
  • 99,94% Verfügbarkeit, gemessen als "alle Teile der Seite - verfügbar für alle" gegenüber mindestens eine Teil der Seite nicht verfügbar für einige Benutzer
  • Die Datenbank ist virtualisiert und spannt sich über 600 Produktionsinstanzen in mehr als 100 Serverclustern
  • 15.000 Anwednungsserver, alle J2EE. Ungefähr 100 Funktionsgruppen alias "Apps". Die Idee eines "Pools": "alle Maschinen, die mit Verkauf zu tun haben"...
Die Architektur
  • Alles wird unter der Diktat der Frage geplant: "Was, wenn sich die Last verzehnfacht?". Es wird nur horizontal skaliert, nicht vertikal; viele parallele Boxen.
  • Die Architektur ist strikt in zwei Schichten getrennt: Datenschicht (data tier), Anwendungsschicht (application tier), Suche, Aufgaben
  • Leverages MSXML-Framework für die Präsentationsschicht (presentation layer) (auch in Java)
  • Oracles Datenbank, WebSphere Java (immer noch 1.3.1)
  • Getrennte Datenbanken nach primärem Zugangspfad, Modulo oder Schlüssel.
  • Jede Datenbank umfasst mindestens drei Online-Datenbanken. Verteilt über acht Datenzentren.
  • Einige Datenbankkopien laufen nach 15 Minuten, andere nach 4 Stunden
  • Es werden keine gespeicherten Prozeduren (stored procedures) verwendet. Es gibt nur einige wenige Trigger.
  • CPU-intensive Arbeit wird aus der Datenbankschicht in die Anwendungsschicht verlagert: referenzielle Integrität, Joins und Sortierungen werden in der Anwendungsschicht erledigt! Begründung: Anwendungsserver sind billig, Datenbanken sind der Flaschenhals.
  • Keine clientseitigen Transaktionen, keine verteilten Transaktionen.
  • J2EE: es werden Servlets, JDBC und Verbindungspools (mit Rewrite) verwendet. Nicht viel mehr.
  • Keine Zustandsinformationen in der Anwendungsschicht. Flüchtige Zustände (transient state) werden in Cookies oder in einer Schmierzetteldatenbank verwaltet.
  • Suche (2002): Die Neuindizierung läuft neun Stunden lang auf der größten verfügbaren Sunkiste - nichts wird aufbewahrt.
  • Ein durchschnittlicher Produktdatensatz ändert seine Suchdatenfünfmal bevor er verkauft wird (zum Beispiel der Preis), drum sind Echtzeitsuchergebnisse extrem wichtig.
  • "Voyager": eine Echtzeiteingabeinfrastruktur von eBay. Verwendet verlässliche Mehrfachaussendung (reliable multicast) von der Hauptdatenbank zu den Suchknoten, einen im Speicher gehaltenen Suchindex, horizontale Zerlegung, N slices, Lastverteilung über M Instanzen und speichert Suchanfragen zwischen.
Gelernte Lektionen
  • Skaliere in die Breite, nicht in die Höhe
    • Horizontales Skalieren in jeder Schicht
    • Funktionale Zerlegung
  • Bevorzuge asynchrone Integration
    • Vermindere die Kopplung von Verfügbarkeiten
    • Verbessere die Skalierungsmöglichkeiten
  • Virtualisiere Komponenten
    • Vermindere physische Abhängigkeiten
    • Verbessere die Deployment-Flexibilität
  • Konstruiere Fehlertolerant
    • Automatische Fehlererkennung und -meldung
    • "Hinkender" Betrieb ("Limp mode") von Geschäftsfeatures
  • Verschiebe Arbeit aus der Datenbank in die Anwendung, weil die Datenbank der Flaschenhals ist. eBay treibt das auf die Spitze. Wir kennen das aus anderen Architekturen, das Zwischenspeicherung und Dateisysteme verwendet werden, aber eBay erledigt sogar eine Menge der traditionellen Datenbankaufgaben in den Anwendungen (zum Beispiel Joins).
  • Verwende was Du willst und schmeiß weg, was Du nicht brauchst. eBay fühlt sich nicht genötigt, den gesamten aufgeblasenen J2EE-Software-Stapel zu verwenden. eBay mochte Java und Servlets, also werden sie verwendet. Du musst kein gesamtes Framework kaufen. Verwende nur, was Du brauchst.
  • Scheue nicht Lösungen zu bauen, die mit deinen Ansprüchen wachsen. Jede Lösung von der Stange wird irgendwann nicht mehr passen. Den Rest musst Du allein machen.
  • Ausführungskontrolle wird wenn Du wächst ein größerer und größerer Teil der Skalierungsfähigkeit. Wie spielst Du Änderungen ein, wie konfigurierst und überwachst Du Tausende von Maschinen in einem laufenden System?
  • Architekturen wachsen mit. Du musst in der Lage sein, dein neues System zu ändern, zu verbessern und zu entwickeln, während Du deine bestehende Seite am Laufen hälst. Das ist die Hauptherausforderung jeder wachsenden Webseite.
  • Es sit ein Fehler, sich vom Start weg um Skalierungsfähigkeit Sorgen zu machen. Quäle dich nicht mit lähmenden Untersuchungen und mit Sorgen über Traffic, der vielleicht nie kommt.
  • Es ist auch ein Fehler, sich niemals um Skalierungsfähigkeit zu sorgen. Du musst eine Organisation aufbauen, die in der Lage ist, mit einer sich weiterentwickelnden Architektur umzugehen. Mach dir klar, dass Du niemals fertig sein wirst. Dein System wird sich immer weiterentwickeln und sich ändern. Baue diese Erwartungen und Möglichkeiten von Anfang an in dein Geschäft ein. Lass die Leute und die Organisation nicht unangetastet, während deine Seite den Bach runter geht. Viele Leute glauben, das System müsste vom Start weg perfekt sein. So läuft das aber nicht. Ein gutes System wird mit der Zeit weiterentwickelt, indem man auf tatsächliche Aufgaben und Zwänge reagiert. Erwarte die Veränderung und pass dich den Veränderungen an.

Freitag, 19. Oktober 2007

Google Architecture

Google Architecture
Artikel von Todd Hoff, Montag, 23. Juli 2007 - 04:26
Quelle: http://highscalability.com/google-architecture

Google ist der König der Skalierungsfähigkeit. Jeder kennt Google für seine riesige, ausgeklügelte und schnelle Suchmaschine, aber Google glänzt nicht nur bei der Suche. Googles Plattformansatz, skalierbare Anwendungen zu bauen, erlaubt Google, im Internet skalierende Anwendungen mit einer alarmierend hohen Konkurrenten-Plattwalz-Rate zu installieren. Googles Ziel ist immer eine noch leistungsfähigere, noch mehr skalierende Infrastruktur zur Unterstützung ihrer Produkte. Wie macht Google das?

Informationsquellen

Plattform
  • Linux
  • Eine große Bandbreite von Programmiersprachen: Python, Java, C++
Was steckt drin??

Die Fakten
  • Geschätzte 450.000 billige normale Server in 2006
  • 2005 indizierte Google 8 Milliarden Webseiten. Und heute ... wer weiß?
  • Zur Zeit gibt es über 200 GFS-Cluster (Google File System Cluster, Google Dateisystem-Cluster) bei Google. Ein Cluster kann 1.000 oder auch 5.000 Maschinen umfassen. Pools von zehntausenden Maschinen holen Daten von GFS-Clustern, die um die 5 Petabyte Speicher haben. Der zusammengefasste Lese-/Schreib-Durchsatz zwischen den Clustern kann bei um die 40 Gigabyte pro Sekunde liegen.
  • Zur Zeit gibt es 6.000 MapReduce-Anwendungen bei Google und hunderte neue Anwendungen werden jeden Monat geschrieben.
  • BigTable skaliert auf Milliarden von URLs, Hunderte von Terabytes von Satellitenbildern und Einstellungen für Hunderte von Millionen von Benutzern.
Der Stapel

Google visualisiert seine Infrastruktur als einen Drei-Schichten-Stapel:
  • Produkte: Suche, Werbung, E-Mail, Karten, Video, Chat, Blogs
  • Verteilte Systeminfrastruktur: GFS, MapReduce und BigTable
  • Rechnerplattformen: eine Menge Maschinen in einer Menge Rechenzentren
  • Mach es den Leuten in deiner Firma einfach, billig zu entwickeln.
  • Achte pro Anwendung auf die Preisentwicklungsdaten. Gib mehr Geld für Hardware aus, um keine Log-Daten zu verlieren, aber gib weniger für andere Arten von Daten aus. Hab ich schon erwähnt, dass Google keine Daten verliert?
Verlässlicher Speichermechanismus mit GFS (Google File System)
  • Verlässlicher skalierbarer Speicher ist eine Grundbedürfnis jeder Anwendung. GFS ist Googles Basisspeicherplattform.
  • Das Google-Dateisystem (GFS, Google File System) ist ein riesiges verteiltes loggendes strukturiertes Dateisystem, in das Google eine Mengen Daten reinschmeißt.
  • Warum sollte man so etwas bauen, statt etwas von der Stage zu nehmen? Weil sie alles kontrollieren und es ist die Plattform, die Google von allen anderen unterscheidet. Sie brauchen:
    • hohe Verlässlichkeit zwischen den Datenzentren
    • Skalierbarkeit auf Tausende von Netzwerkknoten
    • eine gewaltige Schreib-/Lese-Bandbreite
    • Unterstützung für große Datenblöcke bis zur Größe von Gigabytes
    • eine effiziente Aufgabenverteilung zwischen den Knoten, um Flaschenhälse zu vermeiden
  • Im System gibt es Master- und Chunk-Server
    • Master-Server halten Metadaten über die verschiedenen Datendateien vor. Die Daten im Dateisystem in 64 Megabyte-Stückchen ("Chunks") gespeichert. Die Clients kommunizieren mit den Master-Servern, um Metadatenoperationen an Dateien vorzunehmen und den Chunk-Server zu finden, der das Benötigte auf der Festplatte vorhält.
    • Chunk-Server speichern die tatsächlichen Daten auf der Festplatte. Jedes Daten-Stückchen ("Chunk") wird auf drei verschiedenen Chunk-Server gleichzeitig gespeichert (repliziert), um mehrfache Verfügbarkeit (Redundanz) für den Fall sicherzustellen, dass ein Server abstürzt.
  • Eine neue Anwendung, die online gestellt wird, kann einen existierenden GFS-Cluster verwenden oder die Entwickler können ihren eigenen Cluster einrichten. Es könnte interessant sein, den Versorgungsprozess zu verstehen, den Google zwischen seinen Datenzentren verwendet.
  • Der Schlüssel ist eine ausreichende Infrastruktur, um sicherzustellen, das die Leute für ihre Applikation eine Wahl haben. GFS kann so eingerichtet werden, dass es die Anforderungen der verschiedenen Anwendungen befriedigt.
Verwende MapReduce, um etwas mit den Daten zu machen
  • Nachdem Du jetzt ein gutes Speichersystem hast: wie kannst Du irgendetwas mit so vielen Daten anfangen? Nehmen wir an, Du hättest viele Terabyte Daten verteilt auf 1.000 Maschinen gespeichert. Datenbanken können nur bis diesem Level skalieren oder kostenmäßig effizient skalieren. Jetzt kommt MapReduce ins Spiel.
  • MapReduce ist ein Programmiermodell und eine assoziative Implementierung für die Verarbeitung und Generierung großer Datensätze. Der Benutzer gibt eine Abbildungsfunktion (mapping function) an, die alle Schlüssel/Wert-Paare verarbeitet, um einen Satz von Vermittlungs-Schlüssel/Wert-Paaren zu generieren und eine Reduzierungsfunktion (reduce function), die alle Vermittlungswerte mit den entsprechenden Vermittlungsschlüsseln verbindet. Viele Aufgaben aus der realen Welt lassen sich mit diesem Modell ausdrücken. Programme, die in diesem funktionalen Stil geschrieben sind, sind automatisch parallelisiert und können auf riesigen Clustern aus normalen Servern ausgeführt werden. Die Laufzeitsysteme achten auf die Details der Aufteilung (Partitionierung) der Eingabedaten, planen die Ausführung der Programme über mehrere Maschinen hinweg, sorgen sich um Maschinenausfälle und organisieren die benötigte Kommunikation zwischen den Maschinen. Das erlaubt Programmierern mit nur wenig Erfahrung mit parallelisierten und verteilten Systemen ganz leicht Ressourcen aus einem riesigen verteilten System zu verwenden.
  • Warum sollte man MapReduce verwenden?
    • Prima Weg um Aufgaben auf eine Menge Maschinen zu verteilen.
    • Sorgt sich selbst um Maschinenabstürze
    • Arbeitet zwischen verschiedenen Anwendungsarten, wie Suche und Werbung. Fast jede Anwendung beinhaltet Arbeiten vom Typ Map-Reduce. Du kannst nützliche Daten vorverarbeiten, Wörter zählen, Terabyte von Daten sortieren, etc.
    • Die Berechnungen können sich automatisch näher an die Ein- und Ausgabe-Schnittstelle bewegen.
  • Das MapReduce-System kennt drei verschiedene Serverarten.
    • Der Master-Server ordnet die Benutzeraufgaben den Map- und Reduce-Servern zu. Er überwacht außerdem den Status der Benutzeraufgaben.
    • Der Map-Server akzeptiert Benutzereingaben und führt zugehörige Zuordnungsaufgaben aus. Die Ergebnisse werden in die Vermittlungsdateien geschrieben.
    • Der Reduce-Server akzeptieren die Vermittlungsdateien, die von den Map-Servern kommen und führen Reduce-Aufgaben damit durch.
  • Du willst zum Beispiel die Anzahl der Wörter aller Webseiten zählen. Du würdest alle Seiten, die im GFS gespeichert sein ins MapReduce füttern. Dann würde alles gleichzeitig auf 1.000 Maschinen stattfinden und all die Koordination, die Aufgabenplanung, die Fehlerbehandlung und der Datentransport würden automatisch bewältigt.
    • Die Schritte sehen so aus: GFS -> Zuordnen -> Mischen -> Reduzierung -> Ergebnisse zurück ins GFS schreiben.
    • In MapReduce ordnet eine Zuordnung eine Datensicht der anderen zu, ein Schlüssel/Wert-Paar erzeugend, das in unserem Beispiel "Wörter" und die Anzahl sind.
    • Das Mischen vereinigt die Schlüssel-Arten.
    • Die Reduzierung summiert alle Schlüssel/Wert-Paare auf und erzeugt die endgültige Antwort.
  • Die Indizierungspipeline von Google kennt ungefähr 20 verschiedene Zuordnungsreduktionen. Eine Pipeline sieht die Daten mit einer Riesenmenge von Einträgen und Zuordnungsschlüsseln. Ein zweite Zuordnungsreduktion wird durchgeführt, nimmt das Ergebnis und macht dann das nächste. Und so weiter.
  • Programme können sehr klein sein. Bis hin zu nur 20 oder 50 Zeilen Code.
  • Ein Problem sind Bummler. Ein Bummler ist eine Berechnung, die langsamer läuft als andere, was alle aufhält. Bummler können vorkommen wegen langsamer Ein- und Ausgabe (zum Beispiel wegen eines defekten Kontrollers) oder wegen zeitweiligen CPU-Überlastung. Die Lösung ist, die Berechnung mehrmals gleichzeitig auszuführen und wenn eine fertig ist, die anderen einfach abzubrechen.
  • Die Daten, die zwischen Map- und Reduce-Servern übermittelt werden, sind komprimiert. Das ist so, weil die Server nicht CPUs zugeordnet sind und es also Sinn macht, in Kompression und Dekompression zu investieren statt in Bandbreite und Ein- und Ausgabe.
Speichern strukturierter Daten in BigTable
  • BigTable ist ein riesig skalierendes, fehlertolerantes, selbstverwaltendes System, das Terabyte flüchtigen Speichers und Petabyte festen Speichers beinhaltet. Es kann Millionen von Schreib- und Lesezugriffen pro Sekunde aushalten.
  • BigTable ist ein verteilter Hash-Mechanismus, der auf dem GFS (Google File System) aufbaut. Es ist keine relationale Datenbank. Es unterstützt keine Joins oder SQL-Abfragen.
  • Es bietet Suchmechanismen, um strukturierte Daten an Hand des Schlüssels zu suchen. Das GFS speichert undurchsichtige Daten und viele Anwendungsanforderungen drehen sich ja um strukturierte Daten.
  • Kommerzielle Datenbanken skalieren einfach nicht bis auf dieses Level und können nicht über 1.000 Maschinen hinweg arbeiten.
  • Indem Google sein eigenes Speichersystem bis in die Grundfesten kontrolliert, erhält es mehr Kontrolle und sitzt am Hebel, wenn es darum geht, das System zu verbessern. Wenn Google zum Beispiel neue Funktionen haben will, die die Aufgaben zwischen den Datenzentren einfacher macht, kann es sie einfach einbauen.
  • Maschinen können hinzugefügt und herausgenommen werden, während das System läuft und das ganze System einfach weiterarbeitet.
  • Jeder Datensatz wird in einer Zelle gespeichert, auf die mit einem Spalten- und einem Zeilen-Schlüssel oder einem Zeitstempel zugegriffen werden kann.
  • Jeder Zeile wird in einem oder mehreren Tablets gespeichert. Ein Tablet ist eine Folge von 64 Kilobyte-Blöcken in einem Datenformat namens SSTable.
  • BigTable kennt drei verschiedene Arten von Servern:
    • Die Master-Server (master server) ordnen Tablets den Tablet-Servern zu. Sie überwachen, wo die Tablets liegen und verteilen die notwendigen Aufgaben neu.
    • Die Tablet-Server (tablet server) nehmen Lese-/Schreib-Anfragen für die Tablets vor. Sie trennen Tablets auf, wenn die die Größengrenze erreichen (in der Regel 100 - 200 Megabyte). Wenn ein Tablet-Server abstürzt, dann übernehmen 100 Tablet-Server je ein neues Tablet und das System erholt sich wieder.
    • Die Sperr-Server (lock server) bilden einen verteilten Sperrdienst. Aufgaben wie das Öffnen von Tablets um hineinzuschreiben, Master-Entscheidungen und Zugriffskontrollüberprüfung erfordern einen gegenseitigen Ausschluss.
  • Eine Lokalitätsgruppe kann verwendet werden, um zusammengehörige Daten-Bits physisch zusammen zu speichern, um eine bessere Lokalitätseigenschaft zu erreichen.
  • Tablets werden so viel wie irgend möglich im RAM gecached.
Hardware
  • Wenn Du eine Menge Maschinen hast, wie konfigurierst Du sie, um kosten- und energieeffizient zu sein?
  • Verwende ultrabillige Standardhardware und baue dann eine Software, die mit deren Tod umgehen kann.
  • Einen tausendfachen Rechenleistungsanstieg kann man für 33-fach geringere Kosten haben, wenn Du eine fehleranfällige Infrastruktur einer Infrastruktur vorziehst, die aus hochzuverlässigen Komponenten besteht. Du musst Verlässlichkeit auf Unzuverlässigkeit aufbauen, damit diese Strategie funktioniert.
  • Linux, In-House-Racks, Hauptplatinen der PC-Klasse, billige Festplatten.
  • Der Preis pro Wattleistung je Rechenleistung wird nicht besser. Nimm hohen Wattleistung hin und beschaff Dir eine gute Kühlung.
  • Verwende eine Mischung aus gemeinschaftlichen und separaten Rechenzentren.
Verschiedenes
  • Schiebe Änderungen schnell raus, statt auf QA zu warten.
  • Bibliotheken sind der vorherrschende Weg, um Programme zu bauen.
  • Einige Anwendungen werden als Service angeboten, wie zum Beispiel das Crawling.
  • Die Infrastruktur besorgt die Versionierung der Anwendungen, so dass man etwas Veröffentlichen kann, ohne Angst davor haben zu müssen, dass man etwas kaputt macht.
Zukünftige Vorgaben für Google
  • Unterstützung weltweit verteilte Cluster.
  • Schaffung eines einzelnen globalen Namensraums für alle Daten. Zur Zeit sind die Daten nach Clustern getrennt.
  • Mehr und besser automatisierte Migration von Daten und Berechnungen.
  • Lösen von Konsistenzproblemen, die auftreten, wenn Du eine Breitbandreplikation mit Netzwerkaufteilung koppelst (zum Beispiel um Dienste am Laufen halten, auch wenn ein Cluster wegen Wartungsarbeiten oder wegen etwas anderem ausgeschaltet werden).
Gelernte Lektionen
  • Infrastruktur kann ein Wettbewerbsvorteil sein. Es ist gewiss einer für Google. Google kann neue Internetdienste so schnell, billig und skalierungssicher herausbringen, dass nur ein paar andere mithalten können. Viele Firmen haben einen komplett anderen Ansatz. Viele Firmen sehen Infrastruktur nur als Kostenfaktor an. Jede Gruppe verwendet komplett andere Technologien und es gibt nur wenig Planung und Öffentlichkeit was den Aufbau des Systems angeht. Google sieht sich selbst als eine Systemtechnikfirma, was ein erfrischender Blick auf die Softwareherstellung ist.
  • Die Verbindung mehrerer Datenzentren ist nach wie vor ein ungelöstes Problem. Die meisten Webseiten sind in einem oder höchstens zwei Datenzentren. Wie man eine Webseite komplett über mehrere Datenzentren hinweg herausbringt ist, sagen wir, knifflig.
  • Sieh dir Hadoop (das Produkt) an, wenn Du keine Zeit hast, die ganze Infrastruktur von Grund auf selbst aufzubauen. Hadoop ist eine Open Source-Implementierung, die viele der hier vorgestellten Ideen enthält. ( http://lucene.apache.org/hadoop/ )
  • Ein unterschätzter Vorteil des Plattform-Ansatzes ist, das unerfahrene Entwickler auf der Plattform aufbauend schnell und sicher robuste Anwendungen schaffen können. Wenn jedes Projekt dasselbe verteilte Infrastruktur-Rad neu erfinden muss, wirst Du Probleme kriegen, weil die Leute, die wissen wie das geht, ziemlich selten sind.
  • Synergie ist nicht immer Scheiße. Indem man alle Teile eines Systems dazu bringt zusammenzuarbeiten, hilft eine Verbesserung an einem Teil allen anderen auch. Verbessere das Dateisystem und alle profitieren sofort und klar erkennbar. Wenn jedes Projekt ein anderes Dateisystem verwendet, gibt es keine stetig wachsende Verbesserung im gesamten Stapel.
  • Baue selbstverwaltende Systeme, die arbeiten, ohne dass man das System herunterfahren muss. Das erlaubt dir, einfacher Ressourcen zwischen den Servern auszubalancieren, dynamisch mehr Kapazität hinzuzufügen, Maschinen abzuschalten und Upgrades elegant handzuhaben.
  • Schaffe eine darwinistische Infrastruktur. Führe zeitfressende Aufgaben parallel durch und nimm den Gewinner.
  • Ignoriere die Forschung nicht. Akademiker haben eine Menge guter Ideen, die leider nicht in Produktionsumgebungen übertragen werden. Das meiste von dem was Google tut, ist Stand der Technik, nicht nur die riesige Skalierungsfähigkeit.
  • Ziehe Kompression in Betracht. Kompression ist eine gute Option, wenn Du viele CPUs und wenig Ein-/Ausgabe-Bandbreite hast.