On Wed, Oct 10, 2012 at 10:36:22PM +0330, [email protected] wrote: > Dears; > > I have been face with a problem... after 3 years, out attachments table has > been grown over 300GB in size and it's about 15 Million of records. > for performance tuning I Ihad changes it's Table Engine into InnoDB and > configured MySQL as file_peer_table with Dynamic Row format to bring out > the BLOB data out of the caching space and reduction it's response time. > > but I have always a question in my mine! why RT is storing this much > attached objects in BLOG fields? > why it dose not use a separate file system to store file on and just table > it links ( or auto generated name ) on DB? > in such a way, we will have some better ways to backup this much files... > -- features like snapshots on ZFS > > -- > Regards, > Ali R. Taleghani
Hi Ali, You can check the archives. There actually was a branch developed by Best Practical that moved the attachments into the filesystem. I believe the customer was motivated by performance needs. Certainly, keeping all of the information is a single DB is vastly easier to manage consistently. Once you get to the size of the DB that you are reaching, care and handling is a much different beast whether or not the data is in the DB or on a tied filesystem. You are certainly an inspiration using MySQL as the backend for an instance that large. Regards, Ken -------- Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
