No sql (not only sql)
Download as PPTX, PDF2 likes2,435 views
The document discusses NoSQL databases and Cassandra. It provides background on the rise of NoSQL with the need for large web companies to handle big data in a distributed manner. It introduces the CAP theorem and explains that NoSQL databases sacrifice consistency to achieve availability and partition tolerance. Eventual consistency is described where updates eventually propagate throughout the system. Cassandra is summarized as an open source, distributed, column-oriented database developed at Facebook to be highly scalable and fault tolerant. It uses an eventual consistency model and is robust to failures.
Ad
More Related Content
What's hot (20)
Similar to No sql (not only sql) (20)
Ad
Recently uploaded (20)
Ad
No sql (not only sql)
- 2. History What is NoSQL? CAP Theorem Eventual Consistency Data Models Cassendra
- 3. 1980 1990 2000 2010 Rise of Relational Database Pros: Persistent, Concurrency Cons: Impedance Mismatch Problem Rise of Object Database Dominance of Relational Database Cons: Data needs increased, distributed database started, SQL not designed for DDBMS Google BigTable Amazon Dynamo
- 4. NoSQL is a term for a loosely defined class of non-relational data stores that breaks the long history of relational databases and ACID guarantees. Data stores that fall under this term may not require fixed table schemas, and usually avoid join operations. The term was first popularised in early 2009.
- 5. Three properties of a system: consistency, availability and partitions We can have at most two of these three properties for any shared-data system. Consistency -all clients see current data regardless of updates or deletes Availability -the system continues to operate as expected even with node failures Partition Tolerance -the system continues to operate as expected despite network or message failure CA CP AP
- 6. A consistency model determines rules for visibility and apparent order of updates. For example: Row X is replicated on nodes M and N Client A writes row X to node N Some period of time t elapses. Client B reads row X from node M Does client B see the write from client A? Consistency is a continuum with tradeoffs For NoSQL, the answer would be: maybe CAP Theorem states: Strict Consistency can't be achieved at the same time as availability and partition-tolerance. X X M N A WRITES B READS X* X or X*?
- 7. When no updates occur for a long period of time, eventually all updates will propagate through the system and all the nodes will be consistent Known as BASE (Basically Available, Soft state, Eventual consistency), as opposed to ACID * Basically Available - system seems to work all the time * Soft State - it doesn't have to be consistent all the time * Eventually Consistent - becomes consistent at some later time
- 9. 123 564 789 Databases Pros: very fast very scalable simple model able to distribute horizontally Cons: - many data structures (objects) can't be easily modeled as key value pairs Document Data Model: -Each document is a complex structure -Represented in XML,Jason -Query into the document structure to retrieve portions of the database metadata key
- 11. Cheap, easy to implement (open source) Data are replicated to multiple nodes (therefore identical and fault-tolerant) and can be partitioned ◦ Down nodes easily replaced ◦ No single point of failure Easy to distribute Don't require a schema Can scale up and down Relax the data consistency requirement (CAP) What we are giving up… • joins • group by • order by • ACID transactions • SQL as a sometimes frustrating but still powerful query language • Easy integration with other applications that support SQL
- 12. Originally developed at Facebook It is a distributed, extreme scalable, fault tolerant post-relational database solution Data Model : column-oriented Uses the Dynamo Eventual Consistency model Written in Java Open-sourced and exists within the Apache family Uses Apache Thrift as it’s API
- 13. Cassendra was designed with the understanding that system/hardware failures can and do occur. Peer-to-peer ,distributed system All nodes are the same Read/Write-anywhere design Data center 1 Data center 2
- 14. The coordinator sends the write to all replicas that own the row being written. As long as all replica nodes are up and available, they will get the write regardless of the consistency level (Tunable) specified by the client. (LOCAL_QUORUM) Multiple Data Center Write Requests
- 15. There are two types of read requests : 1) direct read request 2) background read repair request. The number of replicas contacted by a direct read request is determined by the consistency level specified by the client. Background read repair requests are sent to any additional replicas that did not receive a direct request. Read repair requests ensure that the requested row is made consistent on all replicas.
- 16. The coordinator first contacts the replicas specified by the consistency level. If multiple nodes are contacted, the rows from each replica are compared for consistency in memory. If replicas are inconsistent, the following events occur: ◦ The coordinator uses the replica that has the most recent data (based on the timestamp) to forward the result back to the client. ◦ In the background, the coordinator compare the data from all the remaining replicas that own the row.
- 17. Created at Facebook along with Cassandra Is a cross-language, service-generation framework Binary Protocol (like Google Protocol Buffers) Compiles to: C++, Java, PHP, Ruby, Erlang, Perl, ...
- 18. Relational (SQL) ◦ SELECT `column` FROM `database`,`table` WHERE `id` = key; Cassandra (standard) (CQL) ◦ keyspace.getSlice(key, “column_family”, "column")
- 20. Thank You