NOSQL and CAP Theorem NOSQL Not Only SQL
- Slides: 8
NOSQL and CAP Theorem
NOSQL - Not Only SQL (and with it relational databases) have dominated the database market for the last 30 years. Relational databases offer an appealing compromise between performance and the ACID principles making them reliable and performant. The NOSQL movement is a push for nonrelational databases in circumstances that traditional databases are failing. http: //blog. agroknow. com/? p=3854
NOSQL Variety There isn't one type of NOSQL database. NOSQL is defined by what it isn't. Is CSV NOSQL? Sure (but most wouldn't call it that). This week, we'll be talking about different Non-SQL databases, how to use them, and their performance and other tradeoffs. One of the biggest tradeoffs (that we have mentioned before) are related to the CAP theorem.
CAP Theorem - Pick 2 Consistency means that each client always has the same view of the data Availability means that all clients can always read and write Partition tolerance means that the system works well across physical network partitions. http: //dba. stackexchange. com/questions/18435 /cap-theorem-vs-base-nosql
What CAP properties do traditional, relational databases optimize? 1. Consistency 2. Availability 3. Partition Tolerance 4. My Project 5 implementation is terrible, so None.
http: //blog. flux 7. c om/blogs/nosql/c ap-theorem-whydoes-it-matter
Types of Databases Relational - (My. SQL, Postgres, SQLite) stores data in rigid schemas and because of that an service complicated queries (involving joins) quickly Column-Based - (Google's Big. Table, Apache's Hbase) stores huge amounts of data efficiently Key-Value - (Amazon's Dynamo. DB, Facebook's Cassandra) meant for extremely fast retrievals of small amounts of information Document-Stores - (Mongo. DB, Couch. DB) used as an alternative to relational tables with less rigidity and hierarchical structured objects Graph-Based - (Neo 4 J, Graph. Base) stores billions of nodes and the edges between them for efficient network/graph traversals. These types are neither exclusive, nor comprehensive, and some DBMSs transcend each category.
Why you should not use NOSQL is well understood, interoperable between DBMSs, performant for many circumstances, and stable. Almost every different NOSQL DBMS has its own language, data format restrictions, hardware/OS compatibilities issues, and quirks. Most of the time, a relational database (like SQLite) is a simpler, faster and better than NOSQL alternatives. But, there are times when NOSQL is better, but I want to combat some of the hype. NOSQL is generally built for scale, but most of the time, you don't need scale, or you can shift when you do.
