Pull to refresh

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

Reading time 7 min
Views 5.1K
К сожалению, несмотря на то, что ваши вопросы Монти были отправлены задолго до конца декабря, ответить на них он сумел несколько позже запланированного срока, что, впрочем, не умаляет интересности и актуальности его ответов (англоязычный оригинал ответов Майкла на ваши вопросы можно скачать здесь (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. Голос важен, из какого уголка мира он бы не пришёл. Этот голос может повлиять на будущее и здесь в Евросоюзе, и в России.

Всем спасибо за интересные вопросы :)
Tags:
Hubs:
+68
Comments 46
Comments Comments 46

Articles