Bessere Archiv-Zugriffe mit der Storage-Engine Spider

Eine Million Logs pro Tag bei BlaBlaCar dank MariaDB

| Autor / Redakteur: Jan Schulze* / Ulrike Ostler

"Spider" ist eine Speicher-Engine mit integrierten Sharding-Funktionen und nun nebst MariaDB bei BlaBlaCar im Einsatz.
"Spider" ist eine Speicher-Engine mit integrierten Sharding-Funktionen und nun nebst MariaDB bei BlaBlaCar im Einsatz. (Bild: BlaBlaCar/ dm_art/Fotolia.com)

BlaBlaCar, die moderne Form der Mitfahrzentrale, wächst schnell. Nicht nur die Geschäftstätigkeit der Plattform weitet sich aus – auch das Volumen der vorhandenen Daten steigt rapide an.Das Unternehmen hat sich deswegen entschlossen, sein Archiv künftig auf Basis der noch jungen Speicher-Engine „Spider“ mit MariaDB zu führen. Das Ziel des Projekts: Alle historischen Daten sollen einfach durchsuchbar sein, selbst wenn sich die Tabellen der produktiven Datenbanken ändern.

Alle Unternehmen, die ihre Dienste über das Internet anbieten, bekommen früher oder später das gleiche Problem: Die Datenmenge, die verwaltet und archiviert werden muss, steigt rapide an. Je mehr Erfolg ein Unternehmen hat, desto mehr aktuelle und historische Daten fallen an.

Um die Performance der produktiv genutzten Datenbanken zu gewährleisten, ist die Verlagerung aktuell nicht benötigter Daten in ein Archiv unvermeidlich. Doch auch die Archivbestände müssen jederzeit schnell für Abfragen zugänglich sein.

BlaBlaCar macht da keine Ausnahme. Das 2006 gegründete Unternehmen der Comuto SA mit dem Hauptsitz in Paris vermittelt Mitfahrgelegenheiten über ein Web-Portal und mobile Apps. Mittlerweile ist die Plattform in 22 Ländern aktiv, über 400 Mitarbeiter an 14 Standorten weltweit betreuen die Community und kümmern sich um die Technik.

In Deutschland unterhält das Unternehmen Büros in München und in Hamburg. BlaBlaCar verzeichnet 25 Millionen Mitglieder, pro Quartal nutzen rund zehn Millionen Reisende die Dienste der Community. Der Name leitet sich übrigens von einem besonderen Merkmal der Plattform ab: Nutzer können auf einer Skala von einem bis drei „Blas“ angeben, ob sie bei der gemeinsamen Fahrt lieber ihre Ruhe haben möchten oder ob sie gesprächsfreudig sind.

Komplexe IT, kritische Datenbanken

Den Kern von BlaBlaCar bildet die Datenbank „MariaDB“ in Version 10.0. Eine zentrale Anforderung an die Datenbank war von jeher, dass diese mit dem Unternehmenswachstum beliebig skalieren kann. Dabei liegt der Fokus von BlaBlaCar auf einer Scale-Out-Strategie: Mehr Datenbankleistung wird durch Hinzufügen weiterer Server in die bestehenden Cluster erreicht.

Inzwischen betreibt das Unternehmen in seinen beiden Rechenzentren fast 250 physikalische Server. Als Cluster-Lösung nutzt BlaBlaCar „MariaDB Enterprise Cluster“. Die Datenbank-Tabellen müssen aktuell über eine Million Logs pro Tag verarbeiten. Und dabei hochverfügbar sein, schließlich basiert das Geschäftsmodell des Unternehmens auf einer funktionierenden IT.

Ein typisches "Spider"-Deployment besitzt eine shared-nothing Cluster-Architektur.
Ein typisches "Spider"-Deployment besitzt eine shared-nothing Cluster-Architektur. (Bild: MariaDB)

Die verteilte Umgebung ist per se schon komplex. Noch komplexer wird es durch die unterschiedlichen Nutzungsbereiche der verschiedenen Datenbank-Cluster: Je nach Einsatzgebiet kommen verschiedene Storage-Engines zum Einsatz. Die produktiven Systeme speichern die Daten mittels der transaktionalen Engine „InnoDB“, die bis Version 10.0.8 der Standard bei MariaDB ist. Auf den Archiv-Shards in einem separaten Cluster hingegen kommt zusätzlich die schlankere auf Leseabfragen optimierte Storage-Engine MyISAM zum Einsatz.

„Es war recht schwer, Daten aus dem Archiv abzufragen“, erinnert sich Nicolas Blanc, Head of Platform Architecture bei BlaBlaCar. „Zudem ließ sich dieser Ansatz nicht skalieren, da alle Tabellen auf einem Server gespeichert werden müssen, um eine Abfrage über alle Tabellen hinweg auszuführen. Zudem stellte die Modifikation der Datenbank-Schemata eine Hürde dar: Wenn wir eine produktive Tabelle ändern, sollen wir dann auch alle Tabellen im Archiv ändern?“

Einfacher dank XA-Transaktionen

Allerdings ist es für das Unternehmen keine Alternative, auf das Archiv zu verzichten. BlaBlaCar verfolgt die Strategie, die Datenbestände auf den produktiven Systemen möglichst gering zu halten und gleichzeitig historische Daten für Auswertungen und dergleichen vorzuhalten. Um das Problem des umständlichen Archivzugriffs in den Griff zu bekommen, begann das Unternehmen Anfang des vergangenen Jahres damit, die neue Storage-Engine „Spider“ einzuführen.

BlaBlaCar setzt auf geteilte Ressourcen.
BlaBlaCar setzt auf geteilte Ressourcen. (Bild: BlaBlaCar)

Spider ist eine Speicher-Engine mit integrierten Sharding-Funktionen, die Partitionen und XA-Transaktionen (verteilte Transaktionen) unterstützt. Tabellen auf verschiedenen Datenbank-Servern können dadurch so behandelt werden, als lägen sie auf derselben Maschine. Dabei spielt es keine Rolle, welche Storage-Engine für die jeweilige Tabelle selbst zum Einsatz kommt. Damit agiert Spider selbst wie ein eigenständiger Cluster. MariaDB unterstützt Spider seit Version 10.0.4.

Der Grund für diese Entscheidung seitens BlaBlaCar: „Die Lösung sollte einfach sein, leicht aufzusetzen und leicht zu administrieren“, erläutert Blanc. Bei der Einführung der Spider-Engine bekam das Unternehmen Unterstützung durch MariaDB, die auch beim Tuning der Lösung behilflich waren.

Spider arbeitet nun als Proxy-Tabelle, mit dessen Hilfe die MyISAM-Shards abgefragt werden können, die auf verschiedene Schemata verteilt sind. Nachdem Spider nun das BlaBlaCar-Archiv auf eine solide technologische Basis gestellt hat, werden seit Beginn dieses Jahres die Workflows optimiert, mit dem Daten aus den produktiven Systemen ins Archiv übernommen werden. Ein eigenes Entwicklerteam befasst sich mit diesem Redesign.

Die Spider-Engine erlaubt viele gesplittete Reads bei gleichzeitigen Partitionen-Scans.
Die Spider-Engine erlaubt viele gesplittete Reads bei gleichzeitigen Partitionen-Scans. (Bild: MariaDB)

Rechtzeitig an Archivierung denken!

Die Einführung der Spider-Engine wurde damit erfolgreich abgeschlossen. „Wir können nun unsere historischen Daten einfach abfragen“, zieht Blanc das Fazit. Jedoch stellt er auch klar: „Die Migration alter Archivdaten auf eine neue Architektur ist sehr zeitaufwändig.“

Zudem war einiges an Kopfarbeit im Vorfeld notwendig, um die neue Zielarchitektur auszuarbeiten. Auch sei Spider ein noch sehr junges Projekt, gibt Blanc zu bedenken. Man müsse nun aufmerksam verfolgen, wie sich die Engine entwickle.

Die Lesson Learned bei BlaBlaCar: „Wenn man im produktiven Umfeld eine neue Tabelle erzeugt, sollte man auch gleich definieren, wann die Daten in dieser Tabelle irrelevant werden. Denn wenn man über die kontrollierte Auslagerung nachdenkt, wenn die Tabelle bereits drei Jahre alt und mehrere Gigabytes umfasst, wird die Archivierung ziemlich schwierig“, so Blanc.

* Jan Schulze ist feier Autor.

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44048843 / Konsolidierung/TCO)