• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Big Data & NoSQL
 

Big Data & NoSQL

on

  • 2,282 views

 

Statistics

Views

Total Views
2,282
Views on SlideShare
894
Embed Views
1,388

Actions

Likes
1
Downloads
0
Comments
0

13 Embeds 1,388

http://blogs.dotnetgerman.com 972
http://www.sascha-dittmann.de 201
http://cloudbloggers.de 164
http://feeds.feedburner.com 20
http://cloudblog.azurewebsites.net 13
http://95d20b5dcb88468f9b559777d8994d70.cloudapp.net 4
http://webcache.googleusercontent.com 4
http://arabic.ws 3
http://websitevalue.asso.in 2
http://sascha-dittmann.de 2
http://127.0.0.1 1
http://translate.googleusercontent.com 1
https://www.sascha-dittmann.de 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Big Data & NoSQL Big Data & NoSQL Presentation Transcript

    • 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 Horizontale Skalierung
    • 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
    • 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 5.00 4.00 3.00 2.00 1.00 0.00
    • 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 gleichzeitig das gleiche • Availability: Alle können lesen & schreiben • Partition Tolerance: Ausfall eines Knotens führt nicht zum Ausfall des Systems
    • CAP-Theorem: Wähle 2 aus 3 ACID oder Consitency eventualy Consistent Antwort Verhalten Partion Availabilty Tolerance
    • 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
    • Sql Azur
    • 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
    • DBMS: Sql-Azure  Latenz beachten  Licht braucht 1,8 ms  Sql Ping ca. 15 ms
    • 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
    • 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.
    • 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
    • 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
    • Azure Table Storage
    • 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
    • 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
    • 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
    • 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 nah • D.h. Map-Reduce auf einer zentralen DB macht in der Regel keinen Sinn
    • Map-Reduce In Linq • map --> Enumerable.Select • reduce --> Enumerable.Aggregate Mehrere Implementierungen (deprecated) • DryadLINQ • Daytona Hadoop