On Wed, Mar 01, 2000 at 02:41:48PM +0800, Orlando Andico allegedly wrote:
> 2) even though an ATA66 hard drive, particularly a Barracuda (I have one
> on my home machine, the very same 27Gb model.. bliss) can sustain 26MB/sec
> (I gather you got that from hdparm?) that doesn't mean squat in a database
> environment. What matters is the number of IO's per second, and a single
> drive cannot manage more than 30-50 of those. This is because, unless you
> are using a log-structured filesystem, most disk access will be in small
> (typically 4K to 8K depending on your FS block size) chunks.
I think your 30-50 is a bit low. PostgreSQL (on FreeBSD 3.3) can do about
90 insert (and a few more updates) with the database on a 9.1 GB Barracuda
disk. This is with all indexes removed though. With indexes things really
start slowing down, unless you use transcations. I haven't used Oracle
much (as a DBA), so I don't know how that will compare to 'toy' RDBMSes
like PostgreSQL and MySQL.
> 4) If you use a Promise FastTrack controller (ATA66) I think future models
> can do hardware RAID1 (software RAID is evil!)
If you want maximum reliability, then you are right. If you want maximum
speed (and are willing to take a bit more risks), software RAID may be
faster (at the expense of using more system resources).
> 5) long select's will block when updates occur. This is a limitation of
> MySQL's table-level locking. There's no way around it. 3.23.x allegedly
> solves this by allowing ONE update and multiple selects to run
> concurrently. Haven't tried it though.
I seem to recall this only works on tables without any deleted recordsl,
but I'm not absolutely sure.
> ---------------------------------------------------------------------
> Orlando Andico <orly@stripped> +63 (2) 937-2293
> Mosaic Communications, Inc. +63 (917) 531-5893
> Any sufficiently perverted technology is indistinguishable from Perl.
Cool sig :)
Mathijs
--
For answers:
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
