Michael Widenius（MySQL）とのHabrainterview

残念ながら、 あなたの質問は12月末よりずっと前にモンティに送信されたという事実にもかかわらず、彼は計画より少し遅れて答えることができましたが 、彼の答えの興味と関連性を損なうことはありません（ マイケルの元の英語の答えはここからダウンロードできます （RTFファイル、16.6 Kバイト）;以下に翻訳を示しますが、完璧ではないかもしれませんので、エラーの可能性を指摘していただければ幸いです ）。



Michael“ Monty” Videinusは人気の高いMySQL DBMSの主要な開発者の1人であり、Oracle Corporationはこれを手に入れたいと考えています。 明らかな理由から、モンティはこの状況に満足しておらず、それに関連して昨年彼のブログで対応するメモを公​​開し、コミュニティに助けを求めました。



モンティ、Habrahabr.ruから質問を受けましたか？ 人々はあなたがそれほど長く答えないことを心配します。

気がついた。 遅れて申し訳ありません。helpmysql.orgに外国語のサポートを追加しました。最近ではほとんどすべての時間がかかりました。



1994年にMySQLを作成するというアイデアをどのようにして思いついたのですか？ なぜこれをすることにしたのですか？ 既存のソリューションに適さないものは何ですか？

MySQLは、1982年に開発を開始した古いUniregデータベースプログラムに基づいていました。 tty（スクリーン）ベースのアプリケーションジェネレーターでした。 Uniregを使用して、顧客向けのアプリケーションプログラムを作成しました。



1993年には、インターネット経由でUniregデータベースへのアクセスを顧客に提供する必要がありました。 この問題を解決するために、ODBCドライバーと同様に、Uniregの上にSQLレイヤーを作成しました（SQLはHTMLスクリプトに簡単に埋め込むことができると思ったため）。



言い換えると、MySQLの当初の目標は、お客様にデータへのアクセスを提供するために、私たち自身の問題を解決することでした。



別の方法として、Sybaseを検討しましたが、このDBMSは（Uniregに比べて）十分に高速ではなく、HTMLページに簡単に埋め込むことができませんでした。



現在、MySQLは（他のリレーショナルDBMSと同様に）実際に、データの保存と取得のすべての問題に対する「デフォルトソリューション」になっています。 しかし、ご存じのとおり、一般的なソリューションは高度に専門化されたソリューションに負けています。 RDBMSの使用はほぼどこでも正当化されていると思いますか、または異なるアプローチを使用する方が良い幅広いタスクがあり、一般的な比較可能な効率を得るために従来のRDBMSを「シャープ」にするよりも一般的に独自のソリューションを書く方が速いと思いますか？ RDBMSを使用する場所-誤った決定である、いくつかの実例を挙げてください。

特にSQLに基づくRDBMSの主な利点は、読みやすさを維持しながら、アプリケーションコード（特にPHPなどのスクリプト）に簡単に統合できることです。 SQL文字列の通常の修正により、アプリケーション自体のコードをほとんど変更することなく、さまざまなレポートを取得できます。



昔、RDBMSの最大の問題は、特殊なシステムと比較して、より多くのシステムメモリとディスクスペースを必要とする、より普遍的なソリューションであったことでした。 コンピュータのパフォーマンスが向上し、大量の安価なドライブが出現したため、通常はこれはもはや問題ではありません。



しかし、もちろん、特定のタスクを解決するために常に最適なツールを選択する必要があり、RDBMSは場合によっては理想的なソリューションではありません。



-プログラムのサイズが重要な場合。 たとえば、小型または非常に安価なモバイルデバイス。



-可能な限り最高の速度を取得したい場合、護衛の利便性を犠牲にすることができます。 たとえば、ペタバイトのデータを処理する必要がある場合。



-ツールを使用してすべてのデータをメモリにロードできる場合（ただし、既存のRDBMSは使用しない場合）。



-RDBMS言語が適切でないパターンでデータ処理が必要な場合（たとえば、友人の友人から友人を検索する場合）。



-更新/削除/挿入などの操作で多くの複雑なパッケージを実行する必要がある場合、特殊なアプリケーションですべてを1つのパッケージで実行できる場合、RDBMSでは10xパッケージを実行する必要があります。 （これは、UniregがSQLベースのRDBMSよりも優れている場合です）。



-データサイズが非常に重要な場合（RDBMSでは、通常、ボリュームの冗長性が観察されます）。



高負荷システムの設計/開発に携わったことはありますか？また、リレーショナルDBMSの制限をどのように回避しましたか？

TCX（私はUnireg / MySQLの開発中に働いていました）では、高負荷にはUniregを、データの表示にはMySQLを使用しました。



現在、MySQLのみが使用されている場合、多くの並列スレーブプロセスを複製して起動することでパフォーマンスを達成できます。



NoSQLパラダイムについてどう思いますか？ Web開発にとってより有望なものは何ですか：リレーショナルデータベースまたはNoSQL？

NoSQLは、私が前に挙げたタスクの多くを解決するためにすでにその役割を果たしています。



SQLはコードに簡単に埋め込むことができ、RDBMSが行う機能（グループ化や並べ替えなど）を複製する必要がないため、Web開発では通常、リレーショナルDBMSが優れています。



オラクルはどのようにMySQLを脅かしますか。この問題に関する欧州委員会の決定は万能薬ですか？

OracleがMySQLを破壊する方法はいくつかあります。



-すべての開発プロセスをクローズドソースのMySQLの企業バージョンに転送し、オープンソースバージョンに最小限/ゼロのプログラマーを残します。



-MySQLライセンスの販売を停止するか、価格を引き上げます（これにより、MySQLを取り巻く経済的エコシステムが破壊されます）。



-Oracleソリューションの販売に積極的に参加するが、MySQLには積極的に参加しない。



-クローズドソースのMySQLの有料版またはOracleサーバーへのユーザーの転送を開始します。



-他の企業が競争力のあるビジネスを開発するのが困難になるように、ユーザーがフォークにあまりにも早く切り替えないように、MySQLのサポートとオープンソースバージョンの最小限の開発（期間限定）を提供します。



Oracleがフォークの生存をほぼ不可能にする他の多くの方法があります。 適切なフォークがすべてなくなると、OracleはMySQLを安全に強制終了できます。



欧州委員会は、Oracle / Sunの取引を引き続きブロックする可能性があります。 最終決定は1月11〜15日に発表されます。 helpmysql.orgに対する申し立てが十分な署名を収集した場合、欧州委員会は取引をブロックし、OracleはSunを購入しないか、MySQLを別のビジネスに分離するか、MySQL司法保護に対する真の保証を提供する必要があります。 MySQLがOracleに対して競争力を持ち続けるように。



Oracleなしでコミュニティが代替MySQLブランチを開発することは可能ですか？

技術的には、だれかがMySQLをフォークできますが、商用目的で使用することはできません。 したがって、そのような深刻な開発をサポートするのに十分なお金を稼ぐことはほとんど不可能です。



したがって、Oracleが本当にMySQLを殺したいのであれば、彼らは望むならそれをすることができます。 それには長い時間がかかりますが、最終的には彼らが望むものを手に入れることができます。



このトピックをブログでカバーしようとしました。



Drizzleについてどう思いますか？ フォークするのは価値があったのですか、それとも何らかの形でMySQL自体をモジュール化して、異なるビルドオプションを使用してみてください

Drizzleは興味深いプロジェクトだと思います。 コードを試すことで、彼らは誰にとっても役立つ新しいものを発見するでしょう。 もちろん、プロジェクトの将来はOracleとSunの契約にも依存しているため、次に何が起こるか見てみましょう。



MySQLの管理（および導入されたルール）のためにBrian AkerがMySQLに変更を加える能力を失ったため、分岐する必要があったため、彼のアイデアを実装する唯一の方法は別のプロジェクトを作成することでした。



PostgreSQLなど、他の無料DBMSの個人的な見解は何ですか。 彼らをあなたの競争相手と考えていますか？

その中で、最も注目に値する（そしてよく使用される）ものはPostgreSQLとSQL-liteです。 どちらも優れたDBMSであり、独自のアプリケーションがあります。



SQL-liteには競争のない明確なニッチがあります。 主に1人のユーザーのために、非常に使いやすく、メモリをほとんど消費しないものが必要な場合は、これが最初の選択肢です。



PostgreSQLとMySQLは互いに補完します。 アプリケーションによっては、どちらか一方の方が優れています（PostgreSQL / MySQLについては、常にholivarで終わるため、議論を始めたくありません）。 多くの場合、アプリケーションをPostgreSQLからMySQLに、またはその逆に移植できますが、アプリケーションが大きくなり、使用するモジュールが増えるほど難しくなります。 また、レプリケーションとモニターにこだわっている場合は、さらに難しくなります。



主に大企業が私たちの後ろにいて、どこでもサポートを提供したという事実により、MySQLは常にPostgreSQLよりも商業市場ではるかに大きなシェアを占めています。



FireBird / Interbaseデータベースについてどう思いますか？

私はこのプロジェクトについてあまり知識がありませんが、著者であるジム・スターキーとアン・W・ハリソンに精通しています。



MySQLやPostgreSQLと比較すると、それほど普及しておらず、商業市場で需要があったことはありません。



Falconプロジェクトの将来は何ですか？

私の知る限り、プロジェクトは死んでいます。 FalconはInnoDBを置き換えるために作成されましたが、MySQLの購入に対するOracleの関心の出現により、その使命は尽きました。

これは、Falconが主要な機能であったMySQL 6.0での作業の中断により確認されています。



MySQL 6.0の機能のリストはまだ不明ですが、Falconは存在しないはずです。



MySQLで再帰クエリの将来的なサポートはありますか？ もしそうなら、いつ計画されますか？

CONNECT BYを意味する場合、はい、これは計画中です。 実装作業の費用を支払う意思のある顧客を見つける必要があります。 または、私たちと一緒に仕事をすることに同意する人をコミュニティで見つけてください。



一般に、私の新しい会社Monty Program Abは、MariaDB DBMSに新しい機能を実装することで収益を上げています。これはMySQLブランチです。 私たちは、時間の40％をコミュニティと協力し、60％を顧客の注文による機能の実装に費やしています。



MySQLは、ローカルプログラムでMySQL Embeddedを使用するために、組み込みバージョンを使用してプログラムの販売コピーごとに250ユーロの支払いを要求しました。 ほとんどの場合、その価格はソフトウェアのコストを超えていたため、小さな商用製品でライブラリを使用することは不可能になりました。 MySQL Embeddedの開発計画はどのようなものですか？また、商用製品でライブラリを使用する実際の法的機会はありますか？

250ユーロは、単一のコピーの標準価格でした。 さらに購入すると、価格は1コピーあたり1ユーロに下がる可能性があります。



価格は、アプリケーションのコストにも依存します。 コストが低い場合、非常に安価なライセンスをサンから購入することができます。



一般的に、私は個人的に、組み込みサーバーのコストはアプリケーションのコストに比例すべきであると考えていましたが、10％を超えてはなりません。 また、今日のDBMS市場での競争により、この割合はさらに低くなるはずです。



SunとOracleが合併した後、MySQL開発の優先順位は変わりますか？

Oracleができる限り早く、開発の大部分をクローズドバージョンまたはプライベートモジュールに移行すると信じています。



オラクルは、主力製品である11gに関して、MySQLをより競争力のあるDBMSにできる機能を実装することもありません。 ラックのような機能、障害時の自動制御インターセプトを使用した複製、マルチコアプロセッサのサポートの改善、オプティマイザーの改善などを待つ必要はありません。



このシナリオを回避する最も簡単な方法は、 helpmysql.orgへの請願書に署名することです 。 声は重要であり、彼は世界のどこから来ないのでしょう。 この声は、欧州連合とロシアの両方で未来に影響を与える可能性があります。



興味深い質問をありがとうございます:)