|
Home > Archive > MySQL ODBC Connector > February 2006 > MYSQL: Unlimited Forums, Scalablity Issues, advice please?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
MYSQL: Unlimited Forums, Scalablity Issues, advice please?
|
|
|
| Hi there,
I am in the midst of creating a forums hosting site.
1. It has to be highly scalable, so I doubt a single MYSQL db with TONS
of "subforums that simulate full forums" would do.
2. Also regarding scalablity, I hope to "Add capacity" as and when its
needed. So i'll have one server running initially, and when it gets too
crowded, i'll get two servers etc.
3. I will be providing a user with a "dashboard" that allows him to view
all his subscribed posts across ALL forums. So lets say a user is a
member of 25 forums, this dashboard view will allow the user to view all
his posts across all the forums.
Does anyone have advice that could point me in the right direction?
I have solved the scalability issue WITHIN a forum (code can handle
million + posts easy), but I havent solved the issue of scaling MULTIPLE
separate forums.
I dont think putting EVERYTHING on one single DB would be a good idea,
considering that a single forum could grow huge, and have a million posts.
I am thinking that the solution would possibily involve like a fixed
amount of forums per db/server, and then drop in a new server everytime
that limit is reached.
Regarding point 3, where a user has a "dashboard" that allows him to
view all subscribed posts across ALL forums, an obvious solution would
be to have a user-centric table that also stores copies of all his
subscribed post IDs (including last viewed time stamp etc), eliminating
the need to query across all separate DBs.
Am I heading in the right direction?
Also, does there exist any php package that helps ease the process of
"deciding which Server/database to connect to"?
For example, someone accesses FORUM A, so the script would automatically
know to direct all queries to the DB in SERVER 1 etc, and if i try to
access FORUM J, it would connect to SERVER 2 etc. I could easily hard
code this, but I was thinking "what if internal IP addresses change, or
I decide to migrate a busy forum to a server of its own etc", so perhaps
there is a better available packaged solution designed for this task.
Appreciate any advice!
Sprock
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw
| |
| Philip Hallstrom 2006-02-28, 8:28 pm |
| > Hi there,
> I am in the midst of creating a forums hosting site.
>
> 1. It has to be highly scalable, so I doubt a single MYSQL db with TONS of
> "subforums that simulate full forums" would do.
>
> 2. Also regarding scalablity, I hope to "Add capacity" as and when its
> needed. So i'll have one server running initially, and when it gets too
> crowded, i'll get two servers etc.
>
> 3. I will be providing a user with a "dashboard" that allows him to view all
> his subscribed posts across ALL forums. So lets say a user is a member of 25
> forums, this dashboard view will allow the user to view all his posts across
> all the forums.
>
> Does anyone have advice that could point me in the right direction?
> I have solved the scalability issue WITHIN a forum (code can handle million +
> posts easy), but I havent solved the issue of scaling MULTIPLE separate
> forums.
What about having a single write master with many read-only slaves? Then
modify your code so that posts go to the master and everything else
happens on the slaves?
> Also, does there exist any php package that helps ease the process of
> "deciding which Server/database to connect to"?
> For example, someone accesses FORUM A, so the script would automatically know
> to direct all queries to the DB in SERVER 1 etc, and if i try to access FORUM
> J, it would connect to SERVER 2 etc. I could easily hard code this, but I was
> thinking "what if internal IP addresses change, or I decide to migrate a busy
> forum to a server of its own etc", so perhaps there is a better available
> packaged solution designed for this task.
Create a table on a "central" server that contains this mapping. This
server could also hold the login tables as well...
Just a thought.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw
| |
|
| Hi Philip, thanks for the reply.
Single master + many read only slaves would only solve the problem of
handling many many concurrent read accesses, by distributing the load
across all slaves.
However, I guess the real problem, is that the writes would still need
to be performed across ALL databases, and the DB would be HUGE, would it
not?
Lets say I host 100 forums, with 100k posts each, every write would need
to be replicated to as many slaves as I have.
Thanks!
Jay
Philip Hallstrom wrote:
>
>
> What about having a single write master with many read-only slaves?
> Then modify your code so that posts go to the master and everything
> else happens on the slaves?
>
>
>
> Create a table on a "central" server that contains this mapping. This
> server could also hold the login tables as well...
>
> Just a thought.
>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw
|
|
|
|
|