Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

No Sql


Published on

Slides for my talk at Developer Konferenz

Published in: Technology

No Sql

  1. NoSQL An Introduction Internet Briefing Developer Konferenz, 7/4/2010 Michael Marth @michaelmarth |
  2. “NoSQL” ??? Product? Technology?
  3. “NoSQL” ??? Product? Technology? persistence Bunch of proje cts w ih share d interes t
  4. relational non-relational your requirements Not only SQL
  5. NoSQL Focus data models scalability
  6. NoSQL Focus ly? shard al ing Re read- slave vertic s al sc aling data models scalability
  7. NoSQL Focus what is scaling 1. Horizontal scale: scalability more ser vers crea capacity tes more 2. Trans parent t applicati o the on: the busin ess logic app shou of the ld be se from con parated cerns of server re scaling sources 3. No sin gle point no one s of failur erver wh e: lost, cau ich, if ses down the appl time of ication
  8. reme mber the ambrian E xplosion? C
  9. according to Column stores Key Value / Tuple Store Document stores Eventually Consistent Key Value Store Graph Databases XML Databases
  10. Column stores Key Value / Tuple Store Chordless Hadoop / HBase Berkeley DB Redis! Cassandra MemcacheDB Scalaris Hypertable Mnesia Tokyo Cabinet / Tyrant LightCloud GT.M HamsterDB Document stores Scalien Jackrabbit Riak Eventually Consistent CouchDB Terrastore MongoDB ThruDB Key Value Store Terrastore CloudKit Voldemort Dynomite a lm o KAI ope s t a l l n s o a re u rc e Graph Databases XML Databases Neo4J Mark Logic Server InfoGrid Sedna EMC Documentum xDB ! Sones Xindice Tamino HyperGraphDB Berkeley DB XML eXist
  11. Background check large contributions by web content management system vendor Day (Basel)
  12. Data Model stuc ture mandatory fields d field types schem allowed parents a etc. unst ruct ured look Ma, no schema! s schemales
  13. 1 Data First 2 Structure Structure First later (maybe)
  14. Data Model title: granular nosql date: 20/3/2010 binary
  15. Data Model granular binary 1 ordere d 2
  16. Data Model granular binary ordered node-level access control
  17. Data Model granular binary ordered node-level access control versioning
  18. The Sweet Spot web content
  19. Background check ideas and 1st implementations by ex-Notes developer
  20. Data Model Documents { schemaless “_id”: “abc”, “title”: “NoSQL”, JSON “tags”: [ binary attachments “data model”, “scalability” ], “_rev”: 1234 }
  21. Interface ODBC? JDBC? HTTP! + JSON
  22. Interface read GET /somedatabase/some_doc_id?rev=946B7D1C HTTP/1.0 write POST /somedatabase/ HTTP/1.0 Content-Length: 245 Content-Type: application/json { "Subject":"I like Plankton", "Author":"Rusty" } delete DELETE /somedatabase/some_doc?rev=1582603387 HTTP/1.0
  23. quer y “No SQL”, remember? meet “map-reduce”
  24. all documents results of map 1 map() reduce() 2 result 1 3 result 2 result of reduce result 3 parallel
  25. example: map-reduce { { "total_rows":2, id: “abc”, "offset":0, title: “nosql”, "rows": type: “talk” [ } function(doc) { { if (doc.type == "talk") { "id":"abc", emit(doc.title, doc); "key":"nosql", } "value": {id: “abc”, { title: “nosql”, type: “talk”} id: “xyz”, } }, title: “ajax”, { type: “talk” "id":"xyz", } "key":"ajax", map "value": {id: “xyz”, title: “ajax”, type: “talk”} } ] }
  26. example: map-reduce { "total_rows":2, "offset":0, "rows": [ { "id":"abc", "key":"nosql", function (key, values, rereduce) { "value": {id: “abc”, return sum(values); title: “nosql”, type: “talk”} } }, { "id":"xyz", "key":"ajax", re duce "value": {id: “xyz”, title: “ajax”, type: “talk”} } ] }
  27. Designed for Replication t io n e not the excep co nflicts ar master master (incremental) replication on demand master
  28. Distributed Address Book server desktop mobile (partial replication)
  29. The Sweet Spot distributed databases with schemaless data
  30. Eric Brewer: CAP Theorem Consistency choose any 2 Availability application trade-off Partition tolerance
  31. client 1 client 2 write reads consistent value db replicate db 1 transaction 1 Partition 2 Consistency
  32. client 1 client 2 write reads inconsistent data until replication een time betw db replicate db clicks? DNS 1 Partition 2 Availability
  33. Background check first developed by Facebook for inbox search now also used by Twitter, Digg, ...
  34. Data Model k v on s tero id s
  35. Data Model keyspace Twitter column family Statuses key columns 123 user_id: “abc” text: “i can haz cheesburger” 456 user_id: “abc” reply-to: “123” text: “nom nom” plus super-co lumns column family Users
  36. High Lights datacenter aware • High availability • Eventually consistent • Tunable tradeoffs between consistency and latency • No Single Point of Failure no no de in the clus ter is spec ial
  37. The Sweet Spot really large data sets, really high availability
  38. I’ve seen this before
  39. reme mber the ambrian E xplosion? C extinct
  40. “Polyglot Programming” Neal Ford, 2006 “Polyglot Persistence” Scott Leberknight , 2009
  41. questions ? @michaelmarth |