Heh. :-) This could be many GBs. There's no problem reading rows that
are in RAM (cached by the OS) -- can read over 10,000/second. If
there's enough RAM, the OS will take care of it (you could cat table.MYD
to /dev/null). No ramdisk necessary. :-)
BTW, this is for MySQL's full-text search. It works pretty well (fast)
as far as doing the lookups and searching in the index. That's not a
concern at all. The problem is that it *has to* read the data file for
each matching row (and possibly non-matching rows, depending on the
search). :-( Searches need to be reasonably fast on millions of rows,
while possibly reading 10s of thousands of data rows. It takes a lot
more time when those rows aren't cached.
The only thing I've thought of so far is symlinking the data file on a
separate drive, but I'm not sure how much that will actually help.
----- Original Message -----
Sent: Friday, February 20, 2004 7:24 PM
Subject: RE: Improving seek/access times -- does RAID help?
> Run everything off a ramdisk ;-)
> Ted Gifford
> -----Original Message-----
> From: Matt W
> Sent: Friday, February 20, 2004 5:21 PM
> Subject: Improving seek/access times -- does RAID help?
> Hi all,
> Can anyone tell me whether or not some kind of RAID will improve the
> seek/access times during lots of random reads from, say, MyISAM data
> I *do not care* about improved [sequential] transfer rates; I want the
> fastest possible random access.
> I'm thinking that RAID won't give an improvement in this case, because
> disks can't know where to read from until MySQL issues the seek calls.
> About the only thing I can think of that may help is if you're using
> striping, there won't be as much data on each disk so the head would
> shorter seeks.
> If RAID doesn't help the situation, any other ideas if the sub-6ms
> times of the fastest 15K SCSI drives isn't fast enough? :-)