Top 17 NoSQL Interview Questions And Answers

Q: When should I use a NoSQL database instead of a relational database?

**Relational databases** enforces ACID. So, you will have schema based transaction oriented data stores. It's proven and suitable for 99% of the real world applications. You can practically do anything with relational databases. But, there are limitations on speed and scaling when it comes to massive high availability data stores. For example, Google and Amazon have terabytes of data stored in big data centers. Querying and inserting is not performant in these scenarios because of the blocking/schema/transaction nature of the RDBMs. That's the reason they have implemented their own databases (actually, **key-value stores**) for massive performance gain and scalability. If you need a NoSQL db you usually know about it, possible reasons are: * client wants 99.999% availability on a high traffic site. * your data makes no sense in SQL, you find yourself doing multiple JOIN queries for accessing some piece of information. * you are breaking the relational model, you have CLOBs that store denormalized data and you generate external indexes to search that data.

Q: When would you use NoSQL?

It depends from some general points: * NoSQL is typically good for unstructured/"schemaless" data - usually, you don't need to explicitly define your schema up front and can just include new fields without any ceremony * NoSQL typically favours a denormalised schema due to no support for JOINs per the RDBMS world. So you would usually have a flattened, denormalized representation of your data. * Using NoSQL doesn't mean you could lose data. Different DBs have different strategies. e.g. MongoDB - you can essentially choose what level to trade off performance vs potential for data loss - best performance = greater scope for data loss. * It's often very easy to scale out NoSQL solutions. Adding more nodes to replicate data to is one way to a) offer more scalability and b) offer more protection against data loss if one node goes down. But again, depends on the NoSQL DB/configuration. NoSQL does not necessarily mean "data loss" like you infer. * IMHO, complex/dynamic queries/reporting are best served from an RDBMS. Often the query functionality for a NoSQL DB is limited. * It doesn't have to be a 1 or the other choice. My experience has been using RDBMS in conjunction with NoSQL for certain use cases. * NoSQL DBs often lack the ability to perform atomic operations across multiple "tables".

Q: How does column-oriented NoSQL differ from document-oriented?

The main difference is that **document stores** (e.g. MongoDB and CouchDB) allow arbitrarily complex documents, i.e. subdocuments within subdocuments, lists with documents, etc. whereas **column stores** (e.g. Cassandra and HBase) only allow a fixed format, e.g. strict one-level or two-level dictionaries. For example a document-oriented database (like MongoDB) inserts whole documents (typically JSON), whereas in Cassandra (column-oriented db) you can address individual columns or supercolumns, and update these individually, i.e. they work at a different level of granularity. Each column has its own separate timestamp/version (used to reconcile updates across the distributed cluster). The Cassandra column values are just bytes, but can be typed as ASCII, UTF8 text, numbers, dates etc. You could use Cassandra as a primitive document store by inserting columns containing JSON - but you wouldn't get all the features of a real document-oriented store.

Q: What does Document-oriented vs. Key-Value mean in context of NoSQL?

A **key-value** store provides the simplest possible data model and is exactly what the name suggests: it's a storage system that stores values indexed by a key. You're limited to query by key and the values are opaque, the store doesn't know anything about them. This allows very fast read and write operations (a simple disk access) and I see this model as a kind of non volatile cache (i.e. well suited if you need fast accesses by key to long-lived data). A **document-oriented** database extends the previous model and values are stored in a structured format (a document, hence the name) that the database can understand. For example, a document could be a blog post and the comments and the tags stored in a denormalized way. Since the data are transparent, the store can do more work (like indexing fields of the document) and you're not limited to query by key. As I hinted, such databases allows to fetch an entire page's data with a single query and are well suited for content oriented applications (which is why big sites like Facebook or Amazon like them). Other kinds of NoSQL databases include column-oriented stores, graph databases and even object databases.

Q: Explain BASE terminology in a context of NoSQL

The **BASE** acronym is used to describe the properties of certain databases, usually NoSQL databases. It's often referred to as the opposite of ACID. The BASE acronym was defined by Eric Brewer, who is also known for formulating the CAP theorem. The **CAP** theorem states that a distributed computer system cannot guarantee all of the following three properties at the same time: * Consistency * Availability * Partition tolerance A **BASE** system gives up on _consistency_. * Basically _available_ indicates that the system does guarantee availability, in terms of the CAP theorem. * _Soft state_ indicates that the state of the system may change over time, even without input. This is because of the eventual consistency model. * _Eventual consistency_ indicates that the system will become consistent over time, given that the system doesn't receive input during that time.

Q: Explain eventual consistency in context of NoSQL

Think about **Eventual consistency** (as opposed to Strict Consistency/ACID compliance) as: 1. Your data is replicated on multiple servers 2. Your clients can access any of the servers to retrieve the data 3. Someone writes a piece of data to one of the servers, but it wasn't yet copied to the rest 4. A client accesses the server with the data, and gets the most up-to-date copy 5. A different client (or even the same client) accesses a different server (one which didn't get the new copy yet), and gets the old copy Basically, because it takes time to replicate the data across multiple servers, requests to read the data might go to a server with a new copy, and then go to a server with an old copy. The term "eventual" means that eventually the data will be replicated to all the servers, and thus they will all have the up-to-date copy. **Eventual consistency** is a must if you want low latency reads, since the responding server must return its own copy of the data, and doesn't have time to consult other servers and reach a mutual agreement on the content of the data. The reason why so many NoSQL systems have **eventual consistency** is that virtually all of them are designed to be distributed, and with fully distributed systems there is super-linear overhead to maintaining strict consistency (meaning you can only scale so far before things start to slow down, and when they do you need to throw exponentially more hardware at the problem to keep scaling).

Question 1

What do you understand by NoSQL databases? Explain.

Accepted Answer

At the present time, the internet is loaded with big data, big users, big complexity etc. and also becoming more complex day by day. NoSQL is answer of all these problems; It is not a traditional database management system, not even a relational database management system (RDBMS). NoSQL stands for “Not Only SQL”. NoSQL is a type of database that can handle and sort all type of unstructured, messy and complicated data. It is just a new way to think about the database.

Question 2

What are NoSQL databases? What are the different types of NoSQL databases?

Accepted Answer

A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases (like SQL, Oracle, etc.).

Types of NoSQL databases:

* Document Oriented
* Key Value
* Graph
* Column Oriented

Question 3

Explain difference between scaling horizontally and vertically for databases

Accepted Answer

* Horizontal scaling means that you scale by adding more machines into your pool of resources whereas 
* Vertical scaling means that you scale by adding more power (CPU, RAM) to an existing machine.

In a database world horizontal-scaling is often based on the partitioning of the data i.e. each node contains only part of the data, in vertical-scaling the data resides on a single node and scaling is done through multi-core i.e. spreading the load between the CPU and RAM resources of that machine.

Good examples of horizontal scaling are Cassandra, MongoDB, Google Cloud Spanner. and a good example of vertical scaling is MySQL - Amazon RDS (The cloud version of MySQL).

Question 4

What are the advantages of NoSQL over traditional RDBMS?

Accepted Answer

**NoSQL is better** than RDBMS because of the following reasons/properities of NoSQL:

* It supports semi-structured data and volatile data
* It does not have schema
* Read/Write throughput is very high
* Horizontal **scalability** can be achieved easily
* Will support Bigdata in volumes of Terra Bytes & Peta Bytes
* Provides good support for Analytic tools on top of Bigdata
* Can be hosted in cheaper hardware machines
* In-memory caching option is available to increase the performance of queries
* Faster development life cycles for developers

Still, **RDBMS is better** than NoSQL for the following reasons/properties of RDBMS:
* Transactions with **ACID** properties - Atomicity, Consistency, Isolation & Durability
* Adherence to **Strong Schema** of data being written/read
* Real time query management ( in case of data size < 10 Tera bytes )
* Execution of complex queries involving **join** & **group by** clauses

Question 5

When should I use a NoSQL database instead of a relational database?

Accepted Answer

**Relational databases** enforces ACID. So, you will have schema based transaction oriented data stores. It's proven and suitable for 99% of the real world applications. You can practically do anything with relational databases.

But, there are limitations on speed and scaling when it comes to massive high availability data stores. For example, Google and Amazon have terabytes of data stored in big data centers. Querying and inserting is not performant in these scenarios because of the blocking/schema/transaction nature of the RDBMs. That's the reason they have implemented their own databases (actually, **key-value stores**) for massive performance gain and scalability.

If you need a NoSQL db you usually know about it, possible reasons are:

* client wants 99.999% availability on a high traffic site.
* your data makes no sense in SQL, you find yourself doing multiple JOIN queries for accessing some piece of information.
* you are breaking the relational model, you have CLOBs that store denormalized data and you generate external indexes to search that data.

Question 6

When would you use NoSQL?

Accepted Answer

It depends from some general points:

* NoSQL is typically good for unstructured/"schemaless" data - usually, you don't need to explicitly define your schema up front and can just include new fields without any ceremony
* NoSQL typically favours a denormalised schema due to no support for JOINs per the RDBMS world. So you would usually have a flattened, denormalized representation of your data.
* Using NoSQL doesn't mean you could lose data. Different DBs have different strategies. e.g. MongoDB - you can essentially choose what level to trade off performance vs potential for data loss - best performance = greater scope for data loss.
* It's often very easy to scale out NoSQL solutions. Adding more nodes to replicate data to is one way to a) offer more scalability and b) offer more protection against data loss if one node goes down. But again, depends on the NoSQL DB/configuration. NoSQL does not necessarily mean "data loss" like you infer.
* IMHO, complex/dynamic queries/reporting are best served from an RDBMS. Often the query functionality for a NoSQL DB is limited.
* It doesn't have to be a 1 or the other choice. My experience has been using RDBMS in conjunction with NoSQL for certain use cases.
* NoSQL DBs often lack the ability to perform atomic operations across multiple "tables".

Question 7

How does column-oriented NoSQL differ from document-oriented?

Accepted Answer

The main difference is that **document stores** (e.g. MongoDB and CouchDB) allow arbitrarily complex documents, i.e. subdocuments within subdocuments, lists with documents, etc. whereas **column stores** (e.g. Cassandra and HBase) only allow a fixed format, e.g. strict one-level or two-level dictionaries.

For example a document-oriented database (like MongoDB) inserts whole documents (typically JSON), whereas in Cassandra (column-oriented db) you can address individual columns or supercolumns, and update these individually, i.e. they work at a different level of granularity. Each column has its own separate timestamp/version (used to reconcile updates across the distributed cluster).

The Cassandra column values are just bytes, but can be typed as ASCII, UTF8 text, numbers, dates etc. You could use Cassandra as a primitive document store by inserting columns containing JSON - but you wouldn't get all the features of a real document-oriented store.

Question 8

What does Document-oriented vs. Key-Value mean in context of NoSQL?

Accepted Answer

A **key-value** store provides the simplest possible data model and is exactly what the name suggests: it's a storage system that stores values indexed by a key. You're limited to query by key and the values are opaque, the store doesn't know anything about them. This allows very fast read and write operations (a simple disk access) and I see this model as a kind of non volatile cache (i.e. well suited if you need fast accesses by key to long-lived data).

A **document-oriented** database extends the previous model and values are stored in a structured format (a document, hence the name) that the database can understand. For example, a document could be a blog post and the comments and the tags stored in a denormalized way. Since the data are transparent, the store can do more work (like indexing fields of the document) and you're not limited to query by key. As I hinted, such databases allows to fetch an entire page's data with a single query and are well suited for content oriented applications (which is why big sites like Facebook or Amazon like them).

Other kinds of NoSQL databases include column-oriented stores, graph databases and even object databases.

Question 9

Explain BASE terminology in a context of NoSQL

Accepted Answer

The **BASE** acronym is used to describe the properties of certain databases, usually NoSQL databases. It's often referred to as the opposite of ACID. The BASE acronym was defined by Eric Brewer, who is also known for formulating the CAP theorem.

The **CAP** theorem states that a distributed computer system cannot guarantee all of the following three properties at the same time:

* Consistency
* Availability
* Partition tolerance

A **BASE** system gives up on _consistency_.

* Basically _available_ indicates that the system does guarantee availability, in terms of the CAP theorem.
* _Soft state_ indicates that the state of the system may change over time, even without input. This is because of the eventual consistency model.
* _Eventual consistency_ indicates that the system will become consistent over time, given that the system doesn't receive input during that time.

Question 10

Explain eventual consistency in context of NoSQL

Accepted Answer

Think about **Eventual consistency** (as opposed to Strict Consistency/ACID compliance) as:

1. Your data is replicated on multiple servers
 2. Your clients can access any of the servers to retrieve the data
 3. Someone writes a piece of data to one of the servers, but it wasn't yet copied to the rest
 4. A client accesses the server with the data, and gets the most up-to-date copy
 5. A different client (or even the same client) accesses a different server (one which didn't get the new copy yet), and gets the old copy

Basically, because it takes time to replicate the data across multiple servers, requests to read the data might go to a server with a new copy, and then go to a server with an old copy. The term "eventual" means that eventually the data will be replicated to all the servers, and thus they will all have the up-to-date copy.

**Eventual consistency** is a must if you want low latency reads, since the responding server must return its own copy of the data, and doesn't have time to consult other servers and reach a mutual agreement on the content of the data.

The reason why so many NoSQL systems have **eventual consistency** is that virtually all of them are designed to be distributed, and with fully distributed systems there is super-linear overhead to maintaining strict consistency (meaning you can only scale so far before things start to slow down, and when they do you need to throw exponentially more hardware at the problem to keep scaling).

Top 17 NoSQL Interview Questions

What are NoSQL databases? What are the different types of NoSQL databases?

What do you understand by NoSQL databases? Explain.

What are the advantages of NoSQL over traditional RDBMS?

Explain difference between scaling horizontally and vertically for databases

When would you use NoSQL?

How does column-oriented NoSQL differ from document-oriented?

When should I use a NoSQL database instead of a relational database?

What does Document-oriented vs. Key-Value mean in context of NoSQL?

What is Selectivity of the query in MongoDB?

What is BASE property of a system?

Explain how would you keep document change history in NoSQL DB?

Explain eventual consistency in context of NoSQL

Explain use of transactions in NoSQL

How do you track record relations in NoSQL?

Explain BASE terminology in a context of NoSQL

Explain the differences in conceptual data design with NoSQL databases?

Is the C in ACID is not the C in CAP?