hab acht

Quelle: http://highscalability.com/unorthodox-approach-database-design-coming-shard
Autor: Todd Hoff am 31. Juli 2007 18:13
Übersetzung: Sebastian Wallroth

Vor langer, langer Zeit skalierten wir Datenbanken, indem wir immer größere, schneller und teurere Maschinen kauften. Während diese Vorgehensweise tolle fette Gewinnspannen ist, funktioniert es nicht so gut mit den Girokonten unserer heldenhaften Systembauer, die weit mehr skalieren müssen, als sie für gigantische Datenbankserver aufbringen können. In einer außergewöhnlichen zweiteiligen Artikelserie erklärt Dathan Pattishall seine Beweggründe für ein revolutionäres neues Datenbankdesign - Sharding -, über das er nachzudenken begann noch bevor er bei Friendster arbeitete und dann bei Flickr voll implementierte. Flickr verarbeitet heute mehr als 1 Milliarde Transaktionen pro Tag, in weniger als ein paar Sekunden antwortend und bei niedrigen Kosten linear skalieren.

Was ist Sharding und wie wurde es die Antwort auf die Skalierungsprobleme großer Webseiten?

Informationsquellen

• Unorthodox approach to database design Part1:History
  
• Unorthodox approach to database design Part 2:Friendster

• Hohe Verfügbarkeit. Wenn eine der Kisten abstürzt, können die anderen weiterarbeiten.
  
• Schnellere Abfragen. Kleine Datenmengen in jeder Benutzergruppe bedeuten schelleres Durchsuchen.
  
• Mehr Schreibbandbreite. Ohne Masterdatenbank, die die Schreibzugriffe serialisiert kann man parallel schreiben, was die Schreibdurchsatz erhöht. Schreiben ist der Hauptengpass für viele Webseiten.
  
• Du kannst mehr Arbeit erledigen. Ein paralleles Backend bedeutet, dass Du mehr Arbeiten gleichzeitig erledigen lassen kannst. Du kannst mit mehr Benutzerlast verkraften, insbesondere, wenn Du Daten schreibst, weil es parallele Wege durch das System gibt. Du kannst die Last zwischen den Webservern verteilen, die auf die Shards über verschiedene Netzwerkwege zugreifen, von getrennten CPUs betrieben werden, getrennte RAM-Caches und getrennte IO-Wege verwenden, um die Aufgaben zu bearbeiten. Nur sehr wenige Engpässe begrenzen Deine Arbeit.

• Daten sind denormalisiert. Traditionell normalisieren wir Daten. Daten werden über anomaliefreie Tabellen verteilt und dann wieder miteinander verbunden, wenn sie gebraucht werden. Beim Sharding werden die Daten denormalisiert. Man speichert Daten zusammen, wenn sie später zusammen verwendet werden.
  Das bedeutet nicht, dass man Daten auch nach Typ aggregiert. Man kann Benutzerprofile getrennt von deren Kommentaren, Blogs, E-Mails, Medien etc. speichern, aber die Benutzerprofildaten würden als Einheit gespeichert und verarbeitet. Das ist ein sehr schneller Ansatz. Man holt und speichert einfach einen Blob. Man braucht keine Joins und man kann sie mit einem Festplattenzugriff speichern.
  
• Daten sind über viele physikalische Instanzen hinweg parallelisiert. Nach althergebrachter Weise werden Datenbanken vertikal skaliert (scale up). Man kauft größere Maschinen, um mehr Power zu kriegen. Mit diesem Ansatz kann man jedoch massiv mehr Arbeit erledigen, weil sie parallel erledigt werden kann.
  
• Daten werden klein gehalten. Je größer ein Datenset ist, das ein Server bearbeitet, desto schwerer ist es, intelligent zu optimieren, weil man auf eine so breite Vielfalt von Daten zugreifen muss. Man braucht gewaltige Brocken RAM, die dann nicht mal dazu ausreichen, die Daten zu cachen, wenn man es braucht. Indem man Daten in kleineren Shards isoliert, können die Daten, auf die man zugreift leichter im Cache gehalten werden.
  Kleinere Datensets kann man außerdem leichter sichern, wiederherstellen und verwalten.
  
• Daten sind höher verfügbar. Weil die Shards unabhängig sind, schadet eine Fehlfunktion an einem Shard keinem anderen Shard. Und wenn man jeden Shard mit 50% Kapazität laufen lässt, ist es viel einfacher, einen Shard an Ort und Stelle upzugraden. Das Vorhalten mehrerer Datenkopien innerhalb eines Shards hilft außerdem bei Redundanzen und dabei, die Daten mehr zu parallelisieren, so dass mehr Arbeit mit den Daten erledigt werden kann. Man kann einen Shard auch so aufsetzen, dass man eine Master-Slave- oder eine Doppel-Master-Beziehung zwischen den Shards hat, um einzelne Fehlerquellen innerhalb des Shards zu vermeiden. Wenn ein Server abstürzt, kann ein anderer übernehmen.
  
• Man braucht keine Replikation. Daten von einem Master-Server zu einem Slave-Server zu replizieren ist ein traditioneller Ansatz für das Skalieren. Daten werden auf den Master-Server geschrieben und dann auf einen oder mehr Slave-Server repliziert. An diesem Punkt können Lese-Operationen von den Slaves übernommen werden, aber alle Schreiboperationen passieren auf dem Master.
  Selbstverständlich wird der Master zum Schreib-Engpass und zur Fehlerquelle. Und wenn die Last zunimmt, nehmen auch die Kosten für die Replikation zu. Replikation kostet CPU, Netzwerkbandbreite und Festplatten-IO. Die Slave fallen zurück und haben veraltete Daten. Die Typen bei YouTube hatten ein großes Problem mit Replikationsoverhead, als sie skalieren wollten.
  Sharding löst das Replikationsproblem klar und elegant.

• Rebalancieren von Daten. Was passiert, wenn ein Shard die Speichergröße übersteigt und geteilt werde muss? Sagen wir, einige Benutzer haben ein besonders lange Freundesliste, die die Speicherkapazitäten für den Shard überschreiten. Man muss den Benutzer in einen anderen Shard übertragen.
  Auf einigen Plattformen, mit denen ich gearbeitet habe, war das ein tödliches Problem. Man muss das Datenzentrum von Anfang an korrekt ausbauen, weil das übertragen von Daten von Shard zu Shard eine Menge Downtime verbraucht.
  Rebalancing muss von Anfang an eingebaut sein. Googles Shards werden automatisch rebalanciert. Dafür müssen Datenreferenzen durch so eine Art Naming-Dienst laufen, so dass sie wiedergefunden werden können. So macht es Flickr. Und die Referenzen müssen annullierbar sein, so dass die darunterliegenden Daten übertragen werden können, während man sie benutzt.
  
• Daten von multiplen Shards joinen. Um eine komplexe Freundeseite zu bauen oder eine Benutzerprofilseite oder eine Diskussionsseite mit Threads muss mann normalerweise viele verschiedene Daten aus vielen verschiedenen Quellen zusammen ziehen. Mit Sharding kann man nicht einfach eine Abfrage ausführen und alle Daten kriegen. Man muss einzelne Anfragen an die Datenquellen stellen, alle Antworten einsammeln und dann die Seite bauen. Dankenswerterweise ist dieser Prozess wegen Caching und schnellen Netzwerken normalerweise schnell genug, so dass die Ladezeiten der Seiten exzellent sein können.
  
• Wie partitioniert man Daten in Shards? Welche Daten tut man in welche Shards? Wo kommen Kommentare hin? Gehören alle Benutzerdaten wirklich zusammen oder nur die Profildaten? Sollten die Mediendaten, IMs und Freundeslisten usw. der Benutzer irgenwo anders hin? Unglücklicherweise gibt es keine einfachen Antworten auf diese Fragen.
  
• Weniger Schwung. Die Leute haben Erfahrung mit traditionellen RDBMS-Werkzeugen, so dass es viel Hilfe von außen gibt. Man hat Bücher, Experten, Werkzeugsätze und Diskussionforen, wenn etwas schief läuft oder man sich fragt, wie man ein neues Feature implementiert. Eclipse wird keinen Shard-View haben und man wird keine automatischen Backup- und Wiederherstellungsprogramme für Shards finden. Mit Shards ist man auf sich gestellt.
  
• Die Implementierung von Shards wird nicht gut unterstützt. Sharding ist zur Zeit zumeist ein Eigenbau-Ansatz. LiveJournal macht seine Werkzeugsätze verfügbar. Hibernate entwickelt eine Bibliothek, MySQL hat die Unterstützung von Partitionierung hinzugefügt. Aber im Allgemeinen ist es immer noch etwas, was man selbst implementieren muss.

• Die Flickr Architektur (englisch) um viele interessante Ideen dafür zu finden, wie man Sharding implementieren kann.
  
• Die Google Architektur
  
• Die LiveJournal Architektur (englisch). Sie erzählen ein bisschen über ihren Shardingansatz und liefern viele hilfreiceh Details.

0 Comment

Original: http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
Autor: Todd Hoff am 10. Agust 2007 21:01
Übersetzung: Sebastian Wallroth

Twitter begann als Nebenprojekt und wuchs schnell an, von 0 auf Millionen Pageviews in erschreckend wenigen Monaten. Frühe Design-Entscheidungen, die im Kleinen gut funktionierten schmolzen unter dem Andrang neuer Benutzer, die Piepse zu all ihren Freunden zwitscherten. Der Web-Liebling Ruby on Rails wurde früh für die Skalierungsprobleme verantwortlich gemacht, aber Blaine Cook, Twitters Hauptarchitekt, hält Ruby für schuldlos:

Für uns geht es wirklich um horizontales Skalieren - auf dieser Seite waren Rails und Ruby nicht die Stolpersteine, verglichen mit anderen Sprachen und Frameworks. Die Leistungssteigerung, die mit “schnelleren” Sprachen assoziiert wird, hätte uns 10-20% Verbesserung gebracht, aber Dank der Architektur-Änderungen, die Ruby und Rails glücklicherweise beinhaltet, ist Twitter im August 2007 1.000% schneller, als es im Januar 2007 war.

• Scaling Twitter Video by Blaine Cook.
  
• Scaling Twitter Folien
  
• Good News Blogpost von Rick Denatale
  
• Scaling Twitter Blogpost Patrick Joyce.
  
• Der Traffic der Twitter API ist 10x höher als der der Website von Twitter.
  
• A Small Talk on Getting Big. Scaling a Rails App & all that Jazz - really cute dog picks

• Ruby on Rails
  
• Erlang
  
• MySQL
  
• Mongrel - Ein hybrider Ruby/C-HTTP-Server, designed, klein, schnell und sicher zu sein
  
• Munin
  
• Nagios
  
• Google Analytics
  
• AWStats - Echtzeit-Logdatei-Analysierer für erweiterte Statistiken
  
• Memcached

• Mehr als 350.000 Benutzer. Die tatsächliche Anzahl ist wie immer, sehr sehr super geheim.
  
• 600 Aufrufe pro Sekunde.
  
• durchschnittlich 200-300 Verbindungen pro Sekunde. Spitzen bis zu 800 Verbindungen pro Sekunde.
  
• MySQL verarbeitet 2.400 Aufrufe pro Sekunde.
  
• 180 Rails-Instanzen. Verwendet Mongrel als "Web"-Server.
  
• 1 MySQL Server (eine große 8-Kern-Box) und einen Slave. Der Slave ist nur zum lesen für Statistiken und Reporting.
  
• 30+ Prozesse für die Behandlung von Sonderaufträgen (odd jobs).
  
• 8 Sun X4100s.
  
• Ein Aufruf wird in Rails innerhalb von 200 Millisekunden verarbeitet.
  
• Die durchschnittliche Verarbeitungszeit in der Datenbank liegt bei 50-100 Millisekunden.
  
• Über 16 GB Memcached.

• Lief vor aller Augen in Skalierungsprobleme. Eine Zeit lang traten immer wieder Fehler auf.
  
• Ursprünglich hatten sie kein Monitoring, keine Diagramme, keine Statistiken, was es schwer machte, die Probleme festzumachen und zu lösen. Munin und Nagios wurden hinzugefügt. Es gab Schwierigkeiten damit, die Tools unter Solaris zu verwenden. Sie hatten Google Analytics, aber die Seiten wurden gar nicht geladen, so dass das nichts brachte :-)
  
• Verwendet Caching mit Memcached ausgiebig.
  • Wenn zum Beispiel der Aufruf eines Zählers langsam wird, kann man den Zähler in Millisekunden in Memcache memoisieren.
    
  • Die Status der Freund zu erhalten ist schwierig. Es gab Sicherheits- und andere Herausforderungen. Anstatt eine Datenbanksuche auszuführen, wird der Freundesstatus im Cache erneuert. Das gibt einen vorhersagbaren Antwortzeitrahmen (Obergrenze 20 Millisekunden).
    
  • ActiveRecords-Objekte sind gewaltig, weshalb sie nicht gecached werden. Also wollen sie kritische Attribute in einem Hash speichern und die anderen Attribute bei Bedarf per Lazy loading holen.
    
  • 90% der Anfragen sind API-Abfragen. Also mach kein Seiten/Abschnitts-Caching im Frontend. Die Seiten sind so zeitempfindlich, dass nichts Gutes dabei herauskommt. Aber sie cachen API-Abfragen.
• Messaging
  • Verwende Messaging ausgiebig. Produzenten produzieren nachrichten, die in Warteschlangen warten und dann an die Kunden ausgeliefert werden. Twitters Hauptfunktionalität ist es, als eine Nachrichtenbrücke zwischen verschiedenen Formaten (SMS, Web, IM, etc.) zu agieren.
    
  • Sende eine Nachricht, um die Cache des Freundes im Hintergrund zu leeren, anstatt alles einzeln gleichzeitig zu machen.
    
  • Gestartet mit DRb (Distributed Ruby). Eine Bibliothek, die Dir erlaubt Nachrichten von ferngesteuerten Ruby-Objekten (remote Ruby objects) via TSP/IP zu senden und zu empfangen. Aber es funktionierte irgendwie komisch und war eine Fehlerwuelle.
    
  • Umstellung auf Rinda, eine gemeinsam genutzte Warteschlange, die ein Tuple space-Modell im Rahmen von Linda verwendet. Aber die Warteschlangen sind persistent und die Nachrichten gehen im Fehlerfall verloren.
    
  • Erlang wurde getestet. Problem: Wie kriegt man einen abgestürzten Server am Sonntag zum Kaufen, wenn 20.000 Benutzer warten? Der Entwickler wusste es nicht. Nicht viel Dokumentation. Also bedrohte es den Betrieb - was tödlich ist.
    
  • Umstellung auf Starling, eine in Ruby geschriebene verteilte Warteschlange.
    
  • Verteilte Warteschlangen wurde geschaffen, um Systemabstürze zu überleben, indem sie auf die Festplatte geschrieben werden. Andere große Webseiten verwenden diesen einfachen Ansatz ebenfalls.
• SMS werden mittels einer von einer Drittpartei bereitgestellten API verwendet. Ist sehr teuer.
  
• Deployment
  • Sie untersuchen und installieren neue Mongrel Server. Kein sehr schöner Weg.
    
  • Dem Benutzer wird ein interner Serverfehler angezeigt, wenn die Mongrel Server ersetzt werden.
    
  • Alle Server werden zeitgleich abgeschossen. Ein rollender Ausfall wird nicht angewandt, weil der Status der Nachrichtenschlange in Mongrels steckt und ein rollierender Ansatz die Warteschlangen dazu bringen würde, die verbleibenden Mongrels überlaufen zu lassen.
• Missbrauch
  • Eine Menge Downtime weil Leute durch die Seite surfen und jedermann als Freund hinzufügen. 9.000 Freunde in 24 Stunden. Das würde die Seite abstürzen lassen.
    
  • Baue Werkzeuge, um diese Probleme anzuzeigen, so dass man genau festmachen kann, wann und wo sowas passiert.
    
  • Sei unbarmherzig. Lösche deren Benutzeraccounts.
  Partitionierung
  • Es gibt Pläne für eine zukünftige Partitionierung. Zur Zeit machen sie das nicht. Diese Änderungen haben bisher gereicht.
    
  • Das Partitionierungsschema wird auf Zeit basieren, nicht auf Benutzern, weil die meisten Anfragen zeitlich eng begrenzt und nur lokal auftreten.
    
  • Partitionierung wird schwierig sein wegen der automatischem Memoisation. Sie können nicht garantieren, das Nur-Lesen-Operationen wirklich nur-lesend sein werden. Sie könnten auf einen Nur-Lesen-Slve schreiben, was wirklich schlecht ist.
• Twitters API-Traffic ist zehnmal größer als der Seiten-Traffic
  • Deren API ist das wichtigste, was Twitter gemacht hat.
    
  • Den Dienst zu halten erlaubt den Entwicklern auf der Infrastruktur aufzubauen und mit Ideen zu kommen, die besser sind als das, was Twitter selbst einfallen würde. Twitterific zum Beispiel, ein wundevollerer Weg, Twitter zu nutzen, als ein kleines Team mit anderen Prioritäten erstellen könnte.
• Monit wird verwendet, um Prozesse abzuschießen, wenn sie zu groß sind.

• Sprich mit der Community. Verstecke dich nicht und versuche nicht, Probleme selber zu lösen. Viele hervorragende Leute sind bereit zu helfen, wenn Du fragst.
  
• Behandle Deinen Skalierungsplan wie einen Geschäftsplan. Stelle ein Beratergremium zusammen, das Dich unterstützt.
  
• Mach es selbst. Twitter verbrachte viel Zeit damit, anderer Leute Lösungen auszuprobieren, die fast zu funktionieren schienen, aber dann doch nicht ausreichten. Es ist besser, einige Dinge selber zu bauen, so dass man immerhin etwas Kontrolle behält und man kann die Features einbauen, die man braucht.
  
• Baue Benutzerbeschränkungen ein. Die Leute werden versuchen, Dein System kaputt zu machen. Baue vertretbare Beschränkungen und Warnmelder ein, um Dein System davor zu beschützen, abgemurkst zu werden.
  
• Mach die Datenbank nicht zum zentralen Flaschenhals des Untergangs. Nicht alles erfordert einen gigantischen Join. Cache Daten. Denk über andere kreative Wege nach, um dasselbe Ergebnis zu erhalten. Ein gutes Beispiel wird in Twitter, Schienen, Hämmer und 11.000 Nägel pro Sekunde beschrieben.
  
• Mach Deine Applikation von Start weg partitionierbar. Dann wirst Du immner einen Weg haben, Dein System zu skalieren.
  
• Wenn Du merkst, dass Deine Seite langsam ist, füge sofort ein Reporting hinzu, um die Probleme analysieren zu können.
  
• Optimiere die Datenbank.
  • Indiziere alles. Rails macht das nicht für Dich.
    
  • Versuche mal zu erklären, was deine Abfragen (queries) machen. Die Indexe könnten anders sein, als Du erwartest.
    
  • Denormalisiere viel. Kleinlichkeit nützte ihnen. Zum Beispiel speichern sie alle Benutzer-IDs zusammen mit den IDs der Freunde, was ihnen eine Menge aufwändiger Joins erparte.
    
  • Vermeide komplexe Joins.
    
  • Vermeide das Scannen großer Datenmengen.
  Cache verdammt noch mal alles. Individuelle aktive Einträge werden derzeit noch nicht gecached. Testabfragen sind zur Zeit noch schnell genug.
  
• Teste alles.
  • Du willst wissen, wenn Du eine Applikation ausrollst, dass sie richtig funktionieren wird.
    
  • Sie haben jetzt eine komplette Testsuite. Wenn das Caching nicht funktioniert, dann sind sie in der Lage den Fehler zu finden, bevor sie Live gehen.
• Lange laufende Prozesse sollten zu Daemons abstrahiert werden.
  
• Verwende Ausnahme-Melder und Ausnahme-Logger, um sofort über Probleme benachrichtigt zu werden, so dass Du korrekt reagieren kannst.<
  
• Mach keine Dummheiten.
  • Skalieren bedeutet, dass vorher richtige Vorgehensweisen jetzt bescheuert sind.
    
  • Zu versuchen 4.000 Freunde auf einmal in den Speicher zu laden, kann den Server zum Absturz bringen, aber wenn da nur 4 Freunde sind, funktioniert es großartig.
• Die meiste Leistung kommt nicht von der Sprache, sondern vom Anwendungsdesign.
  
• Mach aus Deiner Webseite einen offenen Dienst, indem Du einen API baust. Ihre API ist ein gewaltiger Grund für Twitters Erfolg. Es erlaubt Benutzern ein immer weiter expandierendes Ökosystem um Twitter herum aufzubauen, so dass es schwierig ist, mit ihm zu konkurrieren. Du kannst niemals all die Arbeit machen, die Deine Benutzer machen und Du wirst wahrscheinlich niemals so kreativ sein. Also öffne Deine Anwendungen und mach es Anderen einfach, ihre Anwendungen mit Deinen zu verbinden.

• Für eine Betrachtung zu Partitionierung sieh Dir Amazon Architecture, An Unorthodox Approach to Database Design : The Coming of the Shard (englisch) und Flickr Architecture (englisch) an
  
• Die Mailinator Architecture (englisch) enthält gute Strategien für den Schutz vor Missbrauch
  
• GoogleTalk Architecture (englisch) enthält einige interessante Punkte über die Skalierung von Sozialen Netzwerk Seiten

0 Comment

Original: http://www.royans.net/arch/2007/10/25/scaling-technorati-100-million-blogs-indexed-everyday/
Autor: Royans Tharakan
Übersetzung: Sebastian Wallroth

Mit der Indizierung von 100 Millionen Blogs mit über 10 Milliarden Objekten und einer Benutzerbasis, die sie alle sechs Monate verdoppelt, ist technorati den meisten anderen Blog-Suchmaschinen weit voraus. Aber technorati ist viel mehr als nur eine Suche und jeder technorati-Benutzer kann Dir das erläutern. Ich empfehle, John Newtons Interview mit David Sifry zu lesen, dass ich faszinierend fand. Hier ein paar Höhepunkte aus diesem Interview, wenn Du nicht die Zeit hast, das ganze Ding zu lesen.

Gegenwärtiger Stand von technorati

• 1 Terabyte Inhalt kommen pro Tag hinzu
  
• 100 Millionen Blogs
  
• 10 Milliarden Objekte
  
• 0,5 Milliarden Fotos und Videos
  
• Datenverdopplung alle sechs Monate
  
• Benutzerverdopplung alle sechs Monate
  

• Diese Version tat alles in eine relationale Datenbank, was ausreichte, solange die Größe des Indexes kleiner war als der physikalische Speicher
  
• Es funktionierte gut bis etwa 20 Millionen Blogs
  

• Die Daten wurden in Shards aufgebrochen
  
• Die Daten wurden häufig zwischen den Servern synchronisiert
  
• Die Datenbankgröße erreichte die größte bekannte OLTP-Größe.
  
  
  
  • Daten Schreiben und Lesen hielten sich sie Waage
    
  • Die Verwaltung der Datenintegrität war wichtig
    
    
    
    • So kam viel Druck auf das System
      
    
    
  
  

• Die Shards entwickelten sich weiter
  
  
  
  • Die Shards basierten jetzt auf Zeiten statt auf URLs
    
  • Inhalte wurden in spezielle Datenbank verschoben, anstatt sie in einer relationalen Datenbank zu halten
    
  
  
• Nichts wurde gelöscht
  
• Es wurden nur Shards bewegt und für Hinzugekommenes wurden neue Shards verwendet
  

• Green Plum - ermöglicht Firmen, für eine genaue Analyse schnell auf große Mengen kritischer Daten zuzugreifen. Entworfen für hohe Leistung und groß skalierende Business Intelligence besteht Greenplums Familie von Datenbankprodukten aus Lösungen für Installationen von Abteilungs-Datamarts bis zu Multi-Terabyte-Data Warehouses.
  

• Man hätte sich für Klickstromanalyse-Software interessieren sollen, um zu analysieren, was Klicks mit den Benutzern
  
  
  
  • Aussagen, wieviel Zeit die Benutzer mit einem Feature zubringen
    
  
  

0 Comment

• 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

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.

• 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

• 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!

0 Comment

• Ursprünglich schrieb ich eine Bitte um Hilfe in Hilfe, überzeugt Dell LSI zu drängen, MegaCli unter Open Source zu stellen
  
• Kevin Burton antwortete mit der Behauptung "RAID stirbt" in MySQL und Der Tod von RAID
  
• Ich antwortete Kevin, indem ich die Vorteile von RAID pries und meinen Standpunkt darlegte in RAID: Lebendig und wohlbehalten in der realen Welt
  
• Kevin antwortete, ein paar meiner Punkte aufgreifend in Ja Jeremy, RAID Stirbt Wirklich
  
• Brian Moon antwortete auf den Schlagabtausch, verwirrt von der Behauptung "RAID stirbt" in RAID stirbt?
  
• Kevin antwortete auf Brians Kommentar mit der Behauptung "Nur Skalierung funktioniert wirklich." in RAID und Horizontales Skalieren vs. Vertikales Skalieren

0 Comment

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.

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.

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.

0 Comment

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.

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

• Hibernate-Shards: Hibernate-Shards erlauben es dir die Hibernate APIs, die Du kennst und liebst, weiterhin zu benutzen: SessionFactory, Session, H Criteria, Query. Wenn Du bereits weißt, wie man Hibernat verwendet, dann weißt Du auch bereits, wie man Hibernate Shards verwendet.
• Digg skalieren... Shards und Datenbank. Hier ein weiterer Diskussionsbeitrag über Digg.
• Anmerkungen zu Sharding, unique Keys und foreign Keys
• Das Sharding von Datenbanken mit MySQL
• Sharding?

0 Comment