Choosing SQL Vs NoSQL

In this blog, we shall be discussing about a strategy to choose from Relational & Non-Relational databases.

Question #1.) Can you showcase the difference between the volumes of the data being handled earlier and now ?

Question #2.) Back In 1970s, how much data was considered as enough ?

Question #3.) What was the design principle with the databases, back in earlier times ?

Question #4.) What’s the change in the volume of the data being handled in 2010 ?

Question #5.) Where all NoSQL databases are being used ?

Question #6.) How do we interact with RDBMS like creating a record, modifying record, deleting an entry, etc. ?

Question #7.) What was the threshold when FaceBook had to switch from the RDBMS ?

Answer:- It was somewhere, when FB onboarded around 100 Crore Users on it’s platform.

Question #8.) How is the Latency related to the User-Experience ?

Question #9.) What’s the state of the NOSQL databases looks like today ?

Question #10.) What are the different varieties of NOSQL databases possible ?

Question #11.) What‘s the guiding principle for RDBMS ?

Question #12.) What are the key aspects for which RDBMS is being loved for?

Question #13.) What’s the guiding principle for NOSQL ?

Question #14.) What are the key aspects for which NOSQL is being loved for?

Question #15.) What is OLTP Vs OLAP ?

Question #16.) What’s the major difference between Relational & NoSql databases ?

• RDBMS can scale vertically. Though, we can have Master-Slave architectures as well.
• NOSQL can scale horizontally. If there is more traffic, we can just add-on more nodes, as simple as that.

Question #17.) Explain the Key-Value type of NoSql ?

Question #18.) What are the possible options available with NOSQL ?

Question #19.) What’s the NoSql design ?

Question #20.) When to choose the NoSql database ?

Question #21.) When to choose the RDBMS database ?

Question #22.) What are the key aspects to consider, while choosing Nosql Vs RDBMS?

1.) Following are the scenarios, where NoSql can be chosen :-

• First, you might be thinking a NoSQL database if you’re building the next hyper-scale app and potentially need to support millions or more users with near immediate response times.
• In case, you work in a sector that needs to quickly support the burst capability at certain times of the year and then scale back to keep costs down.
• If you are dealing with terabytes or more of data and millions, billions, or more rows per table.
• And finally, maybe you have a use case that fits one of the many NoSQL models, like time series, document, key value, or graph.

2.) Following are the scenarios, where a relational-database can be chosen :-

• If we have a legacy app using a relational database and there is no performance, data size, or other pressure forcing you to look at a change.
• If you have an absolute requirement on guaranteed transactions, and you can tolerate some constraints and scale.
• Maybe you want to execute both analytics and transactional queries on data without the need to maintain multiple systems to do so.
• And finally, maybe you’re not working with big data and have up to thousands to millions of rows of data per table.

I want to be clear, these points are all debatable. But if you need performance at scale, have continuously growing data, require resiliency during failures, and flexibility in your data modeling, a NoSQL database is probably a really good choice. But if these things aren’t as much of a concern and your current relational database is working and performing well for you, it may not be worth the effort to switch.

Question #23.) Can we augment our existing RDBMS with some NoSql as well ?

• You can always augment your relational database capability with NoSQL databases for specific purposes, like fast lookups using a key value store.
• That can decrease load on your relational database while giving you lightning fast performance. Or maybe you can replicate data from your relational database to a graph database to get insights that help connect the dots in cases like fraud detection.

There’s no rulebook that says you can’t mix and match. Finally, no matter the requirements, you should always performance test and push the boundaries of your databases and data models.

That’s all in this blog guys. Kindly clap on this page, if you liked reading this.