MariaDB Blog - Latest Comments

Re: Database Master-Slave Replication in the Cloud

Daniel Bartholomew — Thu, 09 May 2013 08:30:36 -0000

A big thanks to Jelastic for letting us publish it here.

We should probably do a hands-on post about MariaDB Galera Cluster. Until we do, the Galera section of the Knowledgebase has some good articles: https://kb.askmonty.org/en/gal...

Re: Database Master-Slave Replication in the Cloud

Joseph Raj Kumar — Thu, 09 May 2013 03:03:42 -0000

Thanks Daniel!!

An excellent and Simple introduction and Hands-on to Master-Slave replication in MariaDB.

Couldn't have been simpler!

How do you set up Multi-Master Replication.
Is there any limit on the number of masters/ slaves?

Thanks & rgds,
JR Kumar

Re: On performance of JDBC drivers.

Vladislav Vaintroub — Thu, 09 May 2013 02:27:36 -0000

Roland, when I say "user doers not care where time is spent", I mean the end-user, who wait for web page to load, and who does not know there is java and database behind. Of couse, one can argue that my own users (users of that driver) are DBAs, programmers, consultants etc, people who use JDBC to write web apps. Yes, these people hopefully do care and measure etc.

Re: On performance of JDBC drivers.

Vladislav Vaintroub — Wed, 08 May 2013 11:58:24 -0000

Nope, it is one-time connection and thousands of exactly the same queries. The speed of the connect was not measured at all, only of the queries. Connect/Disconnect is another story. I might write about this next time, this is where pooling would matter.

Re: On performance of JDBC drivers.

Roland Bouman — Wed, 08 May 2013 01:59:33 -0000

Vlad, thanks for the extra info. Much appreciated. I agree that all performance gain is good, and surely as a developer I would care about these differences.

I don't agree the user doesn't care where the time was spent though; I mean, if they experience performance problems that can be explained mainly in terms of waiting for the network or database io, then they simply won't be able to solve that by switching drivers. If they aren't aware that switching drivers doesn't make the difference they need or expect, they will just be disappointed spending work and time on something that didn't solve their problems.

(Of course, I'm not saying it is any driver developer's fault that the user doesn't understand what problem they have on their hands :-)

Re: On performance of JDBC drivers.

Andy — Tue, 07 May 2013 20:23:53 -0000

You're making a new connection for each query in this benchmark, correct? Would the performance difference between different drivers go away if using connection pool?

Re: On performance of JDBC drivers.

Vladislav Vaintroub — Tue, 07 May 2013 15:37:34 -0000

no clue abotu real scenario, I hope there are people better qualified to know life than me:) With large result sets, the problems often is that drivers reads the full huge result sets into memory, and programs die of OOM.
Reading full result set into memory - this mode is default in JDBC connectors too ( Drizzle JDBC does not know any other mode)

ConnectorJ and MariaDB JDBC however have an option to read big results row-by-row ("streaming")

It is activated with

stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
java.sql.ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(Integer.MIN_VALUE);

If streaming is used, problem that often "in real life" happens is that client does not read off the result set fast enough, and server blocks in socket writ()e, and if it waits long enough (net_write_timeout), and after that it just closes client's connection. ConnectorJ increases net_write_timeout before executing streaming query. MariaDB JDBC does not do that but of course people can set their timeouts higher themselves, e.g in the connection URL'a "sessionVariables=net_write_timeout=1000"

Re: On performance of JDBC drivers.

Massimo — Tue, 07 May 2013 14:43:59 -0000

Good work vlad! :) Would be interesting to see the difference in handling a more real scenario (where I assume the difference will be more or less zero) and big result sets, I had lot of issues in the past with different connectors... Also would be good during your tests to see the CPU usage...

Re: On performance of JDBC drivers.

Vladislav Vaintroub — Tue, 07 May 2013 14:28:54 -0000

About ConnectorJ DML detection - The standard says it this way
"If the SQL string being executed does not return a ResultSet object, the method executeQuery throws an SQLException". It does not say - driver should attempt to parse SQL query in order to find out whether it possibly would be an update.

About realistic scenario : I'm not sure whether good performance is noticeable in realistic scenario either. I had to improvise, and I choose those queries - I was curious myself whether I could dig something useful , or learn something new . I did and I shared some tidbits.

I still think every milli-and-microsecond saved on client is good, user does not care where it is spent.

Yes, I had ran some more tests with larger result sets, and with bigger rows, and connect/disconnect, however I did not have time to really understand the results in detail, and I did not want to publish numbers without explanation. I also think my "large result set" tests sucked because they were retrieving from information schema, it has prohibitive overhead. They were also least conclusive.

However one thing that I noticed is that (already fixed) Drizzle bug was noticable, also on much slow queries with ~60 qps, and even with ~20 qps. IIRC, ConnectoJ driver was slightly better that MariaDB on blobs , but bad on connect/disconnect, even with "useConfigs=maxPerformance". Drizzle JDBC had stellar connect/disconnect (it does nothing upon establishing connection), very closely followed by MariaDB with "fastConnect=true". One day, when I have profiled those cases, it could make sense to write about it again.

Re: MariaDB Introduces Atomic Writes

Vince Fleming — Tue, 07 May 2013 12:57:35 -0000

Yes, the atomic writes do extend Endurance by significantly reducing write amplification.

Re: MariaDB Introduces Atomic Writes

Vince Fleming — Tue, 07 May 2013 12:55:05 -0000

That depends on other manufacturers adopting the API. It's a public API.

Re: On performance of JDBC drivers.

Roland Bouman — Tue, 07 May 2013 04:03:32 -0000

Thanks for sharing! Couple of remarks:

"If absolutely necessary, throwing an exception can be delayed, until the client finds out that the server sent an OK packet instead of a result set."

Well, the problem is that in this case the server would already executed the UPDATE statement, right? Even if the underlying storage engine would allow a rollback, you really don't want to go near that position. Or maybe I'm missing something.

Regarding the benchmark itself: Personally I'm not sure the slightly better performance of the mariadb driver is noticeable in a more realistic scenario (i.e. real queries). My assumption is that in almost all cases database io, and in case of resultsets, network will sooner be a limiting factor than raw java performance.

However, it'd be really interesting if my assumption could be proved false. Have you done such tests? If not, that's ok, maybe you'll find time to do so in the future. If you have done such tests, then it'd be nice if you could share the result. If it turns out it doesn't make much of a difference then it's not necessary to post detailed data; I would be happy to take your word for it.

Despite these reservations, I think this does show that doing benchmarks is still useful from a standpoint of quality, since it helped identify and fix a drizzle bug. Drizzle has traditionally refrained from publishing benchmarks on the grounds that they are unrealistic and aren't trusted anyway unless executed by an independent party; this exercise shows that such benchmarks still have value since they can identify bugs or poorly optimized code.

Another interesting observation is the comparison of C client lib versus JDBC driver. This is yet another confirmation that the myth that Java is slow should be buried.

So, thanks again! Enjoyable read.

Re: On performance of JDBC drivers.

Justin Swanhart — Mon, 06 May 2013 17:56:47 -0000

Oh, sorry, I guess I got you confused with another Vlad :) oops. Anyway, great idea with respect to overriding the method.

Re: On performance of JDBC drivers.

Vladislav Vaintroub — Mon, 06 May 2013 16:38:25 -0000

Justin, you must have met someone else at PLMCE . Its been a while I attended a conference (last one was 2011, still OReilly MySQL conf :) But thanks anyway!
After some thinking, I believe ConnectorJ bug might be solved without contacting JVM folks - since ConnectorJ derives NamedPipeSocket from a Socket, they could just l override the culprit method Socket.shutdownInput() to do nothing.

Re: On performance of JDBC drivers.

Justin Swanhart — Mon, 06 May 2013 15:31:57 -0000

Given that Oracle owns MySQL and Java you think they could prioritize that bug fix with the named pipes :)

Also, it was great meeting you at PLMCE. Thanks for letting me show you Shard-Query.

Re: MariaDB 10.0.2-alpha Now Available

Daniel Bartholomew — Wed, 01 May 2013 11:00:27 -0000

10.0.2 packages for Debian and Ubuntu are now available.

Re: MariaDB 10.0.2-alpha Now Available

Daniel Bartholomew — Sat, 27 Apr 2013 08:17:48 -0000

As mentioned in the release notes at https://kb.askmonty.org/en/mar... the Ubuntu/Debian packages have been delayed. Unfortunately it's taken longer than normal to get them ready. They should appear soon.

Re: MariaDB 10.0.2-alpha Now Available

Athalas — Sat, 27 Apr 2013 07:21:46 -0000

10.0.2 doesn't appear to be in the repositories, checking http://mirror3.layerjet.com/ma... lists 10.0.1

Re: MariaDB Introduces Atomic Writes

Andy — Sat, 27 Apr 2013 02:13:27 -0000

Will this ever work on non-FusionIO SSDs?

Re: MariaDB Introduces Atomic Writes

Ilari Stenroth — Fri, 26 Apr 2013 00:28:51 -0000

Do atomic writes reduce flash storage wearing? Have you measured the affect on amount of total blocks written on a block device?

Re: MariaDB well-represented at Percona Live MySQL Conference

Damian Tylczyński — Tue, 16 Apr 2013 10:53:14 -0000

Waiting for slides

Re: MariaDB participates in Google Summer of Code 2013

colincharles — Thu, 11 Apr 2013 03:54:18 -0000

Hi @facebook-100001195552708 - yeah it was removed because it might have taken a lot longer to do than a summer. To ask questions, send email to maria-discuss@lists.launchpad.net and feel free to add your own ideas if you'd like to work on something

Re: MariaDB participates in Google Summer of Code 2013

Amit Kartik — Wed, 10 Apr 2013 15:13:05 -0000

Where do we ask questions about the projects and is the list of projects on ideas page final ? The Full text search plugin project has been removed !

Re: Slackware and Arch Linux switch to MariaDB as a default

Daniel Bartholomew — Sat, 06 Apr 2013 21:38:20 -0000

No worries, everything you've learned about MySQL can be applied to MariaDB.

Re: Slackware and Arch Linux switch to MariaDB as a default

Jason Comito — Sat, 06 Apr 2013 16:15:19 -0000

but I just started learning MySQL!