Dear Ke; due the type if our attachments which are JPEG files, don't hope compression to help me more! but I serious to test it ASAP. it seems pretty to be able to compress Emails body on side DB engine. :-)
On Wed, Oct 10, 2012 at 10:54 PM, [email protected] <[email protected]> wrote: > 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 > -- Regards, Ali R. Taleghani
-------- Final RT training for 2012 in Atlanta, GA - October 23 & 24 http://bestpractical.com/training We're hiring! http://bestpractical.com/jobs
