NOSQL - not only sql
•Transferir como PPTX, PDF•
2 gostaram•1,078 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Destaque
Destaque (20)
Semelhante a NOSQL - not only sql
Semelhante a NOSQL - not only sql (20)
Mais de Sergey Shishkin
Último
Último (20)
NOSQL - not only sql
- 1. NOSQL– Not Only SQL Sergey ShishkinMT AG http://www.mt-ag.comhttp://shishkin.org @sshishkin
- 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
- 12. Key-Value Store
- 14. Document Store
- 15. Column Store
- 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
- 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
- 20. Sergey Shishkin http://shishkin.org sergei.shishkin@gmail.com @sshishkin
- 21. Images http://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.png http://www.flickr.com/photos/ebarney/3348965007/ (tools)
Notas do Editor
- 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