Algorithmen. Consistent Hashing Bloom Filter MapReduce. Distributed Hash Tables. Einführung 1

Transkript

1 Algorithmen Consistent Hashing Bloom Filter MapReduce Distributed Hash Tables Einführung 1

2 Consistent Hashing Problem: Wie finde ich den Speicherort für ein Objekt in einem verteilten System mit n Knoten? Z.B. bei Caches, (NoSQL) DBs, verteilte Filesysteme, Naive/klassische Lösung: hash (Objekt) mod n Funktioniert gut wenn n konstant ist wenn nicht (durch Ausfall oder Scale Out) Funktioniert gut wenn alle Server gleich dimensioniert sind Publikumsfrage Wie viele Hashes/Keys werden bei einem Ausfall ungültig? Einführung 2

3 Consistent Hashing S 0 Knoten werden im Adressraum/Hashtabelle (0..S) angeordnet (z.b. durch Hashen der IP) Objekte werden mit der gleichen Hashfunktion gehashed Der Zuständige Knoten ist der mit dem nächsthöheren Hashwert (im Uhrzeigersinn der nächste) Knoten werden mehrfach virtualisiert im Ring angeordnet (z.b durch Hash ( IP1-1 ), Hash ( IP1-2 ), ) Anzahl der virtuellen Punkte pro Knoten kann auch anhand der Leistungsstärke variiert werden Anordnung kann auch anhand von Partitionen erfolgen Hash (IP1) Hash (IP3) Hash (obj 1) Hash (obj 2) Hash (IP2) Einführung 3

4 Consistent Hashing Gleichmäßige Verteilung der Last wenn sich die Anzahl der Knoten ändert Publikumsfrage Wie viele Hashes/Keys werden bei einem Ausfall ungültig? Dynamische Anpassung der Last durch die Anzahl virtueller Punkte möglich => langsames Anfahren Redundanz / Replikation durch weitere Schreib Vorgänge beim nächsten, übernächsten etc. Knoten. Dadurch auch bereits gefüllter Cache möglich Einführung 4

5 Bloom Filter Suche nach einem Schlüssel in: Unsortierte Liste: Schlüssel ist vorhanden O(n/2) Schlüssel ist nicht vorhanden O(n) Sortierte Strukturen, Bäume, etc. - O(log n) Hash (ohne Kollisionen) O(1) Problem Skalierung: Hauptspeicher ist schnell aber endlich HD groß aber langsam BloomFilter: Schon 1970 von Burton H. Bloom für eine Rechtschreibprüfung Verwendet (k) Hash Funktionen auf Teile des Schlüssels O(k) Akzeptiert eine Wahrscheinlichkeit für False Positives Abhängig von der Wahrscheinlichkeit ist die Datenstruktur deutlich kleiner als eine Hashtabelle Wird z.b.: verwendet in: Squid, Cassandra, Hadoop, etc Einführung 5

6 Bloom Filter Quelle: Wikipedia - Einführung 6

7 Bloom Filter Beispiel Hashfunktion: h(n) = n mod m; m = 7 n n n mod e i s Test: sobald eine Position im Bitarray der k hashes 0 ist => Schlüssel nicht vorhanden Wenn alle 1 sind ist die Wahrscheinlichkeit p=füllgrad ^zahl der hashes dass der Schlüssel vorhanden ist Löschen nicht möglich (Lösung: counting bloom filter) Einführung 7

8 MapReduce Problem: Verarbeitung großer Datenmengen in einem verteilten System Hohe I/O Last Orchestrierung Konzept inspiriert aus der funktionalen Programmierung von Google als Framework/Programmiermodell zur verteilten Berechnung eingeführt Map/Reduce Verteilung / Steuerung der Jobs auf Prozesse/Worker im Cluster (Filesystem GFS/HDFS) Open Source Implementierungen Hadoop, Qt Concurrent Einführung 8

9 MapReduce MAP Schritt: Die Map Funktion wird für jedes key => value Paar einer Eingabeliste aufgerufen Ausgabe ist eine neue Abbildung key => Ergebniss Dieses wird als Zwischenergebnis vom Map Schritt gesammelt Reduce Schritt: Die Zwischenergebnisse werden der reduce Funktion übergeben die daraus eine Ergebnisliste berechnet/aggregiert Einführung 9

10 Map/Reduce Ablauf Mapper 1 Reducer 1 Daten Partitionierung/ Verteilung Mapper 2 Reducer..m Daten Mapper..n Einführung 10

11 MapReduce Beispiel Quelle: Wikipedia - Einführung 11

12 MapReduce Beispiel das ist das Haus vom Nikolaus der Nikolaus ist raus MAP Reduce das 1 das 2 ist 1 ist 2 das 1 Haus 1 Haus 1 Vom 1 vom 1 Nikolaus 2 Nikolaus 1 Raus 1 der 1 Nikolaus 1 ist 1 raus 1 Einführung 12

13 Wegweiser Scaling: wie kriegen wir die Cloud groß genug? Einführung 13

14 Scaling Dimensionen Scaling Storage Netzwerk Processing Filesystem DB RAM Einführung 14

15 Wegweiser DB Scaling Einführung 15

16 Umgang mit Relationalen DBMSs Siehe Einführung Scale-Up Scale-Out Normalisierung + De-Normalisierung! Sharding Dimensionen: Storage Zugriffe/Performance technische DB-Optimierung (z.b. Indizes, Caching) Einführung 16

17 Zoo an Alternativen aka NoSQL In Memory DBs: SAP HANA; memcached, extremedb Caches: memcached, redis Key-Value Stores: redis, Amazon Dynamo, Apache Cassandra Dokumenten DBs: Riak, CouchDB, MongoDB Graph DBs: InfoGrid, Neo4j Object DBs: ZopeDB, Gemstone Einführung 17

18 Häufige Eigenschaften Nomen est Omen keine SQL basierte Abfrage => aber bewegt sich in die Richtung Verzicht auf striktes ACID Eventual Consistent Einfache Skalierbarkeit durch Daten Verteilung / Sharding => siehe Consistent Hashing. Spezialisierter Use-Case Keine oder weniger strikte Schema Einführung 18

19 Apache Open Source, Ursprünglich Entwickelt von Facebook Viele Konzepte von Amazons Dynamo (der Core Entwickler von Cassandra hatte vorher Dynamo mitentwickelt) und Google BigTable Kommerzieller Support von DataStax Einführung 19

20 Cassandra Konzepte (1) Peer-to-Peer Modell - kein Master => Gossip Protokoll Automatische Replikation / Verteilung => Consistent Hashing Multi-Datacenter Support Tuneable Consistency Modell (per Operation) read repair Konflikt Auflösung Hohe Performance => r/w skaliert weitestgehend linear mit Anzahl der Knoten Hohe Verfügbarkeit => definierbarer Replikationsfaktor, Hinted Handoff Einführung 20

21 Cassandra Konzepte (2) Key-Value++ / Column Based Cassandra Query Language (CQL) Lightweight Transactions => PAXOS Map/Reduce support => Integration in Hadoop Einführung 21

22 Cassandra Tuneable Consistency Replikationsfaktor wird festgelegt Quorum = Replikationsfaktor / Verschiedene Konsistenzlevel (pro Operation wählbar) Konflikt Auflösung via Timestamp neuster gewinnt Lesend (Auswahl): ONE: Antwort des nächsten Knotens Quorum: Antwort mit aktuellstem Zeitstempel aus Quorum Knoten Local Quorum: wie Quorum aber nur aus einem Rechenzentrum ALL: Antwort mit aktuellstem Zeitstempel nach Abfrage aller Replika- Knoten Einführung 22

23 Cassandra Tuneable Consistency Schreibend (Auswahl): Any: Der Schreibzugriff muss persistiert sein (eventuell Lesen nicht möglich wenn die zuständigen Knoten nicht verfügbar => Hinted Handoff) ONE: Der Schreibzugriff muss einem zuständigen Knoten persistiert sein (ist danach lesbar) Quorum: der Schreibzugriff muss bei Quorum Knoten erfolgreich sein Local Quorum: wie Quorum nur 1 RZ All: der Schreibzugriff muss bei allen Replika-Knoten erfolgreich sein Publikumsfrage Beispiele für verschiedene Lese Schreibszenarien Einführung 23

24 Cassandra Datenmodell Bestimmt den zuständigen Knoten => Consistent Hashing Keyspace (=>Datenbank) Column Family (=>Tabelle ) Row Column Row Key: Name:Value Name:Value Name:Value Row Key: Row Der Inhalt der Row liegt linear auf der Platte Einführung 24

25 Cassandra Datenmodell Beispiele Keyspace: StudiDB Column Family: Student 123: Vorname:Paul Nachname: Muster Note:1plus 124: Vorname:Lisa create keyspace StudiDB; use StudiDB; create column family Student; set Student [ 123 ][ Vorname ] = paul set Student [ 123 ][ Nachname ] = Muster set Student [ 123 ][ Note ] = 1plus set Student [ 124 ][ Vorname ] = Lisa get Student[ 123 ] =>(colum-vorname, value=paul, timestamp=34324) =>(column-nachname=muster, timestamp=132423) =>(column get Student where note= 1plus Secondary Index muss gesetzt sein Einführung 25

26 Cassandra Randbedingungen Colums können hinten oder vorne hinzugefügt werden => implizite zeitliche Sortierreihenfolge möglich Löschen von Colums erzeugen Tombstones => z.b: Queues sind ein Anti-Pattern Schreibzugriffe schneller als Lesen (disk commit log => Memtable => DataFile (Sorted Strings Table) & SSTableIndex & Bloomfilter) Vorsicht bei secondary Indexen auf Columns Die Rows sind verteilt gespeichert Niedrige Kardinalität (viele Duplikate) von Vorteil Level:ANY Level:ONE Bei Hoher Kardinalität (und sehr kleine ausgeprägte Selektivität) zu hoher overhead => unnötige Anfragen an alle Knoten im Cluster Einführung 26