NoSQL theory: All content tagged as NoSQL theory in NoSQL databases and polyglot persistence
Abel Perez in a post about Cassandra:
Horizontal scalability boils down to the ability to add new hardware to a system without any interruption or downtime. An ideal horizontally scalable system does not require reconfiguration and supports incremental addition of hardware.
Nope. This is the definition of elasticity.
Horizontal scalability is the capability of a system to accept adding or removing multiple nodes (independent units of resources) and making them work as a single system. The scalability of a system can be further categorized as: negative, sub-linear, linear, or supra-linear depending on the shape of the performace1/nodes curve
This is the part where things can get more complicated as there are multiple ways to characterize the performance of a system (e.g. throughput, latency, etc.) ↩
Original title and link: Horizontal Scalability vs Elasticity ( ©myNoSQL)
This question was posted on LinkedIn:
During my research I came across a new database technology called ‘NuoDB’. It seems to share many attributes of NoSQL databases and still maintain a SQL query interface. It uses a key value store as its data storage engine. It also promises the performance and scale of NoSQL databases.
Enterprises that have not yet embraced NoSQL, will be inclined to try this option before going NoSQL way in my opinion. Mainly because it does not require them to change their database interface layer drastically and also because NoSQL databases have not moved towards a standards based query interface yet.
For an outsider this comment might look extremely valid. I mean who in his right mind would give away all the expertise and tools and history of SQL for something like NoSQL?
But the real answer is in the details. “It seems to share many attributes of NoSQL databases” . Ask yourself what are these shared attributes:
- what is the supported data model? The relational model advantages have been discussed over and over for the last 30 years. But there are alternative data models that bring different
- what is the persistence model? Is it disk based, memory based, cluster based? IS it durable?
- what is the distribution model? Is it master-slave or master-master or peer-to-peer or masterless?
- what are the scalability characteristics of the system?
- what are the elasticity characteristics of the system?
In the only comment worth reading, Stefan Edlich correctly points to the tons of NewSQL solutions. Before asking if these systems “pose a threat” to NoSQL databases, I’d firstly ask if they are at least a threat to the existing relational databases first. And the answer is no.
Sid Anand wrote in the State of NoSQL 2012 post:
Many of the NoSQL vendors view the “battle of NoSQL” to be akin to the RDBMS battle of the 80s, a winner-take-all battle. In the NoSQL world, it is by no means a winner-take-all battle. Distributed Systems are about compromises.
I’d go even further and say that data storage is not anymore a winner-takes-all battle. Actually it’s not even a zero-sum game. We are living the polyglot persistence age.
Original title and link: Threat to NoSQL Database? ( ©myNoSQL)
The 5 key elements for a firehose data system as per a presentation by Josh Berkus, CEO of PostgreSQL Experts Inc. summarized by Brian Proffitt on ITworld:
- Queuing software to manage out-of-sequence data
- Buffering techniques to deal with component outages
- Materialized views that update data into aggregate tables
- Configuration management for all the systems in the solution
- Comprehensive monitoring to look for failures
Basically firehose data systems are the perfect showcase of the 4 V’s in Big Data. To get an idea of the complexity involved by such systems check the DataSift architecture which relies on MySQL, HBase, Memcached, Redis, Kafka to deal just1 with the Twitter firehose.
While Twitter is a high volume service, the Internet of Things or the Sensor networks are producing much much more data. ↩
Original title and link: 5 Key Elements for a Firehose Data System ( ©myNoSQL)
Werner Vogels in the post about Amazon DynamoDB:
We had been pushing the scalability of commercially available technologies to their limits and finally reached a point where these third party technologies could no longer be used without significant risk. This was not our technology vendors’ fault; Amazon’s scaling needs were beyond the specs for their technologies and we were using them in ways that most of their customers were not. A number of outages at the height of the 2004 holiday shopping season can be traced back to scaling commercial technologies beyond their boundaries.
Here is what I wrote about the history behind NoSQL databases:
Providing decent solutions, up to a point, to a wide range of problems and covering more scenarios than alternative storage solutions existing at that time, made relational databases the de facto storage for the last 30 years. But during the last years, more and more problems crossed the boundaries of what could have been considered decent solutions leading to the need for specialized, better than good enough alternative solutions. And thus NoSQL databases.
It feels rewarding to get such confirmation from people that are at the forefront of NoSQL.
Original title and link: The History of NoSQL: This Was Not Our Technology Vendors’ Fault ( ©myNoSQL)