HBase Vs Cassandra Vs MongoDB - Choosing the right NoSQL database
324 likes104,696 views
The document compares HBase, Cassandra, and MongoDB as NoSQL database solutions, highlighting their unique features, strengths, and appropriate use cases. It discusses the limitations of traditional databases, the CAP theorem, and the advantages of NoSQL in handling large volumes of varied data. Additionally, the document provides guidelines on when to use or avoid each NoSQL database based on specific application requirements.
HBase Vs Cassandra Vs MongoDB - Choosing the right NoSQL database
- 1. Slide 1 HBase Vs Cassandra Vs MongoDB - choose the right NoSQL database View NoSQL database Courses at : www.edureka.in *
- 2. Slide 2 Objectives of this Session • Un For Queries during the session and class recording: Post on Twitter @edurekaIN: #askEdureka Post on Facebook /edurekaIN Traditional databases Challenges with traditional databases CAP Theorem NoSQL to the rescue A BASE system Choose the right NoSQL database www.edureka.in
- 3. Slide 3 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions RDBMS/OLTP/Real Time NoSQL/New SQL/BigData DSS/OLAP/DW Oracle MySQL MS SQL DB2 Netezza SAP Hana Oracle Express MongoDB HBase Cassandra CouchDB Database Categories www.edureka.in
- 4. Slide 4 www.edureka.in 5000 TPS Caching Layer 300 ~ 500 SQL Transaction 100 ~ 200 SQL Transaction 1000 TPS WEB APPLICATION RDBMS1 Applications Changing Data RDBMS1 Elastic Scale A Traditional database solution
- 5. Slide 5 www.edureka.in 1000 TPS Elastic Scale WEB APPLICATION Applications Changing Data Elastic Scale CASSANDRA 300 ~ 500 SQL Transaction 100 ~ 200 SQL Transaction 5000 TPS A NoSQL database solution
- 6. Slide 6 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in Challenges with traditional databases Not a good fit for large Data Volume (petabytes of data) with Varying data types e.g. images, videos, text etc. Can’t scale for large data volume e.g. 15 - 20 petabyte data in Govt. of India “AADHAR” project Scale-up - Limited by Memory and Processing (CPU) capabilities Scale-out - Cache dependent ‘Read’ and ‘Write’ Operations Complex RDBMS model – Parsing, Locking, Logging, Buffer pool, Threads etc. Sharding causes operational problems e.g. managing a shard failure Consistency – A bottleneck for Scalability in RDBMS Satisfying ACID is an hindrance for Scaling Relaxed consistency to scale out with NoSQL databases
- 7. Slide 7 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in CAP We must understand the CAP theorem when we talk about NoSQL databases or in fact when designing any distributed system. CAP theorem states that there are 3 basic requirements which exist in a special relation when designing applications for a distributed architecture. Consistency Availability Partition Tolerance CAP Theorem This means that the system is always on (service guarantee availability), no downtime. This means that the system continues to function even the communication among the servers is unreliable, i.e. the servers may be partitioned into multiple groups that cannot communicate with one another. This means that the data in the database remains consistent after the execution of an operation. For example after an update operation all clients see the same data.
- 8. Slide 8 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions CAP provides the basic requirements for a distributed system to follow 2 of the 3 requirements. In theoretically it is impossible to fulfill all 3 requirements. Therefore all the current NoSQL database follow the different combinations of the C, A, P from the CAP theorem. CAP Theorem and NoSQL databases CA - Single site cluster, therefore all nodes are always in contact. When a partition occurs, the system blocks. CP - Some data may not be accessible, but the rest is still consistent/accurate. AP - System is still available under partitioning, but some of the data returned may be inaccurate. www.edureka.in
- 9. Slide 9 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in NoSQL to the rescue A scale-out, shared-nothing architecture, capable of running on a large number of nodes A non-locking concurrency control mechanism so real-time reads will not conflict with writes Scalable replication and distribution Thousands of machines with distributed data An architecture providing much higher per-node performance than available from the traditional SQL-based databases Schema-less Data Model Mostly Query and Few Updates
- 10. Slide 10 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in Basically Available indicates that the system does guarantee availability, in terms of the CAP theorem. Basically Available Soft State indicates that the state of the system may change over time, even without input. This is because of the eventual consistency model. Soft State Eventual Consistency indicates that the system will become consistent over time, given that the system doesn't receive input during that time. Eventual Consistency A BASE system gives up on consistency. NoSQL database - A BASE not ACID system
- 11. Slide 11 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in ~ 150 No SQL Database are there in Market ~150 NoSQL database – Not a Panacea
- 12. Slide 12 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions NoSQL Database – Storage Architecture CouchDB, MongoDB Collection of key value Connections Incomplete Data Tolerant Query Performance, No Standard Query Syntax Hbase, Cassandra Column Families Fast Look-ups Very Low Level API Amazon Simple DB, Redis Collection of Key Value pairs Fast Look-ups Stored Data has no Schema InfoGrid, Infinite Graph “Property Graph” - Nodes Graph Algorithms – Shortest Path, Connected ness, Etc Not easy to Cluster, traverse whole graph to get answer Data Model Example Weakness Strength Data Model Example Weakness Strength Data Model Example Weakness Strength Data Model Example Weakness Strength Document Data Store Databases Key Value Databases Columnar NoSQL Databases Graph NoSQL Databases No SQL Database Types www.edureka.in
- 13. Slide 13 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions Right Data Model Pros and Cons of Consistency Compromising Features of RDBMS Step 2 Step 3 Selecting a NoSQL database Step 1 www.edureka.in
- 14. Slide 14 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions Where to Use Cassandra? If looking for simple setup, maintenance and code Very High Velocity Random Reads & Writes Flexible Sparse / Wide Column Requirements No Multiple Secondary Index Needs www.edureka.in
- 15. Slide 15 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.inwww.edureka.in Massive Scale, High Availability Cassandra Use Case - Twitter
- 16. Slide 16 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions Where NOT to Use Cassandra? Do not use Cassandra if your application has: Secondary Indexes. Relational Data. Transactional (Rollback, Commit) Primary & Financial Records. Stringent Security & Authorization Needs On Data Dynamic Queries on Columns. Searching Column Data Low Latency www.edureka.in
- 17. Slide 17 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions Where to Use HBase Optimized for reads Well suited for doing Range based scans Applications with strict consistency requirements Applications with fast read and writes with scalability Facebook uses it to manage its user statuses, photos, chat messages etc. www.edureka.in
- 18. Slide 18 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.inwww.edureka.in Consistency and Scale HBase Use Case - Facebook Messenger
- 19. Slide 19 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in It is not optimized for classic transactional applications or even relational analytics Application that need: full table scans data to be aggregated, rolled up, analysed across rows Where Not to use HBase
- 20. Slide 20 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in Where to Use MongoDB www.edureka.in RDBMS replacement for Web Applications Semi-structured Content Management Real-time Analytics & High-Speed Logging Caching and High Scalability Web 2.0, Media, SAAS, Gaming http://www.mongodb.org/about/production-deployments/
- 21. Slide 21 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in MySQL for Active posts MongoDB for Archived posts Migrated Two billion plus posts to MongoDB Migrated from RDBMS to MongoDB Storage of venues and check-ins High-performance and Schema-free MongoDB Use Cases
- 22. Slide 22 Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in Highly Transactional Applications Applications with traditional database systems requirements such as foreign-key constraints etc. Where Not to use MongoDB
- 23. Slide 23 www.edureka.in Distributed and scalable big data store Strong consistency Built on top of Hadoop Distributed File system (HDFS) CP on CAP Cassandra MongoDBHBase High availability Incremental scalability Eventually consistent Trade-offs between consistency and latency Minimal administration No SPF (Single Point of Failure) AP on CAP Schemas to change as applications evolve (Schema-free) Full Index Support for High Performance. Replication and Failover for High Availability. Auto Sharding for Easy Scalability. Rich Document based queries for Easy readability CP on CAP HBase Vs Cassandra Vs MongoDB
- 24. Slide 24 Questions? Buy NoSQL database Courses at : www.edureka.in Twitter @edurekaIN, Facebook /edurekaIN, use #askEdureka for Questions www.edureka.in