3 ms·

That's a very obtuse point of view. I'm curious sociologically: what field do you work in and what your exposure to data is? Consider an inventory system for

by kev009 13y ago

That's a very obtuse point of view. I'm curious sociologically: what field do you work in and what your exposure to data is? Consider an inventory system for a big box retailer. I can't think of anything better than a fat-ass RDBMS as the primary data store. Sharding sounds like a horrific idea. There are myriad workloads like this. Personally, I've seen pgsql handle terabytes of data just fine and it wasn't really noteworthy or a source of problems to even bring up considering something else. YMMV but it's a good idea to use logic and reason to dictate architecture instead of following the shiny thing or hubris.

davidw 13y ago
Well, yes and no. Everybody knows that relational databases don't scale because they use JOINs and write to disk. Also, relational databases weren't built for web scale. MongoDB handles web scale. You turn it on and it scales right up. And before you knock shards, shards are the secret ingredient in the web scale sauce. They just work. Furthermore, relational databases have impetus mismatch, and Postgresql is slow as a dog. MongoDB will run circles around Postgresql because MongoDB is web scale.
- rimantas 13y ago
  Check this "web scale" out: http://smalldatum.blogspot.com http://smalldatum.blogspot.com (via http://dom.as/2014/03/31/mongo-io/ http://dom.as/2014/03/31/mongo-io/ )
  - davidw 13y ago
    I was actually referring to this: http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/ - which is what contingencies' comments reminded me of, but I guess people either didn't get it or thought it was a bit stale. C'est la vie. I am a happy Postgres user and always default to it unless I am really sure a project calls for something else.
    - captainmojo 13y ago
      It cracked me up! And same here, I tell people to start their datastore selection with looking for a reason NOT to use Postgres.
- ro_sharp 13y ago
  Are you being intentionally sarcastic? Because this reads a lot like http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/ Edit: Whoops, just read your reply :)
  - GFischer 13y ago
    His post was a textbook example of Poe's Law http://en.wikipedia.org/wiki/Poe's_law http://en.wikipedia.org/wiki/Poe's_law "without a clear indication of the author's intent, it is difficult or impossible to tell the difference between an expression of sincere extremism and a parody of extremism"
- pistle 13y ago
  Thank you for this. TO all the haters, davidw is quoting a funny animated pokeyfun of people who lightly consider a DB problem and throw out the NoSQL mantras, without even understanding what they, themselves, are even saying and implying.
- sanxiyn 13y ago
  You know what is web scale? WebScaleSQL is. :) http://webscalesql.org/ http://webscalesql.org/
deleted 13y ago
[deleted]
contingencies 13y ago
Sure, if you are running stats across everything in a nontrivial and frequently changing way, then you have a great ally in an RDBMS. But I don't believe many people do that, because usually that sort of stuff is pretty damn predictable, executed offline, or can be consolidated from shards. However, if you have any of the following: (1) vastly different security requirements for different parts of your datastore (2) vastly different backup schedules or temporal sensitivities (3) privacy requirements deriving from different legal jurisdictions (4) wish to scale by running on commodity hardware (5) cannot tolerate any downtime whatsoever ... and probably many other cases ... then in my experience you are going to meet some serious issues with conventional RDBMS, at least with the vast majority of configurations. I'm all for logic and reason too... but your comments seem closer to name-calling and a single example.
- arethuza 13y ago
  Apart from your point on "wish to scale by running on commodity hardware" I'd say that relational databases handle all of those other things pretty well - might cost you an arm and a leg for the licenses, hardware and network connections but those goals are achievable. Anyway, in a lot of environments it's application's that drive choice of database engine - not the other way round.
- kev009 13y ago
  I counter that many people have met each of your numbers for the past 20 years using commercial RDBMS. I can't think of anything that is magnificently easier or better at solving your numbers, especially all together. #4 seems less relevant, is it really cheaper than operationalizing a distributed system? These days, likely for situations where consistency can be relaxed. Not so for many business workloads. Can you enlighten us with some example products for your numbers?
  - contingencies 13y ago
    Haha, went out and these comments got downvoted to pluto. Honestly though, I haven't heard a decent argument in response other than "lazy is good". Sure, but architecturally, you're basically in the "engineers run the architecture" or "its an architecture of convenience for business purposes" camp. I'm in the former, I'd like to hope that some nontrivial subset of the participants here are in the former, but most are no doubt in the latter. People get upset when you slight their world. That's understandable. The TLDR is: even if people made a lot of stuff happen 20 years ago; it doesn't justify using the same methods today, and discussing the tradeoffs is constructive not dismissive.

by kev009 13y ago

davidw 13y ago

Well, yes and no. Everybody knows that relational databases don't scale because they use JOINs and write to disk. Also, relational databases weren't built for web scale. MongoDB handles web scale. You turn it on and it scales right up. And before you knock shards, shards are the secret ingredient in the web scale sauce. They just work. Furthermore, relational databases have impetus mismatch, and Postgresql is slow as a dog. MongoDB will run circles around Postgresql because MongoDB is web scale.

rimantas 13y ago
Check this "web scale" out: http://smalldatum.blogspot.com http://smalldatum.blogspot.com (via http://dom.as/2014/03/31/mongo-io/ http://dom.as/2014/03/31/mongo-io/ )
- davidw 13y ago
  I was actually referring to this: http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/ - which is what contingencies' comments reminded me of, but I guess people either didn't get it or thought it was a bit stale. C'est la vie. I am a happy Postgres user and always default to it unless I am really sure a project calls for something else.
  - captainmojo 13y ago
    It cracked me up! And same here, I tell people to start their datastore selection with looking for a reason NOT to use Postgres.
ro_sharp 13y ago
Are you being intentionally sarcastic? Because this reads a lot like http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/ Edit: Whoops, just read your reply :)
- GFischer 13y ago
  His post was a textbook example of Poe's Law http://en.wikipedia.org/wiki/Poe's_law http://en.wikipedia.org/wiki/Poe's_law "without a clear indication of the author's intent, it is difficult or impossible to tell the difference between an expression of sincere extremism and a parody of extremism"
pistle 13y ago
Thank you for this. TO all the haters, davidw is quoting a funny animated pokeyfun of people who lightly consider a DB problem and throw out the NoSQL mantras, without even understanding what they, themselves, are even saying and implying.
sanxiyn 13y ago
You know what is web scale? WebScaleSQL is. :) http://webscalesql.org/ http://webscalesql.org/

deleted 13y ago

[deleted]

contingencies 13y ago

Sure, if you are running stats across everything in a nontrivial and frequently changing way, then you have a great ally in an RDBMS. But I don't believe many people do that, because usually that sort of stuff is pretty damn predictable, executed offline, or can be consolidated from shards. However, if you have any of the following: (1) vastly different security requirements for different parts of your datastore (2) vastly different backup schedules or temporal sensitivities (3) privacy requirements deriving from different legal jurisdictions (4) wish to scale by running on commodity hardware (5) cannot tolerate any downtime whatsoever ... and probably many other cases ... then in my experience you are going to meet some serious issues with conventional RDBMS, at least with the vast majority of configurations. I'm all for logic and reason too... but your comments seem closer to name-calling and a single example.

arethuza 13y ago
Apart from your point on "wish to scale by running on commodity hardware" I'd say that relational databases handle all of those other things pretty well - might cost you an arm and a leg for the licenses, hardware and network connections but those goals are achievable. Anyway, in a lot of environments it's application's that drive choice of database engine - not the other way round.
kev009 13y ago
I counter that many people have met each of your numbers for the past 20 years using commercial RDBMS. I can't think of anything that is magnificently easier or better at solving your numbers, especially all together. #4 seems less relevant, is it really cheaper than operationalizing a distributed system? These days, likely for situations where consistency can be relaxed. Not so for many business workloads. Can you enlighten us with some example products for your numbers?
- contingencies 13y ago
  Haha, went out and these comments got downvoted to pluto. Honestly though, I haven't heard a decent argument in response other than "lazy is good". Sure, but architecturally, you're basically in the "engineers run the architecture" or "its an architecture of convenience for business purposes" camp. I'm in the former, I'd like to hope that some nontrivial subset of the participants here are in the former, but most are no doubt in the latter. People get upset when you slight their world. That's understandable. The TLDR is: even if people made a lot of stuff happen 20 years ago; it doesn't justify using the same methods today, and discussing the tradeoffs is constructive not dismissive.