I know noSQL is all the rage with the crazy kids these days and I know it has its place but why is half of the literature regarding noSQL about solving problems that are trivial in an RDBMS?
This particular article is addressing problems that would not be trivial in an RDBMS. If you're worried about concurrency when incrementing a counter, you're at a level of scale few people get to work on.
There's a legitimate rant to be had about using elephant architecture to serve mouse traffic, and I think that's what annoys me most about the NoSQL fad. But that doesn't mean the problems mentioned in this article don't exist.
"If you're worried about concurrency when incrementing a counter, you're at a level of scale few people get to work on."
I'm not sure I understand. If I make an application that has to increment a counter, shouldn't I always be worried about concurrency?
What I mean is, sure, if I'm serving only a few requests, then of course the probability of running into concurrency issues is lower than a site with more requests/sec. But it's still a matter of chance, there is some probability that two requests will come in at exactly the same time and cause a problem.
You are worrying about correctness of concurrency. Yes, this should always be worried about.
The parent poster is worrying about performance of concurrency. This doesn't need to be worried about unless you are one of about 5-10 tech companies whose name is recognisable to people on the street.
I think we are on the same page. In this particular article I was referring to the paragraph regarding paging results which is ancillary to the main point.
Because RDBMS can only scale as far as your most powerful machine. Unless of course you start sharding to several machines, and then you hit the same issues mentioned in this article.
I think people really overestimate their data-store needs, and underestimate how much a big iron DB server can deliver.
Its probably worth thinking about scaling out on your data end, but until you start hitting some sort of limit on a 8 core 96 gig machine with server level SSD's its probably worth investing your time in other issues.
That's a very valid point. You can get reallllly far with just one really powerful database.
But, if you've built a site on the precondition that one database is enough, with a lot of joins so you can't split tables, and your hardware can't keep up.. you're in a really bad place. I say this out of experience ;)
Just out of curiosity what sort of site would that be? I would be really interested to hear of the use cases that cause a single powerful db server to be insufficient.
Of course over a certain scale this is normal, so im not interested in a site with 50 millions users, but cases where a single DB is not the best solution.
Basically, it was a site with a medium amount of paid users. Probably 10-20k daily uniques. However, the nature and diversity of the data behind this site required thousands of tables and tens of thousands of stored procedures.
Since these queries were built over ~10 years with the expectation of being able to join any of the thousands of tables, it would now be a tremendous undertaking to perform any sort of sharding or other ways of distributing load (other than master-slave replication, which was used widely).
It's been a struggle to keep hardware up to pace with the desired growth of the company. Even with a dedicated data center and top of the line hardware, doubling their user base would probably require a significant architectural undertaking.
Had the site been designed to support an arbitrary amount of distributed database servers from day one, it would now be trivial to grow horizontally.
The scalability you get really depends on the type of queries you fire, which depends on the kind of schema you have. A good schema designed for read (assuming that read is much more frequent than a write for some use-case) rather than write would definietly work out well with a SQL db.
