MySQL に必ず伝えるべき 8 つの落とし穴

Mysql はインストールが簡単で、高速で、機能が豊富です。さらに、これはオープンソース運動のベンチマークでもあり、その偉大な成果は、成功する企業がオープンソース コードに基づいて構築できることを示しています。

しかし、MySQL を使用したことのある人は皆、モニターに向かって拳を振りました。しかし、毎秒数千行のインターネット データをエラーなく保存できるテクノロジーを発明することはできません。

この夏を盛り上げるために、オープンソースのリレーショナル データベースについて不満を言う 8 つの理由をリストします。以下に挙げる理由は MySQL に限定されるものではなく、リレーショナル データベースに特有のものもあります。リレーショナル データベースと MySQL を理解しなければ、私たちは常に 1990 年代の考え方に囚われることになります。これらを取り壊してから再構築する必要があります。あるいは、以下のようなさまざまな理由を正当化できるほど長く存在していない、最近人気のあるデータベースに目を向けます。

根深いバグ

どんな大きなソフトウェアパッケージにもバグは存在します。しかし、もう少し詳しく調べてみると、Mysql に関連するバグは自己完結型であることがわかります。 NULL は同じように表示されず、外部キー制約は思ったように機能せず、主キーの自動インクリメントさえも失敗するため、突然注意する必要があります。

小さな問題はたくさんあり、常に解決できるわけではないため、リストを作成している人もいます。幸いなことに、MySQL は非常に優れたバグ報告システムを維持しているので、私たちは想像できないことを知ることができ、他の人が同じ試練を経験していることを知ることができます。

リレーショナル テーブルの柔軟性の低さ

リレーショナル テーブルは整理されており、整理は良好ですが、プログラマは、一部のデータをすでに定義されたパターンで列に作成したり、詰め込んだりする必要があります。 NoSQL の人気が高まっている理由の 1 つは、NoSQL がプログラマにデータベースの使用を高速化するための十分な柔軟性を提供することです。住所に追加の行が必要な場合は、それを NoSQL ドキュメントに簡単に挿入できます。完全な新しいデータ ブロックを追加する場合、その内容に関係なく、ドキュメント モデルは、必要なデータ形式に変更することなく、データを変更せずに受け入れることもできます。

すべての郵便番号を整数形式で含むテーブルを作成すると想像してください。このテーブルは非常に効率的で、適用するルールも非常に優れています。突然、誰かがハイフンを使用した 9 桁の郵便番号をアップロードしました。あるいは、カナダの顧客から郵便番号が記載された手紙を受け取るかもしれません。

この時、すべてが混乱していました。上司は、ウェブサイトを数時間以内に復旧して稼働させるように要求しています。ただし、データベースを再構築する時間がありません。プログラマーは何ができるのでしょうか?おそらく、ハッカーを利用してカナダの郵便番号を Base64 デジタル形式から Base10 形式に変更できるのではないでしょうか?それとも、エスケープ コードを使用して実際の郵便番号などを示す補助テーブルを設定しますか?知るか？ハッカーはどこにでも存在しており、危険です。しかし、それを理解する時間はありません。

MySQL のアソシエーション ルールにより、誰もが正直かつ慎重になりますが、脆弱で欺瞞的になるという問題を回避する必要があります。

結合ユニオンクエリ

かつて、データを別々のテーブルに保存することは、コンピューターサイエンスの歴史において大きな革新でした。セパレートテーブルは構造がシンプルなだけでなく、使い方も簡単です。ただし、クエリに join ステートメントを使用する必要があります。

SQL は、一連の結合によって構築された複雑なクエリを通じて、開発者を混乱と絶望の深淵に突き落とします。さらに、ストレージ エンジンは、結合ステートメントを最適な方法で効率的に解析する必要もあります。開発者は知恵を絞ってクエリ ステートメントを作成し、データベースがクエリ ステートメントを解析する必要があります。

これが、実行速度を重視する多くの開発者がデータサブテーブルを放棄し、代わりに非標準のデータテーブルを使用する理由です。複雑なクエリを避けるために、データ エンティティを区別せず、すべてのデータを 1 つの大きなテーブルに保存します。これは非常に高速であり、サーバーのメモリが不足することはありません。

最近のディスク容量は安価です。 8TB ディスクはすでに販売されており、さらに大きなディスクも間もなく登場します。結合を使用するために頭を悩ませる必要はもうありません。

ブランチの混乱

はい、確かで十分にサポートされている MySQL フォークは競争と選択肢をもたらす可能性がありますが、混乱と混乱を引き起こす可能性もあります。さらに悪いことに、Monty Widenius によって保守されている MariaDB と呼ばれる MySQL のフォークがあります。彼は MySQL の作成にも携わっています。では、MariaDB は本当に独立しており、サポートに値するのでしょうか?それともMySQLでしょうか？元の MySQL データベースを作成した組織が運用しているコア コードを使い続ける必要があるでしょうか?それとも、賢いと思われているクールな脱北者たちに加わるべきでしょうか？

また、互換性に関する情報はどのように入手すればよいですか?一方で、私たちは MariaDB と MySQL が非常に似ていると確信しています。一方、私たちは違いがあると信じなければなりません。そうでない場合、なぜ誰もがそれについて議論するのでしょうか?おそらく、パフォーマンスとクエリの範囲の点で、どちらの陣営でも同じように機能するのでしょうか?しかし、おそらくそれらは異なるものであるか、将来的には異なるものとなるでしょう。

ストレージ エンジンの混乱

MySQL は事実上同じデータベースではなく、複数のデータベースで構成されており、それらの詳細のほとんどは均一な表面によって隠されています。当初は MyISAM エンジンがありましたが、高速ではありましたが、一貫性の点で完全ではありませんでした。スピードが必要で、一貫性のない結果を受け入れることができる場合には、それが良い場合もあります。

人々がさらに多くを必要としたとき、完全なトランザクション サポートを備えた InnoDB が登場しました。しかし、これでは十分ではありません。現在、ストレージ エンジンの選択肢は 20 種類もあり、データベース管理者を夢中にさせるには十分です。もちろん、SQL を書き直すことなく、異なるストレージ エンジン間で切り替えることが望ましい場合もありますが、切り替え後は常に混乱が生じます。このテーブルのエンジンとして MyISAM または innoDB を選択する必要がありますか?それとも出力するデータはCSV形式になるのでしょうか？

利益動機

MySQL はオープンソース製品として成功していますが、それでも、それによって報酬を得ているプロの開発者がたくさんいるビジネスです。ほとんどのユーザーはオープンソース ライセンスによってもたらされる最高のエクスペリエンスを引き続き楽しんでいますが、この会社が運営を維持するのに十分な収益を得るのに依然として苦労していることは間違いありません。これにより、「コミュニティ エディション」と企業に販売される完全な製品との間で、無料コードの奇妙な分岐が生じます。

支払うべきですか？ここでいくら稼いでいますか？コミュニティ バージョンで運用するのは公平ですか?エンタープライズ版の追加機能は、私たちをより多くの料金を支払わせるための単なる仕掛けなのでしょうか?これは少なくとも、これが別の一連の質問に答える必要があることを示しています。どのバージョンを選択しますか?どのライセンスに基づいて?どの機能セットを使用すればよいですか?

ネイティブ JSON サポートの欠如

MySQL の時代を振り返ると、最善の方法はそれをインストールすることですが、その後、それを使用できるようにするためにさらにドライバーを追加する必要があることがわかります。 MySQL は通常、ポート 3306 で通信し、理解できない形式のデータを出力します。コードで MySQL と通信できるようにするには、MySQL の言語を有用なものに変換する別のコード層を追加する必要があります。これらのレイヤーのコードはライブラリとして配布されており、多くの場合、商用ライセンスの購入が必要になります。

最新のデータ ストレージ レイヤーは、多くの場合、JSON で直接通信します。 MySQL と MariaDB は SQL の JSON 部分を解析できるようになりましたが、これは十分とは言えず、ネイティブ JSON インターフェイスはすでに CouchDB、MongoDB、または最新のツールで広く使用されています。

クローズド ソースと独自モジュールの台頭

MySQL はオープン ソースであると言いましたか?これは、一部の新しいものを除いて、非オープン ソース コードおよび「オープン ソース コア」を中心に開発された独自のモジュールです。プログラマーは食べる必要があり、オラクルはその努力の成果をお金と交換する必要があります。これがビジネスの現実の 1 つです。 MySQL を使用して無料の医療を受けられる病院とは異なります。 MySQL を使用して食料を配っている農家とは異なります。

オープンソースの成功は罠になる可能性があるため、MySQL に常に非常に高い水準を維持するよう要求するのは少し不公平です。それは、最初から無料である可能性があるというだけで、常に無料であるという意味ではありません。企業が多くの新機能を必要とする場合、何らかの形で料金を支払わなければなりません。自分でコードを書くよりも、Oracle に支払う方が安い場合があります。場合によっては、商用の非オープンソース コードが意味をなすことがあります。事実がすべてを物語っています。

上記は、言及する必要がある 8 つの MySQL トラップです。さらに関連するコンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。