No updates to the master is the rule, our primary key is actually based on a timestamp unless we can figure an auto_increment bigint (yes, expecting an obscene amount of transactions) as the key. I think the bigint auto_increment might be a better option, certainly easier to use in a select as the key on one of the slaves than a pesky timestamp--er, I think.
Right now it is timestamp. Thanks for the thoughts guys, I'll be sure to provide feedback on the results if you are interested. Regards, Tony On Thursday 25 October 2001 12:45 pm, Kyle Hayes wrote: > On Wednesday 24 October 2001 23:09, Jeremy Zawodny wrote: > > On Wed, Oct 24, 2001 at 06:25:58AM -0400, Tony wrote: > > > I am looking for a creative way to optimize my web application > > > (largely reads) with a transaction firehose on the data input side. > > > Batch vs. OLTP, if you will. > > > > > > Is there any technical reason why I could not configure the master > > > database without indices and the slave(s) _with_ indices? The > > > intent being to isolate the inbound transactions from the reads > > > _and_ make the database inserts as simple as possible (e.g. few or > > > no indices). > > > > That ought to work. > > Unless you have _any_ UPDATEs. Then, it'll slow to a crawl. MySQL is > really fast if you've got the right indexes. It isn't much faster than > grep on a big text file if you don't :-) > > If all you have are INSERTs and you can prove that they will never try to > overwrite old data on the slaves, you should be fine. This is a pretty > serious constraint though. > > > > Several slaves could be configured to throttle performance on the > > > web side (more reads, move slaves, etc.), which could gain a > > > performance edge by indexing. > > > > > > For disaster recovery of the master, one slave could be "untouched" > > > and not indexed. > > > > > > I'd be interested to hear comments. > > > > That's an interesting idea that I hadn't considered before. > > I'd be worried about maintaining the strict "completely new INSERTs only" > policy over time. If you are running stock or measurement data into it > where it is guaranteed that it is always new INSERTs, you should be OK. > > Best, > Kyle > > bot fodder: database, query, mysql, lions and tigers and bears, oh my! --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
