21–30 of 34 posts
Can we please stop with these ridiculous "SQL is utterly hopeless" and SQL vs NoSQL articles? Saying that SQL is not scalable, full stop, is ignoring decades of real-world evidence. There's a right tool for every job, and SQL isn't always that tool, but articles like this aren't helpful in the slightest.
I can't count how many Rails fanboys have written this same article. What do they think big companies, banks, government agencies -- organizations with huge databases -- use? What kind of database do the RoR developers think the real world runs on? Claiming that SQL databases don't scale, especially using MySQL as the example, is simply ignorant. Oracle, DB2, SQL Server all scale to handle databases orders of magnitu…
Well, they don't scale indefinitely, and you do run in to Brewers Theorem at some point. While you're right in saying that if you have enough cash and horsepower to throw at SQL databases you can get a very long way, there is some point where anything which must be consistent is going to have an impact on availability. This gets especially critical once you stop assuming that data can be centralised. Once your requir…
SQL and the Relational data model are not limited by Brewers Theorem, this is a myth.
More info here: http://sergeitsar.blogspot.com/2011/02/mongodb-vs-clustrix-c...
In my experience I have seen more atrocities committed due to developers using a relational database as a file-system, an XML document, a key value store or some variation in between.
When people complain about scaling in relational databases they usually mean that it is more rigid, and not easily adapted to changes. Which is valid and is why you cannot apply software development practices to database design. With database design you have to plan for the future and think out how your solution will grow as to not paint yourself into a corner. Further in relational design there is no such thing as premature optimization, if one thinks there is, one has already failed at setting up a robust relational database architecture.
At one of my start-ups we supported massive amounts of traffic from Hotels.com, Orbitz, Travelocity and Expedia all looking for pricing and allotment each time someone hit their front door and we did it all on applications that where backed by relational databases. We never saw Google or Facebook size traffic, but we had constant load of more than any one of those travel sites and many times load of all of them combined.
A solid application architecture and a sound relational model can scale quite well you just have to have good people that understand each discipline.
Isn't that what Oracle RAC is for? If you are managing that much data, and you don't want to go the specialty DB route (nosql, for example) RAC scales. It's also hellishly complicated, but so is the problem.
I think TFA gets it all wrong. It's not that SQL databases do not scale per se , they just can't arbitrarily scale. Most applications today manage pretty well with nothing more than sharding and replication. Sure, it's not the optimal solution, and it's not easy - but it gets the job done. Facebook, at the very core (behind all the layers of cache), run, arguably, the largest MySQL landscape in the world - and they s…
"It's not that SQL databases do not scale per se, they just can't arbitrarily scale." Tell that to Clustrix, Vertica, and VoltDB. SQL is a query language, Relational is a data model, neither one prevents scaling out.
NoSQL databases scale much easier. Just add a new node and you are done. +1. Many of them are also freeware. +1 again. Many of them are also faster, because no parsing is done, +1. Many of them don't have and don't need locking. +1. No looks mean no write waiting. +1.
Decide yourself.
Oracle RAC may come closest to addressing most of these issues. Of course it is pricey. However it fulfills pretty much all the constraints mentioned here - application transparency while scaling(sharding does not involve changing the app), horizontal scalability(add nodes as needed), failover for both read & write transactions. It sounds like sale-pitch for RAC but it seems to geared to deal with these kind of scena…
I'm not trying to defend the article though.
I take issue with the assumption here. What you want, which is obviously "free/open mysql-ish thing that scales indefinatly", is not a problem people have been working that hard to solve until quite recently.
To put it in perspective, 20 years ago, many banks offered no access to your money outside open hours and the internet was not a thing normal people used.
Today, if you go to Oracle or IBM, you'll find that they'll be happy to help you solve your enourmous problem at great profit to them. The thing that's changed in the last few years, is that Web 2.0 guys want the same power (or more) for a tiny fraction of the cost.
This is a good thing. This is exciting. People recognize that the status quo sucks and are working hard on change. The solution will probably involve some SQL, and probably some other tools as well. Don't be such a downer. ;-)
What Adam means to say is "some of the semantics defined by SQL are hard to get correct while maintaining scalability." Hard is very different from impossible, and there is a large number of very smart people currently solving this problem very well. There is another large number of smart people trying to solve the problem by ignoring the hard parts of the semantics. It seems they will likely come up with something very fast and scalable, but ultimately less useful for certain things which are done easier with proper SQL semantics. In fact, it's not clear in all cases that they are even making something that's more performant: cf. http://sergeitsar.blogspot.com/2011/01/mongodb-vs-clustrix-c...
Saying "SQL Databases Don't Scale" is like saying "oil paintings on wood aren't appealing". Not all oil-on-wood paintings are good, but some are, and some tempera-on-fresco paintings suck too. The logic is simply invalid.