Big Data & NoSQL

  • 2,062 views
Uploaded on

 

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
No Downloads

Views

Total Views
2,062
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
1

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. RavenDB, schnell und skalierbarBig Data & NoSQL,Aydin Mir Mohammadibluehands GmbH & Co.mmunication KGam@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 nichtBinsenweisheit
  • 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. RDBMS: Performance no. clients2.001.801.601.401.201.000.800.600.400.200.00 1 3 6 12
  • 8. Man muss die Daten „verteilen“ Willkommen in der HölleBinsenweisheit
  • 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