Greg Lorriman wrote:
>> I've been down the road of traditional clustering with appservers
>> sending messages to each other furiously duplicating state, and also
>> with session affinity to avoid some of the duplication, but presently I
>> feel the "shared nothing" architecture is best for me. It has some
>> successful precedences with high-volume sites, and you basically get it
>> for free with Ruby/Rails/Apache/Mongrel.
> 
> I would agree in general, but as you mentioned earlier eventually
> something is going to become a bottleneck if user growth is enourmous.
> I expressely wish to explore the clustered appserver side of things
> since it does ultimately scale endlessly. This particular app is
> simple enough for me to consider trying my had at it.
> 
> So it is interesting to read your comments about "furious duplication"
> and session affinity. Were there other notable features to such a
> system, and to the developemnt of it?

Probably the most "notable" feature was that I really do want to do it 
again :) I don't know of any highly scalable architectures that use that 
type of approach - they could very well exist, I just don't know of 
them. On the other hand, I know of several using the "share nothing" 
approach.

It might be enlightening for you to perform some tests to determine what 
type of load is required to cause the database to become the limiting 
factor in your growth. It may be premature for you to worry about it. It 
might be cheaper for you to simply purchase a faster database server.

This should do:
http://www.sun.com/servers/highend/sunfire_e25k/index.xml

Or even something more attainable:
http://www.dell.com/content/products/productdetails.aspx/pedge_6800?c=us&l=en&s=bsd&cs=04

If we ignore the fact that you most likely can't create a workload large 
enough to swamp a fast database server (and if you can, you'll have no 
trouble hiring some brilliant performance freaks to handle the mundane 
scaling task while you do the fun stuff), you may want to consider other 
ways of reducing the limiting factor of the database besides 
partitioning your data - maybe one database instance for insert/updates 
with replication to several read/only database instances for example.

Google for livejournal architecture - there is some interesting info 
regarding how they scaled.

> 
> Greg
>