Hey Chris,
I'm afraid that this is not what databases are for, and the first thing you'll
likely run into is amount of concurrent connections.
This is typically something you should really tackle from a systems
perspective. Seek times are dramatically improved on SSD or similar storage -
Hi All,
Thanks for the responces, and I do concur. I was taking a stab in the
dark so to speak.
We are working with our hosting providers currently and will be
introducing a multitude of small iSCSI SANs to split the storage
structure over a multitude of disks... This is something that needs
Count the disk hits
If you have a filesystem directory, consider that it is designed to handle
small numbers of files per directory. Consider that there is a limited cache
for directories, etc. Plus there is the inode (vnode, whatever) storage for
each file. I don't know the details (and it
Your argument against FS assumes that you don't know the exact filename
(directory traversals), but your argument for InnoDB assumes that you do (index
lookup). Apples and oranges.
Besides, the venerable ext2 handled up to a couple of tens of thousands of
files per directory smoothly when
Well that information I can provide
As mentioned, we use an md5 (hex) checksum to track the files. In
terms of the tables, I would definately consider the md5 checksum as a
PK (char(32) due to the hex nature), a blob for the data, and then
there will also be a datetime column to indicate
2013/07/27 00:58 +0200, Chris Knipe
I would definately consider the md5 checksum as a
PK (char(32) due to the hex nature),
Well, not that it greatly matters, but you could convert it to BINARY(16).
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
