4 ms·

This sort of post was most useful in the days when the term 'NoSQL' was being thrown around as the silver bullet that would revolutionize one's business, and th

This sort of post was most useful in the days when the term 'NoSQL' was being thrown around as the silver bullet that would revolutionize one's business, and there was a significant knowledge gap between the domain experts -- who quite often weren't the promoters -- and everyone else. While it's still plausible that someone obtains this information for the first time right now, today the mystique around the term 'NoSQL' has more muted, the marketing has become more factual, and a fair number of people understand the different types of data paradigms (KV, document, graph, timeseries) that the newer offerings provide. As it stands, this post is a brief comparison sheet of AWS's datastore offerings, with bite-sized anecdotes that hint at a valuable usecase. It doesn't make a particularly strong case for the necessities, justifications, and tradeoffs of each particular type of paradigm or concrete offering, but is instead a brief content marketing piece with just enough practicality to justify its existence and make its point.

unclebucknasty 8y ago
What's weird is that we create a tech (say, NoSQL) to address the shortcomings of another tech (say, SQL). We then call it a win and give it this strange grace period, during which we don't honestly assess the shortcomings of the new tech. Worse, we actually declare the good parts (say, ACID transactions) of the old tech unnecessary and even dub it a feature that they are absent in the new tech. Finally, the grace period expires and everyone seems to get the memo at the same time. The response is then "This is nuts. What the hell are we doing?" The old tech is then restored to its rightful place and it's on to the next tech.
- CaptainZapp 8y ago
  The ironic part to me from the No SQL crowd was: SQL Bad! SQL Slow! SQL terrible overhead! SQL is just an abstraction layer. What makes relational databases "slow" is actually the overhead to implement ACID and implictly guarantee consistency and integrity at all times. When Facbook losses a dozen status updates that will piss off a few users. When a bank loses a single transaction and depending on the value and importance of that transaction (I.e. mainting a position in FX, with deals that can go into the billions) this can literally kill the bank. Besides: relational databases (which I'd wager are still the backbone of > 90% of businesses) are definitly not slow. And very few companies have such insane requirements like Google, or Facebook. Edit: Wrong word that didn't make sense
  - zzzcpan 8y ago
    Banks do lose transactions and make plenty of other mistakes that result in sudden appearance or disappearance of money from people's accounts. They are also eventually consistent, somewhat strongly. And are the ones who can in fact drop ACID pretty much completely in favor of proper strong eventual consistency with CRDTs and stuff, with all that "consistency and integrity at all times". What makes things slow with interactive transactions in distributed environments is explicit tradeoff of latency and availability for consistency. It just can't be done in bounded time [1]. But that's not the reason traditional databases are slow, they do not actually make this tradeoff in most deployments and are assuming you are ok losing some consistency due to network problems (yeah, so much for that ACID guarantees, you really need distributed algorithms to guarantee consistency if you talk to a database over an asynchronous network, like ethernet). They are slow because for performance SQL is just a bad leaky abstraction and arguing that it can be fast, is like arguing for a sufficiently smart compiler [2] that can turn your high level abstraction into the fastest possible opcode. [1] https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf [2] http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler

unclebucknasty 8y ago

What's weird is that we create a tech (say, NoSQL) to address the shortcomings of another tech (say, SQL). We then call it a win and give it this strange grace period, during which we don't honestly assess the shortcomings of the new tech. Worse, we actually declare the good parts (say, ACID transactions) of the old tech unnecessary and even dub it a feature that they are absent in the new tech. Finally, the grace period expires and everyone seems to get the memo at the same time. The response is then "This is nuts. What the hell are we doing?" The old tech is then restored to its rightful place and it's on to the next tech.

CaptainZapp 8y ago
The ironic part to me from the No SQL crowd was: SQL Bad! SQL Slow! SQL terrible overhead! SQL is just an abstraction layer. What makes relational databases "slow" is actually the overhead to implement ACID and implictly guarantee consistency and integrity at all times. When Facbook losses a dozen status updates that will piss off a few users. When a bank loses a single transaction and depending on the value and importance of that transaction (I.e. mainting a position in FX, with deals that can go into the billions) this can literally kill the bank. Besides: relational databases (which I'd wager are still the backbone of > 90% of businesses) are definitly not slow. And very few companies have such insane requirements like Google, or Facebook. Edit: Wrong word that didn't make sense
- zzzcpan 8y ago
  Banks do lose transactions and make plenty of other mistakes that result in sudden appearance or disappearance of money from people's accounts. They are also eventually consistent, somewhat strongly. And are the ones who can in fact drop ACID pretty much completely in favor of proper strong eventual consistency with CRDTs and stuff, with all that "consistency and integrity at all times". What makes things slow with interactive transactions in distributed environments is explicit tradeoff of latency and availability for consistency. It just can't be done in bounded time [1]. But that's not the reason traditional databases are slow, they do not actually make this tradeoff in most deployments and are assuming you are ok losing some consistency due to network problems (yeah, so much for that ACID guarantees, you really need distributed algorithms to guarantee consistency if you talk to a database over an asynchronous network, like ethernet). They are slow because for performance SQL is just a bad leaky abstraction and arguing that it can be fast, is like arguing for a sufficiently smart compiler [2] that can turn your high level abstraction into the fastest possible opcode. [1] https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf [2] http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler