言及すべき8つのMySQLの落とし穴を共有する

MySQL はインストールが簡単で、高速で、豊富な機能を備えています。これはオープンソース運動のベンチマークでもあり、その偉大な業績は、成功する企業がオープンソースコードの上に築かれることを示しています。

しかし、MySQL を使用したことがある人なら誰でも、モニターに向かって拳を振り上げたことがあるでしょう。しかし、1秒間に何千行ものインターネットデータをエラーなく保存できる技術を発明することはできません。

この夏を楽しく過ごすために、オープンソースのリレーショナル データベースについて不満を言うべき 8 つの理由をまとめました。以下に挙げる理由は MySQL に限定されるものではなく、リレーショナル データベースに特有の理由もあります。リレーショナル データベースと MySQL を理解しなければ、私たちは永遠に 90 年代に留まってしまうでしょう。これらを破壊して再構築する必要があります。あるいは、次のような理由を挙げるには十分な期間が経っていない、最近人気のデータベースに目を向けることもあります。

1. 根深いバグ

大規模なソフトウェア パッケージには必ずバグがあります。しかし、もう少し深く掘り下げてみると、MySQL 関連のバグは独自の世界であることがわかります。突然、NULL が同じように表示されず、外部キー制約が期待どおりに動作せず、主キーの自動増分も同じように動作しないため、注意が必要になります。

小さな問題はたくさんあり、必ずしも解決できるとは限りません。そのため、リストを作成している人もいます。幸いなことに、MySQL は非常に優れたバグ報告システムを維持しており、これによって、私たちが想像もできない事柄を知ることができ、他の人も同じ苦難を経験していることを知ることができます。

2. リレーショナルテーブルの柔軟性のなさ

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

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

この時点で、すべてが混乱状態に陥っていました。上司は、ウェブサイトが数時間以内に通常の動作に戻ることを要求しました。しかし、データベースを再構築する時間がありません。プログラマーは何ができるのでしょうか?おそらく、ハックを使用してカナダの郵便番号を base64 数値形式から base 10 形式に変更することは可能ですか?または、実際の郵便番号などを考慮してエスケープ エンコーディングを使用するセカンダリ テーブルを設定しますか?知るか？ハッカーはどこにでもいて、彼らは危険です。しかし、それを理解する時間はありません。

MySQL の関連ルールにより、誰もが誠実かつ慎重に行動できるようになりますが、攻撃や欺瞞に対して脆弱になるというトラブルを回避するよう強制されることもあります。

3. JOIN ジョイントクエリ

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

一連の結合を通じて SQL によって構築される複雑なクエリは、開発者を混乱と絶望の深淵に追いやります。また、ストレージ エンジンは、結合ステートメントを最適な方法で効率的に解析する必要もあります。開発者は頭を悩ませてクエリ ステートメントを記述する必要があり、その後データベースがそれを解析します。

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

最近はディスク容量が安くなりました。 8TB ディスクはすでに販売されており、さらに大きなサイズのディスクも近々発売される予定です。 join を使用するために頭を悩ます必要はもうありません。

4. 分岐の混乱

確かに、MySQL の堅牢で十分にサポートされているフォークは競争と選択肢をもたらしますが、混乱や混沌を引き起こす可能性もあります。さらに悪いことに、Monty Widenius によって管理されている MariaDB と呼ばれる MySQL のフォークがあります。彼は MySQL の作成にも協力しました。では、MariaDB は本当に独立しており、サポートする価値があるのでしょうか?それともMySQLでしょうか?オリジナルの MySQL データベースを作成した組織が運用するコアコードに固執すべきでしょうか?それとも、より賢く、よりクールな裏切り者たちの仲間に加わるべきでしょうか?

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

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

MySQL は実際には単一のデータベースではなく、統一された表面によって詳細の大部分が隠されている複数のデータベースで構成されています。当初は MyISAM エンジンがありましたが、これは高速ではありましたが完全に一貫性があるわけではありませんでした。スピードが必要で、一貫性のない結果を受け入れられる場合には、これが良いこともあります。

より多くの機能が必要になったとき、完全なトランザクション サポートを備えた InnoDB が登場しました。しかし、それだけでは十分ではありません。現在、ストレージ エンジンの選択肢はおそらく 20 種類あり、データベース管理者を困惑させるほどです。確かに、SQL を書き直さずにストレージ エンジンを切り替えることができると便利な場合もありますが、切り替えによって必ず混乱が生じます。このテーブルのエンジンとして MyISAM と innoDB のどちらを選択すべきでしょうか?それとも、データをCSV形式で出力することにしますか?

6. 利益追求の動機

MySQL は成功したオープンソース製品ですが、依然として、それを使って報酬を得るプロの開発者で溢れたビジネスです。ほとんどのユーザーはオープンソース ライセンスによる最高の体験を楽しみ続けていますが、同社が経営を維持するのに十分な収益を上げるのに依然として苦労していることは間違いありません。これにより、無料コードが「コミュニティ エディション」と企業に販売される完全な製品に奇妙に分かれるようになりました。
支払うべきでしょうか?ここでいくら稼いだんですか？コミュニティバージョン上で操作するのは公平ですか? Enterprise Edition の追加機能は、より多くの料金を支払わせるための単なる仕掛けなのでしょうか?これは少なくとも、答える必要のある別の一連の質問であることを示しています。どのバージョンを選択すればよいですか?どのライセンスですか?どの機能セットを選択すればよいですか?

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

MySQL の古さを知る最良の方法は、それをインストールしてみて、それを使用可能にするためにさらにドライバーを追加する必要があることに気づくことです。 MySQL は通常ポート 3306 で通信し、通常は MySQL 自身が理解できない形式でデータを出力します。コードで通信したい場合は、MySQL の言語を有用なものに変換するための別のコード レイヤーを追加する必要があります。これらのレイヤーのコードはライブラリとして配布されるため、商用ライセンスの購入が必要になることがよくあります。

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

8. クローズドソースとプロプライエタリモジュールの台頭

MySQL はオープンソースだと言いましたか?いくつかの新しい非オープンソース コードを除き、これは「オープンソース コア」を中心に開発された独自のモジュールです。プログラマーは食べる必要があり、Oracle は懸命な努力から利益を得る必要があります。これがビジネスの現実の 1 つです。 MySQL を使用して医療が無料で提供される病院とは異なります。農家が MySQL を使って食料を配布しているわけではありません。

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

要約する

上記は私が皆さんに共有する 8 つの MySQL トラップです。皆さんのお役に立てれば幸いです。ご質問がある場合は、メッセージを残してください。すぐに返信いたします。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。