mysqlと比較したmongodbの長所と短所

リレーショナルデータベースと比較したMongoDBの利点:

① 弱い整合性(結果整合性)、ユーザーのアクセス速度をより確実に確保できる:

たとえば、従来のリレーショナル データベースでは、カウント タイプの操作によりデータ セットがロックされ、現在の状況の正確な値を確実に取得できます。これは、ATM を通じて口座情報を確認する場合など、場合によっては重要ですが、Wordnik の場合、データは常に更新され、増加するため、この「正確な」保証はほとんど意味がありませんが、遅延に大きな影響を与えます。彼らが必要としているのは、「おおよその」数値とより高速な処理です。

ただし、場合によっては、MongoDB がデータベースをロックすることがあります。現時点で何百ものリクエストがある場合、それらが積み重なり、多くの問題が発生する可能性があります。ロックインを回避するために次の最適化を使用します:

各更新の前に、まずレコードをクエリします。クエリ操作はオブジェクトをメモリに配置するため、更新をできるだけ高速に行うことができます。マスター/スレーブ展開シナリオでは、「-pretouch」パラメーターを使用してスレーブ ノードを実行でき、同じ効果が得られます。

複数の mongod プロセスを使用します。アクセスパターンに基づいてデータベースを複数のプロセスに分割します。

②文書構造の保存方法によりデータの取得が容易になります。

階層データ構造の場合、フラットなテーブルのような構造を使用してデータを保存したい場合、データのクエリや取得が非常に困難になります。

例 1: 「辞書項目」を例に挙げると、それほど複雑ではありませんが、「定義」、「品詞」、「発音」、「引用」などの内容が含まれます。ほとんどのエンジニアは、リレーショナル データベースの主キーと外部キーを使用してこのモデルを表現しますが、これを「一連の関連テーブル」ではなく「ドキュメント」と考えた方がよいのではないでしょうか? "dictionary.defining.partOfSpeech='noun'" を使用してクエリを実行すると、テーブル間の一連の複雑な (そして多くの場合コストがかかる) 結合クエリよりも便利で高速になります。

例 2:

リレーショナル データベースでは、ブログ (記事のコンテンツ、コメント、コメントへの投票を含む) が複数のデータ テーブルに分散されます。 MongoDB では、ドキュメントを使用してブログを表すことができ、コメントと投票がドキュメント配列としてメイン テキスト ドキュメントに配置されます。これにより、データの管理が容易になり、従来のリレーショナル データベースのパフォーマンスと水平方向のスケーラビリティに影響を与える「JOIN」操作が不要になります。

コード↓

> db.blogposts.save({ title : "私の最初の投稿", author: {name : "Jane", id :1}, コメント : [{ by: "安倍", text: "ファースト" },
{ 投稿者: "エイダ"、テキスト: "良い投稿" }]
})

> db.blogposts.find( { "author.name" : "ジェーン" } )

> db.blogposts.findOne({ title : "私の最初の投稿", "著者。名前": "ジェーン"、 コメント : [{ by: "安倍", text: "ファースト" },
{ 投稿者: "エイダ"、テキスト: "良い投稿" } ]
})
> db.blogposts.find( { "comments.by" : "エイダ" } )

>> db.blogposts.ensureIndex( { "comments.by" : 1 } );

例 3:
MongoDB は、現在 10gen によって開発および保守されているドキュメント指向データベースであり、豊富で完全な機能を備えており、MySQL を完全に置き換えることができます。製品のプロトタイピングに MongoDB を使用する過程で、MonogDB のハイライトのいくつかをまとめました。

習得と理解が容易な JSON スタイルの構文の使用: MongoDB は、内部ストレージの形式と構文として、JSON のバリアントである BSON を使用します。 MongoDB 上のすべての操作は JSON スタイルの構文を使用し、クライアントによって送信または受信されたデータは JSON 形式で表示されます。 SQL と比較して、より直観的で理解しやすく、使いこなすのが簡単です。

スキーマレス、埋め込みサブドキュメントをサポート: MongoDB はスキーマフリーのドキュメント データベースです。データベースには複数のコレクションを持つことができ、各コレクションはドキュメントのコレクションです。コレクションとドキュメントは、従来のデータベースのテーブルと行に相当しません。コレクションを事前に定義する必要はなく、いつでも作成できます。

コレクションには、異なるスキーマを持つドキュメント レコードを含めることができます。 これは、前のレコードのドキュメントには 3 つの属性があり、次のレコードのドキュメントには 10 の属性を含めることができることを意味します。属性のタイプは、基本データ型 (数値、文字列、日付など) または It のいずれかになります。配列やハッシュ、さらには埋め込みドキュメントを指定することもできます。このようにして、非正規化データ モデルを実現し、クエリ速度を向上させることができます。

③ 内蔵の GridFS は大容量ストレージをサポートします。

GridFS は、大規模なデータ ストレージをサポートできる優れた分散ファイル システムです。
GridFS と MongoDB が組み込まれており、大規模なデータセットの高速範囲クエリに対応できます。

④組み込みシャーディング。

範囲ベースの自動シャーディング メカニズムを提供します。レコード範囲に従ってコレクションを複数のセグメントに分割し、異なるシャードに分割できます。

シャードはレプリケーションと組み合わせることができ、レプリカ セットを使用してシャーディング + フェイルオーバーを実現でき、異なるシャード間で負荷分散を実現できます。クエリはクライアントに対して透過的です。クライアントはクエリ、統計、MapReduce およびその他の操作を実行し、これらの操作は MongoDB によって自動的にバックエンド データ ノードにルーティングされます。これにより、ビジネスに集中できるようになり、必要に応じてスムーズにアップグレードできるようになります。 MongoDB のシャーディング設計機能は最大約 20 ペタバイトをサポートでき、一般的なアプリケーションをサポートするには十分です。

これにより、MongoDB が安価な PC サーバー クラスター上で実行されるようになります。 PC クラスターは拡張に非常に便利でコスト効率が高く、「シャーディング」操作の複雑さとコストを回避できます。

⑤ 豊富なサードパーティサポート。 (これは、MongoDB が他の NoSQL と比較して持つ利点です)

インターネット上の多くの NoSQL オープンソース データベースは完全にコミュニティベースであり、公式サポートがないため、ユーザーに大きなリスクをもたらします。

オープンソースのドキュメント データベース MongoDB の背後には、商用トレーニングとサポートを提供する営利企業 10gen があります。

また、MongoDB コミュニティは非常に活発で、多くの開発フレームワークがすぐに MongoDB をサポートしています。多くの有名な大企業や Web サイトも実稼働環境で MongoDB を使用しており、Django と RoR に匹敵する技術ソリューションとして MongoDB に注目する革新的な企業が増えています。

⑥優れたパフォーマンス:

千 数千万のドキュメントオブジェクト、ほぼ10gのデータを使用する場合、インデックスIDのクエリはmysqlより遅くなりませんが、非インデックスフィールドのクエリは完全に勝ちます。実際、Mysql は大量のデータのフィールドをクエリすることができませんが、mongodb のクエリ パフォーマンスには本当に驚きました。書き込みパフォーマンスも非常に満足です。数百万のデータを書き込む場合、mongodb は以前試した couchdb よりもはるかに高速で、基本的には 10 分以内に解決できます。監視プロセス中、mongodb は決して CPU キラーではないことを付け加えておきたいと思います。

リレーショナル データベースと比較した MongoDB の欠点:

①mongodbはトランザクション操作をサポートしていません。

したがって、厳格なトランザクション要件を持つシステム (銀行システムなど) では、間違いなくそれを使用できません。 (この点がメリット①に相当します)

②Mongodbは容量をとりすぎます。

その理由について、公式 FAQ では次の点が言及されています:

1. スペースの事前割り当て: 過度のハードディスクの断片化を避けるために、mongodb はスペースが不足するたびに大きなハードディスクスペースを申請し、アプリケーションの量は 64M、128M、256M と指数関数的に増加し、 2G は 1 つのファイルの最大サイズです。データの量が増加すると、ブロック生成容量が増加してデータ ディレクトリにこれらのファイルが表示されるようになります。

2. フィールド名が占めるスペース: クエリの各レコードの構造情報を維持するために、値ドメインが大きくない場合、mongodb は各フィールドのキーと値を BSON 形式で保存する必要があります。数値データの保存などのキー ドメインでは、データのオーバーヘッドが最も大きくなります。スペース使用量を削減する 1 つの方法は、フィールド名をできるだけ短くしてスペースを少なくすることですが、これには読みやすさとスペース使用量の間のトレードオフが必要です。私はかつて、作成者に、フィールド名をインデックスにして、各フィールド名を表すのに 1 バイトを使用して、フィールド名の長さを気にする必要がないようにすることを提案しました。しかし、このインデックス作成方法では、各クエリ結果が取得された後にインデックス値を元の値に置き換えてクライアントに送信する必要があり、この置き換えにも非常に時間がかかります。現在の実装は、空間と時間を交換することです。

3. レコードを削除してもスペースは解放されません。これは、レコードの削除後の大規模なデータの移動を避けるために、元のレコード スペースは削除されず、「削除済み」としてマークされるだけであることを理解するのが簡単です。将来的には再利用できます。

4. db.repairDatabase() を定期的に実行してレコードを整理できますが、このプロセスは遅くなります。

③MongoDB には MySQL ほど成熟したメンテナンス ツールがありませんが、これは開発と IT 運用の両方にとって注目に値します。

添付ファイルやテキストのアップロードに制限があるため、一部の写真やテキストが表示されない場合があります。詳しくは、http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000725&idx=3&sn をご覧ください。 =1e1354fe3a774b01f3d4301f82735024#rd

誰でもコミュニケーションを取ることができます。
下のQRコードをスキャンすると、素敵な記事がどんどん増えていきます！ (QR コードをスキャンしてフォローすると、予期せぬサプライズが待っています!!)

購読番号QRコード.jpg (39.39 KB、ダウンロード数: 0)

添付ファイルをダウンロードする

2016-6-2 18:37にアップロードされました

WeChat サブスクリプション アカウント (uniguytech100) とサービス アカウント (uniguytech) をフォローして、より多くの優れた記事を入手してください。
[Everyone Technology Network Discussion QQ Group] (グループ番号: 256175955) への参加も大歓迎です。自己紹介に注目してください。一緒にそれについて話しましょう!