Login
Newsletter
Werbung

Do, 20. Oktober 2011, 15:00

Cassandra – Die Datenbank hinter Facebook

Datenbanksysteme gibt es heutzutage viele – sowohl relationale wie z.B. MySQL, PostgreSQL oder Oracle als auch die verschiedenen Systeme aus dem Bereich der sogenannten »NoSQL«-Datenbanken (siehe NoSQL – Jenseits der relationalen Datenbanken). Zu letzteren gehört auch Cassandra, wobei diese Datenbank insofern anders ist, als dass sie ursprünglich von Facebook speziell für Facebook und deren spezifische Probleme entwickelt wurde.

Entwicklung

Die Entwicklung von Cassandra wurde durch das sogenannte »Inbox Search Problem« motiviert. Dabei geht es darum, dass ein Facebook-Nutzer seine erhaltenen und gesendeten Nachrichten nach Begriffen durchsuchen kann. Grundsätzlich ist dies natürlich leicht machbar. Bei Facebook bestand das Problem aber darin, dass es für die Anzahl der aktiven Nutzer kombiniert mit der gespeicherten und konstant (sowie vermutlich relativ schnell) wachsenden Datenmenge keine ausreichend performante Lösung mehr mit MySQL & Co. gab. Also wurde Cassandra entwickelt – und das Problem damit erfolgreich gelöst. Die Datenbank ist dabei in Java implementiert.

Aufgrund der Anforderungen ist es nicht verwunderlich, dass Cassandra auf hohe Schreib- und Lesedurchsätze optimiert ist, wobei in der Standardeinstellung die Schreibvorgänge asynchron erfolgen, d.h. die Daten werden erst im RAM gehalten und dann »gebündelt« auf die Festplatte geschrieben. Des Weiteren unterstützt Cassandra die Partitionierung der Datenbank, wobei die Rechner auch an verschiedenen Orten (Rechenzentren) stehen können. Außerdem beherrscht die Datenbank Replikation, automatische Erkennung von ausgefallenen Rechnern im Datenbankverbund und ist sehr gut skalierbar. Die Details und Hintergründe hierzu findet man in der sechsseitigen Veröffentlichung »Cassandra – A Decentralized Structured Storage System« (PDF), welche sehr empfehlenswert ist, wenn man sich näher mit Cassandra beschäftigen möchte.

Open Source

Nun erfreut sich Facebook bekanntlich nicht uneingeschränkter Beliebtheit unter den Computernutzern und mancher Leser mag Cassandra deswegen kritisch gegenüberstehen. Erfreulicherweise kann an dieser Stelle aber Entwarnung gegeben werden: Cassandra wurde im Frühjahr 2009 an die Apache Foundation übergeben und ist somit Open Source unter der Apache-Lizenz. Seit Februar 2010 ist die Datenbank ein »Top-Level-Projekt«, die Entwicklung wird somit aktiv vorangetrieben.

Datenmodell

Cassandra besitzt ein relativ einfaches Datenmodell (siehe auch hier). Dies ist eine Mischung aus einem Key-Value-Store und einer spaltenorientierten Datenbank. Die Daten werden dabei in »Column Families« (kurz: CF) organisiert. Eine CF besteht aus beliebig vielen »Row Keys«, welchen wiederum beliebig viele Schlüssel-Werte-Paare zugeordnet werden können. Im Cassandra-Kontext werden die Schlüssel dabei als »Column« (auf deutsch: Spalte) bezeichnet. Eine CF ist also eine mehrdimensionale Map. Verschiedenen Row Keys können Werte für gleiche Spalten zugeordnet werden – dies muss aber nicht der Fall sein. Des Weiteren ist das Datenmodell von Cassandra zwar strukturiert, es besteht aber keine Notwendigkeit der Definition vorab. Das heißt, im laufenden Betrieb können jederzeit neue Columns hinzugefügt werden.

Eine Column Family mit zwei Row Keys kann also z.B. so aussehen:

Row Key: "User_1"
 Column "Name"     - Wert: "Otto"
 Column "Alter"    - Wert: "40"

Row Key: "User_2"
 Column "Name"     - Wert: "Susi"
 Column "Alter"    - Wert: "25"
 Column "Nickname" - Wert: "TurboS"

Neben den zuvor beschriebenen Column Families kennt Cassandra noch »Super Columns«. Hierbei handelt es sich um eine erweiterte Variante der normalen CF, die eine Ebene mehr hat. Dies kann man sich so vorstellen, dass die Column wiederum eine Column Family ist. Das folgenden Schema verdeutlicht dies:

Row Key: "User_1":
 Super Column "Name":
  Column "Vorname"     - Wert: "Otto"
  Column "Nachname"    - Wert: "Normal"
 Super Column "Kontaktdaten":
  Column "E-Mail"      - Wert: "otto@example.de"
  Column "Jabber"      - Wert: "on@superjabber.de"

Row Key: "User_2":
 Super Column "Vorname":
  Column "Vorname"     - Wert: "Susi"
  Column "Nachname"    - Wert: "Sorglos"
  Column "Maedchenname" - Wert: "Sonnenschein"
 Super Column "Kontaktdaten":
  Column "E-Mail"      - Wert "susi@sorglos.de"

Zu erwähnen ist noch, dass die Datenbank zusätzlich zu jedem Wert einen »Timestamp« (auf deutsch: Zeitstempel) speichert, der angibt, wann der Wert in die jeweilige Column geschrieben wurde. Dies geschieht automatisch.

CF und Super Columns wiederum werden in »Keyspaces« abgelegt. Ein Keyspace kann dabei beliebig viele Column Families und Super Columns enthalten. Die Daten sind dabei aber völlig getrennt voneinander, der Keyspace ist also eine Art »Sammelcontainer«. Abfragen der Datenbank über mehrere Column Families hinweg, was einem Join über mehrere Tabellen in relationalen Datenbanken entspräche, gibt es in Cassandra nicht.

Cassandra kennt keine verschiedenen Datentypen, alles wird intern als »ByteType« gespeichert, wobei sowohl Schlüssel als auch Werte beliebig lang sein können. Da binäre Daten für Menschen bekanntlich recht schwierig zu lesen sind, gibt es natürlich auch die Möglichkeit, Daten z.B. als ASCII- oder UTF-8-Text zu speichern.

Kommentare (Insgesamt: 7 || Alle anzeigen )
Re[4]: Titel eigentlich Blödsinn (LH_, Sa, 22. Oktober 2011)
Re[3]: Titel eigentlich Blödsinn (Jochen Schnelle, Fr, 21. Oktober 2011)
Fehler im Code (Error, Fr, 21. Oktober 2011)
Re[2]: Titel eigentlich Blödsinn (cbda, Do, 20. Oktober 2011)
Re: Titel eigentlich Blödsinn (fs111, Do, 20. Oktober 2011)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung