Big Data & NoSQL
0 gefällt mir1,300 aufrufe
Das Dokument behandelt die Skalierung und Leistung von NoSQL-Datenbanken, insbesondere RavenDB, sowie die Herausforderungen und Strategien im Umgang mit großen Datenmengen. Es wird das CAP-Theorem erläutert, das die Eigenschaften Konsistenz, Verfügbarkeit und Partitionstoleranz in verteilten Systemen beschreibt, und es werden verschiedene Methoden wie Sharding und Federation zur Datenverteilung vorgestellt. Zudem werden spezifische Einschränkungen und Vorteile von SQL Azure und Azure Table Storage besprochen.
Big Data & NoSQL
- 1. RavenDB, schnell und skalierbar Big Data & NoSQL, Aydin Mir Mohammadi bluehands GmbH & Co.mmunication KG [email protected]
- 2. Immer mehr… Mehr Performance Mehr Menge Mehr Verfügbarkeit
- 3. Skalierung http://www.flickr.com/photos/39901968@N04/4864698533/ Vertikale Skalierung Horizontale Skalierung
- 4. Skalierung Vertikale Skalierung ist einfacher • Multi-Threading • Cores, Speicher und IO ausnutzen • Wird sehr schnell sehr teuer • Hohes Potential, um klassische Anforderungen (ACID) gerecht zu werden
- 5. Am Ende hängt es an den Daten Klassische Datenbanken skalieren nicht Binsenweisheit
- 6. RDBMS: Performance no. clients 3 Instances 5.00 4.00 3.00 2.00 1.00 0.00 12 Instances 5.00 4.00 3.00 2.00 1.00 0.00
- 7. RDBMS: Performance no. clients 2.00 1.80 1.60 1.40 1.20 1.00 0.80 0.60 0.40 0.20 0.00 1 3 6 12
- 8. Man muss die Daten „verteilen“ Willkommen in der Hölle Binsenweisheit
- 9. CAP-Theorem Betrifft ein System mit verteilten Daten. Betrachtet folgende Eigenschaften • Consistency: Alle sehen gleichzeitig das gleiche • Availability: Alle können lesen & schreiben • Partition Tolerance: Ausfall eines Knotens führt nicht zum Ausfall des Systems
- 10. CAP-Theorem: Wähle 2 aus 3 ACID oder Consitency eventualy Consistent Antwort Verhalten Partion Availabilty Tolerance
- 11. CAP-Theorem: Beispiele Oracle Cluster (RAC) • Kein CAP-Theorem, da nicht verteilt Datenbank Mirroring (Log-Shipping) • Synchrone Commits: CA • Asynchrone Commits & Sync: AP Partitionierung • Sharding & Federation: CA
- 12. Sql Azur
- 13. RDBMS: Sql-Azure Sql-Server in Azure Immer drei Knoten • 1 Primary, 2 Standby • 1 Sync commit, 1 async commit Funktional eingeschränkt • Kein Xml • Kein CLR • Kein OleDB (not supported) It just works
- 14. DBMS: Sql-Azure Latenz beachten Licht braucht 1,8 ms Sql Ping ca. 15 ms
- 15. Sharding Für Join und ref. Integrität müssen Mütter verteilt werden. Storage Mutter Mutter Mutter Storage Kind Mutter Mutter Mutter Kind Storage Mutter Mutter Mutter Kind Geeignete Aufteilung finden
- 16. Sql-Azure: Skalierung (CA) Manuelles Sharding • Daten werden auf mehrere Knoten verteilt. Zugriff wird im Client gesteuert. Sql Azure Federation • Eingebautes Sharding. Zugriff wird im Server gesteuert, jedoch nicht transparent.
- 17. Federation Limits • Keine Transaktionen über shards. Verteilte Transaktionen sind in Sql-Azure nicht supported • Kein Auto-Increment Vorteile gegenüber manuelles Sharding • Online Split, Management • Datenbank kennt die Verteilung. Shard kann abgefragt werden
- 18. Federation Federation „key“ überlegen • Über welche Eigenschaft einer Tabelle wird verteilt Federations erstellen • Man kann die einzelnen Shards immer wieder splitten Sql-Statements anpassen • Vor jedem Statement: Use Federation xxx (key=value),with filtering=off, reset
- 20. Table-Storage Schemalos. Partitioniert. Jede Partition kann auf eine andere Maschine gehalten werden. Jede Entität hat ein PartitionKey und ein RowKey Versionierung über Timestamp
- 21. Table-Storage: How to use Queries nur auf RowKey und PartionKey mit „=„ • Table-Storage ist eine Hash-Table. • Alle andere Operationen machen einen Full- Scan. • Evtl. PartitionKey und danach Properties Limits beachten • 64k pro Eigenschaft, 1 MB pro Entität • 5000/sec auf Account und 500/sec auf Partition
- 22. Table-Storage: How to use Komplizierte denormalisierte Objekte • Z.B.: Profile, Settings • Eher statische Entitäten Vorberechnete Sichten. Daten werden je nach Anwendung vorbereitet. • In RDBMS: Mehrere Clustered Indizes
- 24. Blob-Storage „Filesystem“ in der Cloud Content ist von überall abrufbar Über http als Ressource einbinden
- 25. Query
- 26. Map-Reduce Idee • Query in kleine Teile aufteilen • Auf viele Knoten ausführen Voraussetzung • Code und Daten sind nah • D.h. Map-Reduce auf einer zentralen DB macht in der Regel keinen Sinn
- 27. Map-Reduce In Linq • map --> Enumerable.Select • reduce --> Enumerable.Aggregate Mehrere Implementierungen (deprecated) • DryadLINQ • Daytona Hadoop