1 / 15

NoSQL and RDBMS

NoSQL and RDBMS. IST210 Week 3, Lecture 1. NoSQL = “Not Only SQL”. It is not intended to replace SQL or traditional RDBMS, but to provide an alternative technology suited to particular uses.

kamil
Download Presentation

NoSQL and RDBMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NoSQL and RDBMS IST210 Week 3, Lecture 1

  2. NoSQL = “Not Only SQL” • It is not intended to replace SQL or traditional RDBMS, but to provide an alternative technology suited to particular uses. • They are also not necessarily mutually exclusive. The future may see relational databases blending with Big Table or other NoSQL solutions.

  3. SQL/RDBMS has it’s own advantages: • Well known, rich language • Extensive code base already developed • Exacting/precision responses on complicated data • Focus on accuracy

  4. NoSQL databases take a different approach: • Semi-structured data • Unstructured data • Able to produce results across huge data sets (but not necessarily comprehensive or precise) • Focus on scalability and availability

  5. To Normalize or Not To Normalize? • Normalization is great when you want to do complex analysis or often re-use your data in multiple applications. • Other times you may prefer the speed of storing a wide variety of data in great volumes • You may be working with data that has huge scale but simple structure (Tweets)

  6. What do you know? • Student-led discussion

  7. ACID Properties: • Atomicity • Consistency • Isolation • Durability • The ACID properties, if adhered to, can guarantee transactional accuracy.

  8. Atomicity: • Every transaction is a whole entity and unless all of it is successful, none of it is successful. • This avoids partial updates. • A partial transaction could be a disaster: • Transaction 123 (transfer funds from customer A to customer B): • Part 1: reduce Customer A account balance by $200 • Part 2: increase Customer B account balance by $200

  9. Consistency: • The database will be in a "valid state" before and after the transaction • defined rules, constraints, etc. will be observed

  10. Isolation: • Transactions should have the same outcome if run simultaneously as if run one after another

  11. Durability: • A technical failure (power outage, crash, etc.) should not erase a transaction

  12. CAP Theorem (Brewer’s Theorem): • Consistency • Availability • Partition Tolerance • Distributed Computer systems can achieve up to two at any time, but cannot provide all three. • Works well for services like Facebook (recording posts, displaying a timeline) where minor inconsistencies are tolerable for a greater availability. • (Eric Brewer, UC Berkeley)

  13. BASE: • Basically Available Soft-State Services with Eventual-consistency • Keep the services available and running, sacrifice immediate consistency for availability • Use background operations to "clean up" and resolve problems, like conflicts in transactions.

  14. NoSQL and SQL/RDBMS: • Traditional RDBMS then, may not currently scale to meet demands of certain applications, but NoSQL solutions may also not be able to create the accuracy and consistency necessary for some needs. • You wouldn't want your bank to sacrifice consistency, but you might prefer your social networking to always be up, even if you get a 99% accurate result. • "When it absolutely, positively doesn't have to be right; but it does have to be right-now."

  15. Discussion • Student-led discussion

More Related