前回の出版以来、高価なエディションは多くのレビューを受けています。 それらのほとんどはポジティブであり、それは間違いなく人類における親愛なる編集者の信仰を強化します。 MySQLに対する批判という形でいくつかの深刻な追加がありましたが、私はそれを忘れていたか、聞いたこともありませんでした。 これにより、2番目の部分が作成されました。これは実際には1番目の部分に追加されるもので、当初は私の計画には含まれていませんでした。



そのため、 文化交流と秋の悪化の枠組みの中で、MySQLに関する典型的な誤解を分析し続けています。 最初に、最初の部分に関するいくつかの重要なレビュー。

「MySQLを使用している企業の長いリストは、キーバリューストレージとしてMySQLを使用しているため、意味がありません。」

時々、彼らはFacebook / Twitterについてだけ聞いたと付け加えますが、残りについては知りません。 誰かがJOINを使用しないと言います。 しかし、誰もソースを指し示していません。



第一に、たとえそうであったとしても、何も変わらないでしょう。 表示するために会社の完全なリストとは程遠いものを挙げました：誰かが好きかどうかは別ですが、MySQLは最大のWeb企業で最も人気のあるDBMSであるため、 レガシーテクノロジーは並列現実。



第二に、数十から数百の内部サービスを備えた1.5ダースの巨大企業について話していることを理解する必要があります。各企業には独自の構造とデータ量、応答時間の要件、読み取り/書き込みの配布などがあります。 これらのサービスのすべてがMySQLを使用するわけではありませんが、それぞれの場合に、キー値ストレージとしてMySQLが排他的に使用されると言っても、少なくとも素朴です。



最も簡単な方法は、Wikipediaを使用することです。MediaWikiのソースコードは公開されており、誰でも個別にリクエストの種類を確認できます。 さらに、ウィキペディアの従業員は、他の会社の代表者よりも詳細にインフラストラクチャについて話します。



Facebookに戻ると、最も負荷の高いサービスのいくつかは間違いなくキーバリューとして機能します。 データが数千のサーバーに分割されており、DBMSにキー値キャッシュがあるため、集約、結合などの使用が多少制限されているためです。 しかし、Facebookには多くのサービスがあり、それらの要件は異なります。 Facebookがデータを保存するために使用しているテクノロジーのごく最近の説明です。 MySQLを使用することの排他的キーバリューの性質に関する論文の確認を見つけたら、私に知らせてください。

「MySQLを使用している企業の長いリストは何の意味もありません。なぜなら、今ではMySQLを選択しないからです」

当然、正当な理由はありませんが、私は自分で試してみます。 成長しておらず、データを保存および処理するための新しいサービスや新しいタスクが表示されない静的な会社について話している場合、これには独自のロジックがあります。 または、リソースが限られている中小企業の場合、最適なDBMSは「チームが精通している」ことを意味します。 悪名高いFacebookに戻ると、どちらもそれを参照していません。 「宗教的な」偏見はなく、特定の技術的タスクに基づいてさまざまなテクノロジーが使用されます。 また、既存の技術はどれも要件を満たしていないため、新しい技術が開発されています。 例：カサンドラ、プレスト、スキューバ。



企業がMySQLを選択し続けている理由を要約しようとすると、MySQLがOLTPロード用の信頼性の高いスケーラブルなストレージとして使用されていると言っても、アメリカを発見することはできません。 私はPostgreSQLを批判することを慎重に避けているので、ここでは黙って大幅に残ります-別の出版物があります。



そして、誰かがあらゆる機会に魔法の DBMSがあると言ったら、彼にロリポップを買ってください。

「MyISAMは実際に関連しています...」

誰かが「家庭」（とにかくそれは何ですか？）CMSはMyISAMを使用すると言います。 システムテーブルはまだMyISAMにあると誰かが言います（これは5.7でも部分的に当てはまりますが、修正される見込みはありました）。 誰かがMyISAMをログなどの一時的/追加専用データのストレージとして使用します。



私は自分自身を繰り返すことができます。MyISAMは言葉の意味で本当にレガシーです。 制限は誰もが知っており、コードは開発されておらず、ほとんどサポートされていません。完全に置き換えられています。 他の誰かがその使用をどこかで見つけた場合、それは問題ありませんが、InnoDBを調べることをお勧めします。 特に5.7では、MyISAMと比較したパフォーマンスが優先事項の1つでした。 MyISAM 薬にノーと言うだけで、そのすべての問題はいくつかのささやかなパフォーマンスボーナスの価値はありません。

「しかし、MySQLがどこにも行かないことを証明するようなレポートと記事があります」

わかった、ありがとう。 レプリケーションの一般的なレビューと、特にレポート/記事は、この出版物の代わりに出版されるべきでしたが、私は思っているよりも時間がありません。 すべてが約束どおりになります。



そして、コメントに追加されたいくつかの新しい神話。

「MySQLはプロプライエタリです！」

これは、MySQLについての神話を発明したり広めたりしたことのない同じ人によって言われました。 MySQLは無料ライセンスの下で無料のプロジェクトです。 そしてスピーチはMySQL Enterpriseに関するもののようです。 MySQL Enterprise製品とEnterpriseDB製品はほぼ直接一致しています。 しかし、これからPostgreSQLを「独自」と呼ぶ人はいません。



更新された11.16.2015：いくつかの永続的なリクエストについて、コメントに次のテキストを追加します。

はい、MySQLが配布されるGPLライセンスでは、所有権を含むライセンスの変更は許可されていません。 したがって、閉じたフォークはありません。 オラクルは、著作権の所有者として、その裁量でライセンスを変更できます。



PostgreSQLが配布されるBSDライセンスでは、ライセンスの変更が許可されています。 したがって、多くの独自のフォーク。

2016年12月11日更新： 1年前のコメントで予測したように、Postgres Proは独自のfork を静かに静かに リリースしました 。 「専有の」MySQLについての話は、どういうわけか自分たちで無駄になりました。

「MySQLは必要ありません。<インターネットからのばかげた例>」

通常、 この記事へのリンクがあります。これは、おそらく、前の記事に読んだすべてのコメントの中で最も深刻な追加です。 私の意見では、この記事自体は、「MySQLはどこにも行かない」、「MySQLは必要ない」、「明らかにDBMSに欠陥がある」などの「福音的」結論のない有能なMySQL批判の例です。 人は奇妙なまたは直感に反する行動の例をリストします。 それらの半分は、1つの単純な事実に基づいています。MySQLには、演算子だけでなく関数にも適用される暗黙の型変換があります。 上記の記事のLEAST（）を含むすべての例は、この単一の事実を利用しています。 これには、SELECT 0 = 'Sean'を使用した一般的な例も含まれます。



厳密なタイピングを頻繁に扱う人にとっては奇妙に見えるかもしれませんが（例えば、私にとっては奇妙に見えます）、JavaScript、PHP、Perl、およびWebの世界の他の言語のプログラマーにとってはまったく自然です。 これらの言語について多くの同様の例を挙げることができますが、これは特に誰も驚くことではありません。



上記の記事の他の例：



-ENUMの例：はい、奇妙ですが、 文書化されていますが、動作。 しかし、一般的に、ENUMを使用しないはるかに深刻な理由があり、これはあらゆるDBMSに適用されます。



-UNIONとINNER JOINの例-はい、パーサーには多くの問題があり、異論はありません。 私は長年MySQLのパーサーを書き直す計画について聞いたことがあり、作業がついに始まりました 。これは朗報です。



- バグ＃27877の例：ドイツ語のソート規則に関する悪名高いニュアンスと、互換性とアップグレードの問題の束。 しかし、この問題の解決策は主にMySQLとして3年前から存在していましたが、MariaDBとPercona Serverではさらに早期に解決策が現れました。



更新された2016年3月24日：これは、PostgreSQLのそれほど深刻ではないエンコードの問題の最近の例です 。



要約すると、私はそのようなことから、彼らがそれらから引き出す典型的な結論の機会を見ていません。 他のDBMSにそのようなものがないと誰かが信じている場合、 悪いニュースがあります。 ここではPostgreSQLのコンテキストで話をしているので、「postgresql gotchas」というキーワードで検索できます。面白いことがあります。



このすべてを要約し、正しく定式化しようとするなら、私はそう言うでしょう。 MySQLでは、SQL標準への準拠が優先事項ではなく、全体的な準拠は、標準への準拠が最優先事項の1つであるPostgreSQLを含む他の多くのDBMSよりも低くなっています。 しかし、MySQLはこれを好みません 。 これについては後で詳しく説明します。



2015年11月22日更新：一般的なルールには例外があります。 MySQLがPostgreSQLよりも標準をサポートしている場合。 トピックに関する記事 。

おわりに

MySQLユーザーの観点から、MySQLとPostgreSQLとのレプリケーションおよび比較に関する別の出版物を執筆する予定です。 しかし、その前に、PostgreSQLコミュニティからのMySQL批判のトピックを閉じたいと思います。 このような出版物は、「コミュニティがなく、静かにゼロで割る！」というスタイルのコメントが急増することが予想されるため、これは重要です。 何回も答えないために、すべての答えを1か所に集める方が便利です。 コメントをくださった皆さんに感謝します。何も見逃していないことを願っています。