1 of 10

DATABASES

DROPPING ACID

RHYANNON

JOY

RODRIGUEZ

2 of 10

DROPPING OVERVIEW

02

WHY DO WE USE IT?

03

WHY IS IT IMPORTANT?

04

ALT TO ACID

05

LIMITS OF RDBMS

06

FURTHER READING

01

WHAT IS ACID?

Data Science Resources, Freecodecamp

CAP Theorem, SQL vs NoSQL, Scalability

Ensure data integrity, transaction reliability

DB Failure Recovery, Security

ACID vs BASE

DB Design Model

*commonly-associated with RDBMS

3 of 10

ATOMICITY

CONSISTENCY

ISOLATION

DURABILITY

4 of 10

WHAT IS ?

ATOMICITY

  • Each transaction must follow an all or nothing rule
  • If any part of the transaction violates these rules -> abandon transaction

CONSISTENCY

  • Each DB transaction must meet all of the DB defined protocols
  • Any transaction that violates these rules is abandoned to never endanger the structural integrity of the DB

ISOLATION

  • Each DB transaction will occur independently of any other transaction -> slow, but secure
  • If multiple transactions are submitted concurrently, DB will prevent interference bwtn them

DURABILITY

  • Each DB transaction will permanently exist despite any DB failure via backups / other means
  • Follows all 4 goals == ACID-compliant

​

*In practice: write-ahead logs, shadow-paging, 2-phase commit protocol

5 of 10

WHY USE

?

RELIABILITY

SAFETY

  • Generally it’s a good idea to abide by tested design principles to save time & resources so that we’re not forced to reinvent the wheel during each design process
  • The zero-tolerance for invalid states or unfinished transactions & additional ACID-compliant practices aim to

ensure accurate, reliable data

  • Changes need to be performed with care & ACID-compliant DB practice prioritizes safety from network failures / crash, invalid input or inconsistency of any kind

6 of 10

WHY IS IMPORTANT?

Organizing data is a difficult task. Following conventional design principles can help us be efficient by saving time & resources. Understanding these patterns provides us a way to articulate our design intentions, our project purpose & identify constraints or problems. Specifically, ACID refers to a standard set of properties that guarantee DB transactions are processed reliably; concerned with how a DB recovers from any failure that might occur while processing a transaction (service outages, crashes, other cases of failure).

7 of 10

ALTERNATIVE TO ACID : BASE

BASIC AVAILABILITY

SOFT STATE

EVENTUAL CONSISTENCY

8 of 10

WHY WOULD WE USE BASE?

SPEED

FLEXIBILITY

  • Re: chemistry, base is the opposite to acid. Re: DB concepts, ACID & BASE have a similar relationship. It doesn’t make sense to introduce one without the other bc their design principles directly reference one another.
  • BASE models focus more on data availability rather than safety from network failure or inconsistency
  • If all transactions need to be checked for consistency an ACID DB might be slower at reading & writing; more demanding re: storing new data in new formats
  • BA: Basic Availability guarantee data availability; there will be a response to any request (even if that’s failure)
  • S: Soft State doesn’t check strict protocol / rules; the state of the system could change over time
  • E: Eventually Consistent no guarantee of enforced immediate consistency, but can become consistent over time (once it stops receiving input)
  • BASE: possibly faster, flexibility; trades atomicity, consistency, or durability in return for improvements in scalability

9 of 10

LIMITS OF RDBMS (SQL vs NoSQL)

​

  • 1960s-1974: RDBMS categorize based on type & functionality via SQL (Structured Query Language, IBM) ACID-like pattern emerged to reduce data duplication bc storage was expensive, but -> rigid, complex, tabular schemas with vertical scaling (larger server) -> this is a less appropriate model as data gets larger, diverse bc changing schemas is expensive
  • 1983: While building on Jim Gray’s work, Andreas Reuter & Theo Harder coined ACID while characterizing the transaction concept; 4 ACID properties are the major guarantees of the transaction paradigm -> influenced many aspects of development in DB systems
  • 1998: Eric Brewer’s Cap Theorem - impossible for a DB to simultaneously guarantee consistency, availability, or partition tolerance; must compromise between the 3
  • Late 2000s: Drop in cost of storage, amount of data apps accommodating diverse data (dot.com boom), Agile Manifesto, growth of DevOps field, cloud computing all influenced the need for flexible models like NoSQL
  • Modern apps (Amazon, FB, networking apps) release updates, new functionalities, extra modules -> NoSQL DBs (“not-only-SQL”, “not-only-tabular”: key-value, graph, wide-column, document; generally follow BASE model & horizontal scaling (across commodity servers)
  • New DBs are being invented for specific uses; learn the type of data your app generates -> easier to choose the appropriate DB MGMT system

​

​

  1. key-value: hash table, unique key + pointer, no query language; Pinterest via Redis for lists of users, followers, unfollowers, boards
  2. graph: nodes + edges re: ppl, place, things; relationships between nodes
  3. wide-column: tables, rows + dynamic columns; Spotify via Cassandra for profile attr & metadata
  4. document: JSON, XML, BSON + key; single doc per record; SEGA via MongoDB for in-game accounts

10 of 10

SOURCES & FURTHER READING

​