Dienstag, 8. Juni 2010

Lesetip: MongoDB: Warum Etsy und Shutterfly auf neue Datenbanken setzen

Marcel Weiß hat auf Exciting Commerce einen interessanten Artikel zum Thema MongoDB: Warum Etsy und Shutterfly auf neue Datenbanken setzen geschrieben, der ein guter Einstieg in hochskalierbare Datenbanken ist.

Mittwoch, 2. Juni 2010

Magento im High Performance Umfeld

Christiane Philipps (CTO), Martin Rothenberger (Head of Engineering) - DailyDeal GmbH

Einsatz von Magento im High Performance Umfeld



Im Rahmen der Social Live Shopping Plattform DailyDeal.de setzt sich die Firma sehr intensiv mit Performance-Anforderungen an die technische Infrastruktur sowie an Magento selbst auseinander. Performance ist einer der kritischsten Faktoren für den Erfolg einer High-Traffic-Anwendung. Auf der anderen Seite ist es nach wie vor ein zu bearbeitendes Thema im Magento-Umfeld, das nicht out of the box gelöst ist, aber im zunehmenden Maße dringender wird, je mehr Shopbetreiber auf Magento umstellen. Philipps und Rothenberg stellen ihre Erfahrungen dar und welche Optimierungsmaßnahmen sie ergriffen haben.

Freitag, 28. Mai 2010

Sonntag, 2. März 2008

Ein unorthodoxer Ansatz für ein Datenbank-Design: Das Aufkommen des Shardings

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?

InformationsquellenWas ist Sharding?
Während er an Auction Watch arbeitete kam Dathan die Idee, ihre Skalierungsprobleme zu lösen, indem er einen Datenbankserver für eine Benutzergruppe aufbaute und diese Server auf billigen Linuxkisten laufen ließ. In diesem Schema sind die Daten für den Benutzer A auf einem Server gespeichert und die Daten für Benutzer B auf einem anderen Server. Es ist ein föderatives Modell. Gruppen von 500.000 Benutzern werden zusammen in sogenannten Shards gespeichert

Die Vorteile sind:
  • 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.
Was unterscheidet Sharding von traditionellen Architekturen?
Sharding unterscheidet sich von traditionellen Datenbankarchitekturen in mehreren wichtigen Punkten:
  • 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.
Einige Probleme mit Sharding
Sharding ist nicht perfekt. Es hat einige Probleme.
  • 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.

Siehe auch

Samstag, 12. Januar 2008

Twitter skalieren: Wie man Twitter 1.000 Prozent schneller macht

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.

Wenn Ruby on Rails nicht Schuld war, wie lernte Twitter immer höher und höher zu skalieren?

Website: http://twitter.com

Informationsquellen
Die Plattform
  • 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
Die Fakten
  • 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.
Die Architektur
  • 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.

Gelernte Lektionen
  • 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.


Verwandte Artikel

technorati skalieren - 100 Millionen täglich indizierte Blogs

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

Die erste Version war dafür vorgesehen, für eine gewisse Zeit für wenig Geld Informationen zu tracken.

  • 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 nächste Generation zog Vorteil aus der Parallelisierung.

  • 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 dritte Generation

  • 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

Verwendete Werkzeuge

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

Hätte früher gemacht werden sollen

  • 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

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.