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