Database Principles: ACID, CAP, and BASE
Explore the fundamental principles governing classical relational databases such as ACID rules, CAP theorem, and BASE characteristics. Learn about transaction integrity, consistency, isolation, and durability, as well as the trade-offs between consistency, availability, and partition tolerance in distributed systems. Delve into the differences between RDBMS and NoSQL databases in terms of data structure, query language, consistency models, and performance priorities. Gain insights into the concepts of eventual consistency and basically available, soft state, eventually consistent (BASE) systems.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Classical relation database follow the ACID Rules Atomic: A transaction is a logical unit of work which must be either completed with all of its data modifications, or none of them is performed. Consistent: At the end of the transaction, all data must be left in a consistent state. Isolated: Modifications of data performed by a transaction must be independent of another transaction. Unless this happens, the outcome of a transaction may be erroneous. Durable: When the transaction is completed, effects of the modifications performed by the transaction must be permanent in the system. Prof V B More, MET s IOE BKC Nashik
CAP Theorem (Brewers Theorem) CAP theorem states that there are three basic requirements which exist in a special relation when designing applications for a distributed architecture. Consistency - 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. Availability - This means that the system is always on (service guarantee availability), no downtime. Partition Tolerance - 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. Prof V B More, MET s IOE BKC Nashik
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 Prof V B More, MET s IOE BKC Nashik
RDBMS vs NoSQL RDBMS NoSQL Structured and organized data Unstructured and unpredictable data Structured query language SQL Schema declaration No declarative query language Not Only SQL (NoSQL) No predefined schema Data and its relationships are stored in separate tables. Key-Value pair storage, Column Store, Document Store, Graph databases Data Manipulation Language, Data Definition Language requires a deeper understanding of data structures and algorithms Tight Consistency ACID property Eventual consistency CAP Theorem Tight Security, High performane for structured data Prioritizes high performance, high availability and scalability Prof V B More, MET s IOE BKC Nashik
The BASE A BASE system gives up on consistency. Basically Available indicates that the system does guarantee availability, in terms of the CAP theorem. The database is basically available such that if some part of the database becomes unavailable, other parts of the database continue to function as expected. Prof V B More, MET s IOE BKC Nashik
The BASE Soft state indicates that the state of the system may change over time, even without input. This is because of the eventual consistency model. Data may be time-dependent on user interaction with possible expiration after a period of time. The data must be updated or accessed to remain relevant in the system. Prof V B More, MET s IOE BKC Nashik
The BASE Eventual consistency indicates that the system will become consistent over time, given that the system doesn't receive input during that time. Updated data may not be immediately consistent across the entire system but with time will become consistent. Prof V B More, MET s IOE BKC Nashik
BASE Transactions Opposite of ACID Basically Available, Soft state, Eventually Consistent Characteristics: Weak consistency stale data OK Availability first Best effort Approximate answers OK Aggressive (optimistic) Simpler and faster Prof V B More, MET s IOE BKC Nashik
