Hi Raj Shekhar,
Thanks for suggestion.. This could be a solution
If we can not upgrade thn Merge tables could be a solution..
But app will need to create a new table every year and alter merge table definition..
However I doubt that merge table would give a decent performance for Select operaton..
Thanks
SN
________________________________
From: Raj Shekhar <rajlist@stripped>
To: mysql@stripped
Sent: Thu, 5 November, 2009 9:41:05 PM
Subject: Re: Fw: 50M records each year.. how to handle
Johan De Meersman <vegivamp <at> tuxera.be> writes:
>
> I did some quick math, and it comes down to 1.5 records per second on
> average. Even with peak loads, this is doable without the annoying
> manual partitioning, I think.
A major benefit of partitioning is the ease of maintenance (running
operations like optimize/mysqlcheck).
Coming to the original question -
>
> On 11/5/09, || Sudhir Nimavat || <sudhir_nimavat <at> yahoo.com> wrote:
> > Ok,
> >
> > Now the problem is.. currently we are using mysql 4.1 and it is not possible
> > to upgrade mysql at this time.. as far as I know mysql 4.1 does not support
> > partitioning.. So the only solution would be to use manual partitioning and
> > handle it through code..
Look into the "merge table" storage engine
<http://dev.mysql.com/doc/refman/4.1/en/merge-storage-engine.html>.
Your app will still need to handle to job of creating and loading the
underlying tables, but selects/deletes/updates be transparent. This is
the closest that you can come to partitioning with 4.1, unless you can
rewrite your app to handle sharding.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=1
Keep up with people you care about with Yahoo! India Mail. Learn how.
http://in.overview.mail.yahoo.com/connectmore
