When you consider the futures of NoSQL databases, a natural question
arises, how do they differ from relational databases and Hadoop.
In this section, let's summarize the differences and understand the
scenarios where each platform best fits.
Starting with relational databases, first of all,
relational databases have fixed schemas. NoSQL databases don't.
Now the main reason relational databases are fixed schemas is that
the focus is on data integrity. Data is normalized across tables with
proper relations and constraints to guarantee the integrity of data.
NoSQL databases, on the other hand, don't focus on data integrity.
Data is simply written in whatever structure.
In other words, the focus is on flexibility rather than strict
data integrity rules. Data integrity requirements also mandates the
presence of atomic transactions in the relational databases.
This means data lock mechanisms must be in place.
As you might know, atomic transactions, while great for data
integrity, they massively impact scalability.
NoSQL databases however, favor scalability over anything else,
and so typically, have no support atomic transactions.
Oracle NoSQL has an exception to this rule, which we will examine later.
As you can sequence to all of this, write throughputs in the
relational databases are slow when compared to NoSQL databases.
Relational databases need to process and understand the data structure
before data is written and atomic transactions are in place to
guarantee data integrity. NoSQL, however, simply dumps the data with
whatever structure it's written in and this results in much faster
writes and much higher throughput. Also, read throughput in the
relational databases is slower than NoSQL.
Relational databases join data from multiple tables.
Also, depending on the consistency levels, whether it's optimistic or
pessimistic, some read operations might be blocked waiting for lock
data by write transactions to be released.
Again, in NoSQL, such complications do not exist.
Simply locate the shot where data exists and read the data with the
same structure it was written in. No joins have no blocking.
And finally, relational databases typically adopt the
shared storage architecture. Multiple nodes connect to a shared
storage, typically SN. Oracle RAC is a prime example of this architecture.
NoSQL databases, however, adopt the shared nothing architecture where
each node stores and processes its own data.
This means NoSQL databases scale horizontally in a much higher fashion
than shared storage architectures. In summary,
relational databases are still the most widely-used data management
systems and they will continue to be. Applications that demand data
integrity will continue to use relational databases.
Core banking CRMs, ERPs are just examples of such applications.
NoSQL databases, however, are used when high throughput low latency
writes and reads are required. And when data integrity is not the
priority, instead, scalability and flexibility are.
Now when it comes to Hadoop, the difference has become less obvious.
Hadoop like NoSQL does not mandate predefined schemas.
Focus is again on flexibility and scalability and not data integrity.
And Hadoop also adopts a shared nothing architecture with data locality.
The difference, however, is a major one and it's about how data is
stored and retrieved, which directly impacts the latency of data
writes and reads. See as you probably know, data is written to
Hadoop, or more precisely, HDFS, as files that are divided into blocks
of data stored over the cluster. This means write operations incur
the latency of dividing files into blocks.
This also means random updates are not supported, well at least,
not without workarounds such as those implemented by HBase.
Read operations also suffer from latency as data has to be collected
from various blocks across the cluster and that's why Hadoop is best
suited for batch analysis. Data and NoSQL databases, however,
is written as records, not simply as a block of files, meaning data is
indexed by a key and can be queried specifically as a record.
That's why, it's actually a database and not simply some distributed
file storage system. Moreover, records are written into specific
shards and not simply divided into blocks of undistributed files.
This means NoSQL databases support high throughput and low-latency
writes and reads, which make them suitable for real-time
interactive transactional applications.
So now that we have discussed the differences, what do you think is
the most suitable type of applications to run over a NoSQL database.
Well the perfect example is the MoviePlex application.
Assume that this is a very popular online streaming movie application
and millions of users are logged in at the same time.
At all times, the application is restoring all user interactions,
user profile updates, movie listings, movie ratings,
streaming positions, in other words, the place where the movie was
posted, and at the same time, this information is also read whenever
a user logs in to personalize that user's experience.
So in summary, we have massive amount of data being written and read
in a real-time manner. Such applications do not fit Hadoop,
which is suitable for batch processing, and also, do not fit
relational databases, word relations, integrity rules, and table joins
means they favor data integrity over low latency writes and reads.
Therefore, NoSQL databases are the perfect fit for an application such
as MoviePlex where the focus is on throughput and latency for
real-time data interaction and not on relations and integrity.