It's my understanding that the biggest remaining difference has to do
with SCSI having far superior command queueing capabilities --
although SATA's command queueing may have closed the gap somewhat --
which provides for much better real-world performance when you have
multiple database threads doing work.
The bottom line is that (at least in the past -- who knows, perhaps
the latest-n-greatest SATA gear has truly tipped the scales, although
I doubt it) you will see better real-world performance with less
fidgeting* from SCSI (or Fibre Channel, switched or otherwise) in
terms of access times and throughput than you will from PATA or SATA.
* - For example: We faced a NASTY problem using AMD 64-bit CPUs +
SATA + Linux where I/O on the system (the WHOLE system, not JUST the
SATA spindles -- network, PATA, USB, EVERYTHING) would suddenly come
to a grinding halt (or very nearly halted) randomly when the SATA
subsystem was under heavy load. It required a LOT of trial-and-error
kernel adjustments to find a configuration that did not suffer this
problem.
As to whether it is PREFERRED, that comes down to your constraints.
There are some problem domains where it's REALLY REALLY HARD to split
database load across multiple servers. There are many problem
domains where bad or overly-simplistic design patterns are common
that make scaling to multiple machines hard. So sometimes you wind
up in a nasty situation where your only option is to have REALLY fast
spindles -- in which case, the 10x or 20x price premium for SCSI may
be unavoidable.
Generally speaking, if you need ultra-fast spindles you should
probably be re-evaluating your database architecture as you're asking
for financial and technological pain.
-JF
On Jul 11, 2006, at 4:18 PM, Brian Dunning wrote:
My understanding is that SCSI has a faster transfer rate, for
transferring large files. A busy database needs really fast access,
for making numerous fast calls all over the disk. Two different,
unrelated things.
I am more than willing to be called Wrong, slapped, and cast from a
bridge.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?
[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
