Atomic Read-Modify-Write
While RDBMSs offer you a lot of these operations directly (because you are
talking to a central, single server), it can be more difficult to achieve in
distributed systems. They allow you to prevent race conditions in multi-threaded
or shared-nothing application server design. Having these compare and swap
(CAS) or check and set operations available can reduce client-side complexity.
Locking, waits and deadlocks
It is a known fact that complex transactional processing, like 2-phase commits,
can increase the possibility of multiple clients waiting for a resource to become
available. In a worst-case scenario, this can lead to deadlocks, which are hard to
resolve. What kind of locking model does the system you are looking at support?
Can it be free of waits and therefore deadlocks?
We will look back at these dimensions later on to see where HBase fits and
where its strengths are. For now, let us say that you need to carefully
select the dimensions best suited for your issues at hand. Be pragmatic
about the solution and be aware that there is no hard and fast rule that
where an RDBMS is not working ideally that a NoSQL system is the perfect
match. Evaluate your options, choose wisely, and mix and match if needed.
An interesting term to describe is impedance match, which describes the
need to find the ideal solution for a given problem. Instead of using a "one-
size-fits-all" approach, you should know what else is available. Try to use
the system that solves your problem best.
Scalability
While the performance of RDBMSs is well suited for transactional processing, it is less
so for very large-scale analytical processing. This is referring to very large queries
that scan wide ranges of records or entire tables. Analytical databases may contain
hundreds or thousands of terabytes, causing queries to exceed what can be done on
a single server in a reasonable amount of time. Scaling that server vertically, i.e.,
adding more cores or disks, is simply not good enough.
What is even worse is that with RDBMSs, waits and deadlocks are increasing non-
linearly with the size of the transactions and concurrency - i.e., the square of
concurrency and the third or even 5th power of the transaction size.
[18]
Sharding is
often no practical solution, as it has to be done within the application layer, and may
involve complex and costly (re)partitioning procedures.
There are commercial RDBMSs that solve many of these issues, but they are often
specialized and only cover certain aspects. Above all they are very, very expensive.
Looking at open-source alternatives in the RDBMS space, you will likely have to give
up many or all relational features, such as secondary indexes, to gain some level of
performance.
The question is, wouldn't it be good to trade relational features permanently for
performance? You could denormalize (see below) the data model and avoid waits
and deadlocks by minimizing necessary locking. How about built-in horizontal
scalability without the need to repartition as your data grows? Finally, throw in fault
tolerance and data availability, using the same mechanisms that allow scalability, and
what you get is a NoSQL solution - more specifically, one that matches what HBase
has to offer.
Database (De-)Normalization
At scale, it is often required to design schema differently, and a good term to
describe the principle is: Denormalization, Duplication and Intelligent Keys
[19]
(short
Add a comment
Add a comment
Add a comment
Add a comment
Add a comment
Add a comment