К сожалению, несмотря на то, что ваши вопросы Монти отправили задолго до конца декабря; ему удалось ответить на них несколько позже запланированного, что, однако, не умаляет интересности и актуальности его ответов( Английский оригинал ответов Михаила на ваши вопросы можно скачать Здесь (RTF-файл, 16,6 КБ); Ниже наш перевод, возможно он не идеален, поэтому буду рад, если вы укажете на возможные ошибки.
).
Напомню, что Майкл «Монти» Видеоинус — один из главных разработчиков популярной СУБД MySQL, которой, в свою очередь, хочет владеть корпорация Oracle. По понятным причинам Монти совсем не устраивает такое положение дел, поэтому в прошлом году он опубликовал в своем блоге соответствующее примечание , обращаясь за помощью к сообществу.
Итак, Монти, тебе поступали вопросы от Хабрахабр.
ру? Люди обеспокоены тем, что вы так долго отвечаете.
Я только что заметил.
Прошу прощения за задержку, добавлял поддержку иностранных языков на helpmysql.org , в последние дни это заняло почти все мое время.
Как вам пришла в голову идея создания MySQL в 1994 году? Почему вы вообще решили это сделать? Что вам не понравилось в существующих решениях? MySQL был основан на более старой программе управления базами данных Unireg, которую я начал разрабатывать в 1982 году.
Это был генератор приложений на основе tty (экрана).
С помощью Unireg мы создавали прикладные программы для наших клиентов.
В 1993 году нам нужно было предоставить клиентам доступ к их базам данных Unireg через Интернет. Чтобы решить эту проблему, я создал слой SQL поверх Unireg (поскольку я полагал, что SQL будет легко встраивать в сценарии HTML), а также драйвер ODBC. Другими словами, первоначальной целью MySQL было решение наших собственных проблем по предоставлению клиентам доступа к данным.
В качестве альтернативы мы рассматривали Sybase, но эта СУБД была недостаточно быстрой (по сравнению с Unireg) и ее нелегко было встроить в HTML-страницы.
Сейчас MySQL (как и другие реляционные СУБД) фактически стала «решением по умолчанию» для всех вопросов хранения и поиска данных.
Но, как известно, любое общее решение уступает узкоспециализированному.
Считаете ли вы, что использование СУБД оправдано практически везде, или существует широкий круг задач, где лучше использовать другой подход, или где вообще быстрее написать собственное решение, чем «заточить» традиционную СУБД? получить сопоставимую эффективность? Можете ли вы назвать несколько показательных примеров, когда использование СУБД является неправильным решением? Основным преимуществом СУБД, особенно основанных на SQL, является простота интеграции в код приложения (особенно такие сценарии, как PHP) при сохранении читабельности.
С помощью простой коррекции SQL-строки можно получать самые разнообразные отчеты, практически не меняя код самого приложения.
В прежние времена самая большая проблема ССУБД по сравнению со специализированными системами заключалась в том, что это решение более общего назначения требовало больше системной памяти и дискового пространства.
С ростом производительности компьютера и появлением больших и дешевых дисков это обычно больше не является проблемой.
Но, конечно, всегда следует выбирать наиболее подходящий инструмент для конкретной задачи, а в некоторых случаях СУБД не является идеальным решением.
– Когда размер программы важен.
Например, на маленьких или очень дешевых мобильных устройствах.
– Когда вам нужно получить максимально возможную скорость и вы можете пожертвовать простотой обслуживания.
Например, когда вам приходится иметь дело с петабайтами данных.
– Когда вы можете загрузить все данные в память с помощью своего инструмента (но не с помощью готовой СУБД).
– Когда вам необходимо обрабатывать данные по шаблонам, для которых язык СУБД не подходит (например, поиск друзей среди друзей ваших друзей).
— Когда нужно запустить много сложных пакетов с операциями типа обновление/удаление/вставка, если в специализированном приложении можно сделать всё в одном пакете, то в СУБД придётся запускать 10х пакетов.
(В этом Unireg по-прежнему лучше любой СУБД на базе SQL).
– Когда размер данных очень важен (в СУБД обычно имеется избыточность томов).
Вы когда-нибудь проектировали/разрабатывали высоконагруженные системы и как вы обходились ограничениями реляционных СУБД? В TCX (где я работал во время разработки Unireg/MySQL) мы использовали Unireg для высокой нагрузки и MySQL для отображения данных.
В наши дни, когда используется только MySQL, производительность может быть достигнута за счет репликации и параллельного запуска множества подчиненных процессов.
Как вы относитесь к парадигме NoSQL? Что более перспективно для веб-разработки: реляционные базы данных или NoSQL? NoSQL уже занял свое место в решении многих проблем, которые я перечислил ранее.
Для веб-разработки реляционные СУБД обычно лучше, потому что SQL очень легко встроить в ваш код, и вам не нужно дублировать функции, которые выполняет за вас СУБД (например, группировка и сортировка).
Чем Oracle угрожает MySQL и является ли решение Еврокомиссии по этому вопросу панацеей? Существует несколько способов, которыми Oracle может повредить MySQL. – Перенести все процессы разработки в корпоративную версию MySQL с закрытым исходным кодом, оставив минимальное/нулевое количество программистов для версии с открытым исходным кодом.
– Прекратить продажу или повысить цены на лицензии MySQL (что убьет экономическую экосистему вокруг MySQL).
– Будьте активны в продаже решений Oracle, но не MySQL. – Начните переводить пользователей на платную версию MySQL с закрытым исходным кодом или на серверы Oracle. — Обеспечить такую поддержку MySQL и такой минимальный объём разработки версии с открытым исходным кодом (в течение ограниченного времени), чтобы пользователи не перешли на форк слишком рано, чтобы любая другая компания столкнулась с трудностями при создании конкурентоспособного бизнеса.
Существует множество других способов, с помощью которых Oracle может сделать существование форка практически невозможным.
Когда все адекватные форки умрут, Oracle сможет спокойно добить MySQL. Европейская комиссия все еще может заблокировать сделку Oracle/Sun. Окончательное решение они объявят 11-15 января.
Я считаю, что если наша петиция будет принята helpmysql.org соберет достаточное количество подписей, Еврокомиссия заблокирует сделку, и Oracle придется либо не покупать Sun, либо выделять MySQL в отдельный бизнес, либо предоставить реальные гарантии юридической защиты MySQL (а не те озвученные гарантии, которые не имеют никакой ценности ), так что MySQL продолжает оставаться конкурентной силой против Oracle. Возможно ли сообщество разработать альтернативную ветку MySQL без участия Oracle? Технически кто-то мог бы создать форк MySQL, но его нельзя было бы использовать в коммерческих целях.
Поэтому практически невозможно заработать на этом достаточно денег, чтобы поддержать столь серьезный объем разработки.
Так что, если Oracle действительно хочет уничтожить MySQL, они могут это сделать, если захотят. Это займет много времени, но в конце концов они смогут добиться своей цели.
Я пытался освещайте эту тему в своем блоге .
Что вы думаете о Дриззле? Стоило ли делать форк или можно было попытаться как-то сделать сам MySQL более модульным, с разными вариантами сборки? Я думаю, Drizzle — интересный проект. Экспериментируя с кодом, они откроют для себя что-то новое, полезное каждому.
Конечно, будущее проекта также зависит от сделки Oracle/Sun, поэтому посмотрим, что будет дальше.
Форк был необходим, потому что Брайан Акер потерял возможность вносить изменения в MySQL из-за управления MySQL (и установленных им правил), поэтому единственным способом реализовать его идеи было создание отдельного проекта.
Каково ваше личное мнение о других бесплатных СУБД, таких как PostgreSQL? Считаете ли вы их своими конкурентами? Среди них наиболее заметными (и часто используемыми) являются PostgreSQL и SQL-lite. Обе они являются хорошими СУБД и имеют свое применение.
SQL-lite имеет четкую нишу без конкурентов.
Если вам нужно что-то в первую очередь для одного пользователя, очень простое в использовании и потребляющее очень мало памяти, это ваш первый выбор.
PostgreSQL и MySQL дополняют друг друга.
В зависимости от вашего приложения лучше то или другое (не хочу начинать дискуссии о PostgreSQL/MySQL, потому что они всегда заканчиваются холивером).
Во многих случаях вы можете перенести приложение с PostgreSQL на MySQL или наоборот, но чем больше приложение и чем больше модулей оно использует, тем сложнее это сделать.
А если вы застряли в репликациях и мониторах, то еще сложнее.
На коммерческом рынке MySQL всегда занимала гораздо большую долю, чем PostgreSQL, во многом благодаря тому, что за нами стояла крупная фирма и мы обеспечивали широкую поддержку.
Как вы относитесь к базе данных FireBird/Interbase? Я не очень хорошо осведомлен об этом проекте, хотя хорошо знаком с его авторами Джимом Старки и Энн В.
Харрисон.
По сравнению с 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 евро за каждую проданную копию программы с использованием встроенной версии.
Это делало невозможным использование библиотеки в небольших коммерческих продуктах, поскольку в большинстве случаев ее цена превышала стоимость программного обеспечения.
Каковы ваши планы по развитию MySQL Embedded и будет ли реальная легальная возможность использовать библиотеку в коммерческих продуктах? Стандартная цена за единственный экземпляр составляла 250 евро.
Если вы купите больше, цена может снизиться до 1 евро за экземпляр.
Цена также зависит от стоимости вашего приложения.
Если стоимость невысока, то можно купить очень недорогие лицензии у Sun. Вообще, лично я всегда считал, что стоимость встроенного сервера должна быть пропорциональна стоимости приложения, но не превышать 10%.
А при сегодняшней конкуренции на рынке СУБД этот процент, вероятно, должен быть еще ниже.
Изменятся ли приоритеты разработки MySQL после слияния Sun и Oracle? Я считаю, что как только Oracle сможет, они переведут большую часть разработки на проприетарные версии или проприетарные модули.
Oracle также вряд ли внедрит какие-либо функции, которые сделают MySQL более конкурентоспособной по сравнению с их флагманским продуктом 11g. Не ждите стоечных возможностей, репликации с автоматическим переключением при сбое, лучшей поддержки многоядерных процессоров, улучшений оптимизатора и т. д. Самый простой способ избежать такого сценария – подписать петицию helpmysql.org .
Голос важен, независимо от того, из какой точки мира он исходит. Этот голос может повлиять на будущее как здесь, в Европейском Союзе, так и в России.
Спасибо всем за интересные вопросы :) Теги: #Интервью #MySQL #Майкл Вижнус #Монти
-
Мобильная Версия 2Гис Появилась В Ovi Store
19 Oct, 24 -
Приходите И Забирайте Прототипы Книг!
19 Oct, 24 -
Lxc На Сервисе Qos (Заменяемый Ifb На Veth)
19 Oct, 24 -
Вышла Alien Arena 2009.
19 Oct, 24 -
Ecfg: Посадить ~/.Emacs На Диету
19 Oct, 24
