List:General Discussion« Previous MessageNext Message »
From:Sasha Pachev Date:February 23 2004 5:59pm
Subject:Re: Improving seek/access times -- does RAID help?
View as plain text  
Matt W wrote:
> Hi Ted,
> 
> 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.
> 
> 
> Matt

Matt:

Post your schema (use SHOW CREATE TABLE), and give an example of a couple of 
queries that are slow including the output of EXPLAIN. It is quite possible that 
we can find a fairly simple solution to avoid excessive random disk access.


-- 
Sasha Pachev
Create online surveys at http://www.surveyz.com/
Thread
Improving seek/access times -- does RAID help?Matt W21 Feb
  • Re: Improving seek/access times -- does RAID help?Dan Nelson21 Feb
  • Re: Improving seek/access times -- does RAID help?beacker21 Feb
RE: Improving seek/access times -- does RAID help?Ted.A.Gifford21 Feb
  • Re: Improving seek/access times -- does RAID help?Matt W21 Feb
    • Re: Improving seek/access times -- does RAID help?Sasha Pachev23 Feb