1. RavenDB, schnell und skalierbar
Big Data & NoSQL,
Aydin Mir Mohammadi
bluehands GmbH & Co.mmunication KG
am@bluehands.de

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

19. Azure Table Storage

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

23. Azure Blob Storage

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