Hello,
The principal reason for dropping SQLite is as Radek stated -- it is
simply extra overhead that we do not need. This is particularly evident
when we have database schema changes. Doing schema changes with an
existing database can be quite complicated and prone to errors with
SQLite, while with MySQL and Postgres, it is generally very easy.
So mainly it is a matter of not having the time and community input to
continue to support SQLite.
In addition, though I prefer postgres, using MySQL is trivial. Install
mysql, then install Bacula with the mysql driver and it works out of the
box. Though the complexity of MySQL is more than SQLite, the ease of
installation with Bacula is essentially identical.
Best regards,
Kern
On 4/19/19 1:32 PM, Oliver Lehmann wrote:
Hi Radoslaw,
thanks for your mail.
I would understand that if the developers say that they don't
want to support SQLite because of the extra work it creates
for them to support it. But this would be more or less the
only reason I could accept ;-)
SQLite is a good solution for an embedded RDBMS. If it
just comes to some CRUD operation for a single application it
is the easiest solution when it comes to maintenance and
complexity of systems.
You should know, that with each piece you add to your
landscape, the complexity gains and the reliability as well
as the availability goes down.
So - SQLite is perfect here for me. It is just a library.
No server which needs to be up and monitored for correct
working. No configuration. Easy upgradeable.
Of course in big installations which trillions of files and
where performance really matters - SQLite is no alternative.
In this environment, you probably have already an RDBMS
sitting around which is activly monitored, and tweaked
anyway. You will always use this instead of bringing another
solution which does "the same" on-line.
But in small installations, why would someone wants to setup
and maintain a RDBMS for just a backup solution?
When it comes to limits: https://www.sqlite.org/limits.html
Of course there might be some SQL syntax which is not
supported by SQLite - this could be a criteria. But let me
tell you - if it is just "get the work done" and not caring
about best performance - every SQL compatibily issue can
be worked around. Says the since-2003-database-developer.
I definitly like to have small units of systems with the
least possible dependencies between each other. Performance
together with bacula is not a matter for me.
A Full-Backup of my Samba node handles 620k files with a
Transfer rate of 66.89 MB/sec at a Image size of 1.874 TB.
It takes around 7:47 hours for this backup. Running with
SQLite. If it might speed up to 7 hours is not crucial for
me. System simplicity is more important to me for a backup
solution than performance.
The while SQLite DB-file is 310MB in size. I just back this
up instead of dumping the content and save the dump. This
is also perfect in case of disaster recovery. You just need
to get the DB file back and are back working in some seconds.
No need to install and configure a RDBMS....
Just my two cents. I guess the decision is already made
anyway and not open to discussion any more. I just wanted
to state that I'm sad with this decision - but this is
my problem ;)
Best regards,
Oliver
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
