Peter Zaitsevは、MySQLとMongoDBの違いを示しています。 これは、 Highload ++ 2016を使用したレポートのトランスクリプトです 。



このようなよく知られているDB-Enginesランキングを見ると、長年にわたって、オープンソースデータベースの人気が高まっており、商業的であることが徐々に低下していることがわかります。







さらに興味深いのは、さまざまな種類のデータベースのこの関係を見ると、多くの種類（円柱状データベース、時系列、ドキュメントストーリーなど）でオープンソースデータベースが最も人気があることがわかります。 リレーショナルデータベースなどの古いテクノロジ、または多値データベースなどのさらに古いテクノロジの場合のみ、商用ライセンスがはるかに人気があります。







多くのアプリケーションは、その長所を活用するために複数のデータベースを使用していることがわかります。 あらゆる種類のユーザーケースに最適化されたデータベースはありません。 たとえそれがPostgreSQLであっても[ステージ上およびホールでの笑い声]。



一方で、これは良い選択です。他方では、バランスが取れているかどうかを確認する必要があります。さまざまな技術があればあるほど、特に会社がそれほど大きくない場合は、それらをサポートするのが難しくなります。



多くの場合、人々はそのような会議に参加し、FacebookやYandexを聞いて、「うわー！ 面白いことをしている人の数。 20種類のテクノロジーがあり、さらに10種類の技術を作成しました。」 そして、彼らは10人のスタートアップで同じアプローチを使おうとしますが、もちろんうまくいきません。 これはまさにサイズが重要な場合です。

アーキテクチャのアプローチ

多くの場合、メインの運用ストレージといくつかの追加サービスが使用されていることがわかります。 たとえば、キャッシュまたは全文検索用。



さまざまなデータベースを使用するアーキテクチャへの別のアプローチは、マイクロサービスです。各マイクロサービスには独自のデータベースがあり、この特定のサービスのタスクに最適化されています。 例として、メインストレージは、MySQL、Redis、Memcache（キャッシング、Elastic Search、またはネイティブSphinx）にあり、検索に使用できます。 また、Kafkaのようなもの-データを分析システムに転送します。これは、Hadoopのようなものでよく行われていました。



メインの運用ストレージについて話している場合、おそらく2つの選択肢があります。 一方では、SQL言語を使用してリレーショナルデータベースを選択できます。 一方、非リレーショナルなもので、この場合に利用可能な亜種を見てください。



NoSQLデータモデルについて話すと、多くのモデルもあります。 最も典型的なのは、キー値、ドキュメント、またはデータベースの幅の広い列です。 例：それぞれ、Memcache、MongoDB、Cassandra。



この場合、なぜMySQLとMongoDBを比較するのですか？ 実際、いくつかの理由があります。 ランキングデータベースを見ると、この評価によると、MySQLは最も人気のあるリレーショナルデータベースであり、MongoDBは最も人気のある非リレーショナルデータベースであることがわかります。 したがって、それらを比較することは合理的です。



また、これら2つのデータベースを使用した経験が最もあります。 Perconaの私たちは彼らと密接に連携し、多くのクライアントと協力し、この選択を支援します。 別の理由：両方のテクノロジーは当初、単純なアプリケーションの開発者を対象としていました。 PostgreSQLが複雑すぎる人々のために。



MongoDBは当初、MySQLユーザーに非常に焦点を合わせていました。 そのため、多くの場合、人々はこれらの2つのテクノロジーの使用経験と選択肢を持っています。



Perconaでは、これらの技術のサポートとコンサルティングに取り組んでいるという事実に加えて、両方の技術用に作成された非常に多くのオープンソースソフトウェアがあります。 スライドで見ることができます。 これについては詳しく説明しません。







個人的に私が従うこと：私はMySQLをMongoDBよりもはるかに扱います。 バランスのとれた概要を提供しようとしているという事実にもかかわらず、ゴキブリの方がよくわかっているので、MySQLの素質があるかもしれません。

MySQLとMongoDBの選択

私の意見では考慮に値するさまざまな問題のリストを以下に示します。 ここで、それぞれについてさらに詳しく検討します。



私の意見で最も重要なことは、チームの経験と好みを考慮に入れることです。 どちらのソリューションも多くのタスクに適しています。 両方を行うことができるため、少し複雑になり、少し簡単になります。 しかし、SQLデータベースを長い間使用しており、リレーショナル代数などを理解しているチームがある場合、完全なトランザクションすら存在しないMongoDBなどの非リレーショナルデータベースを使用するようにドラッグして強制することは困難です。



逆もまた同様です。MongoDBを使用し、よく知っているコマンドがある場合、SQL言語は複雑になる可能性があります。 また、元の開発とさらなるメンテナンスと管理の両方を検討することは理にかなっています。これはすべて、アプリケーションサイクルで最終的に重要であるためです。



これらのシステムの利点は何ですか？



MySQLについて話すと、これは実証済みのテクノロジーです。 MySQLは15年以上にわたって大企業で使用されてきたことが理解されています。 SQL標準を使用しているため、必要に応じて、他のSQLデータベースへのかなり単純な移行の可能性があります。 取引の可能性があります。 分析を含む複雑なクエリがサポートされています。 などなど。



MongoDBの観点から見ると、ここでの利点は、ドキュメント用の柔軟なJSON形式があることです。 一部のタスクと一部の開発者にとっては、SQLデータベースに列を追加して苦労するよりも便利です。 SQLを学ぶ必要はありません-一部の人にとっては難しいです。 単純なクエリが問題を引き起こす可能性は低くなります。 パフォーマンスの問題を見ると、大部分のテーブルとGROUP BY



でJOIN



して複雑なクエリを作成するときに主に発生します。 システムにそのような機能がない場合、複雑なクエリを作成することはより困難です。



MongoDBには、シャーディングテクノロジーを使用したかなり単純なスケーラビリティが組み込まれています。 複雑なクエリが発生した場合、通常はアプリケーション側で解決します。 つまり、 JOIN



などの操作が必要な場合は、データを選択し、リンクからデータを選択して、アプリケーション側で処理することができます。 SQL言語を知っている人にとっては、なんとなく悲惨で不自然に見えます。 しかし実際には、多くの人にとって、アプリケーションサーバーの開発はJOIN



理解するよりもはるかに簡単です。

開発アプローチとアプリケーションライフサイクル

MongoDBを使用するアプリケーションと、それらが何に焦点を当てているかについて話す場合、これは非常に高速な開発です。 すべてを常に変更できるため、ドキュメントの厳密な形式を常に気にする必要はありません。



2番目のポイントは、データスキーマです。 ここで、データには常にスキームがあることを理解する必要があります。唯一の問題は、データの実装場所です。 何らかの方法でこのデータを使用するため、アプリケーションにデータスキームを実装できます。 または、このスキームはデータベースレベルで実装されます。



非常に多くの場合、何らかのアプリケーションがある場合、このアプリケーションのみがデータベース内のデータを処理します。 たとえば、このアプリケーションからこのデータベースにデータを保存します。 アプリケーションレベルの回路はうまく機能します。 同じデータを多くのアプリケーションで使用している場合、これは非常に不便で制御が困難です。



また、これはアプリケーションの寿命の問題を提起します。 MongoDBを使用すると、ライフサイクルが非常に制限されたアプリケーションを作成できます。 つまり、長生きしないアプリケーション、たとえば映画やオリンピアードを起動するサイトを作成する場合です。 私たちはその数ヶ月後に生きましたが、このアプリケーションは実際には使用されていません。 アプリケーションの寿命が長い場合は、別の質問があります。



アプリケーション開発サイクルの観点から、MySQLとMongoDBの長所と短所の分布について話すと、次のように表すことができます。







データモデルは、アプリケーションとチームの経験に大きく依存します。 データベースに対するリレーショナルまたは非リレーショナルのアプローチが常により優れていると言うのは奇妙です。



それらを互いに比較すると、我々が持っていることは明らかです。 MySQLでは、リレーショナルデータベース。 リレーショナルデータベースを使用すると、テーブル間の関係を簡単にマップできます。 データを正規化することで、データの変更を1か所で原子的に強制的に発生させることができます。 データが非正規化されている場合、いくつかの変更を加えて多数のドキュメントを実行および変更する必要はありません。



それは良いですか悪いですか？ 結果は常に表です。 一方で、それは単純であり、一方で、一部のデータ構造は常にテーブルにうまく収まらないため、これで作業するのは不便かもしれません。



これはすべて理論上です。 MySQLの実際の使用について言えば、データを非正規化することがよくあります。アプリケーションによっては、JSON、XML、または別の構造をアプリケーションの列に格納するアプリケーションもあります。



MongoDBにはドキュメントベースのデータ構造があります。 多くのWebアプリケーションのデータは非常に簡単に表示できます。 なぜなら、アプリケーションの関連付けられた配列のような構造を保存すると、開発者がJSONドキュメントにシリアル化するのは非常に簡単で理解しやすいからです。 さまざまなタブレット上のリレーショナルデータベースでこれを拡張することは、より重要な作業です。



完全に異なる構造を持つことができるドキュメントのリストとしての結果-より柔軟なソリューション。



例。 電話から連絡先リストを保存します。 1つのリレーショナルタブレットに適切に適合するデータがあることは明らかです。姓、名など。 しかし、電話やメールアドレスを見ると、1人で複数の人がいる場合があります。 これが適切なリレーショナル形式で保存されている場合は、別々のテーブルに保存するのが良いでしょうJOIN



を収集するだけで、階層ドキュメントが置かれている1つのコレクションにすべてを保存するよりも不便です。







これはすべて厳密なリレーショナル理論に基づいていると言えます-一部のデータベースは配列をサポートしています。 MySQLはJSON形式をサポートしています。JSON形式では、複数のメールアドレスなどを詰めることができます。 または、長年にわたって人々はこれをペンでシリアル化していました。複数の電子メールアドレスを保存し、それらをコンマで区切って書き込む必要があります。アプリケーションはそれを理解します。 しかし、どういうわけかそれはあまりコーシャではありません。

規約

興味深いことに、MySQLとMongoDBの間-一般に、リレーショナルDBMSと非リレーショナルDBMSの間-何かが同じで、何かが異なります。 たとえば、どちらの場合もデータベースについて話しますが、リレーショナルデータベースのテーブルと呼ばれるものは、非リレーショナルデータベースのコレクションと呼ばれることがよくあります。 MySQLの場合は列、MongoDBの場合はフィールドです。 などなど。



JOIN



を使用するという観点から見ると、MongoDBにはそのような概念はありません。これは一般に関係構造からの概念です。 そこで、非正規化の概念に近い埋め込みドキュメントを作成するか、単にフィールドにドキュメント識別子を保存してリンクと呼び、ペンで必要なデータを選択します。



アクセスに関して：リレーショナルデータにSQL言語を使用する場合、MongoDBおよび他の多くのNoSQLデータベースはCRUDなどの標準を使用します。 この規格では、ドキュメントを作成、読み取り、削除、更新するための操作があると述べています。



いくつかの例。



MySQLおよびMongoDBでドキュメントを操作するための最も一般的なタスクは、次のようになります。







挿入の例を次に示します。







更新例。







アンインストールの例。



JavaScript言語に精通している開発者であれば、CRUD（MongoDB）が提供する構文はSQL構文よりも自然です。



私の意見では、最も単純な操作、つまり検索、挿入がある場合、それらはすべて非常にうまく機能します。 私の意見では、より興味深いフェッチ操作に関しては、SQL言語の方がはるかに読みやすくなっています。







単純な「>」記号の代わりに&gt



。 私の意見では、あまり読めません。







インターフェイスを使用すると、テーブルやコレクションの行数をカウントするなどの操作を簡単に実行できます。







ただし、MongoDBでGROUP BY



などのより複雑なことを行う場合、Aggregation Frameworkを使用する必要があります。 これは、フィルタリングの方法、グループ化の方法などを示す、もう少し複雑なインターフェースです。 Aggregation FrameworkはすでにJOIN



操作のようなものをサポートしています。



次のポイントは、トランザクションと一貫性（ACID）です。 MongoDBのドキュメントを読むと、「ACIDトランザクションをサポートしていますが、制限があります。」と表示されます。 私の意見では、「ACIDはサポートしていませんが、他の最小限の非トランザクション保証をサポートしています。」と言う価値があります。



それらの違いは何ですか？



MySQLといえば、任意のサイズのACIDトランザクションをサポートします。 これらのトランザクションのアトミック性、マルチバージョン管理、トランザクションの分離レベルを選択できます。トランザクションの分離レベルは、 READ UNCOMMITED



始まりSERIALIZABLE



で終わることができます。 ホストおよびレプリケーションレベルで、データの保存方法を構成できます。



InnoDBを使用して、ログファイルの操作方法を構成できます。トランザクションをコミットするときにディスクに保存するか、定期的に実行します。 データのコピーがスレーブの1つで受信された場合にのみデータが保存されていると見なされる場合は、たとえば半同期レプリケーションを有効にしてレプリケーションを構成できます。



MongoDBはトランザクションをサポートしていませんが、ドキュメントのアトミック操作をサポートしています。 これは、1つのドキュメントの観点からは、操作がアトミックであることを意味します。 操作によって複数のドキュメントが変更され、この操作中に何らかの不具合が内部で発生した場合、これらのドキュメントの一部は変更でき、一部は変更できません。



一貫性はドキュメントレベルでも実行されます。 クラスターでは、柔軟な一貫性を選択できます。 必要な保証を示すことができます-データが1つのノードにのみ書き込まれたこと、またはクラスターのすべてのノードに複製されたことを保証します。 一貫性の読み取りは、ドキュメントレベルでも行われます。



他のトランザクションから分離して更新を実行できる分離更新オプションがありますが、非常に非効率的です-データベースを排他アクセスモードに切り替えるため、ほとんど使用されません。 私の意見では、トランザクションと一貫性について話すと、MongoDBは十分に貧弱です。

性能

さまざまなデータベーススキーマとアプリケーション設計を作成することが多いため、パフォーマンスを直接比較することは非常に困難です。 しかし、一般的に、MongoDBは元々、シャーディングを介して多くのノードにうまく拡張できるように作られていたため、効率についてはあまり注意が払われませんでした。







これらは、Mark Callaghanが行ったベンチマークの結果です。 ここで、プロセッサの使用率に関して、MySQL I / O（InnoDBとMyRocksの両方）がFacebookのLinkbenchベンチマーク操作で使用するCPUとディスクI / Oが大幅に少ないことがわかります。



スケーラビリティ。



このコンテキストでのスケーラビリティとは何ですか？ 小規模なアプリケーションを数百万、場合によっては数十億のユーザーに簡単に拡張できます。



スケーラビリティは異なります。 単一のマシンのフレームワーク内では、中規模のアプリケーションをサポートしたい場合は平均的であり、アプリケーションがすでに非常に大きい場合は、最も強力なマシンの1つでも対応できないことが明らかな場合はクラスター上のスケーラビリティです。



また、データの読み取り、書き込み、またはボリュームをスケーリングするかどうかについて話すことも理にかなっています。 異なるアプリケーションでは、それらの優先順位は異なる場合がありますが、一般に、アプリケーションが非常に大きい場合、それらは通常これらすべてのことを処理する必要があります。



MySQLでは、新しいバージョンはLTPロードの単一ノード内で非常に優れたスケーラビリティを備えています。 小さなトランザクションがある場合、64個のプロセッサがあるハードウェアがいくつかあり、非常にうまくスケーリングします。 MySQLはクエリごとに1つのスレッドしか使用できないため、分析や複雑なクエリは適切に拡張できませんが、これは悪いことです。



従来、MySQLでの読み取りは、複製、書き込み、シャーディングによるデータサイズに合わせて調整されます。 すべての大企業（Facebook、Twitter）を見ると、それらはすべてシャーディングを使用しています。 従来、MySQLのシャーディングは手動で使用されていました。 これにはいくつかのフレームワークがあります。 たとえば、VitessはGoogleがYouTubeサービスのスケーリングに使用するフレームワークであり、オープンソースでリリースしました。 その前に、Jetpantsフレームワークがありました。 MySQLはシャーディングの標準ソリューションを提供していません。シャーディングに切り替えるには、開発者の注意が必要になることがよくあります。



MongoDBでは、当初は多くのノードのスケーラビリティに重点が置かれていました。 小規模なアプリケーションの場合でも、最初からシャーディングを使用することをお勧めします。 たぶん、ほんの2、3のレプリカセットだけで、アプリケーションとともに成長します。



MongoDBのシャーディングにはいくつかの制限があります。すべてのオペレーターがこれを使用するわけではありません。たとえば、一貫性を確保するための独立したオプションがあります。 シャーディングを使用する場合は機能しません。 しかし同時に、多くの基本的な操作はシャーディングでうまく機能するため、人々はアプリケーションをより良くスケーリングすることができます。 私の意見では、MongoDBでの一般的なシャーディングとレプリケーションは、ユーザーにとって使いやすいMySQLよりもはるかに優れています。

運営

管理は、開発者が考えていないすべてのものです。 少なくともそもそも。 管理とは、アプリケーションのバックアップ、バージョンの更新、監視、障害からの回復などを行う必要があるということです。



MySQLには十分な柔軟性があり、さまざまなアプローチがあります。 すべての優れたオープンソース実装がありますが、このオプションのセットは複雑さを引き起こします。 私は、MySQLを習い始めたばかりのユーザーと頻繁にコミュニケーションを取ります。 彼らは言う：「クリスマスツリー、スティック、いくつのオプションがありますか？ それは単なるレプリケーションです-ステートメントレプリケーション、ローレプリケーション、またはミックスのどれを使用する必要がありますか？ また、gtidと標準のレプリケーションがあります。 「仕事」と言えないのはなぜですか？」



MongoDBは、1つの標準的な方法で機能するという事実にますます焦点を当てています-管理の最小化があります。 しかし、これは柔軟性の損失で起こることは明らかです。 MongoDBのオープンソースソリューションのコミュニティははるかに小さくなっています。 推奨の観点から見たMongoDBの多くの要素は、MongoDBの商用開発で​​あるOps Managerと非常に厳密に結びついています。

神話

MongoDBとMySQLの両方には、過去に修正された神話がありますが、特に何かがうまくいかない場合、人々は良い記憶を持っています。 InnoDBとのトランザクションが登場した後、MySQLで覚えていると、人々は私に10歳について言った：「しかしMySQLにはトランザクションはありませんか？」



MongoDBには、MMAPストレージエンジンに関するさまざまなパフォーマンスの問題がありました。巨大なロック、ディスクスペースの非効率的な使用です。 現在、標準のWiredTigerエンジンにはこれらの問題の多くがありません。 他にも問題はありますが、これらはありません。



「回路の制御はありません」という別の神話があります。 MongoDBの新しいバージョンでは、データが検証されるコレクションごとにJSON構造を定義できます。 挿入しようとしているデータは、どのフォーマットにも対応していないため、破棄することができます。



「 JOIN



の類似物はありません」-同じこと。 MongoDBでは、これが登場しましたが、いくつかの制限があります。 1つのシャードのレベルでのみ、集約フレームワークを使用する場合にのみ、標準クエリでは使用しません。



MySQLにはどのような神話がありますか？ ここでは、MySQLでのNoMySQLソリューションのサポートについて詳しく説明します。これについては明日お話します。 MySQLは、CRUDインターフェイスを介して使用できるようになりました。CRUDインターフェイスは、MongoDBとほぼ同じようにNoSQLモードで使用されます。



MySQLソリューションが使用される典型的な例は、eコマースサイトです。 お金について質問がある場合、多くの場合、完全なトランザクションと一貫性が必要です。 そのようなことについては、解決されたリレーショナル構造が適切であり、リレーショナルデータベースの商取引は何十年も行われてきました。 したがって、データ構造に対して既製のアプローチのいずれかを使用して使用できます。



通常、eコマースの観点から見ると、保有するデータの量はそれほど多くないため、かなり大きな店舗でも、シャーディングすることなく長時間動作できます。 当社のアプリケーションは、長年にわたって常に開発および改善されています。 そして、このアプリケーションには、同じデータを扱う多くのコンポーネントがあります。誰かが価格を変更する場所を計算し、他の誰かが何かをします。



MongoDBは、大規模なオンラインゲームのバックエンドとしてよく使用されます。 Electronic Artsは、非常に多くのゲームにMongoDBを使用しています。 なんで？ スケーラビリティが重要だからです。 ゲームがうまくシュートする場合、予想よりも大幅に拡大する必要があります。



一方、それが発生しない場合は、インフラストラクチャを削減したいと考えています。 多くのゲームでは、次のようになります。ゲームを起動しましたが、何らかのピークがあり、大きなクラスターを作成する必要があります。 その後、ゲームはすでに人気がなくなっています。その理由は、バックエンドを圧縮、保存、使用する必要があるためです。 この場合、1つのアプリケーション（ゲーム）があり、データベースは複雑ではなく、ゲームに重要なすべてのパラメーターを格納するアプリケーションに強く結び付けられています。



多くの場合、オブジェクトレベルでのデータベースの一貫性は十分です。これは、一貫性の問題の多くがアプリケーションレベルで対処されるためです。 たとえば、1つのアプリケーションサービスのみが1人のプレーヤーのデータを保存します。

追加情報

http://www.mongodb-is-web-scale.com/ [ YouTube ]に、この古くて古くて非常に面白いビデオをお勧めします 。 これで終わります。







MySQLとMongoDB-どちらを使用するのが適切ですか？