Habrainterview with Michael Widenius (MySQL)

    Unfortunately, despite the fact that your questions were sent to Monty long before the end of December, he managed to answer them a little later than planned, which, however, does not detract from the interest and relevance of his answers ( Michael's original English answer can be downloaded here (RTF file, 16.6 Kbytes); our translation is given below, it may not be perfect, so I will be glad if you point out possible errors ).

    Let me remind you that Michael “Monty” Videinus is one of the main developers of the popular MySQL database management system, which, in turn, Oracle Corporation wants to get hold of. For obvious reasons, Monti is not happy with this state of affairs, in connection with which he published a note in his blog last yearturning to the community for help.

    So, Monty, did you receive questions from Habrahabr.ru? People worry that you do not answer for so long.
    I just noticed. I apologize for the delay, I added support for foreign languages ​​on helpmysql.org , it took almost all of my time in recent days.

    How did you come up with the idea of ​​creating MySQL in 1994? Why did you decide to do this? What did not suit the existing solutions?
    MySQL was based on an older Unireg database program, which I started developing in 1982. It was a tty (screen) based application generator. With Unireg, we created application programs for our customers.

    In 1993, we needed to provide customers with access to their Unireg databases via the Internet. To solve this problem, I made an SQL layer on top of Unireg (since I thought that SQL would be easy to embed in HTML scripts), as well as an ODBC driver.

    In other words, the original goal of MySQL was to solve our own problems in order to provide customers access to data.

    As an alternative, we considered Sybase, but this DBMS was not fast enough (compared to Unireg) and it could not be easily embedded in HTML pages.

    Now MySQL (like other relational DBMSs) has actually become a “default solution” for all issues of data storage and retrieval. But, as you know, any general solution loses to a highly specialized one. Do you think that the use of an RDBMS is justified almost everywhere, or is there a wide range of tasks where it is better to use a different approach, and there is where it is generally faster to write your own solution than to “sharpen" a traditional RDBMS to obtain comparable efficiency. Can you name some illustrative examples, where to use an RDBMS - an erroneous decision?
    The main advantage of an RDBMS, especially based on SQL, is the ease of integration into application code (especially scripts such as PHP) while maintaining its readability. By the usual correction of the SQL string, you can get a wide variety of reports, practically without changing the code of the application itself.

    In the old days, the biggest problem with RDBMS compared to specialized systems was that it was a more universal solution that required more system memory and disk space. With the increase in computer performance and the advent of voluminous cheap drives, this is usually no longer a problem.

    But of course, you should always choose the most suitable tool for solving a specific problem, and RDBMS is not an ideal solution in some cases.

    - When the size of the program is important. For example, on small or very cheap mobile devices.

    - When you want to get the highest possible speed and you can sacrifice the convenience of escort. For example, when you have to deal with petabytes of data.

    - When you can load all the data into memory using your tool (but not using the RDBMS available).

    - When data processing is required in patterns for which the RDBMS language is not suitable (for example, searching for friends from friends of your friends).

    - When you need to run many complex packages with operations such as update / delete / insert, if in a specialized application you can do everything in one package, and in RDBMS you have to run 10x packages. (This is the case where Unireg is still better than any SQL-based RDBMS).

    - When the size of the data is very important (in RDBMSs, volume redundancy is usually observed).

    Have you ever been involved in the design / development of high-load systems, and how did you circumvent the limitations of relational DBMSs?
    At TCX (where I worked during Unireg / MySQL development), we used Unireg for high load and MySQL for displaying data.

    Nowadays, when only MySQL is used, you can achieve performance by replicating and starting many parallel slave processes.

    How do you feel about the NoSQL paradigm? What is more promising for web development: relational databases or NoSQL?
    NoSQL has already taken its place to solve many of the tasks that I have listed earlier.

    For web development, relational DBMSs are usually better because SQL is so easy to embed in code and you don’t need to duplicate the functionality that RDBMS does for you (like grouping and sorting).

    How does Oracle threaten MySQL and is the European Commission's decision on this subject a panacea?
    There are several ways Oracle can corrupt MySQL.

    - Transfer all development processes to the corporate version of MySQL with closed sources, leaving a minimum / zero number of programmers on the Open Source version.

    - Stop selling or raise the price of MySQL licenses (which will kill the economic ecosystem around MySQL).

    - Be active in selling Oracle solutions, but not MySQL.

    - Start transferring users to the paid version of MySQL with closed sources or to Oracle servers.

    - Provide such support for MySQL and such a minimum amount of development of the Open Source version (for a limited time) that users do not switch to fork too early, so that any other company has difficulty in developing a competitive business.

    There are many other ways that Oracle can make fork survival nearly impossible. When all the adequate forks die, Oracle can safely kill MySQL.

    The European Commission may still block the Oracle / Sun deal. They will announce the final decision on January 11-15. I believe that if our petition on helpmysql.org collects enough signatures, the European Commission will block the deal, and Oracle will either have to not buy Sun, or separate MySQL into a separate business, or provide real guarantees for MySQL judicial protection (and not those voiced guarantees, which have no value) so that MySQL continues to be a competitive force against Oracle.

    Is it possible to develop an alternative MySQL branch by the community without Oracle?
    Technically, someone can fork MySQL, but it cannot be used for commercial purposes. Therefore, it is almost impossible to earn enough money on it to support such a serious amount of development.

    So if Oracle really wants to kill MySQL, they can do it if they want. It will take a long time, but in the end they can get what they want.

    I tried to cover this topic on my blog .

    What do you think of Drizzle? Was it worth it to fork or could you try to somehow make MySQL itself more modular, with different build options?
    I think Drizzle is an interesting project. By experimenting with code, they will discover new things that are useful to everyone. Of course, the future of the project also depends on the Oracle / Sun deal, so let's see what happens next.

    Fork needed to be done because Brian Aker lost the ability to make changes to MySQL due to the management of MySQL (and the rules they introduced), so the only way to implement his ideas was to create a separate project.

    What is your personal view of other free DBMS, such as PostgreSQL. Do you consider them your competitors?
    Among them, the most notable (and often used) are PostgreSQL and SQL-lite. Both of them are good DBMS and have their own application.

    SQL-lite has a clear niche without competition. When you need something mainly for one user, very easy to use and consuming very little memory, this is your first choice.

    PostgreSQL and MySQL complement each other. Depending on your application, either one or the other is better (I do not want to start discussions about PostgreSQL / MySQL, because they always end with a holivar). In many cases, you can port an application from PostgreSQL to MySQL or vice versa, but the larger the application and the more modules it uses, the more difficult it is. And if you're stuck in replications and monitors, it's even harder.

    MySQL has always occupied a much larger share in the commercial market than PostgreSQL, largely due to the fact that a large company was behind us and we provided support everywhere.

    How do you feel about the FireBird / Interbase database?
    I am not very knowledgeable about this project, although I am well acquainted with its authors Jim Starkey and Ann W. Harrison.

    Compared to MySQL and PostgreSQL, it is not very widespread and has never been in demand in the commercial market.

    What is the future of the Falcon project?
    As far as I know, the project is dead. Falcon was created to replace InnoDB, but with the advent of Oracle's interest in buying MySQL, its mission was exhausted.
    This is confirmed by the cessation of work on MySQL 6.0, where Falcon was a key feature.

    The list of MySQL 6.0 features is still unknown, but I'm sure Falcon won't be there.

    Is there any future support for recursive queries in MySQL? If so, when is it planned?
    If you mean CONNECT BY, then yes, this is in the plans. We just need to find a couple of customers willing to pay for the implementation work. Or find someone in the community who agrees to work with us and do it.

    In general, my new company Monty Program Ab makes money by implementing new features in the MariaDB DBMS, this is a MySQL branch. We try to spend 40% of the time working with the community and 60% on the implementation of features for customers.

    To use MySQL Embedded in local programs, Sun demanded a payment of 250 euros for each sold copy of the program using the embedded version. This made it impossible to use the library in small commercial products, since in most cases its price exceeded the cost of the software. What are the plans for the development of MySQL Embedded and will there be any real legal opportunity to use the library in commercial products?
    250 euros was the standard price for a single copy. If you buy more, the price can go down to 1 euro per copy.

    The price also depends on the cost of your application. If the cost is low, then it is possible to buy very inexpensive licenses from Sun.

    In general, I personally always believed that the cost of the embedded server should be proportional to the cost of the application, but not exceed 10%. And with today's competition in the DBMS market, the percentage probably should be even lower.

    Will MySQL development priorities change after Sun and Oracle merge?
    I believe that as soon as Oracle can, they will transfer the bulk of the development to a closed version or private modules.

    Oracle is also unlikely to implement any features that can make MySQL more competitive DBMS in relation to their flagship product 11g. You don’t have to wait for rack-like capabilities, replication with automatic control interception upon failure, better support for multi-core processors, optimizer improvements, etc.

    The easiest way to avoid this scenario is to sign a petition to helpmysql.org . The voice is important, from which corner of the world he would not come. This voice can affect the future both here in the European Union and in Russia.

    Thank you all for interesting questions :)

    Also popular now: