The document provides an overview of NoSQL databases, discussing Brewer's CAP theorem and the key aspects of availability, partition tolerance, and consistency. It then describes different types of NoSQL databases, including key-value stores, document stores, and column stores. Code examples and links to further resources on MongoDB, CouchDB, SimpleDB, and Azure Table Service are also included.
1. NOSQL– Not Only SQL Sergey ShishkinMT AG http://www.mt-ag.comhttp://shishkin.org @sshishkin
2.
3.
4.
5.
6.
7.
8.
9. Brewer’s CAP-Theorem AvailabilityEach client can always read and write Partition ToleranceThe system works well despite physical network partitions ConsistencyAll clients always have the same view of the data
16. Visual Guide to NOSQL AvailabilityEach client can always read and write SimpleDBAzureTSCouchDBRavenDB RDBMS Partition ToleranceThe system works well despite physical network partitions ConsistencyAll clients always have the same view of the data MongoDB
17.
18. Links Code Examples MongoDB http://github.com/shishkin/MyBlog/tree/mongodb/MyBlog.Web/Data CouchDB http://github.com/shishkin/MyBlog/tree/couchdb/MyBlog.Web/Data SimpleDB http://github.com/shishkin/MyBlog/tree/simpledb/MyBlog.Web/Data Azure Table Service http://github.com/shishkin/MyBlog/tree/azure/MyBlog.Web/Data Full Visual Guide to NOSQL http://blog.nahurst.com/visual-guide-to-nosql-systems
19. Application Lifecycle Design Entwicklung BeratungProjekteSchulungen Architektur SOA Cloud Computing BalckeBalcke-Dürr-Allee 9, 40882 Ratingen www.mt-ag.com info@mt-ag.com
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
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