If you can wait for 5.1 (in beta now), you can use partitioning to store
a client on a different database in a different geographical site. You'd
need to partition by region/state (assuming you capture address info).
If you wanted to do any reporting, however, you'd need to set up a data
warehouse, and every night do an extract-transform-load (ETL) from the
regional "sites" into your main database.

It might make more sense to have "mini-sites" all over the country -
database, web and application servers.

Since it sounds like development hasn't started, you can probably go
with 5.1 - it should be released before summer.

David

Chris W wrote:
> I have a potential client that is anticipating rapid growth of a web
> site they want me to build. Some quick research tells me that there
> is the potential for as many as 50 million users that will access the
> site for an hour or two every day. All of those users will be located
> in the USA so most of the access will be during the day.. To use the
> web site you will have to have an account and log in. At this time I
> can't really say how much data will need to be stored about each user.
> If this site grows as much as this client thinks, will I need to have
> some kind of load sharing system to access the database?
> I was reading in the MySQL manual about the NDB Cluster storage
> engine. Is this something that would work well in a situation like
> this? One thing that was mentioned was the possibility of having
> servers in different locations which seems to make the Cluster storage
> engine not a good choice.
>
> Can someone here give some insight and suggest other options I could
> look into?
>