What is the point of Heroku (or other server farms) if Dbs do not scale? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. 开发者_如何学Python Closed 11 years ago.

Since most of the time an application's bottleneck is found in the db SQL code and given that ActiveRecord adds an abstract layer which in itself degrades performance, it would seem that there is little use in scaling the application server. What is the point of adding more dynos if the least common denominator in terms of performance turns out to be the db anyway?

Here is a blog post from heroku:

http://adam.heroku.com/past/2009/7/6/sql_databases_dont_scale/

---

You need to be able to scale all parts of the web app to make it truly elastic. The real benefit with Heroku comes from the system they wrote around AWS, so for example, if an instance were to be killed, it is quickly replaced, keeping your app online.

Furthermore, when you reach a certain size, load balancing becomes essential for uptime, heroku abstracts this all away from the user and just makes this happen- which is just as well, because system admin is a skill in itself.

SQL databases can be scaled by use of replication. It's works very well and is robust.

What makes each application scale is specific to the application; if you have a lot of 'uncacheable' html pages, you will have to have a large number of dynos at the front to process that, equally if you can cache a lot, then maybe the balance will be at the database level. It's unique to your situation.

---

Heroku has other database backends. If SQL is killing you, move the slow data to MongoLab, Cloudant (CouchDB) or MongoHQ.

If your data is really a graph database, save your SQL server the trouble and use Heroku's Neo4j instances.

Of course, now you've made a trade-off and there's certain things that you can't do anymore because you've changed DB paradigms and world views. Concepts change, your code will change and you'll lose some features. But at least you can scale on commodity hardware (at least the promise) linearly. Can't comment on the prices, looks like not a lot of storage even at the upper ends (except for CouchDB).

I agree with what @cjm2671 said except for the replication bit. You can scale reads out with master-slave but doing master-master is really hard. Especially if you are geographically spread out. Even if you could do master-master over a fast pipe, SQL, transactions are going to kill you before you reach even a dozen database nodes. You can throw hardware and custom NewSQL products at it but I don't think there's a silver bullet. Normally, transaction stuff can stay in SQL land and all your OMG horrible data can be loaded into something less relational and speedy. Of course, now the issue is how do you keep the data in sync or do reporting and analytics on both database types. But that's still a solvable problem with a few routes to take.