RavenDB, schnell und skalierbarBig Data & NoSQL,Aydin Mir Mohammadibluehands GmbH & Co.mmunication KGam@bluehands.de
Immer mehr…    Mehr Performance      Mehr Menge    Mehr Verfügbarkeit
Skalierung                         http://www.flickr.com/photos/39901968@N04/4864698533/  Vertikale Skalierung         Hor...
Skalierung Vertikale Skalierung ist einfacher  •   Multi-Threading  •   Cores, Speicher und IO ausnutzen  •   Wird sehr s...
Am Ende hängt es an den Daten   Klassische Datenbanken skalieren nichtBinsenweisheit
RDBMS: Performance no. clients           3 Instances5.004.003.002.001.000.00                                12 Instances  ...
RDBMS: Performance no. clients2.001.801.601.401.201.000.800.600.400.200.00       1        3        6          12
Man muss die Daten „verteilen“   Willkommen in der HölleBinsenweisheit
CAP-Theorem Betrifft ein System mit verteilten Daten. Betrachtet folgende Eigenschaften  • Consistency: Alle sehen gleic...
CAP-Theorem: Wähle 2 aus 3                                               ACID oder                           Consitency   ...
CAP-Theorem: Beispiele Oracle Cluster (RAC)  • Kein CAP-Theorem, da nicht verteilt Datenbank Mirroring (Log-Shipping)  •...
Sql Azur
RDBMS: Sql-Azure Sql-Server in Azure Immer drei Knoten  • 1 Primary, 2 Standby  • 1 Sync commit, 1 async commit Funktio...
DBMS: Sql-Azure                   Latenz beachten                   Licht braucht 1,8 ms                   Sql Ping ca....
Sharding                                    Für Join und ref.                                Integrität müssen Mütter     ...
Sql-Azure: Skalierung (CA) Manuelles Sharding  • Daten werden auf mehrere Knoten verteilt.    Zugriff wird im Client gest...
Federation Limits  • Keine Transaktionen über shards. Verteilte    Transaktionen sind in Sql-Azure nicht    supported  • ...
Federation Federation „key“ überlegen  • Über welche Eigenschaft einer Tabelle wird    verteilt Federations erstellen  •...
Azure Table Storage
Table-Storage Schemalos. Partitioniert. Jede Partition kann auf eine  andere Maschine gehalten werden. Jede Entität hat...
Table-Storage: How to use Queries nur auf RowKey und PartionKey  mit „=„  • Table-Storage ist eine Hash-Table.  • Alle an...
Table-Storage: How to use Komplizierte denormalisierte Objekte  • Z.B.: Profile, Settings  • Eher statische Entitäten Vo...
Azure Blob Storage
Blob-Storage „Filesystem“ in der Cloud Content ist von überall abrufbar Über http als Ressource einbinden
Query
Map-Reduce Idee  • Query in kleine Teile aufteilen  • Auf viele Knoten ausführen Voraussetzung  • Code und Daten sind na...
Map-Reduce In Linq  • map --> Enumerable.Select  • reduce --> Enumerable.Aggregate Mehrere Implementierungen (deprecated...
Nächste SlideShare
Wird geladen in …5
×

Big Data & NoSQL

2.609 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.609
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1.412
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Big Data & NoSQL

  1. 1. RavenDB, schnell und skalierbarBig Data & NoSQL,Aydin Mir Mohammadibluehands GmbH & Co.mmunication KGam@bluehands.de
  2. 2. Immer mehr… Mehr Performance Mehr Menge Mehr Verfügbarkeit
  3. 3. Skalierung http://www.flickr.com/photos/39901968@N04/4864698533/ Vertikale Skalierung Horizontale Skalierung
  4. 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. 5. Am Ende hängt es an den Daten Klassische Datenbanken skalieren nichtBinsenweisheit
  6. 6. RDBMS: Performance no. clients 3 Instances5.004.003.002.001.000.00 12 Instances 5.00 4.00 3.00 2.00 1.00 0.00
  7. 7. RDBMS: Performance no. clients2.001.801.601.401.201.000.800.600.400.200.00 1 3 6 12
  8. 8. Man muss die Daten „verteilen“ Willkommen in der HölleBinsenweisheit
  9. 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. 10. CAP-Theorem: Wähle 2 aus 3 ACID oder Consitency eventualy Consistent Antwort Verhalten Partion Availabilty Tolerance
  11. 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. 12. Sql Azur
  13. 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. 14. DBMS: Sql-Azure  Latenz beachten  Licht braucht 1,8 ms  Sql Ping ca. 15 ms
  15. 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. 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. 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. 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
  19. 19. Azure Table Storage
  20. 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. 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. 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
  23. 23. Azure Blob Storage
  24. 24. Blob-Storage „Filesystem“ in der Cloud Content ist von überall abrufbar Über http als Ressource einbinden
  25. 25. Query
  26. 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. 27. Map-Reduce In Linq • map --> Enumerable.Select • reduce --> Enumerable.Aggregate Mehrere Implementierungen (deprecated) • DryadLINQ • Daytona Hadoop

×