NOSQL– Not Only SQL<br />Sergey ShishkinMT AG<br />http://www.mt-ag.comhttp://shishkin.org<br />@sshishkin<br />
Brewer’s CAP-Theorem<br />AvailabilityEach client can always read and write<br />Partition ToleranceThe system works well ...
Source: the451group.com<br />
Key-Value Store<br />
Document Store<br />
Column Store<br />
Visual Guide to NOSQL<br />AvailabilityEach client can always read and write<br />SimpleDBAzureTSCouchDBRavenDB<br />RDBMS...
Links<br />Code Examples<br />MongoDB<br />http://github.com/shishkin/MyBlog/tree/mongodb/MyBlog.Web/Data<br />CouchDB<br ...
Application Lifecycle Design Entwicklung<br />BeratungProjekteSchulungen<br />Architektur SOA Cloud Computing<br />BalckeB...
Sergey Shishkin<br />http://shishkin.org<br />sergei.shishkin@gmail.com<br />@sshishkin<br />
Images<br />http://www.flickr.com/photos/brianauer/2599299352/ (swimmingpool)<br />http://www.flickr.com/photos/theplanetd...
Upcoming SlideShare
Loading in …5
×

NOSQL - not only sql

1,635 views
1,543 views

Published on

Introduction to NOSQL technology landscape. Presented at Professional .NET 2011 in Vienna.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,635
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Setting expectationsDistributed data issuesNOSQL solutionsNo codeIt’s not a deep dive sessionLet’s first look at the “Scaling” driver.
  • Classical web-farm scale-outMany web front-ends read/write into a single database.
  • Data persistence is a bottleneckACID TransactionsMaintaining Key ConsistencyLocks are expensiveRDBMS power of choiceOptimized for massive writesOr for ad-hoc structured queriesWhat a surprise!How does RDBMS scale?
  • Vertical ScaleMore power to a single machineCosts grow exponentiallyNoteffective
  • Scale Out (Horizontal Scale)Master-SlaveReads from slavesWrites to masterSynchronous replication for consistencyAsynchronous replication for availabilityStill bad for massive writesMaster-MasterHow to resolve conflicts in a normalized model
  • Sharding/PartitioningGive up unique constraints, foreign keys, joins
  • What was the point of all that again?Pretty much nothing left over of RDBMS.Relational model has no benefits without key consistency.Other models are easier to work with.
  • You can choose only two to get acceptable latency!
  • Impedance mismatch
  • Extremely parallelizableExtremely fastGood choice for temporary and/or highly read data: user profile, shopping cart.Can be held in memory (memcache)
  • No SQL support!No value indexingExceptions exist (redis)Complicated querying
  • ACID – Atomicity,Consistentcy, Isolation, DurablityBASE– Basically Available, Soft state, Eventual consistencyDifferent replication models! Master-Master or Master-Slave!Key Integrity requires consistency(unique keys, foreign keys, joins).Eventual Consistency requiresVersion Conflict Resolution (vector clocks help detect conflicts, manual resolution required).
  • Data Storage EcosystemNOSQL = Not Only SQLRDBMS still has its strengthsUnique constraintsBut they don’t scale horizontallyYou don’t need a hammer when you have the right tools ;)CQRS:DocumentstorageforviewsandsearchesWhateverforstoringevents
  • NOSQL - not only sql

    1. 1. NOSQL– Not Only SQL<br />Sergey ShishkinMT AG<br />http://www.mt-ag.comhttp://shishkin.org<br />@sshishkin<br />
    2. 2.
    3. 3.
    4. 4.
    5. 5.
    6. 6.
    7. 7.
    8. 8.
    9. 9. Brewer’s CAP-Theorem<br />AvailabilityEach client can always read and write<br />Partition ToleranceThe system works well despite physical network partitions<br />ConsistencyAll clients always have the same view of the data<br />
    10. 10.
    11. 11. Source: the451group.com<br />
    12. 12. Key-Value Store<br />
    13. 13.
    14. 14. Document Store<br />
    15. 15. Column Store<br />
    16. 16. Visual Guide to NOSQL<br />AvailabilityEach client can always read and write<br />SimpleDBAzureTSCouchDBRavenDB<br />RDBMS<br />Partition ToleranceThe system works well despite physical network partitions<br />ConsistencyAll clients always have the same view of the data<br />MongoDB<br />
    17. 17.
    18. 18. Links<br />Code Examples<br />MongoDB<br />http://github.com/shishkin/MyBlog/tree/mongodb/MyBlog.Web/Data<br />CouchDB<br />http://github.com/shishkin/MyBlog/tree/couchdb/MyBlog.Web/Data<br />SimpleDB<br />http://github.com/shishkin/MyBlog/tree/simpledb/MyBlog.Web/Data<br />Azure Table Service<br />http://github.com/shishkin/MyBlog/tree/azure/MyBlog.Web/Data<br />Full Visual Guide to NOSQL<br />http://blog.nahurst.com/visual-guide-to-nosql-systems<br />
    19. 19. Application Lifecycle Design Entwicklung<br />BeratungProjekteSchulungen<br />Architektur SOA Cloud Computing<br />BalckeBalcke-Dürr-Allee 9, 40882 Ratingen www.mt-ag.com info@mt-ag.com<br />
    20. 20. Sergey Shishkin<br />http://shishkin.org<br />sergei.shishkin@gmail.com<br />@sshishkin<br />
    21. 21. Images<br />http://www.flickr.com/photos/brianauer/2599299352/ (swimmingpool)<br />http://www.flickr.com/photos/theplanetdotcom/4879421740/ (data center)<br />http://www.flickr.com/photos/icatus/2992269179/ (bottleneck)<br />http://www.flickr.com/photos/redbullfanclub/3788029453/ (f1)<br />http://www.flickr.com/photos/stevendepolo/4536694260/ (broken glass)<br />http://www.flickr.com/photos/starstreak007/3232853321/ (toy car)<br />http://browsertoolkit.com/fault-tolerance.png<br />http://www.flickr.com/photos/ebarney/3348965007/ (tools)<br />

    ×