|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 3
Misconception No. 1: You can't build an online application without ACID compliance
This misconception is flat out wrong and largely stems from built-in biases that we RDBMS folks have developed over the past
two decades. Fortunately, you can easily find hundreds of companies such as eBay, Instagram, and Netflix building mission-critical online applications without full ACID compliance.
Misconception No. 2: ACID is an all-or-nothing proposition
Many people forget that ACID is an acronym representing four distinct characteristics: atomicity, consistency, isolation,
and durability. In today's world of online applications, developers and architects make trade-offs to serve the greatest need.
Modern NoSQL databases offer various pieces of ACID that serve the needs of a given application just fine. Postrelational technologies often sacrifice consistency for performance reasons, while following (at least partially) the "AID" aspects of ACID. That's what I mean when I say it's not an all-or-nothing proposition. Parts of ACID may still remain relevant for your application, so you optimize for those accordingly.
Misconception No. 3: Eventual consistency violates the "C" in "ACID"
A few years ago, I wrote a blog post to address this misconception more thoroughly, but the gist is that for many DBAs, the word "consistency" has two very different
meanings. "Consistency" in ACID refers to the enforcement of constraints or rules for a given entry in a database. When we
talk about eventual consistency in a database such as Cassandra, we mean something entirely different -- namely, the temporal
accuracy of the data itself.
In a distributed system, the same piece of data is usually replicated to multiple machines. When you update that piece of information on one of the machines, it may take some time (usually milliseconds) to reach every machine that holds the replicated data. This creates the possibility that you might get information that hasn't yet updated on the replica. In the old relational world, this conundrum comes very close to what we call a "dirty read."
This approach can present its own set of challenges at times, but the point is that eventual consistency is a different issue than the consistency definition you find in ACID. In order for developers to appropriately manage this new dynamic, it's important that they not confuse the two definitions.
Misconception No. 4: Databases and applications have a 1:1 relationship, so it's either/or between relational and NoSQL technologies
Years ago when we wrote applications at much smaller scale, life was easy: We picked a database, wrote our application, and
were done. In fact, a single database system such as an Oracle instance would often house multiple schemas that represented
different applications.
Today's applications are much more sophisticated. The idea of running a single database technology for a datastore is passé. A few years ago, Martin Fowler highlighted a trend called "polyglot persistence" that is now the normative architecture for modern applications. Virtually every customer I talk to houses a services layer between multiple database technologies and the app they power. This trend has established itself firmly in the real world. Polyglot persistence allows us to use the right technology for the right workload inside an application, which can pay huge dividends and enable functionalities not possible in a 1:1 schema.