Steve_C wrote:
> I'm currently developing a social networking site that may, hopefully, in
> the future need to scale out to multiple, maybe even many, database servers.
> Will it happen? Who knows, but I'd like to be prepared for this now, so
> adding additional servers will be quick and somewhat painless. Even if it
> never happens, at least I'll learn something new.
>
> So, this is what I'm thinking....
>
> a database for basic user info
> a database for profiles
> a database for messages
> and so forth
>
> If the site gets to the point where it needs to have additional servers,
> there will be the option of having the databases on their own servers which
> could each serve as masters in the future for replication if needed. The
> database of basic user info would be replicated across all servers so the
> info can be used for joins (to get usernames when querying messages for
> example), since cross database joins require the databases to be on the same
> server.
>
> Since multiple database servers and replication is new to me, I thought I'd
> get some input from you guys here. Does this sound like a good way to go?
> Or, is there a better way to do this? I am aware that I could just put
> everything into one database and replicate it out to many servers, but I
> figured that since some databases will be used far more often than others,
> it would be better to separate them out so that the most used databases
> could possibly get more slaves than the less used ones.
>
> Thanks in advance for any input, suggestions, etc.
>
> Steve
>
>
>


Are stock options available?