The No SQL Principles and Basic Application Of Casandra Model
Download as PPT, PDF•2 likes•1,778 views
The document discusses the principles and applications of NoSQL databases, specifically the Cassandra model, which addresses the limitations of traditional RDBMS in handling large datasets and high read-write rates. It highlights Cassandra's scalability, high availability, and efficiency for modern web applications while featuring concepts like sharding and CAP theorem. Furthermore, it compares performance metrics of MySQL and Cassandra, concluding that NoSQL, particularly Cassandra, is suitable for managing big data challenges.
The No SQL Principles and Basic Application Of Casandra Model
- 1. TThhee NNooSSQQLL PPrriinncciipplleess && BBaassiicc AApppplliiccaattiioonn ooff CCaassssaannddrraa MMooddeell RReesshhmmii RRaaddhhaakkrriisshhnnaann SS77 CCSS BB RRoollll NNOO::7711 GGuuiiddeedd bbyy,, DDrr..SSuuddhheeeepp EEllaayyiiddoomm SSOOEE CCUUSSAATT
- 2. AAGGEENNDDAA • INTRODUCTION • RDBMS • CHALLENGE • NoSQL • COMMON CONCEPTS • CLASSIFICATION • CASSANDRA • CASSANDRA CHARACTERISTICS • CONCLUSION • REFERENCES
- 3. INTRODUCTION * RDBMS is the predominant technology for storing structured data in web and business applications. * The relational database systems have little capability to horizontally scale. * NoSQL approach includes simplicity of design, horizontal scaling and finer control over availability * Cassandra is the right NoSQL database when you need scalability and high availability without compromising performance
- 4. RDBMS MERITS: • Rich language • Easy to use and integrate • Rich toolset • Vertical scaling • The promise: ACID o Atomicity o Consistency o Isolation o Durability
- 5. RDBMS DEMERTS: • Vertical scaling is highly expensive • Fails to handle large amount of data • It is not much efficient in cloud concept The read-write rates of data in RDBMS are very poor So it is hard to face the challenges from the modern web applications using RDBMS
- 6. The Challenge: Modern web apps • Internet-scale data size • High read-write rates • Frequent schema changes • "social" apps - not banks o They don't need the same level of ACID SCALING
- 7. NoSQL • Uses horizontal scaling • Distribute data over many servers • It give up ACID property • Based on CAP -theorem
- 8. Brewer's CAP Theorem: You can only choose two
- 9. CAP Consistency: A distributed system is considered to be consistent if after an update operation of some writer, all readers see his updates in some shared data sources Availability: System is designed in a way that continue operation even if nodes in a cluster crash Partition Tolerance: Ability of a system to continue operation in the presence of network partition
- 10. COMMON CONCEPTS •Sharding •Consistent hashing •Map reduce
- 11. SHARDING • it's a partitioning mechanism • records are stored in different servers according to some key • records that are accesses/updated together reside on same node • load is almost evenly distributed among servers • vertical partitioning: parts of single records are stored on different servers
- 12. Constant Hashing • A,B,C:- NODES • 1,2,3,4:- OBJECTS -> both are placed in ring ->movement is clockwise ->nodes can leave the system ->nodes can enter into the system
- 13. MAP REDUCE •Used in distributed computig • map function • reduce function • process on key/value
- 15. Classification of NOSQL data stores • Document Oriented o CouchDB, MongoDB, Lotus Notes, SimpleDB • Key-Value oriented o Voldemort, Dynamo, Riak (sort of), Redis, Tokyo • Column oriented o Cassandra, HBase, BigTable • Graph Databases oriented o Neo4J, FlockDB, DEX, AlegroGraph
- 16. • Developed at facebook • Follows the BigTable Data Model - column oriented • Follows the Dynamo Eventual Consistency model • Opensourced at Apache • Implemented in Java
- 17. • Distributed Storage System • Manages structured data and scale to large size
- 18. Data Model • Instance of Cassandra – Consists of one table represent multidimensional map indexed by a key • Query for information: get(keyspace, column family, row key) • Keyspace:- top level unit of information, Column families are subordinate of one key space • Column :- atomic unit of information, expressed as: name:value • Super Column :- groups together like columns with a common name, Used for modeling complex data types (address)
- 19. Data Model ROW FAMILY • uniquely identifiable data • groups column and super column • Every row are identified by row key COLUMN FAMILY • It have to be define in advance before a cluster of servers in Cassandra instance is launched • It consists of keyed rows which groups columns and super columns • Column and super column added dynamically to column families and they are not restricted in numbers
- 20. Write Path
- 21. MEMTABLES • In-memory representation of recently written data • When the table is full, it's sorted and then flushed to disk -> sstable SS TABLES Sorted Strings Tables • Unchangeable • On-disk • Sorted by a string key • In-memory index of elements • Binary search (in memory) to find element location • Bloom filter to reduce number of unneeded binary searches. WRITE PROPERTIES • No Locks in the critical path • Always available to writes, even if there are failures. No seeks • Fast • Atomic within a Row
- 22. Read Path
- 23. Read Properteis • Read multiple SSTables • Slower than writes (but still fast) • Seeks can be mitigated with more RAM • Uses probabilistic bloom filters to reduce lookups. • Extensive optional caching o Key Cache o Row Cache
- 24. Bloom Filters • Space efficient probabilistic data structure • Test whether an element is a member of a set • Union and intersection are implemented as bitwise OR, AND
- 25. QUERIES EXAMPLES CREATE INDEX CREATE CUSTOM INDEX IF NOT EXISTS index_name ON keyspace_name.table_name ( KEYS (column_name) ) ( USING class_name ) ( WITH OPTIONS = map ) Restrictions: USING class_name is allowed only if CUSTOM is used and class_name is a string literal containing a java class name. index_name is an identifier, enclosed or not enclosed in double quotation marks, excluding reserved words. map is described in ALTER KEYSPACE. CREATE KEYSPACE CREATE ( KEYSPACE | SCHEMA ) IF NOT EXISTS keyspace_name WITH REPLICATION = map AND DURABLE_WRITES = ( true | false )
- 26. MySQL Comparison • MySQL : for 50 GB Data Writes Average : ~300 ms Reads Average : ~350 ms • Cassandra: for 50 GB Data Writes Average : 0.12 ms Reads Average : 15 ms
- 27. CONCLUSION •NoSQL is highly efficient concept for dealing large amount of data. •It can be used to solve big data problem. •Cassandra model can provide fast reading and writing operations •So this database model is used by all the latest social networking medias
- 28. REFERENCES **The NoSQL Principles and Basic Application of Cassandra Model Guoxi Wang ; Jianfeng Tang Computer Science & Service System (CSSS), 2012 International Conference on Digital Object Identifier: 10.1109/CSSS.2012.336 Publication Year: 2012 , Page(s): 1332 - 1335 IEEE CONFERENCE PUBLICATIONS **Survey on NoSQL database Jing Han ; Haihong, E. ; Guan Le ; Jian Du Pervasive Computing and Applications (ICPCA), 2011 6th InternationalConferenceon Digital Object Identifier: 10.1109/ICPCA.2011.6106531 Publication Year: 2011 , Page(s): 363 - 366 Cited by: Papers (2) IEEE CONFERENCE PUBLICATIONS