Erweiterung des verteilten Datenspeichersystems Cassandra um eine Indexunterstützung

Transkript

1 Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Datenbanken und Informationssysteme Erweiterung des verteilten Datenspeichersystems Cassandra um eine Indexunterstützung Bachelorarbeit im Studiengang Informatik Jan Kantert Erstprüfer: Prof. Dr. Udo Lipeck Zweitprüfer: Dr. Hans Hermann Brüggemann Betreuer: Prof. Dr. Udo Lipeck Abgabedatum: 12 August 2010

2 2

3 Inhaltsverzeichnis 1 Einleitung Übersicht Motivation Aufgabenstellung Aufbau der Arbeit Grundlagen Cassandra Datenmodell Konfigurationsdatei Datenverteilung CAP-Theorem Konsistenz Operationen Beispiele Konzept Übersicht Index-Speicherformat Korrektheit Index definieren Index aktualisieren Index abfragen Index (neu-)aufbauen Index überprüfen/reparieren

4 4 INHALTSVERZEICHNIS 4 Implementierung Externes Interface Internes Interface Beispiele Konfigurationsinterface Datenstrukturen zur Laufzeit Schreiboperationen Leseoperationen Wartungsoperationen Experimente und Tests Benchmarks Schreiben ohne Index Schreiben mit Index Lesen auf Datensäte Lesen mit Index auf einen Datensatz Lesen mit Index auf 10 Datensätze Bewertung der Ergebnisse Simulation hoher Latenz Fazit Zusammenfassung Vergleich zu relationalen Datenbankmanagementsystemen Ausblick Literaturverzeichnis 62 Abbildungsverzeichnis 63 Eidesstattliche Erklärung 65 A Konfigurationsdatei cassandra.yaml 67 B Thrift Interface 75

5 Kapitel 1 Einleitung 1.1 Übersicht Cassandra ist ein hoch-verfügbarer, strukturierter, versionierter Schlüssel-Wert- Speicher. Er ist stark auf Geschwindigkeit optimiert und geht davon aus, dass Ausfälle die Regel und nicht die Ausnahme sind. Die Konsistenz der Daten wird zugunsten von Verfügbarkeit und Partitionstoleranz nicht immer garantiert. Ein Cassandra-Datenspeicher besteht aus mehreren Knoten und alle Datensätze werden anhand ihres Schlüssels über eine Hashfunktion einem Knoten zugewiesen. Datensätze bestehen aus einer beliebigen Anzahl von Attributen, welche nicht durch ein Schema definiert sind, und sie werden auf N Knoten repliziert. Unterstützt werden lediglich grundlegende Operationen: Lesen eines Datensatzes, Schreiben eines (Teil-)Datensatzes und Lesen von Bereichen von Datensätzen anhand des Schlüssels. Alle Operationen werden vom Benutzer an einen Koordinator-Knoten gesendet, welcher sich um die Ausführung auf den richtigen Knoten kümmert. Dabei ist es möglich, anzugeben, auf wie viele Knoten direkt zugegriffen werden soll, um verschieden starke Konsistenzen zu erreichen. Es ist nicht möglich, einen Datensatz über etwas anderes als den Schlüssel abzufragen. Mehrere Datensätze werden in einer ColumnFamily zusammengefasst, welche das schemalose Äquivalent zu einer Tabelle in einem RDMS 1 ist. 1 Relationales Datenbank Management System 5

6 6 KAPITEL 1. EINLEITUNG 1.2 Motivation In relationalen Datenbanksystemen ist es im Unterschied zu Cassandra möglich Anfragen nach beliebigen Spalten zu stellen. In vielen Anwendungsfällen ist es sinnvoll, Datensätze effizient über den Wert eines Attributes abfragen zu können. Dabei ist in den meisten Fällen vorher bekannt um welche Attribute es sind handeln wird. Aktuell ist das nur durch einen ineffizienten Scan über alle Datensätze zu realisieren. Zielsetzung der Arbeit ist es daher, einen effizienten und flexiblen Mechanismus zu entwickeln und zu implementieren, der einen verteilten Index über ein oder mehrere Attribute aufbaut und nutzt. Dem Benutzer soll es ermöglicht werden effizient alle Datensätze zu einem Wert eines vorher definierten Attributs zu finden. 1.3 Aufgabenstellung Als Ziel der Arbeit sollen folgende Dinge erreicht werden: Es soll ein geeignetes Konfigurationsinterface geschaffen werden, in welchem von einem Benutzer ein Index über eine ColumnFamily, also eine Gruppe von Datensätzen, definiert werden kann. Dabei können die beteiligten Attribute und der Name des Indexes gewählt werden. Es soll eine Methode entwickelt werden, um einen Index initial aufzubauen und zu validieren. Eine Validierung soll die normale Nutzung des Indexes nicht einschränken. Es soll ein Verfahren entworfen werden, welches bei jeder schreibenden Operation auf ein Attribut in einer ColumnFamily den entsprechenden Index aktualisiert. Dazu wird überprüft, ob die geschriebenen Attribute im Index enthalten sind. Dann wird gegebenen Falles der Index aktualisiert. Ein besonderes Augenmerk wird dabei auf die Architektur von Cassandra gelegt. Es soll dem Benutzer ermöglicht werden, lesende Operationen mit Hilfe des Indexes auszuführen. Dabei soll es möglich sein, einzelne Indexwerte oder auch Bereiche von Werten abzufragen.

7 1.4. AUFBAU DER ARBEIT 7 Der Index soll, wie andere Datensätze auch, per Hashfunktion über alle Knoten verteilt und repliziert werden. Es sollen die gleichen Qualitätsanforderungen wie für normale Schreibzugriffe auch für den Index gelten. Für jeden Zugriff wird angegeben, auf wie vielen Knoten er mindestens erfolgen soll. Auf entsprechend vielen Knoten wird auch der Index geschrieben. In jedem Fall soll der Index konsistent zu den indexierten Datensätzen bleiben. Das gilt besonders bei Ausfällen von Knoten oder von Verbindungen zwischen Knoten. Die Implementierung erfolgt als Teil des Cassandra-Codes in Java. Falls möglich, soll sie in das nächste Cassandra Release einfließen. 1.4 Aufbau der Arbeit In Kapitel 2 werden die Grundlagen von Cassandra erklärt. Dabei wird Cassandra in die Entwicklungslinien der NoSQL-Datenspeicher eingeordnet und die generellen Begrifflichkeiten werden erläutert. Besonders eingegangen wird auf das Datenmodell, die Datenverteilung und die Einschränkung der Konsistenz. Zuletzt wird eine Übersicht über alle Operationen gegeben. Danach wird in Kapitel 3 beschrieben, wie Indexe in Cassandra implementiert werden sollen. Dabei muss auf die Eigenheiten von Cassandra Rücksicht genommen werden. Es wird darauf eingegangen, welche Operationen ermöglicht werden sollen und wie ein Index vom Benutzer erstellt werden kann. Weiterhin wird diskutiert, wie ein Index beim Schreiben aktualisiert wird und wie es möglich ist die Daten abzufragen. Zuletzt werden der initiale Aufbau und die effiziente Überprüfung eines Indexes beschrieben. In Kapitel 4 wird die konkrete Implementierung eines verteilten Indexes in Cassandra beschrieben. Zunächst wird der generelle Aufbau von Cassandra kurz erklärt. Danach werden das geplante Speicherformat und die Datenstrukturen zur Laufzeit entworfen und es wird die Verarbeitung der Konfigurationsdatei erläutert. Es wird beschrieben, wie schreibende Operationen modifiziert werden müssen, um beim Schreiben einen Index zu aktualisieren. Anschließend wird eine sinnvolle Implementierung für lesende Operationen auf den Datenspeicher vorgeschlagen und kurz auf die Wartungsoperationen eingegangen.

8 8 KAPITEL 1. EINLEITUNG Weiterhin wird die Implementierung in Kapitel 5 experimentell überprüft. Dabei werden Geschwindigkeit und Durchsatz vor und nach der Implementierung gemessen. Außerdem wird der Einfluss von großer Netzwerklatenz auf Durchsatz und Geschwindigkeit von Schreiboperationen auf einen Index untersucht.

9 Kapitel 2 Grundlagen In diesem Kapitel werden die für die Arbeit wichtigen Grundlagen von Cassandra erklärt und die zugrundeliegende, verteilte Architektur und Philosophie erläutert. Dabei werden das Datenmodell, die Verteilung der Datensätze sowie die Einschränkungen, welche sich daraus ergeben, erörtert. Danach wird eine Übersicht über grundlegende Operationen gegeben und die besondere Behandlung der Konsistenz von Daten erklärt. 2.1 Cassandra Apache Cassandra ist ein verteiltes, strukturiertes Datenspeichersystem [14]. Als Vorlage dienten Amazon Dynamo[12] und Google BigTable[11]. Dabei wurde das Datenformat von Google BigTable übernommen und später etwas erweitert. Während Google ein eigenes verteiltes Dateisystem verwendet, hat sich Amazon für eine einfachere Verteilung per Distributed Hashtable entschieden. Der Fokus bei Amazon liegt auf guten Antwortzeiten in E-Commerce-Anwendungen und es wird ein einfaches Schlüssel-Wert-Datenmodell verwendet. BigTable dagegen speichert zu jedem Schlüssel eine beliebige Anzahl an Attributen mit jeweils einem Wert und eignet sich somit dazu, große Datenmengen zu verarbeiten und zu analysieren. Cassandra kombiniert die strukturierte Datenhaltung von BigTable mit der Verteilung von Dynamo und unterstützt wie Dynamo und BigTable nur primitive Abfrageoperationen. Die meisten solcher NoSQL-Datenspeichersysteme 1 1 NoSQL = Not Only SQL 9

10 10 KAPITEL 2. GRUNDLAGEN unterstützen kein SQL 2 als Anfragesprache und sind in der Regel auch nicht relational. Entwickelt wurde Cassandra von Facebook[13] zum Einsatz als Speicher für mehrere Reverse Word Indexes 3 [14, S. 5]. Aus diesem Grund wurden einige Änderungen am von Google übernommenen Datenmodell durchgeführt und es wurde ein besonderes Augenmerk auf gute Performance, hohe Verfügbarkeit und Skalierbarkeit über viele einfache Knoten gelegt. Mittlerweile ist Cassandra ein Apache Toplevel Projekt geworden und wird von mehreren großen Firmen genutzt und weiterentwickelt. Ähnliche Projekte sind Apache Hadoop[1] und Apache Hbase[2]. Wobei es sich um einen Klon von Googles Dateisystem und Googles BigTable handelt. Sie eignen sich besonders für die Analyse großer Datenmengen. Im Unterschied zu Cassandra garantieren sie starke Konsistenz, dafür wird bei Ausfällen von einzelnen Knoten zeitweise die Nichtverfügbarkeit einzelner Datensätze in Kauf genommen[2]. Ein Cassandra-Datenspeicher besteht aus einer Anzahl von Knoten, die zur Laufzeit entfernt und hinzugefügt werden können. Alle Knoten besitzen die gleichen Rollen, es gibt keine Sonderrollen und keinen Single Point of Failure, also keinen Knoten, dessen Ausfall zum Ausfall des gesamten Systems führt. Jeder Knoten ist zugleich Speicher-Knoten und Koordinator-Knoten. Die Kommunikation funktioniert nach dem Peer-to-Peer-Modell. Das bedeutet, dass es keine zentrale Koordinationsinstanz gibt, sondern, dass alle Knoten gleichberechtigt sind und direkt miteinander kommunizieren [vgl. 12, S. 208], [vgl. 14, S. 3]. Die Philosophie von Cassandra besagt, dass Leseoperationen in linearer Zeit zur Größe der zurückgegebenen Daten abgeschlossen werden. Bei Ausfällen von Knoten ist es möglich, dass einige Bereiche zeitweise nicht zum Lesen verfügbar sind. Allerdings schlagen Schreiboperationen niemals fehl, solange ein einziger Knoten erreichbar ist und keine Konsistenzanforderungen gestellt werden[14]. 2 SQL = Structured Query Language 3 Ein Index für Volltextsuche, bei dem für jedes Wort gespeichert wird, in welchen Dokumenten es an welcher Stelle vorkommt.

11 2.2. DATENMODELL Datenmodell Während es in relationalen Datenbanksystemen mehrere Datenbanken gibt, verwendet Cassandra sogenannte Keyspaces 4. Ein Keyspace definiert einen eigenen Namensraum für die enthaltenen Datentypen und muss beim Verbinden vom Client, der eine Anfrage stellt, angegeben werden. Es kann beliebig viele Keyspaces geben. In der Regel verwendet man einen Keyspace pro Anwendung. Cassandra bietet zwei verschiedene Datentypen an: ColumnFamilies und SuperColumnFamilies. Sie werden über ihren Schlüssel referenziert und sind eindeutig in einem Keyspace definiert [5], [7]. Eine ColumnFamily kann mit einer Tabelle in einer relationalen Datenbank ohne fixe Anzahl an Spalten verglichen werden und enthält eine beliebige Menge von Attributen mit jeweils einem Wert. Die Attribute müssen nicht vorher definiert und können bei Bedarf hinzugefügt werden. Dabei sind die Attributnamen innerhalb einer ColumnFamily eindeutig. Attribute können beliebige Werte enthalten, die binär gespeichert werden. Eine SuperColumnFamily enthält als Attribute eine beliebige Anzahl von (Unter-)ColumnFamilies. Ein vergleichbarer Datentyp ist ein zweidimensionales assoziatives Array. Alternativ kann man sich auch eine traditionelle Tabelle mit einer beliebigen Anzahl an Spalten vorstellen, die jeweils ein Array enthalten [vgl. 14, S.1f]. Im Folgenden werden sowohl Werte zu ColumnFamilies als auch zu Super- ColumnFamilies als Datensatz bezeichnet. In Beispiel 2.1 gibt es zwei Column- Families Users und UserItems. Unter der ColumnFamily Users gibt es zwei Datensätze mit den Schlüsseln a und b. Beide enthalten ein oder mehrere Attribute mit Werten. Außerdem gibt es eine SuperColumnFamily UserCars mit einem Datensatz a. Dieser enthält zwei (Unter-)ColumnFamilies mit den Schlüsseln Auto 1 und Auto 2. Sie beinhalten jeweils wieder Attribute mit Werten. Zu jedem Attributwert wird beim Schreiben automatisch ein aktueller Zeitstempel eingefügt. Dieser wird intern zur Konfliktbehandlung verwendet und kann vom Benutzer abgefragt werden. Semantisch gesehen zeigt das Beispiel 2.1 eine kleine Benutzerdatenbank. Die ColumnFamily Users enthält eine Liste von Benutzern mit verschiedenen Attributen. In der Family UserItems wird die Anzahl an Gegenständen, welche 4 engl. Schlüsselraum

12 12 KAPITEL 2. GRUNDLAGEN MyUserApp Users a b age: 27 19:10 name: Hans 19:10 gender: m 19:20 age: 20 18:55 UserItems a Autos: 2 Hunde: 5 17:10 12:00 UserCars a Auto 1 Auto 2 Farbe: rot PS: 320 PS: 80 20:00 20:02 10:00 Abbildung 2.1: Beispiel Datenbestand gemäß Datenmodell von Cassandra

13 2.3. KONFIGURATIONSDATEI 13 zu einem Benutzer gehören, gespeichert. Dabei wird der gleiche Schlüssel wie in der ColumnFamily Users verwendet. Jeder Attributname gibt einen Gegenstand an, der Attributwert beschreibt die Anzahl der Gegenstände. Außerdem wurde eine SuperColumnFamily UserCars definiert, welche verschiedene Attribute aller Autos eines Benutzers angibt. Der Schlüssel ist hier ebenfalls der gleiche Schlüssel wie beim Benutzer. Die Namen der enthaltenen ColumnFamilies geben die Namen der Autos an. Die enthaltenen Attribute beschreiben jeweils die Eigenschaften der Autos. Das Datenmodell von Cassandra entspricht großteils dem Modell von Googles BigTable [vgl. 11, S.2], auch der Begriff ColumnFamily wurde von Google geprägt. SuperColumnFamilies sind eine Erweiterung in Cassandra, die dem ursprünglichen Einsatzzweck von Cassandra als Volltextindex geschuldet sind. Weiterhin hält Google BigTables eine einstellbare Anzahl von älteren Versionen eines Attributwertes vor und erlaubt es dem Benutzer diese abzufragen [11]. In Cassandra sind ältere Versionen eines Wertes für den Benutzer nicht mehr sichtbar. 2.3 Konfigurationsdatei keyspaces: - name: MyUserApp replication_factor: 5 column_families: - name: Users compare_with: BytesType - name: UsersItems compare_with: BytesType - name: UsersCars column_type: Super compare_with: BytesType compare_subcolumns_with: BytesType Abbildung 2.2: cassandra.yaml Beispiel Die Konfiguration von Cassandra und der ColumnFamilies erfolgt in einer Konfigurationsdatei namens cassandra.yaml (Auszug mit ColumnFamilies siehe

14 14 KAPITEL 2. GRUNDLAGEN Abbildung 2.2; Komplette Datei siehe Anhang A). Es handelt sich beim Inhalt um strukturierte Daten im Yaml-Format[9], die beim Start von Cassandra eingelesen werden. Nach einer Änderung einer ColumnFamily oder eines Keyspaces in der Datei muss das erneute Einlesen und die Verarbeitung durch den Benutzer ausgelöst werden. Alternativ ist das Anlegen, Löschen oder Modifizieren einer Column- Family oder SuperColumnFamily auch über eine Wartungsoperationen möglich. Dauerhaft werden die ColumnFamily-Definitionen intern im System-Keyspace gespeichert. Das oberste Element in der Konfigurationsdatei ist ein Keyspace keyspaces. Für jeden Keyspace müssen der name und der replication factor definiert werden. Der Name muss eindeutig sein. Der replication factor gibt an auf wie viele Knoten N ein Datensatz zu einem Schlüssel k repliziert wird. Außerdem können unterhalb des column families-elements beliebig viele ColumnFamilies und SuperColumn- Families definiert werden. Das Format für eine ColumnFamily enthält Attribute für name, column type und compare with. column type gibt an, ob es sich um eine SuperColumnFamily oder eine normale ColumnFamily handelt. Wird der Parameter ausgelassen ist der Standardwert ColumnFamily. Außerdem wird im Parameter compare with eine Vergleichsfunktion angegeben. Sie definiert in welcher Reihenfolge die Datensätze anhand ihres Schlüssels über die Knoten und Festplatten verteilt werden. SuperColumnFamilies besitzen zusätzlich noch ein weiteres Attribut für die Vergleichsfunktion der enthaltenen (Unter-)ColumnFamilies. 2.4 Datenverteilung Die Verteilung der Daten wurde von Amazon Dynamo inspiriert und funktioniert sehr ähnlich [12, S. 215f]. Alle Datensätze werden anhand ihres Schlüssels über alle Knoten verteilt, um Skalierbarkeit und Lastverteilung zu erreichen. Zu diesem Zweck wird Partitionierung mit konsistentem Hashing verwendet. Aus dem Schlüssel eines jeden Datensatzes wird mit Hilfe einer Hashfunktion ein Hashwert berechnet. Standardmäßig verwendet Cassandra die md5-funktion. Mit dem Parameter partitioner kann die Hashfunktion beeinflusst werden. Der Wertebereich der Hashfunktion wird auf eine Ringstruktur abgebildet. Jedem Knoten wird eine eindeutige Position auf dieser Ringstruktur zugewiesen (siehe Abbildung

15 2.4. DATENVERTEILUNG ). Er ist dann für alle Hashwerte zwischen seiner Position und der Position des nächsten Knotens zuständig. Außerdem wird jeder Datensatz auf N-1 weitere Knoten repliziert, welche dann ebenfalls zuständig sind. Dazu werden jeweils die nächsten N-1 Knoten nach dem ersten zuständigen Knoten auf der Ringstruktur gewählt. Der Faktor N kann für jeden Keyspace bei der Konfiguration mit dem Parameter replication factor eingestellt werden [vgl. 14, S. 2]. Knoten J Knoten K Knoten A Knoten B Knoten I Hash(Key k) Repliziert Knoten C Knoten H Knoten D Knoten G Knoten E N=3 Knoten F Abbildung 2.3: Verteilung der Daten auf Knoten in einer Ringstruktur In Beispiel 2.3 liegt der Hashwert des Datensatzes mit dem Schlüssel k auf der Ringstruktur zwischen den Hashwerten von Knoten B und C. Damit ist Knoten B der erste zuständige Knoten. Weiterhin wird der Datensatz auf N-1 auf B folgende Knoten repliziert. In diesem Fall sind das die zwei Knoten C und D, welche ebenfalls für den Hashwert zuständig sind. Da alle Knoten nach dem Peer-to-Peer Modell kommunizieren, um voneinander Daten abzufragen, ist es notwendig zu wissen, welche Knoten aktuell verfügbar sind. Dazu wird eine Mitgliedsliste mit dem Status aller bekannten Knoten geführt.

16 16 KAPITEL 2. GRUNDLAGEN Um bei vielen Knoten ohne großen Aufwand alle Knoten zu überwachen, wird ein sogenanntes Gossip-Protokoll[15] verwendet. Dabei sendet jeder Knoten seine Mitgliedsliste periodisch an einen zufällig ausgewählten Knoten. Beim Senden der Knotenliste wird gleichzeitig überprüft, ob der Zielknoten verfügbar ist. Betritt ein neuer Knoten den Cassandra-Cluster, so muss er nur einem Knoten bekannt gemacht werden und wird dann im Laufe der Zeit allen bekannt. Somit haben nicht alle Knoten immer die gleiche Sicht auf den Datenspeicher. Allerdings ist dies aufgrund der Architektur von Cassandra kein Problem. Man kann zeigen, dass in endlicher Zeit ein stabiler Zustand eintritt und die Mitgliedslisten aller Knoten gleich sind, wenn man lang genug wartet [vgl 12, S. 212f], [vgl. 14, S. 3]. 2.5 CAP-Theorem Availability Consistency Partition Tolerance Abbildung 2.4: Grafische Darstellung des CAP-Theorems Das CAP-Theorem, welches 2000 von Eric Brewer aufgestellt wurde, besagt, dass in einem verteilten System von den drei Eigenschaften Konsistenz (Consistency), Verfügbarkeit (Availability) und Partitionstoleranz (Partitiontolerance) nur

17 2.6. KONSISTENZ 17 maximal zwei gewählt werden können [vgl. 10]. Cassandra wählt Verfügbarkeit und Partitionstoleranz [4]. Dies bietet den Vorteil, dass zu jedem Zeitpunkt ein Lese- und Schreibzugriff auf den Speicher möglich ist. Jedoch können die Daten beim Lesen eventuell veraltet sein. Der Verteilungsmechanismus von Cassandra entspricht in etwa dem Mechanismus von Amazon Dynamo [vgl. 12, S. 207]. In der Abbildung 2.4 ist zu sehen, dass sich jeweils nur zwei Eigenschaften überlappen. Allerdings erlaubt Cassandra, wie im nächsten Abschnitt zu sehen sein wird, in einem gewissen Umfang die Partitionstoleranz zugunsten der Konsistenz einzuschränken. Das widerspricht in begrenztem Umfang dem CAP-Theorem. Man sollte die Aussage des Theorems also eher so verstehen, dass es nicht möglich ist in einem verteilten System alle drei Eigenschaften in vollem Umfang gleichzeitig zu gewährleisten [vgl. 8]. 2.6 Konsistenz Cassandra bietet also die Möglichkeit Datensätze mittels einer konsistenten Hashfunktion verteilt auf mehreren Knoten redundant zu speichern, um die Verfügbarkeit und Zuverlässigkeit der Daten zu erhöhen. Dabei werden Einschränkungen der Konsistenz in Kauf genommen. Generell unterscheidet man zwischen drei verschiedenen Konsistenzanforderungen: Strenge Konsistenz (strong consistency) - Wenn ein Schreibvorgang abgeschlossen ist, wird er von allen nachfolgenden Lesezugriffen zurückgeliefert. Die Reihenfolge der Änderungen ist für alle Knoten immer gleich. Schwache Konsistenz (weak consistency) - Nach einem Schreibvorgang existiert ein Zeitfenster, in dem Änderungen für nachfolgende Lesezugriffe nicht zurückgeliefert werden. Die Reihenfolge der Änderungen kann von Knoten zu Knoten variieren. Letztendliche Konsistenz (eventual consistency) - Es wird garantiert, dass in endlicher Zeit alle Änderungen auf allen Knoten in der gleichen Reihenfolge zurückgegeben werden. Cassandra implementiert nur letztendliche Konsistenz. Dies hat zur Folge, dass es während einer Schreiboperation für andere Leseoperationen ein Zeitfenster gibt,

18 18 KAPITEL 2. GRUNDLAGEN in dem die Änderungen nicht immer sichtbar sind. Sie können auch auftauchen und wieder verschwinden, aber in endlicher Zeit werden sie verfügbar sein [vgl. 16]. Für jeden Schlüssel k eines Datensatzes gibt es N zuständige Knoten (entspricht dem replication factor aus Abschnitt 2.3). Bei lesenden sowie schreibenden Operationen ist es möglich, die Anzahl der Knoten anzugeben, auf die direkt gelesen bzw. geschrieben werden soll. Dabei sei R die Anzahl an Knoten auf die gelesen wird und W die Anzahl der Knoten auf die geschrieben. Wird nicht direkt auf alle N Knoten geschrieben, erfolgt die Replikation der Daten asynchron im Hintergrund [vgl. 14, S. 3], [vgl. 12, S. 210]. Bei lesenden und schreibenden Operationen ist es in Cassandra möglich, mit dem Parameter consistency level anzugeben, von wie vielen Knoten die Daten gelesen oder geschrieben werden. Folgende Werte sind für das consistency level möglich (Siehe Anhang B): ONE - Es wird nur auf einen zuständigen Knoten geschrieben bzw. gelesen. QUORUM - Es wird auf (N/2)+1 zuständige Knoten geschrieben bzw. gelesen. Da die Knotenanzahl in der Regel ungerade ist und N/2 abgerundet wird, überlappen sich die Knoten zweier QUORUM Operationen um mindestens einen Knoten. ALL - Es wird auf alle N zuständigen Knoten geschrieben. Beim Lesen ist ALL aktuell nicht implementiert. ANY - Es wird auf einen zuständigen Knoten geschrieben. Wenn dies nicht möglich ist, wird die Schreiboperation an einen beliebigen anderen Knoten geschickt. Sobald ein zuständiger Knoten erreichbar ist, wird die Operation weitergeleitet und ausgeführt. Im Unterschied zu ONE schlägt diese Operation nicht fehl, wenn kein zuständiger Knoten erreichbar ist. Beim Lesen ist ANY nicht sinnvoll und nicht implementiert [vgl. 12, S. 212]. ZERO - Es wird asynchron auf einen zuständigen Knoten geschrieben, wobei nicht auf eine Rückmeldung gewartet wird. Ist kein zuständiger Knoten verfügbar, schlägt die Operation fehl ohne, dass der Client davon etwas bemerkt. Beim Lesen ist ZERO nicht implementiert..

19 2.6. KONSISTENZ 19 Allerdings ist nicht immer garantiert, dass nach Schreiboperationen folgende Leseoperationen den aktuellen Wert lesen. Generell kann man sagen, dass nur Konsistenz erreicht wird, wenn R + W > N gilt, also die Summe aus den Knoten, auf die geschrieben wird, und die Knoten, auf die gelesen wird, größer als die Anzahl der zuständigen Knoten ist. So wird garantiert, dass die Menge der Knoten, auf die geschrieben wird, sich um mindestens einen Knoten mit der Menge der Knoten überlappt, auf die gelesen wird[4]. Wird z.b. auf nur einen Knoten geschrieben, ist nicht sichergestellt, dass nachfolgende lesende Operationen sofort den geschriebenen Wert lesen, wenn sie nicht von allen zuständigen Knoten lesen. Da nicht jedem Knoten sofort die Version des Datensatzes mit dem aktuellen Zeitstempel bekannt ist, müssen mindestens N W + 1 Knoten nach der aktuellen Version befragt werden, um sicher mindestens einen Knoten mit dem aktuellen Datensatz zu erreichen. Für viele Anwendungszwecke ist dies eine elementare Voraussetzung. Es gibt drei Konstellationen, in denen gewährleistet werden kann, dass auf jeden Fall nach einem abgeschlossenen Schreibvorgang aktuelle Daten gelesen werden: Schreiben auf alle N zuständigen Knoten mit consistency level =ALL. Lesen von mindestens einem Knoten mit consistency level =ONE. Effizient bei vielen Lese- und wenig Schreiboperation. Schreiben auf (N/2)+1 zuständige Knoten und Lesen von mindestens N/2 zuständigen Knoten, jeweils mit consistency level =QUORUM. Dies ist der gängigste Arbeitsmodus in Cassandra. Schreiben auf einen zuständigen Knoten mit consistency level =ONE und Lesen von allen N Knoten mit consistency level =ALL. Effektiv bei vielen Schreib- und wenig Leseoperationen. Allerdings führt der Ausfall eines Knotens in den meisten Fällen zu Datenverlust. Aktuell ist diese Konstellation nicht in Cassandra implementiert, da beim Lesen consistency level =ALL nicht unterstützt wird. In allen anderen Fällen wird nicht garantiert, dass nach einer Schreiboperation sofort aktuelle Daten geliefert werden. Dabei tritt kein Datenverlust auf, allerdings kann es eine kurze Zeit dauern, bis alle Änderungen auf allen Knoten ausgeführt worden sind. Unter den oben genannten Bedingungen sind die Änderungen nach

20 20 KAPITEL 2. GRUNDLAGEN Abschließen der Schreiboperation jedoch auf jeden Fall für alle Leseoperationen sichtbar und aufgrund letztendlicher Konsistenz ist auch die Reihenfolge sichergestellt. 2.7 Operationen Jede Operation wird vom Client an einen Koordinator-Knoten geschickt, welcher sie an die zuständigen Knoten weiterleitet. Prinzipiell kann dies jeder Knoten im Datenspeicher sein. Aufgrund der geringeren Latenz 5 bei der Kommunikation ist es idealerweise ein Knoten, welcher topologisch nah am Client ist. Um die Laufzeit klein zu halten, verwendet man typischerweise einen Knoten im gleichen Rack oder zumindest im gleichen Datenzentrum. Da sich die Latenz zwischen einem Client und dem Koordinator-Knoten meist in einer ähnlichen Größenordnung befindet wie die Latenz zwischen Koordinator-Knoten und einem Daten-Knoten, wurde die Funktionalität zum Verbinden mit den zuständigen Knoten in Amazon Dynamo in die Clients verlagert [vgl. 12, S.217f]. So spart man sich bei der Kommunikation zwischen Client und Knoten einen Hop im Netzwerk und halbiert die Latenz der Kommunikation. Direkte Kommunikation mit den Daten-Knoten ohne Koordinator-Knoten ist in Cassandra nur in einem Javaclient verfügbar und wird kaum verwendet. Cassandra Clients verwenden das Thrift-Protokoll[3], um Operationen über das Netzwerk auszuführen. Dabei handelt es sich um ein RPC-Protokoll 6, für welches Bindings in fast allen gängigen Sprachen existieren. Es gibt ein externes RPC-Interface, welches von Clients aufgerufen und vom Koordinator-Knoten bereitgestellt wird. Zwischen Koordinator-Knoten und Daten-Knoten gibt es ein weiteres Interface, welches nur primitive Speicheroperationen ermöglicht und intern vom Koordinator-Knoten benutzt wird. Bei jeder Operation kann der Client über den Parameter consistency level angeben, auf wie viele Knoten direkt gelesen bzw. geschrieben werden soll. Damit kann eine Entscheidung zwischen mehr Konsistenz oder mehr Geschwindigkeit getroffen werden. Der Koordinator-Knoten sucht anhand der Hashfunktion die für den Schlüssel zuständigen Knoten und verbindet sich mit ihnen. Alle Opera- 5 Zeit zwischen dem Absenden eine Anfrage und der Ankunft der Antwort 6 Remote Procedure Call; ermöglicht einen transparenten Methodenaufruf über das Netzwerk

21 2.7. OPERATIONEN 21 tionen sind nur innerhalb eines Datensatzes innerhalb einer ColumnFamily oder SuperColumnFamily atomar. Datensatz mit key k Client Koordinator Knoten N=3 Knoten 1 Knoten 2 Knoten 3 Abbildung 2.5: Ablauf einer Schreiboperation Bei schreibenden Operationen werden die Daten direkt an die verbundenen, zuständigen Knoten gesendet und später asynchron auf die restlichen, zuständigen Knoten repliziert. Bei lesenden Operationen wird ein zuständiger Knoten nach den jeweils aktuellen Timestamps zu den angefragten Attributen eines Datensatzes zu einem Schlüssel gefragt und gleichzeitig eine Digest-Anfrage 7 an alle verbundenen zuständigen Knoten gestellt, um festzustellen, ob ein anderer Knoten ein Attribut mit neuerem Timestamp besitzt. Dabei antworten alle Knoten mit dem Timestamp ihrer aktuellen Version. Gibt es eine neuere Version als die vorhandene, wird diese geholt und die vorherige verworfen. Danach wird die aktuellere Version vom Koordinator-Knoten an alle anderen Knoten geschickt, die nicht das aktuellste Timestamp geliefert haben. So werden mögliche fehlende Daten beim Lesen repariert. Aufgrund dieser relativ aufwändigen Kommunikation und eines Speicherformats, welches Schreiben in konstanter Zeit und Lesen in logarithmischer Zeit ermöglicht, sind Leseoperationen teurer als Schreiboperationen. Wichtige Datenstrukturen für die Leseoperationen (Siehe Anhang B): ColumnPath - Gibt einen Pfad zu einem einzelnen Attribut column einer ColumnFamily oder einer einzelnen SuperColumn einer SuperColumnFamily 7 Digest=Übersicht

22 22 KAPITEL 2. GRUNDLAGEN super column innerhalb einer ColumnFamily column family an. ColumnParent - Gibt eine ColumnFamily column family und optional eine SuperColumn super column an. Wird verwendet um alle oder einige Attribute innerhalb einer Column- oder SuperColumnFamily zu beschreiben. Column - Enthält Name name, Wert value und Timestamp clock eines Attributes. SuperColumn - Beinhaltet eine SuperColumn einer SuperColumnFamily mit dem Namen name und einer Liste von Attributen columns vom Typ Column. ColumnOrSuperColumn - Repräsentiert ein Attribut Column oder eine SuperColumn ConsistencyLevel - Ein ENUM 8 mit den Werten aus Abschnitt 2.6. SliceRange - Beschreibt einen Bereich an Schlüsseln oder Attributnamen. Mit start und finish werden die Grenzen angegeben. Zusätzlich kann die Sortierung umgekehrt werden mit reversed oder die Anzahl an Datensätzen begrenzt werden mit count. SlicePredicate - Gibt einen Bereich mit slice range an oder eine Liste von Attributen mit slice range. Cassandra unterstützt folgende einfache Operationen: set keyspace(string keyspace) - Setzt den Keyspace keyspace für alle folgenden Operationen. get(binary key, ColumnPath column path, ConsistencyLevel consistency level) - Lesen eines Datensatzes über den Schlüssel key. Der Parameter column path gibt eine ColumnFamily und eine SuperColumn oder ein Attributnamen an. Die Operation gibt ein Objekt vom Typ ColumnOrSuperColumn zurück. 8 Enummeration; Aufzählungstyp mit endlichem Wertebereich

23 2.7. OPERATIONEN 23 get slice(binary key, ColumnParent column parent, SlicePredicate predicate, ConsistencyLevel consistency level) - Lesen eines Teiles eines Datensatzes über einen Schlüssel key. Der Parameter column parent gibt eine Column- Family an, in welcher alle Attribute, die mit dem Parameter predicate spezifiziert sind, zurückgegeben werden. Die Operation gibt eine Liste von ColumnOrSuperColumn Objekten zurück. get range slices(columnparent column parent, SlicePredicate predicate, SliceRange range, ConsistencyLevel consistency level) - Lesen mehrerer Datensätze oder Teile davon über einen Schlüsselbereich range. Funktioniert wie get slice. Zusätzlich ist es möglich mit dem Parameter range einen Schlüsselbereich anzugeben. Bereichsabfragen sind nur möglich, wenn als partitioner eine Hashfunktion gewählt wurde, welche die Reihenfolge der Schlüssel beibehält. Die Operation gibt eine Liste von ColumnOrSuperColumn Objekten zurück. multiget slice(list<binary> keys, ColumnParent column parent, SlicePredicate predicate, ConsistencyLevel consistency level) - Lesen mehrerer Datensätze oder Teile davon über einen Schlüssel key. Funktioniert ähnlich wie get range slices mit dem Unterschied, dass statt eines Schlüsselbereiches mit dem Parameter keys eine Liste an nicht zusammenhängenden Schlüsseln angegeben werden kann. Die Operation gibt eine Liste von ColumnOrSuper- Column Objekten zurück. get count(binary key, ColumnParent column parent, ConsistencyLevel consistency level) - Der Parameter column parent gibt eine ColumnFamily und optional eine SuperColumnFamily an. Dabei wird die Anzahl der Attribute in der Column- oder SuperColumnFamily gezählt, denen unter dem Schlüssel key ein Wert zugeordnet worden ist und die nicht zuvor gelöscht wurden. Die Operation gibt eine positive Ganzzahl zurück. insert(binary key, ColumnParent column parent, Column column, ConsistencyLevel consistency level) - Schreiben eines Attributes column mit einem Timestamp und einem Wert in die in column parent angegebene Column- Family oder SuperColumnFamily. remove(binary key, ColumnParent column path, Clock timestamp, Consisten-

24 24 KAPITEL 2. GRUNDLAGEN cylevel consistency level) - Löschen eines Datensatzes oder eines Attributes eines Datensatzes über seinen Schlüssel. batch mutate(map<string, Mutation> mutation map, ConsistencyLevel consistency level) - Modifizieren (Löschen oder Schreiben) mehrerer Datensätze über einen Schlüssel auf einmal. Der Parameter mutation map enthält eine Liste von insert- und/oder remove-operationen. Dadurch, dass mehrere Operationen auf einmal ausgeführt werden, wird die Gesamtzeit für die Ausführung geringer, da zwischen den Operationen nicht auf eine Rückgabe gewartet wird. Alle Operationen sind innerhalb eines Datensatzes atomar [14]. Schreibende Operationen können nicht fehlschlagen, solange eine Verbindung zu einem beliebigen Knoten hergestellt werden kann und das consistency level auf ANY oder ZERO gestellt ist (siehe Abschnitt 2.6). Alle Operationen und Datenstrukturen sind in der Datei interface/cassandra.thrift definiert (Siehe dazu Anhang B) Beispiele Um die Funktion der Operationen zu verdeutlichen, werden nun beispielhafte Operationen auf die Datensätze in Abbildung 2.6 ausgeführt. Als erstes wird mit set keyspace( MyUserApp ) der Keyspace gesetzt. MyUserApp Users a b c d age: 27 19:10 name: Hans 19:10 gender: m 19:20 age: 20 18:55 age: 24 08:00 name: Jan 01:33 gender: m 15:00 name: Udo 17:10 gender: m 17:30 Abbildung 2.6: Beispiel Datensätze gemäß Datenmodell von Cassandra

25 2.7. OPERATIONEN 25 insert( b, {column family = Users }, {name = age, value = 20, clock = 18:55 }, ONE) - Erstellen von Datensatz b. get( a, {column family = Users, column = age }, QUORUM) - Anfrage nach dem Attribut age unter dem Schlüssel a in der ColumnFamily Users. Gibt ein Objekt vom Typ ColumnOrSuperColumn zurück: {name = age, value = 27, clock = 19:10 }. get count( a, {column family = Users }, QUORUM) - Zählt die Anzahl an Attributen in Datensatz a. Gibt 3 zurück. get range slices({column family = Users }, {start = a, finish = h }, {start= a, finish= c }, ONE) - Fragt nach allen Datensätzen in der ColumnFamily Users mit den Schlüsseln zwischen a und c. Dabei werden die Attribute zwischen a und h abgefragt. Zurückgegeben wird die Liste: a => {{name = age, value = 27, clock = 19:10 }, {name = gender, value = m, clock = 19:20 }}, b => {{name = age, value = 20, clock = 18:55 }}, c => {{name = age, value = 24, clock = 08:00 }, {name = gender, value = m, clock = 15:00 }}

26 26 KAPITEL 2. GRUNDLAGEN

27 Kapitel 3 Konzept Die Zielsetzung der Arbeit ist es, Indexe auf dem verteilten Datenspeicher Cassandra zu implementieren. Dazu wird ein Konzept vorgestellt, welches besonders die Eigenheiten von Cassandra berücksichtigt. Dabei soll ein Verzeichnis aufgebaut werden, um effizient alle Datensätze mit bestimmten Attributwerten zu einem oder mehreren festen Attributnamen zu finden. Danach wird ein Speicherformat definiert. Weiterhin werden Veränderungen im Ablauf von schreibenden Operationen erklärt und Operationen beschrieben, die auf den Index lesen. 3.1 Übersicht Der nahe liegende Ansatz zum Aufbauen eines Indexes ist, beim Schreiben von neuen Datensätzen einen Eintrag in einem Verzeichnis einzufügen. Wird der Datensatz geändert, muss zuvor der alte Datensatz gelesen und der alte Eintrag im Verzeichnis entfernt werden. Danach wird ein neuer Eintrag erstellt. Leider ist dieser Ansatz nicht direkt geeignet, da weder Transaktionen noch Sperren von Datensätzen in Cassandra existieren und nur einzelne Operationen innerhalb eines einzelnen Datensatzes atomar sind. Es ist daher nicht möglich sicherzustellen, dass bei zwei gleichzeitig stattfindenden Änderungen an einem Datensatz keine Race Conditions bei der Indexaktualisierung auftreten, da nicht sicher entschieden werden kann, welches der aktuellste Datensatz ist. Beide Operationen könnten den gleichen älteren Datensatz lesen und beide den gleichen älteren Indexeintrag löschen. Danach würden beide einen neuen Indexeintrag schreiben. Dies ist ohne Sperren oder Transaktionen nicht zu verhindern. Als Folge wären zwei Indexein- 27

28 28 KAPITEL 3. KONZEPT träge zu einem Datensatz vorhanden und der Index dauerhaft inkonsistent. Es wäre nun möglich, Sperren in Cassandra zu implementieren. Allerdings widerspräche es der Philosophie von Cassandra, dass Schreibzugriffe niemals fehlschlagen und Leseoperationen eine lineare Laufzeit haben, da sie nun potentiell auf Sperren warten müssten. Transaktionen dagegen würden das Problem potentiell beheben. Leider sind sie in einem verteilten System nur sehr teuer zu implementieren und mit dem Konzept von letztendlicher Konsistenz nicht vereinbar. Wenn man nun davon ausgeht, dass weder Transaktionen noch Sperren verfüg-bar sind und Race Conditions wie oben gezeigt nicht hinnehmbar sind, wird eine Möglichkeit benötigt, um das Aktualisieren des Indexes atomar vorzunehmen. Aus diesem Grund ist es nicht möglich, den alten Datensatz vor der Änderung zu lesen, den alten Index zu löschen und danach den neuen Datensatz und den neuen Indexeintrag zu schreiben. Zusätzlich sind lesende Operationen aufgrund des Speicherformats von Cassandra teurer als schreibende Operationen. Aus diesem Grund könnte man nun das Entfernen des alten Indexeintrages unterlassen. Das hat natürlich zur Folge, dass der Index viel mehr Einträge enthält als es passende Datensätze gibt. Es wird also in Kauf genommen, dass veraltete Einträge im Index vorhanden sind. Um dieses Problem zu beseitigen, wird später beim Lesen vom Index die Korrektheit des Eintrages überprüft, indem das Timestamp des Indexeintrages mit dem Timestamp des indexierten Attributs des Datensatzes verglichen wird. Ist das Timestamp der Indexeintrages älter als das Timestamp des gefundenen indexierten Attributs, wird der Indexeintrag entfernt. Ist das Timestamp neuer so wird der Indexeintrag übersprungen, da der Datensatz wahrscheinlich noch nicht geschrieben wurde. Sind die Timestamps gleich ist der Eintrag korrekt und der Datensatz wird zurückgegeben. 3.2 Index-Speicherformat Der Index wird intern als ColumnFamily mit der angegebenen Vergleichsfunktion im gleichen Keyspace wie die indexierten Datensätze definiert. Der Schlüssel eines indexierten Datensatzes wird als Attributname mit dem Timestamp des Datensatzes und leerem Wert in der ColumnFamily des Indexschlüssels gespeichert. Der Index ist damit wie jeder normale Datensatz verteilt über alle Knoten von

29 3.2. INDEX-SPEICHERFORMAT 29 Cassandra gespeichert. MyUserApp Users a b c age: 27 19:10 name: Hans 19:10 gender: m 19:20 age: 20 18:55 age: 27 13:10 UsersAgeIndex b: 18:55 a: c: 19:10 13:10 Abbildung 3.1: Speicherformat eines Indexes In Beispiel 3.1 werden drei Benutzer in der ColumnFamily Users gespeichert. Es gibt einen Index über das Attribut mit dem Namen age. Der Index wird in der ColumnFamily UsersAgeIndex gespeichert. Zum Wert 27 des Attributes mit dem Namen age gibt es zwei Attribute mit jeweils leerem Wert. Dabei entspricht der Attributname dem Datensatz, auf den referenziert wird, im Beispiel also die Datensätze mit den Schlüsseln a und c. Analog zeigt der Wert 20 auf den Datensatz mit dem Schlüssel b. Dabei ist zu beachten, dass die Timestamps der Indexeinträge und der Datensätze übereinstimmen. Bei Attributkombinationen gäbe es theoretisch mehrere Timestamps, jedoch wird beim Schreiben sichergestellt, dass immer auf alle Indexattribute gleichzeitig geschrieben wird. Daher haben in diesem Fall alle Attribute das gleiche Timestamp und es muss nur das Timestamp eines Attributs überprüft werden. Allerdings ist es dazu wichtig, dass wie in Abschnitt 3.5 beschrieben, alle Schreiboperationen, welche nicht alle Attribute eines zusammengesetzten Indexes enthalten, abgelehnt werden.

30 30 KAPITEL 3. KONZEPT 3.3 Korrektheit Elementare Voraussetzung für eine Indeximplementierung ist, dass nach konkurrierenden Lese- und Schreiboperationen letztendlich ein konsistenter Zustand eintritt. Dazu muss zu jedem Datensatz mit vorhandenem Indexattribut genau ein Indexeintrag vorhanden sein. Da alle Datensätze nur letztendlich konsistent sind und Indexeinträge erst beim Lesen gelöscht werden, muss sichergestellt werden, dass nur Indexeinträge gelöscht werden zu denen auf keinen Fall noch ein Datensatz existieren kann. Wir zu einem Indexeintrag nicht der korrekte Datensatz gefunden, wird er übersprugen und es gilt zu prüfen, ob der Indexeintrag gelöscht werden kann, um die Überprüfung beim nächsten Lesezugriff nicht erneut durchführen zu müssen. Es gibt drei verschiedene Fälle: Der referenzierte Datensatz wurde nicht gefunden. Dabei kann es sein, dass bisher nur der Indexeintrag, aber der Datensatz noch nicht geschrieben wurde. Alternativ kann auch der Datensatz gelöscht worden sein. Da beide Fälle nicht unterschieden werden können, muss so lang gewartet werden bis ausgeschlossen werden kann, dass der Datensatz geschrieben wurde. In der Regel sollte hier eine Zeit von einem Tag verwendet werden. Der gefundene Datensatz hat ein älteres Timestamp als der Indexeintrag. Es kann davon ausgegangen werden, dass der Datensatz noch nicht geschrieben wurde und es muss gewartet werden. Der gefundene Datensatz hat ein neueres Timestamp als der Indexeintrag. In diesem Fall kann der Indexeintrag sofort gelöscht werden, da das Timestamp eines Datensatzes unter keinen Umständen wieder älter werden kann. Um ein potentielles Problem zu demonstrieren, werden im Sequenzdiagramm 3.2 gleichzeitig eine Lese- und eine Schreiboperation auf die Datensätze in Abbildung 3.3 ausgeführt. Die schwarzen Datensätze stellen die Ausgangssituation dar. Im Verlauf wird ein Indexeintrag von Client2 gelesen, bevor der Datensatz zum Indexeintrag von Client1 geschrieben wurde. Beide Clients verwenden jeweils einen eigenen Koordinator-Knoten, welche mit Cassandra1 und Cassandra2 gekennzeichnet sind. Client1 ändert im Datensatz a das indexierte Attribut age auf 20. Zuerst wird vom Koordinator-Knoten Cassandra1 ein Indexeintrag erstellt, der für den

31 3.3. KORREKTHEIT 31 : Client1 : Client2 : Cassandra1 : Cassandra2 : Cassandra Backend : Schreibe a mit age=20 : Schreibe Index von 20=a : Lese age=20 : Lese Index von 20 : Lese a : Lösche a in Index von 20 : Schreibe a Abbildung 3.2: Race Condition beim Indexschreiben/-lesen MyUserApp Users a b c 2. age: 27 19: :00 name: Hans 19:10 gender: m 19:20 age: 20 18:55 age: 27 13:10 UsersAgeIndex 20 b: 18:55 a: 20: a: 19:10 c: 13:10 Abbildung 3.3: Datensätze für Race Condition Beispiel

32 32 KAPITEL 3. KONZEPT Wert 20 auf den Schlüssel a des Datensatzes verweist (siehe 1. in Abbildung 3.3). Zu diesem Zeitpunkt wurde der Wert und das Timestamp des Attributs age im Datensatz a noch nicht geändert. Gleichzeitig liest Client2 alles Datensätze zum Wert 20 vom Index. Cassandra liest alle Indexeinträge und versucht den zugehörigen Datensatz zu lesen. Leider existiert für den von Client1 geschriebenen Indexeintrag im Datensatz a zum Attribut age ein älteres Timestamp. Es gilt an dieser Stelle zu überprüfen, ob der Indexeintrag gelöscht werden kann. Laut der obigen Liste muss gewartet werden. Würde man nicht warten und den Indexeintrag wie im Beispiel löschen, obwohl Client1 den Datensatz später noch schreibt, gäbe es keinen Indexeintrag mehr zum Datensatz a und der Index wäre nicht mehr korrekt. Aus diesem Grund ist es unerlässlich das Löschen von Indexeinträgen abhängig vom Timestamp erst nach längerer Zeit vorzunehmen, damit der Index unter allen Umständen korrekt bleibt. 3.4 Index definieren Als nächstes wird beschrieben, welche Informationen notwendig sind um ein Index auf einer ColumnFamily zu definieren. Alle ColumnFamilies werden in der Konfigurationsdatei cassandra.yaml definiert oder alternativ beim Start aus dem System-Keyspace geladen. Beide sollen nun um einen Elementtyp für Indexe erweitert werden. Das Element soll folgende Attribute enthalten: name - Muss ein im Keyspace eindeutiger Name für den Index sein. index type - Gibt den Namen der Indeximplementierung an, die verwendet werden soll. compare with - Die Vergleichsfunktion gibt die Verteilung der Indexdatensätze über Knoten und Festplatten an und ist für Bereichsabfragen über den Index wichtig. Entspricht den Vergleichsfunktionen auf ColumnFamilies. keys - Liste mit Attributnamen die indexiert werden sollen Außerdem sollen beliebige Elemente als Optionen möglich sein, welche von der konkreten Indeximplementierung ausgewertet werden. Die Indeximplementierung in index type wird bei jedem Schreibzugriff auf die ColumnFamily sowie bei allen

33 3.5. INDEX AKTUALISIEREN 33 Lesezugriffen auf den Index aufgerufen. Die Vergleichsfunktion compare with gibt die Verteilung der Indexdatensätze über Knoten und Festplatten an. 3.5 Index aktualisieren Wenn auf einer ColumnFamily Indexe definiert sind, muss bei jedem Schreibzugriff überprüft werden, ob die Indexe aktualisiert werden müssen. Da jeder Schreibzugriff zuerst an einen beliebigen Koordinator-Knoten geschickt wird, bietet es sich an, die Indexaktualisierung auf diesem Knoten auszuführen. Für jeden Index muss in der Indeximplementierung überprüft werden, ob eine Aktualisierung notwendig ist und sie gegebenen Falles durchgeführt werden. Knoten 7 Knoten 8 Knoten 9 Index 1. Client N=3 Koordinator Knoten 2. Knoten 1 Knoten 2 Knoten 3 Data Abbildung 3.4: Ablauf einer Schreiboperation mit Indexaktualisierung In der konkreten Implementierungsidee dieser Arbeit (siehe Abschnitt 3.1) muss lediglich überprüft werden, ob der Schreibzugriff auf alle der vorher definierten Indexattribute schreibt und die entsprechenden Indexeinträge erstellen. Sollte sich der Schreibzugriff nur auf einige Attribute eines Indexes erstrecken, wird die Schreiboperation abgelehnt, da es notwendig wäre, alle fehlenden Attribute zu lesen. Weil nicht sichergestellt werden kann, welches der aktuelle Datensatz ist, da der Zugriff nicht atomar erfolgen kann, ist dies nicht lösbar (siehe Abschnitt 2.6). Es ist daher zwingend nötig, bei Änderungen der Indexattribute immer auf alle Attribute zu schreiben, selbst wenn sich nur ein einziges ändert. Dieses Problem

34 34 KAPITEL 3. KONZEPT tritt nur bei Indexen über mehrere Attribute auf. Eigentlich widerspricht das Ablehnen einer Schreiboperation der Philosophie von Cassandra, jedoch ist diese Schreiboperation in diesem Fall als ungültig zu werten, da sie die Integrität eines Indexes dauerhaft zerstören würde. Als Folge muss ein Anwendung immer alle indexierten Attribute lesen, um sie dann wieder schreiben zu können. Sind nun die Werte aller Attribute vorhanden, so wird daraus ein Schlüssel für den verteilten Index generiert und es wird der Indexeintrag geschrieben (siehe Abbildung 3.4). Erst wenn die Schreiboperation auf den Indexeintrag abgeschlossen ist, kann der Datensatz selber geschrieben werden. Es ist also die doppelte Latenz beim Schreiben zu erwarten. Trotzdem wird sichergestellt, dass sowohl der Indexdatensatz als auch der indexierte Datensatz das gleiche Timestamp erhalten und letztendliche Konsistenz erreicht wird. 3.6 Index abfragen Im Gegensatz zu Anfragen an relationale Datenbanksysteme müssen in Cassandra Anfragen vom Benutzer explizit gegen einen Index gestellt werden, da die vorhandenen Operationen (Siehe Abschnitt 2.7) nur Zugriffe über den Schlüssel eines Datensatzes erlauben. Wie bei normalen Datensätzen gesehen, wird es auch bei Indexabfragen möglich sein Abfragen auf einen Wert, mehrere Werte oder einen Bereich von Werten durchzuführen. Dazu werden später in Kapitel 4 konkrete neue Operationen vorgestellt. Um Datensätze in einem Index abzufragen, wird wie beim Schreiben aus den Werten der indexierten Attribute ein Indexschlüssel berechnet. Damit werden alle Indexeinträge zu diesem Schlüssel gelesen. Das geschieht mit den aus Abschnitt 2.7 bekannten Operationen. Durch die gemachten Einschränkungen beim Schreiben müssen alle Indexeinträge beim Lesen auf ihre Aktualität überprüft werden. Dies geschieht durch eine Digest-Anfrage auf alle in einem Eintrag referenzierten Datensätze. Ist ein Datensatz zu einem Eintrag nicht zu finden oder ist das Timestamp des referenzierten Datensatzes nicht gleich dem Timestamp des Indexeintrages, wird der entsprechende Indexeintrag gelöscht und muss bei der nächsten Abfrage nicht wieder überprüft werden. Einzige Ausnahme von dieser Regel sind Indexeinträge, die noch sehr neu sind, da der Schreibvorgang des indexierten Datensatzes noch nicht abgeschlossen sein muss. Alle gefundenen