PlanetMysql.ru — информация о СУБД MySQL

I must admint I was greatly impressed by the Oracle activity on MySQL yesterday. I cannot say I didn’t see it was coming, but most certainly the magnitude of what happened, the flood of announcements, was a bit overwhelming. Looking at the list of improvements, I started wondering what can it actually mean to the MySQL ecosystem.

Several years ago MySQL was forked into several different projects driven by groups of passionates as well as commercial businesses. Many considered the pace of MySQL evolution to be insufficient, while some didn’t agree with the direction or was complaining on the quality.

These were not unfounded. Rather than on the software itself, MySQL AB was focusing more on preparing itself for public offering, which eventually didn’t happen. It sold out to Sun. However, instead of getting a huge boost from being part of a company that was doing a lot of software development after all, the database hit rock bottom. It turned out Sun had no idea for this product. They started using marketing as the driving force, while development practically stopped. At the same time MySQL itself was split between two vendors, which wasn’t making things any easier. Sun owned the database itself, while Oracle the primary-to-be storage engine – InnoDB.

The entire situation allowed the forked projects to grow and gain some market share. They offered new features people wanted. Often simple things, even, but sometimes also revolutionary. Eventually they started shaping MySQL itself. Sun, and later also Oracle, which acquired Sun, began including some of their major work into the mainstream code. In the mean time Percona and MariaDB turned into true commercial vendors offering MySQL-based databases with proper release cycles, product support, life cycle management, and so on. One thing is certain. They used the opportunity when their “opponent” was weak.

Did something change yesterday?

Oracle showed it was coming back to the game. And strong. The company definitely has all the arguments on its side. It can make databases, it knows how to do it. It employs a lot of insanely smart developers working on MySQL, such as Yasufumi Kinoshita with whom I had the pleasure working during my days at Percona, and who largely made Percona Server what it is today. Oracle deliberately chose the moment for publishing all these articles to coincide with Percona Live conference in Santa Clara. It is not accidental, it is a message. How many announcements, lectures or claims from MariaDB, SkySQL, or Percona may not be so valid anymore today?

It is important to remember that MySQL 5.6 is the first true Oracle release and not something inherited from Sun. It is the first time the company can show how serious it is going to be about this database. If MySQL is going to evolve rapidly, can the alternative vendors keep up with this?

It does not seem likely, because incorporating own patches into a continuously changing code base may become very expensive. At the same time, they cannot afford significant delays in releasing up-to-date versions, because otherwise they will just be filling a niche for the few particularly interested in using their software, but they won’t part of the mainstream anymore. From the business perspective, supporting a niche software that is free, may not make too much sense.

In the end, I do not think these businesses are going to disappear, contrary to what the title may suggest. After all, developing MySQL forks is just part of what they do. But this particular area of business may be going away, or the model shall change dramatically, if Oracle decides to keep pulling aces out of the sleeve.

What do you think?

PlanetMySQL Voting: Vote UP / Vote DOWN

I must admint I was greatly impressed by the Oracle activity on MySQL yesterday. I cannot say I didn’t see it was coming, but most certainly the magnitude of what happened, the flood of announcements, was a bit overwhelming. Looking at the list of improvements, I started wondering what can it actually mean to the MySQL ecosystem.

Several years ago MySQL was forked into several different projects driven by groups of passionates as well as commercial businesses. Many considered the pace of MySQL evolution to be insufficient, while some didn’t agree with the direction or was complaining on the quality.

These were not unfounded. Rather than on the software itself, MySQL AB was focusing more on preparing itself for public offering, which eventually didn’t happen. It sold out to Sun. However, instead of getting a huge boost from being part of a company that was doing a lot of software development after all, the database hit rock bottom. It turned out Sun had no idea for this product. They started using marketing as the driving force, while development practically stopped. At the same time MySQL itself was split between two vendors, which wasn’t making things any easier. Sun owned the database itself, while Oracle the primary-to-be storage engine – InnoDB.

The entire situation allowed the forked projects to grow and gain some market share. They offered new features people wanted. Often simple things, even, but sometimes also revolutionary. Eventually they started shaping MySQL itself. Sun, and later also Oracle, which acquired Sun, began including some of their major work into the mainstream code. In the mean time Percona and MariaDB turned into true commercial vendors offering MySQL-based databases with proper release cycles, product support, life cycle management, and so on. One thing is certain. They used the opportunity when their “opponent” was weak.

Did something change yesterday?

Oracle showed it was coming back to the game. And strong. The company definitely has all the arguments on its side. It can make databases, it knows how to do it. It employs a lot of insanely smart developers working on MySQL, such as Yasufumi Kinoshita with whom I had the pleasure working during my days at Percona, and who largely made Percona Server what it is today. Oracle deliberately chose the moment for publishing all these articles to coincide with Percona Live conference in Santa Clara. It is not accidental, it is a message. How many announcements, lectures or claims from MariaDB, SkySQL, or Percona may not be so valid anymore today?

It is important to remember that MySQL 5.6 is the first true Oracle release and not something inherited from Sun. It is the first time the company can show how serious it is going to be about this database. If MySQL is going to evolve rapidly, can the alternative vendors keep up with this?

It does not seem likely, because incorporating own patches into a continuously changing code base may become very expensive. At the same time, they cannot afford significant delays in releasing up-to-date versions, because otherwise they will just be filling a niche for the few particularly interested in using their software, but they won’t part of the mainstream anymore. From the business perspective, supporting a niche software that is free, may not make too much sense.

In the end, I do not think these businesses are going to disappear, contrary to what the title may suggest. After all, developing MySQL forks is just part of what they do. But this particular area of business may be going away, or the model shall change dramatically, if Oracle decides to keep pulling aces out of the sleeve.

What do you think?

PlanetMySQL Voting: Vote UP / Vote DOWN

Mark has some good thoughts on drizzle. I think they’re all valid… and have some extra thoughts too:

“I have problems to solve today”. This is (of course) an active concern in my brain… If we don’t have something out that solves some set of problems with reasonable stability and reliability (and soon), then we are failing. I feel we’re getting there, and will have a solid foundation to build upon.

Drizzle replication, MySQL replication: “I can’t compare the two until Drizzle replication is running in production.“. Completely agree. We need to only say replication is stable and reliable when it really is. Realistic test suites are needed. Very defensive programming of the replication system is needed (you want to know when something has gone wrong). We also need to have it constantly be verifying the right thing is going on. We want our problems to be user visible, not silent and invisible. Having high standards will hopefully pay off when people start running it in production….

3 byte int: “Does this mean that some of my tables will grow from 3GB to 4GB on disk?” I think we’re moving the responsibility down to the engines. The 3 byte int type says two things: use less storage space, limit the maximum value. Often you want the former, not the latter. There are many ways to more efficiently pack integers for storage when they are usually smaller than the maximum you want. The protobuf library does a good job of it.

I think it is the job of storage engines to do better here. Once you’re in memory, 3 byte numbers are horrible to work with.. copy out of a row buffer, convert into a 32bit number and then do foo. Modern CPUs favor 32 or 64bit alignment of data a *lot*. 3byte numbers do not align to 32 or 64bits very well… making things much slower for the common case of using cached data.

“I need stored procedures. They are required for high-performance OLTP as they minimize transaction duration for multi-statement transactions.” The reduction of network round trips is always crucial. I think a lot of round trips could go away if you could issue multiple statements at once (not via semicolon separating them, by protocol awesomeness).

There should be a way to send a set of statements that should be executed. There should also be a way to specify that if no error occurred, commit. This could then be (in the common case) a single round trip to the database. You then only have to make round-trips when what statement to issue next depends on the result of a previous one. The next step being to reduce these round trips… which can either be solved by executing something inside the database server (e.g. stored procedures) or something closer to the database server so that the round trips aren’t as large. This would be where Gearman enters.

I’m interested to see where these two approaches (issuing in batches and executing closer to the DB server) fall down… I know that latency may not be as good… but throughput should be a lot better.

I take heart with “I have yet to use them in MySQL” though. I have my own theories as to why this is… my biggest thought is that it’s because the many, many programmers writing SQL that Mark sees aren’t SQL Stored Procedure programmers. They spend their days in a couple of languages (maybe Perl, Python, PHP, Java, C, C++) and never programmed SQL:2003 Stored Procedures and it just doesn’t come as quickly (or as bug free) as writing code in the languages you use every day.

“Long Running insert, update and delete statements consume too many resources in InnoDB.” I wonder if this desire for MyISAM could be filled by PBXT or BlitzDB? The main reason that MyISAM is currently a temporary table only engine is that MyISAM and the server core were never that well separated.

My ultimate wish is that all engine authors take the approach of that there is an API to their engine and the Storage Engine is merely glue between the database server and their API.

The BlitzDB engine has this, Innobase partially does (and my Embedded InnoDB work goes the whole way) and MySQL Cluster is likely the oldest example.

As a side note, the BlitzDB plugin should go into the main Drizzle tree fairly soon. One of the joys of having an optional plugin that doesn’t touch the core of the server is that we can do this without much worry at all.

“Does Drizzle build on Windows?” Well… no. Funnily enough though, it is increasingly easy to make a Windows port. All the platform specific things are increasingly just plugins. The build system is a sticker… and no, we’re not going to switch to CMake. The C stands for something, and it’s something that even I may not print here… (I had never thought that being able to open up automake generated Makefiles and look at them would be a feature).

This next Drizzle milestone release should be exciting though…

I look forward to having Drizzle widely deployed and relied upon… I think we’ll do well..

PlanetMySQL Voting: Vote UP / Vote DOWN