Das Dokument ist eine umfassende Präsentation über Apache Cassandra, eine verteilte, skalierbare und hochverfügbare NoSQL-Datenbank, die ursprünglich bei Facebook entwickelt wurde. Es behandelt wesentliche Konzepte wie Datenverteilung, Konsistenzmodelle, Replikationsstrategien sowie ein schemaloses Datenmodell und vergleicht die Leistung von Cassandra mit traditionellen relationalen Datenbanken wie MySQL. Die Präsentation betont die Vorteile von Cassandra in Bezug auf Verfügbarkeit und Skalierbarkeit, während auch die Herausforderungen im Umgang mit Konsistenz und Datenintegrität diskutiert werden.

1. NoSQL Deep Dive mit Cassandra
Kai Spichale
1
20.09.2011

2. NoSQL
20.09.2011 2 Tech Talk

3. NoSQL
Wide Column Stores /
Document Stores
Column Families
Graph Databases Key Value / Tupe Stores
20.09.2011 3 Tech Talk

4. Apache Cassandra - eine Definition
“Apache Cassandra is an open source, distributed, decentralized, elastically
scalable, highly available, fault-tolerant, tuneably consistent, column-oriented
database that bases its distribution design on Amazon’s Dynamo and its data
model on Google’s Bigtable. Created at Facebook, it is now used at some of the
most popular sites on the Web.”
Hewitt, Eben: Cassandra – The Definite Guide, S. 14
20.09.2011 4 Tech Talk

5. Agenda
► Key Features
► Projektgeschichte
► Verteilung mit DHT
► Konsistenz
► Replikatverteilung
► Datenmodell
► Client API
► Fazit
20.09.2011 5 Tech Talk

6. Key Features
► Verteilte, horizontal skalierbare Datenbank
► Symmetrisches Design
► Hochverfügbar
► Riesige Datenmenge (Petabytes)
► Flexible Partitionierung, Replikatverteilung
► Eventually consistent: ACID ist nicht immer notwendig
► Flexible Trade-offs zwischen Konsistenz und Performance
► Automated Provisioning (Seek Nodes)
► Erweiterbare Multi-Datacenter Unterstützung
► Schemaloses, strukturiertes Datenmodell
20.09.2011 6 Tech Talk

7. Key Features
► Verteilte, horizontal skalierbare Datenbank
► Symmetrisches Design
► Hochverfügbar
► Riesige Datenmenge (Petabytes)
► Flexible Partitionierung, Replikatverteilung
► Eventually consistent: ACID ist nicht immer notwendig
► Flexible Trade-offs zwischen Konsistenz und Performance
► Automated Provisioning (Seek Nodes)
► Erweiterbare Multi-Datacenter Unterstützung
► Schemaloses, strukturiertes Datenmodell
20.09.2011 7 Tech Talk

8. Projektgeschichte
► Ursprunglich von facebook entwickelt
► Projektbeginn 2007, seit 2008 Open Source
► Verwendung für Inbox Search:
> Benutzer können ihre Nachrichten nach Absendernamen oder anderen
Schlüsselwörtern durchsuchen
> In-house System zum Indexieren (invertierte Indizes) und Speichern der
Nachrichten
► Anforderung:
> kostengünstig (Commodity Server)
> inkrementell skalierbar
20.09.2011 8 Tech Talk

9. Verteilung mit DHT
► Ein Distributed Hash Table
(DHT) ist ein Klasse von
dezentralen verteilten
Systemen
► O(1) Knoten-Lookup
► P2P- Netzwerk
► Shared-nothing Architecture
► Daten werden möglichst ► Symmetrisches Design:
gleichmäßig auf die Knoten > Kein Single Point of
verteilt Failure
> Kein zentraler Controller
> Keine Master/Slaves
► Clients können sich mit
beliebigen Knoten verbinden
20.09.2011 9 Tech Talk

10. Verteilung mit DHT
Partitioner( RowKey ) = Token
Hosts Initial Token
A 0
B 4
C 8
D 12
E 16
F 20
G 24
H 28
20.09.2011 10 Tech Talk

11. Verteilung mit DHT
Partitioner( RowKey ) = Token
Hosts Initial Token [28,31] [0,3]
A 0
B 4
C 8 [24,27] [4,7]
D 12
E 16
F 20
G 24
H 28 [20,23] [8,11]
[16,19] [12,15]
20.09.2011 11 Tech Talk

12. Verteilung mit DHT
Partitioner( RowKey ) = Token
Hosts Initial Token [28,31] [0,3]
A 0
B 4
C 8 [24,27] [4,7]
D 12
E 16
F 20
G 24
H 28 [20,23] [8,11]
[16,19] [12,15]
Beispiel:
Partitioner( „Cassandra“ ) = 7
20.09.2011 12 Tech Talk

13. Verteilung mit DHT
Hosts Initial Token Hosts Initial Token
A 0 A 0
B 4 B 21267647932558653966460912964485513215
C 8 C 42535295865117307932921825928971026430
D 12 D 63802943797675961899382738893456539645
E 16 E 85070591730234615865843651857942052860
F 20 F 106338239662793269832304564822427566075
G 24 G 127605887595351923798765477786913079290
H 28 H 148873535527910577765226390751398592505
Tokens sind Integer von 0 bis 2^127
i * (2^127 / N ) für i = 0 .. N-1
z.B. Random Partitioner mit MD5
20.09.2011 13 Tech Talk

14. Verteilung mit DHT
► Verteilung der Daten im Cluster durch Partitioner
► Random Partitioner ( Consistent Hashing )
> Basiert auf MD5
> Implizites Load Balancing
► Order Preserving Partitioner
> Geeignet für Range Slices
> Evtl. ungleiche Verteilung der Daten im Cluster
► Weitere Implementierungen von org.apache.cassandra.dht.IPartitioner
20.09.2011 14 Tech Talk

15. CAP-Theorem
► CAP:
> Strong Consistency
> High Availability
> Partition Tolerance
► CAP-Theorem nach Eric Brewer besagt, dass ein verteiltes System nicht
gleichzeitig alle drei Anforderungen erfüllen kann, sondern höchstens zwei.
► Cassandra ist ein AP-System
20.09.2011 15 Tech Talk

16. CAP-Theorem
► CA-System:
> Jeder lebende Knoten, der Requests empfängt, sendet Responses
> Netzwerkpartitionen werden nicht berücksichtigt (Implementierungsdetail)
► CP-System:
> Kann bei Netzwerkpartitionen betrieben werden
> Knoten können absichtlich deaktiviert werden, um Konsistenz sicherzustellen
> Verfügbarkeit wird gegen Konsistenz eingetauscht
► AP-System:
> Verfügbar und tolerant gegenüber Partitionen
> Konsistenz kann nicht garantiert werden
20.09.2011 16 Tech Talk

17. CAP-Theorem
► B und C erhalten Request:
► CA:
> B kann antworten
> C wird blockiert
► CP:
> C kann antworten
> Lock von A wird aufgehoben
► AP:
> B und C können antworten
> Eventuell inkonsistente Daten
20.09.2011 17 Tech Talk

18. Konsistenz
► Vertikale vs. horizontale Skalierung
► ACID vs. BASE (basically available, soft state, eventually consistent)
► Eventually consistency
> Synch nach Berlin, asynch nach New York
> Kompromiss zugunsten Verfügbarkeit und Performance
► Cassandra unterstützt verschiedene Konsistenzstufen
20.09.2011 18 Tech Talk

19. Konsistenz
► Verschiedene Konsistenzstufen für Lese- und Schreiboperationen
► Wenn W + R > N, dann (fast) stark konsistent
Level Write Consistency
ZERO Asynchron, ohne Rückmeldung
ANY 1 Knoten (inkl. HintedHandoff Empfänger)
ONE 1 Knoten
QUORUM (N/2)+1 Knoten R+W>N
LOCAL_QUORUM Quorum im lokalen DC
EACH_QUORUM Quorum in allen DCs
ALL N Knoten
Level Read Consistency
ONE 1 Knoten
QUORUM (N/2)+1 Knoten R+W>N
LOCAL_QUORUM Quorum im lokalen DC
EACH_QUORUM Quorum in allen DCs
ALL N Knoten
20.09.2011 19 Tech Talk

20. Konsistenz
► Hinted Handoff: Bei Knotenausfall wird auf einem anderen Knoten ein Hint
hinterlassen, sodass die Schreiboperation nachgeholt werden kann
► Read Repair: Synchronisation aller Replikate (evtl. im Background)
► Anti Entropy: Vergleich der Replikate und Aktualisierung
20.09.2011 20 Tech Talk

21. Konsistenzprobleme beim Löschen
► Eventually consistent: Client liest möglicherweise ein Replikat, das noch nicht
alle Updates erhalten hat (bei niedriger Konsistenzstufe)
► Gleiches Problem beim Löschen
► Lösung:
> Nicht sofort Löschen, sondern mit Tombstones markieren
> Wenn GCGraceSeconds < Tombstone Alter, dann Löschen
► Konsequenz: Knoten dürfen nicht länger als GCGraceSeconds down sein!
20.09.2011 21 Tech Talk

22. Replikationsverteilung
► Variabler Replikationsfaktor bestimmt die Anzahl der Kopien im Cluster
► Strategien zur Verteilung der Replikate im Cluster:
> Simple Strategy
> Old Network Topology Strategy
> Network Topology Strategy
20.09.2011 22 Tech Talk

23. Replikationsverteilung
► Simple Strategy (Rack-unaware Strategy): Replikate werden auf nachfolgende
Knoten im Ring verteilt
► Datacenters und Racks werden nicht beachtet
► Standardstrategie
Data Center 1
Rack 1 Rack 2
Node 1 Node 5
Node 2 Node 6
Node 3 Node 7
Node 4 Node 8
20.09.2011 23 Tech Talk

24. Replikationsverteilung
► Old Network Topology Strategy (Rack-aware Strategy): Heuristik zur
Verteilung der Replikate auf verschiedenen Racks und Datacenters
► Rack-aware Snitch ist notwendig
► Höhere Verfügbarkeit
► Höhere Latenz
Data Center 1 Data Center 2
Rack 1 Rack 2 Rack 3 Rack 4
Node 1 Node 5 Node 1 Node 5
Node 2 Node 6 Node 2 Node 6
Node 3 Node 7 Node 3 Node 7
Node 4 Node 8 Node 4 Node 8
20.09.2011 24 Tech Talk

25. Replikationsverteilung
► Network Topology Strategy (Datacenter Shard Strategy): Für jedes DC kann
pro Keyspace die Anzahl der Replikate angegeben werden
► Verteilung auf verschiedene Racks innerhalb eines DCs (wenn möglich)
► Rack-ware Snitch ist notwendig
Data Center 1 Data Center 2
Rack 1 Rack 2 Rack 3 Rack 4
Node 1 Node 5 Node 1 Node 5
Node 2 Node 6 Node 2 Node 6
Node 3 Node 7 Node 3 Node 7
Node 4 Node 8 Node 4 Node 8
Konfiguration:
DC 1 hat 2 Replikate
20.09.2011 25 Tech Talk DC 2 hat 2 Replikate

26. Datenmodell
► Strukturiertes Datenmodell ohne Schema
► Mehr als nur Key-Value-Modell
► Besteht aus den Konzepten:
Cluster
Keyspace
Column Family
Row
SuperColumn
Column
20.09.2011 26 Tech Talk

27. Datenmodell
► Cluster > Keyspace > Column Family > Row > Column
Column
byte[] name
byte[] value
long timestamp
20.09.2011 27 Tech Talk

28. Datenmodell
► Cluster > Keyspace > Column Family > Row
Row
Key Key Key
Column Column Column
byte[] name byte[] name byte[] name
byte[] value byte[] value byte[] value
long timestamp long timestamp long timestamp
20.09.2011 28 Tech Talk

29. Datenmodell
► Cluster > Keyspace > Column Family
Column Family
Key Row
Key Key Key
Column Column Column
Key Row
Key Key
Column Column
Key Row
Key Key Key Key
Column Column Column Column
20.09.2011 29 Tech Talk

30. Datenmodell
• Cluster > Keyspace Keyspace
Column Family
Key Row
Column Column
Key Row
Column
Key Row
Column Column Column
Column Family
Row
Column Column Column
Row
Column Column
20.09.2011 30 Tech Talk

31. Datenmodell
► Cluster > Keyspace > Column Family > Row > SuperColumn
SuperColumn
Key Column
byte[] name
byte[] value
long timestamp
Key Column
byte[] name
byte[] value
long timestamp
20.09.2011 31 Tech Talk

32. Datenmodell
► Cluster > Keyspace > Column Family > Row
Row
Key Key
SuperColumn SuperColumn
Key Column Key Column
byte[] name byte[] name
byte[] value byte[] value
long timestamp long timestamp
Key Column
byte[] name
byte[] value
long timestamp
20.09.2011 32 Tech Talk

33. Datenmodell
Keyspace
► Cluster > Keyspace Column Family
Key Row
Column Column
Key Row
Column
Key Row
Column Column Column
Column Family
Row
SuperColumn SuperColumn
Column Column Column Column
Row
SuperColumn
Column Column Column
20.09.2011 33 Tech Talk

34. Datenmodellbeispiel
Column
name = "firstname"
value = "Kai"
Column
name = "lastname"
value = "Spichale"
20.09.2011 34 Tech Talk

35. Datenmodellbeispiel
SuperColumn
"firstname" Column
name = "firstname"
value = "Kai"
"lastname" Column
name = "lastname"
value = "Spichale"
20.09.2011 35 Tech Talk

36. Datenmodellbeispiel
Row
"user_name"
SuperColumn
"firstname" Column
name = "firstname"
value = "Kai"
"lastname" Column
name = "lastname"
value = "Spichale"
20.09.2011 36 Tech Talk

37. Datenmodellbeispiel
"user" Column Family
"42" Row
"user_name"
SuperColumn
"firstname" Column
name = "firstname"
value = "Kai"
"lastname" Column
name = "lastname"
value = "Spichale"
20.09.2011 37 Tech Talk

38. Datenmodellbeispiel – flexible Struktur
"user_name"
SuperColumn
"firstname" Column "firstname6" Column
name = "firstname" name = "firstname"
value = "Karl" value = "Jacob"
"firstname2" Column "firstname7" Column
name = "firstname" name = "firstname"
value = "Theodor" value = "Philipp"
"firstname3" Column "firstname8" Column
name = "firstname" name = "firstname"
value = "Maria" value = "Franz"
"firstname4" Column "firstname9" Column
name = "firstname" name = "firstname"
value = "Nikolaus" value = "Joseph"
"firstname5" Column "firstname10" Column
name = "firstname" name = "firstname"
value = "Johann" value = "Sylvester "
20.09.2011 38 Tech Talk

39. Cassandra vs. MySQL (50GB Daten)
► MySQL
> 300ms write
> 350ms read
► Cassandra
> 0.12ms write
> 15ms read
Quelle: http://www.odbms.org/download/cassandra.pdf, Zugriff 7.4.2011
20.09.2011 39 Tech Talk

40. Schreibvorgang
20.09.2011 40 Tech Talk

41. Schreibvorgang
► Client schickt Write Request zu beliebigen Knoten im Cluster
► Write Request wird sequentiell ins lokale Disk Commit Log geschrieben
► Partitioner bestimmt verantwortliche Knoten
► Verantwortliche Knoten erhalten Write Request und schreiben in lokales
Logdatei
► Memtables (Write-back Cache) werden aktualisiert
► Flush auf Festplatte in SSTable und SSTableIndex
► Eigenschaften:
> Kein Lesen, keine Suche, keine Locks
> Sequentieller Festplattenzugriff
> Atomare Vorgang für eine ColumnFamily
> „Always Writable“ (d.h. akzeptiert auch Write Requests bei partiellen Failure)
20.09.2011 41 Tech Talk

42. Lesevorgang
20.09.2011 42 Tech Talk

43. Lesevorgang
► Client schickt Read Request zu beliebigen Knoten im Cluster
► Partitioner bestimmt verantwortliche Knoten
► Warten auf R Antworten
► Warten auf N – R Antworten für Read Repair im Hintergrund
► Eigenschaften:
> Liest mehrere SSTables
> Langsamer als Schreiben
> Skaliert sehr gut
20.09.2011 43 Tech Talk

44. Client API
► „The API is horrible and it produces pointless verbose code in addition to
being utterly confusing.“
► „The RCP interface is baroque, and too tightly coupled to Cassandra‘s
internals.“
20.09.2011 44 Tech Talk

45. Client API
► Cassandra:
> Thrift-Interface bietet für viele Sprachen (Python, Ruby, Java, PHP) die API
> RPC framework
> CQL ab Version 0.8 (SQL-like)
► Aber besser sind high-level Client Libraries:
> Java: Pelops, Hector
> Python: Pycassa
> Ruby: Cassandra
► Object Mapper:
> Kundera: JPA 1.0 Implementierung für Cassandra
> Hector: nicht JPA-compliant, kein Entity Relationship Support
20.09.2011 45 Tech Talk

46. Hector
► High-level Cassandra Client
► Open Source: https://github.com/rantav/hector
► Queries:
> Ein Request bezieht sich auf einen Keyspace und eine ColumnFamily
> Einfache Requests mit ColumnQuery / SuperColumnQuery
> *SliceQuery zur Abfrage von Columns, SuperColumns und Sub-Columns
– Column Range
– Row Range
► Sekundärer Index:
> Abfragen mit IndexedSlicesQuery
20.09.2011 46 Tech Talk

47. Hector – ein Beispiel
Cluster myCluster = HFactory.getOrCreateCluster("MyCluster",
"192.168.178.37:9160");
Keyspace keyspace = HFactory.createKeyspace("MyKeyspace",
myCluster);
StringSerializer se = StringSerializer.get();
20.09.2011 47 Tech Talk

48. Hector – ein Beispiel
List<HColumn<String, String>> subColumns = new
ArrayList<HColumn<String, String>>();
subColumns.add(HFactory.createColumn("firstname", "Kai", se, se));
subColumns.add(HFactory.createColumn("lastname", "Spichale", se, se));
HSuperColumn<String, String, String> superColumn = HFactory
.createSuperColumn("UserName", subColumns, se, se, se);
Mutator<String> mutator = HFactory.createMutator(keyspace, se);
mutator.insert("rowKey1", "User", superColumn);
20.09.2011 48 Tech Talk

49. Hector – ein Beispiel
SuperColumnQuery<String, String, String, String> query = HFactory
.createSuperColumnQuery(keyspace, se, se, se, se);
QueryResult<HSuperColumn<String, String, String>> queryResult = query
.setColumnFamily("User").setKey("rowKey1")
.setSuperName("UserName");
queryResult.execute();
HSuperColumn<String, String, String> hSuperColumn = queryResult.get();
20.09.2011 49 Tech Talk

50. Einschränkungen
► Keine Joins
► Kein ORDERED BY, GROUP BY, LIKE
► Kein kaskadierendes Löschen
► Keine referenzielle Integrität
► Konsequenzen für Datenmodellentwurf
> Bereits beim Entwurf des Datenmodells müssen alle Abfragen identifiziert
sein
> Zusätzliche Abfragepfade können schwer hinzugefügt werden
> Denormalisierung, sodass jeder Request mit einer oder mehreren Zeilen
einer ColumnFamily beantwortet werden kann
> Client macht Joins
20.09.2011 50 Tech Talk

51. Column Comparators
► Bytes
► UTF 8
► TimeUUID
► Long
► LexicalUUID
► Composite (third-party)
20.09.2011 51 Tech Talk

52. Fazit
► Hochskalierbare Datenbank, kann riesige Datenmengen speichern
► Einfache Administration
► Gewöhnungsbedürftiges Modell
► Eventually Consistent
► Keine Standard-Client-Library
► API-Veränderungen
► Upgrade
20.09.2011 52 Tech Talk

53. Vielen Dank für Ihre Aufmerksamkeit!
Fragen?
20.09.2011 53 Tech Talk