Thanks Michael and Edwin. I will go try an implement (2) and get back to you guys asap. :)
You guys rock! Kelvin Quee +65 9177 3635 On Wed, Jul 22, 2009 at 2:12 PM, Michael Clark<[email protected]> wrote: > 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
