[rt-users] Large Attachments Table

[shayne.alone at gmail.com]

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, ktm at rice.edu <ktm at rice.edu> wrote:

> On Wed, Oct 10, 2012 at 10:36:22PM +0330, shayne.alone at gmail.com 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20121011/e58a3f55/attachment.htm>