分库可以在model中加入
  establish_connection :your_connection
  self.abstract_class = true
实现.
分表应该也可以用类似的方法:
set_table_name

Rails遗留数据库访问之二分库分表
Rails遗留数据库访问之一动态ORM
Rails中实现分表（1）垂直分表
项目中遇到的问题（二）（动态创建MODEL）
Rails是否可以这样解决这个辣手的问题?
Rails中如何支持数据库分表啊

http://stackoverflow.com/questions/44145/database-sharding-and-rails
http://stackoverflow.com/questions/5981724/multiple-database-tables-within-one-ar-model-in-rails-3
https://github.com/aglasgall/rails-sharding
http://www.engineyard.com/blog/2009/a-quick-primer-on-sharding-for-ruby-on-rails/
http://blog.sphereinc.com/2010/04/its-boring-to-scale-with-ruby-on-rails/
http://kovyrin.net/2010/04/16/dbcharmer-rails-can-scale/
https://www.ruby-toolbox.com/categories/Active_Record_Sharding
https://www.ruby-toolbox.com/projects/octopus
https://www.ruby-toolbox.com/projects/data_fabric

how RoR scales
I've said it before, but it bears repeating: There's nothing interesting about how Ruby on Rails scales. We've gone the easy route and merely followed what makes Yahoo!, LiveJournal, and other high-profile LAMP stacks scale high and mighty.

Take state out of the application servers and push it to database/memcached/shared network drive (that's the whole Shared Nothing thang). Use load balancers between your tiers, so you have load balancers -> web servers -> load balancers -> app servers -> load balancers -> database/memcached/shared network drive servers. (Past the entry point, load balancers can just be software, like haproxy).

In a setup like that, you can add almost any number of web and app servers without changing a thing.

Scaling the database is the "hard part", but still a solved problem. Once you get beyond what can be easily managed by a decent master-slave setup (and that'll probably take millions and millions of pageviews per day), you start doing partitioning.

Users 1-100K on cluster A, 100K-200K on cluster B, and so on. But again, this is nothing new. LiveJournal scales like that. I hear eBay too. And probably everyone else that has to deal with huge numbers.

So the scaling part is solved. What's left is judging whether the economics of it are sensible to you. And that's really a performance issue, not a scalability one.

If your app server costs $500 per month (like our dual xeons does) and can drive 30 requests/second on Rails and 60 requests/second on Java/PHP/.NET/whatever (these are totally arbitrary numbers pulled out of my...), then you're faced with the cost of $500 for 2.6 million requests/day on the Rails setup and $250 for the same on the other one.

Now. How much is productivity worth to you? Let's just take a $60K/year programmer. That's $5K/month. If you need to handle 5 million requests/day, your programmer needs to be 10% more productive on Rails to make it even. If he's 15% more productive, you're up $250. And this is not even considering the joy and happiness programmers derive from working with more productive tools (nor that people have claimed to be many times more productive).

Of course, the silly math above hinges on the assumption that the whateverstack is twice as fast as Rails. That's a very big if. And totally dependent on the application, the people, and so on. Some have found Rails to be as fast or faster than comparable "best-of-breed J2EE stacks".

The point is that the cost per request is plummeting, but the cost of programming is not. Thus, we have to find ways to trade efficiency in the runtime for efficiency in the "thought time" in order to make the development of applications cheaper. I believed we've long since entered an age where simplicity of development and maintenance is where the real value lies.

其实正如zhangc之前说，理论的问题都清楚，关键还是实践！