Kelvin Quee wrote:
Thanks Puqing and Michael.
Michael, I don't get it. How can (2) and (3) be "sort of" the same?
When you mean same - you mean they give the same results?
Well in both cases you are splitting load over 2 instances and you want
to move some decision/data mining support query load from one instance
and put it on another instance so that you don't disturb the performance
of the other some other function - in this way they are the same.
The only difference is the technology you use to achieve the moving of
data between the two instances e.g. at the database level with
replication (2) or at an application level (3) by writing to certain
tables in specific instances or periodically copying certain data from
data one instance to the other.
At this point it is a design detail, i.e. if you do it at the database
level with selective replication for the tables or schemas that you want
on the other instance (doesn't need to be all tables), or alternatively
you could do this at the application level by making your app write to
different tables on the two instances (split the schema up as you say).
They are pretty much doing the same thing, (3) probably requires more
work, but for the extra effort, you may be able to trim out some
redundancies in the entire database replication approach.
From my naive point of view, it seems that (3) can deliver better
results since we basically torn the db apart - one for each purpose.
Maybe, maybe not. With (2) you can completely isolate your primary
database from your data mining/decision support load - the only downside
is that it is a blunt knife, so as data is getting updated, it will all
propagate to your slave instance - the downside here is the slave has to
support the update load as well as its query load - depending on your
update volume, this may or may not be an issue (where a periodic query
that dumps data to the slave may be more efficient)...
If (2) can give near-to or similar performances as (3), it will be
BRILLIANT as it means a lot less re-development time.
Ya, I would personally would focus on (2) until I had proved that it is
not otherwise feasible as it would be a lot quicker to implement...
_______________________________________________
Slugnet mailing list
[email protected]
http://wiki.lugs.org.sg/LugsMailingListFaq
http://www.lugs.org.sg/mailman/listinfo/slugnet
