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?
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
