You Might Be A Data Radical
hackingdistributed.com
You Might Be A Data Radical
1–7 of 7 posts
Re: You Might Be A Data Radical
#2I'm the "radical" author of this post. It expands this other post (http://hackingdistributed.com/2013/03/07/partition-tolerance...) that busts some commonly propagated myths about partition tolerance in data stores.
But the part that I really wanted to emphasize, and I worry might get lost in the surrounding discussion about partition-obliviousness, is the following:
NoSQL has the potential to supplant RDBMSs and capture the
bulk of the database market. The "daddy knows best"
attitude that RDBMSs bring to data management, the way they
strip all information that the developer had about her data
and force her to write a declarative specification of what
she wants, only to try to then come up with an efficient
evaluation plan in the query optimizer, all reflect a
klunky aesthetic to system design that the lean and mean
NoSQL movement can and will supplant. NoSQL is to RDBMSs
what Unix was to Multics.
Re: You Might Be A Data Radical
#3I'm the "radical" author of this post. It expands this other post ( http://hackingdistributed.com/2013/03/07/partition-tolerance... ) that busts some commonly propagated myths about partition tolerance in data stores. But the part that I really wanted to emphasize, and I worry might get lost in the surrounding discussion about partition-obliviousness, is the following: NoSQL has the potential to supplant RDBMSs and c…
> NoSQL is to RDBMSs what Unix was to Multics.
A simplified version that will eventually have to re-invent a lot of what it stripped away to become so much simpler?
Re: You Might Be A Data Radical
#4I'm the "radical" author of this post. It expands this other post ( http://hackingdistributed.com/2013/03/07/partition-tolerance... ) that busts some commonly propagated myths about partition tolerance in data stores. But the part that I really wanted to emphasize, and I worry might get lost in the surrounding discussion about partition-obliviousness, is the following: NoSQL has the potential to supplant RDBMSs and c…
There are two primary categories of applications that were traditionally developed on sql platforms: Operational and Analytical. Operational applications want the ACID and transactions features of the RDBMS, but analytical applications benefit tremendously from the SQL language itself. If there is a question that my user wants me to answer and I can answer it by writing a SQL query but in the NoSQL world I have to write a program, I just lost one of my super powers. SQL gives me the ability to rapidly answer complex questions about my data. Please recognize that ACID and transactions are not your only hurdles to successfully competing with RDBMS.
Re: You Might Be A Data Radical
#5I'm the "radical" author of this post. It expands this other post ( http://hackingdistributed.com/2013/03/07/partition-tolerance... ) that busts some commonly propagated myths about partition tolerance in data stores. But the part that I really wanted to emphasize, and I worry might get lost in the surrounding discussion about partition-obliviousness, is the following: NoSQL has the potential to supplant RDBMSs and c…
There are two primary categories of applications that were traditionally developed on sql platforms: Operational and Analytical. Operational applications want the ACID and transactions features of the RDBMS, but analytical applications benefit tremendously from the SQL language itself. If there is a question that my user wants me to answer and I can answer it by writing a SQL query but in the NoSQL world I have to wr…
Absolutely spot on. But there is no reason why the translation from the user's query into a series of data accesses cannot happen in the front end. In many ways, NoSQL is a reaction to the poor job RDBMSs were doing in the front end. Everyone has seen the cases where AWK programs on desktops could outperform expensive Oracle servers, and that's mostly because they enable the user to put to use what they know of their specific data and their access patterns.
So, in between "writing a program for each query" (which I agree is a non-starter in some settings) and "SQL is the one and only interface" lies an exciting space of opportunities.
Re: You Might Be A Data Radical
#6I'm the "radical" author of this post. It expands this other post ( http://hackingdistributed.com/2013/03/07/partition-tolerance... ) that busts some commonly propagated myths about partition tolerance in data stores. But the part that I really wanted to emphasize, and I worry might get lost in the surrounding discussion about partition-obliviousness, is the following: NoSQL has the potential to supplant RDBMSs and c…
> NoSQL is to RDBMSs what Unix was to Multics. A simplified version that will eventually have to re-invent a lot of what it stripped away to become so much simpler?
:-) Maybe. Let's not forget the part where the new thing, with its limber, simpler architecture completely displaces the old klunker, and provides an extensible, easily customized platform to its users.
Re: You Might Be A Data Radical
#7I'm the "radical" author of this post. It expands this other post ( http://hackingdistributed.com/2013/03/07/partition-tolerance... ) that busts some commonly propagated myths about partition tolerance in data stores. But the part that I really wanted to emphasize, and I worry might get lost in the surrounding discussion about partition-obliviousness, is the following: NoSQL has the potential to supplant RDBMSs and c…
There are two primary categories of applications that were traditionally developed on sql platforms: Operational and Analytical. Operational applications want the ACID and transactions features of the RDBMS, but analytical applications benefit tremendously from the SQL language itself. If there is a question that my user wants me to answer and I can answer it by writing a SQL query but in the NoSQL world I have to wr…
I don't see why there's a competition. SQL is great for analytics. NoSQL is great for operations. When you want to do analytics on the data from your operations--which are presumably Big Data and far too much to pack into a single node--just query your Operations data using statistical sampling methods to generate a representative data set, stuff that "analytic snapshot" into any old RDBMS, and query it to your heart's content.
(And if they're not Big Data--well, then, the solution is even more obvious. :)