Хабраинтервью с Майклом Видениусом (MySQL)

    К сожалению, несмотря на то, что ваши вопросы Монти были отправлены задолго до конца декабря, ответить на них он сумел несколько позже запланированного срока, что, впрочем, не умаляет интересности и актуальности его ответов (англоязычный оригинал ответов Майкла на ваши вопросы можно скачать здесь (RTF-файл, 16,6 Кбайт); ниже дан наш перевод, он может быть не идеален, так что буду рад, если укажете на возможные ошибки).

    Напомню, что Майкл «Монти» Видеинус — это один из основных разработчиков популярной СУБД MySQL, которую, в свою очередь, хочет заиметь Oracle Corporation. Такое положение дел Монти по понятным причинам совершенно не устраивает, в связи с чем он в прошлом году опубликовал у себя в блоге соответствующую заметку, обращаясь за помощью к комьюнити.

    Итак, Монти, вы получили вопросы от Habrahabr.ru? Люди волнуются, что вы так долго не отвечаете.
    Я только что заметил. Прошу прощения за задержку, добавлял поддержку иностранных языков на helpmysql.org, это заняло почти всё моё время в последние дни.

    Как вы пришли к идее создания MySQL в 1994 году? Почему вообще решили этим заняться? Что не устраивало в существующих решениях?
    MySQL была основана на более старой программе для баз данных Unireg, которую я начал разрабатывать в 1982-м. Это был генератор приложений на основе tty (screen). С помощью Unireg мы создавали прикладные программы для наших клиентов.

    В 1993-м нам понадобилось обеспечить клиентам доступ к их базам Unireg через интернет. Чтобы решить эту проблему, я сделал поверх Unireg слой SQL (поскольку я полагал, что SQL будет легко встроить в скрипты HTML), а также драйвер ODBC.

    Другими словами, первоначальной задачей MySQL было решение наших собственных проблем, чтобы предоставить клиентам доступ к данным.

    В качестве альтернативного варианта мы рассматривали Sybase, но эта СУБД была недостаточно быстрой (по сравнению с Unireg) и её нельзя было легко встраивать в HTML-страницы.

    Cейчас MySQL (как и другие реляционные СУБД) фактически стала «решеним по-умолчанию» для всех вопросов хранения и поиска данных. Но, как известно, любое общее решение проигрывает узкоспециализированному. Считаете ли вы, что использование РСУБД оправдано практически везде, или же есть широкий круг задач, где лучше использовать другой подход, а есть — где вообще быстрее написать своё решение, чем «затачивать» традиционную РСУБД для получения сравнимой эффективности. Можете назвать какие-то показательные примеры, где использовать РСУБД — ошибочное решение?
    Главным преимуществом РСУБД, особенно на основе SQL, является простота интеграции в код приложений (особенно скриптов, таких как PHP) при сохранении его читабельности. Обычным исправлением SQL-строки вы можете получить самые разнообразные отчёты, практически не меняя код самого приложения.

    В старые времена самой большой проблемой РСУБД, по сравнению со специализированными системами, было то, что это более универсальное решение требовало больше системной памяти и места на диске. С повышением производительности компьютеров и появлением объёмных дешёвых дисков это обычно уже не является проблемой.

    Но конечно, вы всегда должны выбрать самый подходящий инструмент для решения конкретной задачи, и РСУБД не является идеальным решением в некоторых случаях.

    – Когда важен размер программы. Например, на маленьких или очень дешёвых мобильных устройствах.

    – Когда требуется получить максимально возможную скорость и можно пожертвовать удобством сопровождения. Например, когда приходится иметь дело с петабайтами данных.

    – Когда вы можете загрузить все данные в память с помощью своего инструмента (но не с помощью РСУБД, имеющейся в наличии).

    – Когда требуется обработка данных в паттернах, для которых язык РСУБД не приспособлен (например, поиск друзей у друзей ваших друзей).

    – Когда нужно запустить много сложных пакетов с операциями типа обновить/удалить/вставить, если в специализированном приложении вы можете сделать всё одним пакетом, а в РСУБД приходится запускать 10x пакетов. (Это тот случай, где Unireg до сих пор лучше любой РСУБД на основе SQL).

    – Когда размер данных очень важен (в РСУБД обычно наблюдается избыточность по объёму).

    Вы когда-нибудь занимались проектированием/разработкой систем с высокой нагрузкой и как вы обходили ограничения реляционных СУБД?
    В компании TCX (где я работал во время разработки Unireg / MySQL) мы использовали Unireg для высокой нагрузки и MySQL для отображения данных.

    В наше время, когда используется только MySQL, можно добиться производительности с помощью репликации и запуска многих параллельных подчинённых процессов.

    Как вы относитесь к парадигме NoSQL? Что перспективнее для веб-разработки: реляционные БД или NoSQL?
    NoSQL уже заняла своё место для решения многих задач, которые я перечислил ранее.

    Для веб-разработки реляционные СУБД обычно лучше, потому что SQL настолько легко встраивать в код и вам не нужно дублировать у себя функциональность, которую РСУБД делает за вас (как группировка и сортировка).

    Каким образом Oracle угрожает MySQL и является ли панацеей решение Еврокомиссии по этом вопросу?
    Есть несколько способов, как Oracle может повредить MySQL.

    – Перенести все процессы разработки в корпоративную версию MySQL с закрытыми исходниками, оставив минимальное/нулевое количество программистов на версии Open Source.

    – Прекратить продажу или повысить цену на лицензии MySQL (что убьёт экономическую экосистему вокруг MySQL).

    – Проявлять активность в продаже решений Oracle, но не MySQL.

    – Начать перевод пользователей на платную версию MySQL с закрытыми исходниками или на серверы Oracle.

    – Обеспечивать такую поддержку MySQL и такое минимальное количество разработки версии Open Source (в течение ограниченного времени), чтобы пользователи не переходили на форк слишком рано, так чтобы любая другая компания испытывала затруднения в развёртывании конкурентного бизнеса.

    Есть много других способов, как Oracle может сделать практически невозможным выживание форка. Когда все адекватные форки умрут, Oracle сможет спокойно прикончить MySQL.

    Европейская комиссия всё ещё может заблокировать сделку Oracle/Sun. Они огласят окончательное решение 11-15 января. Я верю, что если наша петиция на helpmysql.org соберёт достаточно подписей, то Еврокомиссия заблокирует сделку, и Oracle придётся либо не покупать Sun, либо выделить MySQL в отдельный бизнес, либо обеспечить реальные гарантии по судебной защите MySQL (а не те озвученные гарантии, которые не имеют никакой ценности), чтобы MySQL продолжал оставаться конкурентной силой против Oracle.

    Возможна ли разработка альтернативной ветки MySQL сообществом без участия Oracle?
    Технически кто-нибудь может сделать форк MySQL, но его нельзя будет использовать в коммерческих целях. Поэтому почти невозможно заработать на нём достаточно денег, чтобы поддерживать такой серьёзный объём разработки.

    Так что если Oracle действительно захочет убить MySQL, они смогут это сделать, если захотят. Это займёт долгое время, но в конце концов они могут добиться своего.

    Я попытался раскрыть данную тему в своём блоге.

    Что вы думаете о Drizzle? Стоило ли делать форк или можно было попытаться как-то сделать саму MySQL более модульной, с разными вариантами сборки?
    Я думаю, Drizzle — интересный проект. Экспериментируя с кодом, они обнаружат новые вещи, полезные для всех. Конечно, будущее проекта тоже зависит от сделки Oracle/Sun, так что ещё посмотрим, что будет дальше.

    Форк было делать необходимо, потому что Брайан Акер (Brian Aker) потерял возможность вносить изменения в MySQL из-за менеджмента компании MySQL (и правил, которые они ввели), так что единственным способом реализации его идей было создание отдельного проекта.

    Каков ваш личный взгляд на другие свободные СУБД, как например PostgreSQL. Считаете ли вы их своими конкурентами?
    Среди них наиболее заметные (и часто используемыми) — PostgreSQL и SQL-lite. Обе они являются хорошими СУБД и имеют своё применение.

    У SQL-lite есть чёткая ниша без конкуренции. Когда вам нужно что-то, в основном, на одного пользователя, очёнь легкое в использовании и потребляющее очень мало памяти, это ваш первый выбор.

    PostgreSQL и MySQL дополняют друг друга. В зависимости от вашего приложения, лучше либо одно, либо другое (я не хочу начинать дискуссий о PostgreSQL / MySQL, потому что они всегда заканчиваются холиваром). Во многих случаях вы можете перенести приложение с PostgreSQL на MySQL или обратно, но чем объёмнее приложение и чем больше модулей оно использует, тем труднее это сделать. А если вы завязли в репликациях и мониторах, то ещё труднее.

    На коммерческом рынке MySQL всегда занимала намного большую долю, чем PostgreSQL, во многом благодаря тому, что за нами стояла большая фирма и мы повсеместно обеспечивали поддержку.

    Как вы относитесь к БД FireBird/Interbase?
    Я не очень хорошо осведомлён об этом проекте, хотя отлично знаком с его авторами Джимом Старки (Jim Starkey) и Энн Харрисон (Ann W. Harrison).

    По сравнению с MySQL и PostgreSQL, он не имеет особого распространения и никогда не пользовался спросом на коммерческом рынке.

    Каково будущее проекта Falcon?
    Насколько я знаю, проект мёртв. Falcon был создан на замену InnoDB, но с появлением интереса Oracle к покупке MySQL его миссия была исчерпана.
    Это подтверждается остановкой работы над MySQL 6.0, где Falcon был ключевой фичей.

    Список функций MySQL 6.0 до сих пор не известен, но я уверен, что Falcon’а там не будет.

    Есть ли в перспективе поддержка рекурсивных запросов в MySQL? Если есть, то когда планируется?
    Если вы имеете в виду CONNECT BY, то да, это есть в планах. Нам только нужно найти пару заказчиков, согласных оплатить работу по реализации. Или найти кого-нибудь в сообществе, кто бы согласился сотрудничать с нами и сделать это.

    Вообще, моя новая компания Monty Program Ab зарабатывает реализацией новых фич в СУБД MariaDB, это ветка MySQL. Мы стараемся тратить 40% времени на работу с сообществом и 60% на реализацию фич по заказу клиентов.

    Для использования MySQL Embedded в локальных программах Sun требовала оплату в 250 евро за каждую проданную копию программы с использованием embedded-версии. Это делало невозможным использование библиотеки в небольших коммерческих продуктах, так как в большинстве случаев её цена превышала стоимость ПО. Какие планы на развитие MySQL Embedded и будет ли какая-то реальная легальная возможность использования библиотеки в коммерческих продуктах?
    250 евро было стандартной ценой для единственной копии. Если покупать больше, то цена может опуститься вплоть до 1 евро за копию.

    Цена также зависит от стоимости вашего приложения. Если стоимость низкая, то есть возможность купить очень недорогие лицензии у Sun.

    В целом, лично я всегда считал, что стоимость встроенного сервера должна быть пропорциональна стоимости приложения, но не превышать 10%. А с сегодняшней конкуренцией на рынке СУБД процент, вероятно, должен быть ещё ниже.

    Изменятся ли приоритеты при разработке MySQL после объединения Sun и Oracle?
    Я полагаю, что как только Oracle сможет, они перенесут основную часть разработки в закрытую версию или закрытые модули.

    Oracle также вряд ли будет реализовывать какие-либо функции, способные сделать MySQL более конкурентоспособной СУБД по отношению к их флагманскому продукту 11g. Можете не ждать rack-like возможностей, репликации с автоматическим перехватом управления при отказе, лучшей поддержки многоядерных процессоров, улучшений оптимизатора и т.д.

    Самый простой способ избежать такого сценария — подписать петицию на helpmysql.org. Голос важен, из какого уголка мира он бы не пришёл. Этот голос может повлиять на будущее и здесь в Евросоюзе, и в России.

    Всем спасибо за интересные вопросы :)
    Поделиться публикацией

    Похожие публикации

    Комментарии 46

      +11
      В сложившейся ситуации я его понимаю. Всё-таки может погибнуть дело многих лет его жизни.
      Но!

      Может я чего-то не помню (или не знаю), но о чём он думал, когда продавал MySQL AB компании SUN?
        0
        Sun достаточно организованная компания с неплохой репутацией. Просто развели его Oracle в несколько ходов.
        Подписываем петицию и надеемся на лучшее!
          +23
          Ну, Майкл некисло бабла нагрел на этом деле. Пускай или форкает в отдельный проект или не выступает, борец за проданный им mysql.
            –1
            Нельзя не согласиться с вами!
            +1
            По-моему никто никого не разводил, а просто Sun оказалась на гране банкротства (или стала банкротом, не знаю точно).
            Вопрос мой был не в этом.

            Суть в том, что сейчас товарищ Монти раслачивается за то, что в январе 2008 года провернул весьма неплохую для сделку, продав MySQL AB компании Sun.
          0
          Хороший перевод, спасибо.
            +3
            «Oracle может иметь Сун, но не MySQL!»
              0
              Oracle может позволить себе иметь кого угодно.
              Петицию подписал, правда без особой уверенности, что это поможет
                +1
                Я тоже подписал, а потом посмотрел в статистику и сник — чуть более 27 тысяч подписавших (учитывая, сколько людей реально использует MySQL) — это капля в море.
                Из России вообще на текущий момент меньше 500 человек. И это при том, что на одном Хабре в блоге MySQL 1618 читателей!
                  0
                  Хабраэффект всё-таки работает, сейчас уже больше 600 из России, догнали Китай. :-)
                    0
                    А я из Украины, судя по всему мы входим в «Europe, but not EU» :)
                0
                Я тоже заметил, там в переводе ещё несколько ляпов было

                Судя из интервью, он переводил вручную сам, без помощи людей из других стран. Что довольно удивительно и даже поразительно
              • НЛО прилетело и опубликовало эту надпись здесь
                  +1
                  Гуглу с GoogleFS Mysql совсем не нужен (=
                    +1
                    Зачем им это? У них своя БД, явно «покруче» чем MySQL (возможно и чем Oracle). Они предлагают использовать App Engine с этой БД. Хостинга у них своего нет, большая часть предоставляемых ими услуг обеспечиваются их серверами. Что они делали бы с mysql?
                    И что ненужного они купили? Вы точно разбираетесь в этой теме лучше, чем соответствующие работники гугла? Оно точно ненужное?
                      0
                      Если вы про DataStore, то его возможности намного скромнее MySQL. Фактически это не РСУБД, а key-value хранилище. Там фишка только в скалабилити.
                        +2
                        Если не ошибаюсь, для их масштабов как раз таки главный параметр — масштабируемость.
                          +1
                          Я, конечно. согласен. Просто из-за одного этого преимущества вряд ли стоит называть датастор «круче» чем mysql и уж тем более оракл.
                          Может быть дело в том, что мне как Oracle-разработчику (а не джависту или питонисту) возможности его GQL кажутся просто мизерными. В общем, он просто другой совсем.
                            0
                            Ну так для более серьезных операций над данными используется полноценный MapReduce.
                        +5
                        У них нет РСУБД и MySQL они до сих пор используют и выпускают к нему патчи.
                          +1
                          Ну да.
                          Какая то мелочь, адсенс на MySQL крутится.
                          Нафиг она гуглу?
                          :-)
                            +1
                            Хм… Не знал. Спасибо за указание.
                            Только все-таки не adsense, а adwords.
                              0
                              Это вообщето одна система.

                              А называют ее по разному с той стороны с которой смотрят.
                              Adsens — площадки, Adwords — рекламодатели
                              :-)
                      +2
                      Самый простой способ избежать такого сценария — подписать петицию на helpmysql.org.

                      подписал.
                        –1
                        Да, это важно. Петицию уже подписал. Все таки если MySQL станет закрытой и платной СУБД, придется проекты переводить на что-то другое, а это свои проблемы. Пострадают все.

                        За перевод спасибо. Интересно было услышать мнение из первых уст так сказать.
                          +1
                          Тут то PostgreSQL и потирает ручки :)) тем более, что разницы для перехода с MySQL на PostgreSQL почти нет, т.с. поменяем «дельфина» на «слона».
                            0
                            Ну да как же. Один LastInsertId потребует переписать все вставки объектов.
                              –1
                              Репликацию нормальную сначала пусть сделают
                          0
                          Спасибо, весьма интересно
                            0
                            >«Для веб-разработки реляционные СУБД обычно лучше, потому что SQL настолько легко встраивать в код и вам не нужно дублировать у себя функциональность, которую РСУБД делает за вас (как группировка и сортировка).»

                            Как будто в MongoDB нужно дублировать функциональность и ее сложно встраивать в код.
                              0
                              Там надо мыслить по-другому немного.
                              0
                              Интересно получается, если MySQL станет коммерческим или его просто убьют в пользу других БД, то сколько ж сайтов потребуют переделок? Студиям на прибыль )
                                0
                                С плохим неадаптируемым к изменившимся условиям (смена СУБД, например) кодом рано или поздно случается катастрофа. Если код неплох, то он будет отреставрирован в кратчайшие сроки. Если код плохой, то он будет либо списан в Recycle Bin, либо будет переписан чуть менее, чем полностью.
                                  +1
                                  А почему обязательно БД должна обновляться? Что ужасного в том, чтобы использовать необновляющуюся БД? (к тому же багфиксы, думаю, все-таки будут)
                                  +8
                                  Отлично, продал компанию за 1 миллиард долларов, а теперь начинает ныть «ах, сообщество, не допустите перепродажи». Просто жлоб, вот и все.
                                    +4
                                    Монти прекрасно понимает, что:
                                    — без полноценного MySQL AB division эта БД скатится в гетто в плане маркетинга
                                    — придется писать документацию, которую нельзя форкнуть
                                    — Oracle не будет тянуть MySQL до уровня своей основной БД

                                    Все это намечает PostgreSQL, как будущего лидера OpenSourse RDBMS. Монти так же любит нести чушь, например про то, что следующем поглащением будет эта БД, хотя там все яйца не в одной корзине.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        +1
                                        Большинству хомяков и третьей ветки хватило бы за глаза. Многие из разводящих панику не используют и половины возможностей из тех, что есть, а об остальной половине знают понаслышке.
                                        Кому действительно критично использование новых версий или ожидают новых фич за год-два мигрируют на тот же postgre.
                                        Имхо, Монти сам себе на уме. Даже если завтра объявят прекращение любых работ — все равно мы выживем и все будет хорошо. Возможно вспомним лет через 5-10, что была бесплатная и легкая в освоении СУБД, установленная на большинстве хостингов.
                                        +6
                                        Я думаю не стоит драматизировать.
                                        Во-первых, вспомним, что один из самых популярных движков MySQL — InnoDB — уже принадлежит Ораклу. Это не мешает ему развиваться.
                                        Во-вторых, MySQL не является соперником Oracle DB, т.к. они крутятся в совершенно разных весовых категориях.
                                        В-третьих, закрыв MySQL как проект или сделав его платным, Оракл сильно подпортит себе репутацию.
                                        В-четвёртых, у MySQL есть отличнейшая замена — Postgres, и Оракл это понимает.

                                        Даже в случае, если MySQL исчезнет, станет платным или закрытым продуктом, то даю гарантию, что его новая ветвь появится незамедлительно, и разработкой займутся те же самые разработчики или хотя бы их большинство.

                                        Зато сейчас есть шанс, что опыт Оракла позволит улучшить MySQL :) Вот бы научили его нормально работать с многопроцессорными системами!
                                          0
                                          Подписал петицию и пошел читать доки к PostgresSQL :(
                                            +15
                                            Этого Монти надо изолировать от человечества.

                                            Во-первых, его контора делала очень мало для развития MySQL. К примеру, драйвера jdbc написаны очень криво. Люди, которые используют MySQL не для лаб в универе, плюются от глючности этой базы. Только с приобретением мускуля саном эта база начала показывать масштабируемость, сравнимую или превосходящую postgresql.

                                            Во-вторых, этот засранец Монти уже форкнул базу и развивает ее в своем новом уютном гнездышке: askmonty.org/wiki/index.php/MariaDB. Спрашивается, чего жалуешься? Опенсурс опасносте? Ни*я!

                                            В-третьих: этот парниша продав говнобазу сантехникам за один ярд зелени (бля, один миллиард за глючное наколенное поделие!), сейчас хочет снова получить контроль за развитием продукта. И рыбку скушать и вернуть назад своих кастомеров. Ну-ну.

                                            Короче, попахивает гнилью и дерьмецом от этого Монти.
                                              +1
                                              Вот приблизительно эту мысль я и пытался рассказать в самом первом комменте к посту. Просто как-то слова не подобрались.
                                              Вы же раскрыли всё очень верно. Спасибо.
                                                0
                                                Мне кажется что sun покупала не сколько «готовый движок РСУБД с кучей уникальных наворотов / кривыми драйверами jdbc (нужное подчеркнуть)», а торговую марку MySql, сообщество разработчиков/компаний его использующих и готовую инфраструктуру проекта. Я не думаю что сановцы сами не смогли бы написать с 0 аналогичный по возможностям продукт, или что разработка его потребовала вложения миллиардов. Могли бы и намного дешевле, при этом сделать его 100% опенсурсным — только вот кому он сейчас был бы нужен, когда уже есть проверенные и всем давно известные mysql и postgerss? А вот раскрутка нового продукта потребовала бы намного больше денег и самое главное кучу времени. Так что sun не ошиблась как мне кажется с выбором, просто силенок не хватило тащить дальше.

                                                Ораклу «убивать» бренд mysql полностью им смысла точно нет, а вот снизить темпы роста новых фич в сторону enterprise — вполне и этим ограничить его нишу. А изначально мотивы те же что у sun — торговую марку и коммьюнити заполучить.
                                                  +2
                                                  Насчет Монти частично согласен: похоже, его мотивация «не давать и не пущать» скорее всего строится на каких-то своих, корыстных, интересах. Как вариант: после поглощения субжевой компании Ораклом, ядро будет переписано и ветки разойдутся с его форком «MariaDB» и им придется намного больше своих денег вкладывать в фундаментальную разработку, уже нельзя будет «личевать» на 100% совместимости с MySQL (Maria потому что приставку My* выкупил sun) и придется поднимать свой бренд практически с 0.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое