Life may be much simpler for you when you scale if you use a nosql option, at least for some things - redis for example is a great replacement for large join tables (picture tags, user friends, etc.). Also I've found that good row-level caching (on one of our projects, 98.5% hit rate) is far superior to multiple replicas. In other words, you might try to find ways to lighten up mysql if not replace it altogether.
Cheers, Marc -- getCloudCache.com On Wed, Mar 24, 2010 at 4:50 PM, brianp <[email protected]> wrote: > I wish I had known about this place before I paid for my current > hosting =S . Unfortunately I think I'll be staying with my current > host until I see problems or at least start getting customers. > As long as I keep scalability in ind through the whole process I > should be okay. Prepping for multiple db's instances, and backend > queuing I should be able to move anywhere and scale accordingly... > right? > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rubyonrails-talk%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
