Tech Talk Cassandra

  • 1,501 views
Uploaded on

Dieser Vortrag führt in Apache Cassandra ein, eine NoSQL-Datenbank, die vor allem für große Datenmenge und hohe Skalierung geeignet ist. …

Dieser Vortrag führt in Apache Cassandra ein, eine NoSQL-Datenbank, die vor allem für große Datenmenge und hohe Skalierung geeignet ist.

Der Vortrag stammt aus einem adesso Tech Talk.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,501
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. NoSQL Deep Dive mit CassandraKai Spichale 120.09.2011
  • 2. NoSQL20.09.2011 2 Tech Talk
  • 3. NoSQL Wide Column Stores / Document Stores Column Families Graph Databases Key Value / Tupe Stores20.09.2011 3 Tech Talk
  • 4. Apache Cassandra - eine Definition“Apache Cassandra is an open source, distributed, decentralized, elasticallyscalable, highly available, fault-tolerant, tuneably consistent, column-orienteddatabase that bases its distribution design on Amazon’s Dynamo and its datamodel on Google’s Bigtable. Created at Facebook, it is now used at some of themost popular sites on the Web.” Hewitt, Eben: Cassandra – The Definite Guide, S. 1420.09.2011 4 Tech Talk
  • 5. Agenda► Key Features► Projektgeschichte► Verteilung mit DHT► Konsistenz► Replikatverteilung► Datenmodell► Client API► Fazit20.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 Datenmodell20.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 Datenmodell20.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 skalierbar20.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 DHTPartitioner( RowKey ) = TokenHosts Initial TokenA 0B 4C 8D 12E 16F 20G 24H 28 20.09.2011 10 Tech Talk
  • 11. Verteilung mit DHTPartitioner( RowKey ) = TokenHosts Initial Token [28,31] [0,3]A 0B 4C 8 [24,27] [4,7]D 12E 16F 20G 24H 28 [20,23] [8,11] [16,19] [12,15] 20.09.2011 11 Tech Talk
  • 12. Verteilung mit DHTPartitioner( RowKey ) = TokenHosts Initial Token [28,31] [0,3]A 0B 4C 8 [24,27] [4,7]D 12E 16F 20G 24H 28 [20,23] [8,11] [16,19] [12,15] Beispiel: Partitioner( „Cassandra“ ) = 7 20.09.2011 12 Tech Talk
  • 13. Verteilung mit DHTHosts Initial Token Hosts Initial TokenA 0 A 0B 4 B 21267647932558653966460912964485513215C 8 C 42535295865117307932921825928971026430D 12 D 63802943797675961899382738893456539645E 16 E 85070591730234615865843651857942052860F 20 F 106338239662793269832304564822427566075G 24 G 127605887595351923798765477786913079290H 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.IPartitioner20.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-System20.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 werden20.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 Daten20.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 Konsistenzstufen20.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 Knoten20.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 Aktualisierung20.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 Strategy20.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 820.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 820.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 Replikate20.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 Column20.09.2011 26 Tech Talk
  • 27. Datenmodell► Cluster > Keyspace > Column Family > Row > Column Column byte[] name byte[] value long timestamp20.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 timestamp20.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 Column20.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 Column20.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 timestamp20.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 timestamp20.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 Column20.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.201120.09.2011 39 Tech Talk
  • 40. Schreibvorgang20.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. Lesevorgang20.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 gut20.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 Support20.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 IndexedSlicesQuery20.09.2011 46 Tech Talk
  • 47. Hector – ein BeispielCluster 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 BeispielList<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 BeispielSuperColumnQuery<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 Joins20.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► Upgrade20.09.2011 52 Tech Talk
  • 53. Vielen Dank für Ihre Aufmerksamkeit! Fragen?20.09.2011 53 Tech Talk