[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Hi Simon, Thanks for the input. I totally agree with your comments and as I have several years professional experience with large databases I would add that a well designed and normalized database probably adds more to performance than any other single factor. With that in mind I'm not particularly suffering any performance issues, but rather as MariaDB is a drop in replacement for MySQL, fully open source, claims to have improved performance over MySQL and is by the original development team (who have largely left Oracle to continue working together) I was wondering if anyone had had any experiences in the matter. I would like to thank you for your instructive and constructive email, and hope the others gain some helpful insight from it. Thanks again, Fin Sent from my BlackBerry® -----Original Message----- From: Simon Waters <simon@xxxxxxxxxxxxxx> Sender: list-bounces@xxxxxxxxxxxxx Date: Sun, 18 Nov 2012 22:28:43 To: <list@xxxxxxxxxxxxx> Reply-To: list@xxxxxxxxxxxxx Subject: Re: [LUG] Anyone used MariaDB On 18/11/12 20:35, Edward Finlayson wrote: > Hi all, I have a db of around 60 Million records and was wondering if > I could get a tangible performance improvement by switching to > MariaDB as it claims several improvements over current MySQL which > Oracle are known to want to kill thereby removing competition. Do you > have any experience with these two DB, and are you willing to share > your 'real-world' findings; if so I'm really interested to hear > them. What is the current bottleneck? If you don't know optimisation is going to be a slow process. What type of queries are too slow, and what is too slow. What optimizations have you already made of the operating system, of the MySQL configuration, and the queries. My experience of databases is that switching databases is usually the wrong approach to performance issues, unless there is some compelling relevant weakness with the database in use (like it doesn't offer a suitable index for the queries you want to do), or it lacks some sort of relevant feature entirely (even then there are often workaround that keep within the same order of magnitude for performance). This is more likely to be true with such a small database, which can presumably be stuffed into RAM completely if performance matters, so even when the optimizer messes up you don't hit the IO subsystem hard. I don't have specific experience of MariaDB, the benchmarks show it has a marginal lead in throughput which is what you'd expect if they have forked MySQL tidied up some corner cases of the optimizer (which does idiosyncracies which you have to program around sometimes). You trade what is a huge userbase for MySQL who have found all those bugs for this performance, so I'd be very wary of making the change. On the otherhand with MySQL I've seen reordering the tables in apparently irrelevant ways cause a several orders of magnitude improvement in performance for specific queries (e.g. A.id = B.id versus B.id=A.id). Which again is typical of a database queries not using indexes efficiently, or not spotting they can use indexes. I'd also add that probably 90% of database performance issues I've seen have been solved by creating appropriate indexes, which may reflect that most of them didn't have a database administrator. A fair proportion of the remaining issues resolved simply by reconfiguring from default settings for the database (more memory, more connections, more (and less) effort in the optimizer). -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq