Too many data on database - "replication" decision needed
Now I have a problem with a MySQL application. Actually I'm worried about
a problem I might have in a few months.
Here's the scenario: I'm developing a web application that will have a lot
of clients using it. It's a application that has a unique core and several
adaptations (running on the same core), so the database is the same for
all adaptations. Each adaptation has one or more clients using it.
So, my database has more than 200 tables and some tables may have more
than 500 rows per day per client. I'm worried that when the database get
too big the selects may be really expensive.
I was thinking about create several databases (identical schema) and the
application should decide what database to use based on what client is
logged. But I'll have really problems to update the schemas (I'll have to
update each database). My application can choose the database, it's not a
problem.
Do you think that the MySQL can really stop if it has a lot of data?
Is there a way to easily update several identical-schema-databases?
Master/slave approach solves my problem?
I think it's important you to know that in all tables I have a collumn
that tells me to what client that row belongs to and always use it in all
the select queries as a WHERE clause.
So what I need help is to decide what to do. Can you help me with these
questions? Do you have any other smarter solution?
I don't know if it's important but I'm using PHP.
Thank you all!
No comments:
Post a Comment