Hi all,

We run an VERY io intensive file application service. Currently, our
problem is that our disk spindles are being completely killed due to
insufficient SEEK time on the hard drives (NOT physical read/write speeds).

We have an directory structure where the files are stored based on the MD5
checksum of the file name, i.e. /0/00/000/000044533779fce5cf3497f87de1d060
The majority of these files, are between 256K and 800K with the ODD
exception (say less than 15%) being more than 1M but no more than 5M in
size. The content of the files are pure text (MIME Encoded).

We believe that storing these files into an InnoDB table, may actually give
us better performance:
- There is one large file that is being read/written, instead of BILLIONS of
small files
- We can split the structure so that each directory (4096 in total) sit's on
their own database
- We can move the databases as load increases, which means that we can
potentially run 2 physical database servers, each with 2048 databases each)
- It's easy to move / migrate the data due to mysql and replication - same
can be said for redundancy of the data

We are more than likely looking at BLOB columns of course, and we need to
read/write from the DB in excess of 100mbit/s

Would the experts consider something like this as being feasible? Is it
worth it to go down this avenue, or are we just going to run into different
problems? If we are facing different problems, what can we possibly expect
to go wrong here?

Many thanks, and I look forward to any input.

--
Chris.



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql