NOSQL– Not Only SQLSergey ShishkinMT AGhttp://www.mt-ag.comhttp://shishkin.org@sshishkin
Brewer’s CAP-TheoremAvailabilityEach client can always read and writePartition ToleranceThe system works well despite physical network partitionsConsistencyAll clients always have the same view of the data
Source: the451group.com
Key-Value Store
Document Store
Column Store
Visual Guide to NOSQLAvailabilityEach client can always read and writeSimpleDBAzureTSCouchDBRavenDBRDBMSPartition ToleranceThe system works well despite physical network partitionsConsistencyAll clients always have the same view of the dataMongoDB
LinksCode ExamplesMongoDBhttp://github.com/shishkin/MyBlog/tree/mongodb/MyBlog.Web/DataCouchDBhttp://github.com/shishkin/MyBlog/tree/couchdb/MyBlog.Web/DataSimpleDBhttp://github.com/shishkin/MyBlog/tree/simpledb/MyBlog.Web/DataAzure Table Servicehttp://github.com/shishkin/MyBlog/tree/azure/MyBlog.Web/DataFull Visual Guide to NOSQLhttp://blog.nahurst.com/visual-guide-to-nosql-systems
Application Lifecycle Design EntwicklungBeratungProjekteSchulungenArchitektur SOA Cloud ComputingBalckeBalcke-Dürr-Allee 9, 40882 Ratingen www.mt-ag.com info@mt-ag.com
Sergey Shishkinhttp://shishkin.orgsergei.shishkin@gmail.com@sshishkin
Imageshttp://www.flickr.com/photos/brianauer/2599299352/ (swimmingpool)http://www.flickr.com/photos/theplanetdotcom/4879421740/ (data center)http://www.flickr.com/photos/icatus/2992269179/ (bottleneck)http://www.flickr.com/photos/redbullfanclub/3788029453/ (f1)http://www.flickr.com/photos/stevendepolo/4536694260/ (broken glass)http://www.flickr.com/photos/starstreak007/3232853321/ (toy car)http://browsertoolkit.com/fault-tolerance.pnghttp://www.flickr.com/photos/ebarney/3348965007/ (tools)

NOSQL - not only sql

Editor's Notes

  • #3 Setting expectationsDistributed data issuesNOSQL solutionsNo codeIt’s not a deep dive sessionLet’s first look at the “Scaling” driver.
  • #4 Classical web-farm scale-outMany web front-ends read/write into a single database.
  • #5 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?
  • #6 Vertical ScaleMore power to a single machineCosts grow exponentiallyNoteffective
  • #7 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
  • #8 Sharding/PartitioningGive up unique constraints, foreign keys, joins
  • #9 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.
  • #10 You can choose only two to get acceptable latency!
  • #11 Impedance mismatch
  • #13 Extremely parallelizableExtremely fastGood choice for temporary and/or highly read data: user profile, shopping cart.Can be held in memory (memcache)
  • #14 No SQL support!No value indexingExceptions exist (redis)Complicated querying
  • #17 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).
  • #18 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