[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Alternative DB structures-Porposal


On Thursday 25 September 2008 08:02:19 Kern Sibbald wrote:
> On Wednesday 24 September 2008 23:40:03 David Boyes wrote:
> > > ALTER TABLE file  add column size bigint default 0;
> >
> > This seems to assume that files/objects are byte streams. This is not
> > always true on all the platforms that Bacula supports.
>
> I am not sure I understand why this assumes that files/objects are byte
> streams.  I am not arguing, but I find your statement interesting ...
>
> One point is that no platform is obligated to provide size (st_mtime is
> needed), so it may not always be available -- perhaps that is what you
> (David) mean above?
>
> > If the platform
> > is not natively set up that way, you've just added a fair amount of
> > processing to determine the file size, unless you're putting logic in to
> > update this after the file is stored.
>
> It seems to me that the only advantage of John's proposal is that for
> external programs and adhoc queries, they can access the database using SQL
> only. For external programs, code to efficiently get these fields already
> exists, though it cannot be used directly in the SQL.  I believe that
> PostgreSQL can even get to the data directly using SQL (maybe not as
> efficiently as the code subroutines).

In re-reading this, I see that my position on this may not be really clear.  
We (the developers) have already been discussing moving certain fields out of 
the LStat (or duplicating them) directly into a table column so that they can 
be easily accessed by SQL.  The problem is making a design decision that 
involve increasing the size of the database that is not needed by Bacula but 
makes it easier for external programs to access the data.  We have even 
discussed ways of reducing the size of the LStat (it is a variable size) to 
compensate adding new columns.  To date, we have made no decision.

>
> I did a quick and rough calculation of the extra database size this will
> add, and on my 1GB database (pretty small), which is MySQL, it will add
> about 5.13% in size.  This should be a very accurate estimate for most all
> MySQL databases.  Other than test databases, I don't have production data
> for PostgreSQL, but if I assume that most sizes are pretty much the same as
> in MySQL (probably not a good assumption), the increase in database size
> would be 7.69%, which is pretty substantial.

Note, for a user with a small database this increase in size is probably 
inmaterial, but for someone with a 100GB database who looks forward to it 
rapidly growing over time due to the need to keep all records (recently 
discussed on the list), any increase in size of more than 1% is probably 
worrisome, and even more is the performance penalty of having more data ...

Kern

>
> Note the PostgreSQL increase in size is larger than for MySQL, because
> MySQL uses 4 byte TIMESTAMP fields while Postgre uses 8 byte TIMESTAMP
> fields (internally Bacula uses 8 bytes where ever possible).
>
> -------------------------------------------------------------------------
> 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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/bacula-devel



-------------------------------------------------------------------------
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilot Consulting.