Kern Sibbald wrote: > On a similar but slightly different subject: one user brought up a problem > that we are surely likely to see quite a lot in the near future. He has 600 > million File records in his Bacula catalog, and he is required to have at > least a 7 year retention period, which means the database is growing (I think > it is currently at 100GB), and it will continue to grow. > > He has proposed to improve performance to have a separate File table for each > client. This would very likely improve the performance quite a lot because > if you have say 60 clients, instead of having one gigantic File table it > would be split into 60 smaller tables. For example, instead of referencing > File, Bacula would for a clients named FD1 and FD2 reference FD1Files and > FD2Files, and so on, each of which would be identical tables but containing > only the data for a single client.
Why not use a different Catalog for each Client? -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel