On 14/10/15 10:49, Uwe Schuerkamp wrote:
>
> you might also try giving MariaDB a shot which has been performing
> fine as a drop-in mysql replacement for us for the last few years with
> catalogs of similar size.
>

Speaking as a mysql affectionado and one who's using both DBs regularly 
in various applications:

If you have large catalogs there is _no_ substitute for using postgresql.

I spent years regularly tuning mysql for large memory loads and then 
quite a while kicking myself that I'd resisted moving to PGsql all that 
time - since the changeover I've barely had to touch database tuning.

MySQL/Maria are good at what they do, but they don't scale to large 
datasets very well. PGsql is overkill for a small dataset but it scales 
to large ones extremely well.

(48Gb machine for the database. Mysql was using most of the ram and 
using tmpfiles. After changing to PGsql the memory footprint seldom 
exceeds 12Gb.)

Changing over is relatively easy, _BUT_ you have to make sure you make 
your mysqldump in full compatibility mode and that means that it's slow 
to import into PGsql. Budget a day for this step.

If you're determined to stick with MySQL then the solution for seriously 
slow queries is to find out which tables are causing the bottleneck and 
to index appropriate columns. The EXPLAIN and ANALYZE commands are your 
friends.


Let's not get into religious arguments about XYZ database is better. The 
answer is that "better" depends what kinds of loads are being thrown at 
them. Mysql is good on catalogs and PGsql is better on large ones. I 
think the crossover point is between 10 and 20 million entries.





------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users