MongoDB

MongoDB は、Mongo Query Language (MQL)と呼ばれる独自のクエリ言語を実装しています。^{[ 23 ]} MongoDB は、フィールドクエリ、範囲クエリ、正規表現検索をサポートしています。^{[ 24 ]}クエリは、ドキュメントの特定のフィールドを返すことができ、ユーザー定義のJavaScript関数を含めることもできます。クエリは、指定されたサイズの結果のランダムサンプルを返すように構成することもできます。

MongoDBドキュメント内のフィールドには、プライマリインデックスとセカンダリインデックスを設定できます。

MongoDB はレプリカ セットで高可用性を提供します。^{[ 25 ]}レプリカ セットは、データの 2 つ以上のコピーで構成されます。レプリカ セットの各メンバーは、いつでもプライマリ レプリカまたはセカンダリ レプリカの役割を果たすことができます。デフォルトでは、すべての書き込みと読み取りはプライマリ レプリカで行われます。セカンダリ レプリカは、組み込みのレプリケーションを使用してプライマリのデータのコピーを保持します。プライマリ レプリカが故障すると、レプリカ セットは自動的に選出プロセスを実行して、どのセカンダリがプライマリになるかを決定します。セカンダリはオプションで読み取り操作を実行できますが、デフォルトではそのデータは最終的にのみ一貫性があります。

レプリケートされた MongoDB デプロイメントにセカンダリ メンバーが 1 つしかない場合は、アービターと呼ばれる別のデーモンをセットに追加する必要があります。アービターは、新しいプライマリの選出を解決するという唯一の責任を負います。 ^{[ 26 ]}その結果、理想的な分散 MongoDB デプロイメントでは、プライマリが 1 つとセカンダリが 1 つだけの場合でも、少なくとも 3 つの独立したサーバーが必要になります。^{[ 26 ]}

MongoDB はシャーディングを使用して水平方向にスケーリングします。^{[ 27 ]}ユーザーはシャードキーを選択します。これにより、コレクション内のデータがどのように分散されるかが決まります。データは (シャードキーに基づいて) 範囲に分割され、1 つ以上のレプリカを持つマスターである複数のシャードに分散されます。あるいは、シャードキーをハッシュ化してシャードにマッピングすることで、均等なデータ分散が可能になります。

MongoDBは複数のサーバー上で動作させることができ、負荷分散やデータの複製を行うことで、ハードウェア障害が発生した場合でもシステムの機能を維持できます。

MongoDBは、 GridFSと呼ばれるファイルシステムとして使用でき、複数のマシン間で負荷分散やデータ複製機能を備え、ファイルを保存できます。

この機能（グリッドファイルシステムと呼ばれる）^{[ 28 ]}は、MongoDBドライバに含まれています。MongoDBは、開発者向けにファイル操作とコンテンツに関する機能を提供しています。GridFSには、mongofilesユーティリティ、またはNginx ^{[ 29 ]}とlighttpd ^{[ 30 ]}のプラグインを使用してアクセスできます。GridFSはファイルを部分（チャンク）に分割し、それぞれのチャンクを個別のドキュメントとして保存します。^{[ 31 ]}

MongoDB は、集計を実行するための 3 つの方法を提供しています。集計パイプライン (推奨)、マップ リデュース関数 (MongoDB 5.0 以降非推奨)、および単一目的の集計メソッドです。^{[ 32 ]}

Map-reduceはデータのバッチ処理や集計操作に使用できます。ただし、MongoDBのドキュメントによると、集計パイプラインはほとんどの集計操作でより優れたパフォーマンスを提供します。^{[ 33 ]}

集計フレームワークを使用すると、 SQLのGROUP BY句を含むクエリで返される結果と同様の結果を取得できます。集計演算子は、 Unixのパイプに似たパイプラインを形成するために連結できます。集計フレームワークには、複数のコレクションのドキュメントを結合できる$lookup演算子や、標準偏差などの統計演算子が含まれています。

MongoDBは、キャップ付きコレクションと呼ばれる固定サイズのコレクションをサポートしています。このタイプのコレクションは挿入順序を維持し、指定されたサイズに達すると、循環キューのように動作します。

MongoDBは、2018年6月の4.0リリース以降、複数ドキュメントのACIDトランザクションをサポートしています^{。[ 34 ]}

MongoDBのデフォルトのセキュリティ設定では、どのユーザーでもデータベースにフルアクセスできるため、数万ものMongoDBインストールからデータが盗まれています。さらに、多くのMongoDBサーバーが身代金目的で占拠されています。^{[ 42 ] [ 43 ]} 2017年9月、MongoDBの製品セキュリティ責任者であるDavi Ottenheimer氏は、これらのリスクから保護するための対策が講じられたと発表しました。^{[ 44 ]}

アプリケーションが互いにアクセスできない 2 つの異なる MongoDB プロセスにアクセスできる障害シナリオでは、MongoDB が古い読み取りを返す可能性があります。また、MongoDB が承認済みの書き込みをロールバックする可能性もあります。^{[ 45 ]}この問題は、2016 年 11 月にリリースされたバージョン 3.4.0 で対処され、^{[ 46 ]} v3.2.12 以降の以前のリリースにも適用されました。^{[ 47 ]}

バージョン 2.2 より前は、ロックはサーバー プロセスごとに実装されていました。バージョン 2.2 では、ロックはデータベース レベルで実装されました。^{[ 48 ]}バージョン 3.0 以降、^{[ 49 ]}プラグイン可能なストレージ エンジンが利用可能になり、各ストレージ エンジンはロックを異なる方法で実装する場合があります。^{[ 49 ]} MongoDB 3.0 では、MMAPv1 ストレージ エンジンではコレクション レベルでロックが実装されていますが、 ^{[ 50 ]} WiredTigerストレージ エンジンは、ドキュメント レベルのロックを効果的に提供する楽観的同時実行プロトコルを使用しています。^{[ 51 ]} 3.0 より前のバージョンでも、同時実行性を高める 1 つのアプローチはシャーディングを使用することです。^{[ 52 ]}状況によっては、読み取りと書き込みがロックを解放します。MongoDB がページがメモリに存在する可能性が低いと予測した場合、ページがロードされている間、操作はロックを解放します。ロックの解放の使用はバージョン 2.2 で大幅に拡大しました。^{[ 53 ]}

バージョン3.3.11までは、MongoDBは照合順序に基づくソートを実行できず、 memcmpによるバイト単位の比較に限定されていました。そのため、 Unicodeエンコーディングを使用した場合、多くの非英語言語で正しい順序付けができませんでした。この問題は2016年8月23日に修正されました。

MongoDB 4.0 より前は、インデックスに対するクエリはアトミックではありませんでした。クエリの実行中に更新されたドキュメントが見逃される可能性がありました。^{[ 54 ]} MongoDB 4.0 でスナップショット読み取りの懸念が導入されたことで、このリスクが解消されました。^{[ 55 ]}

MongoDBは、バージョン3.6.4がJepsenによる「業界で最も厳しいデータ安全性、正確性、一貫性テスト」に合格し、「MongoDBは、現在利用可能なデータベースの中で最も強力なデータ一貫性、正確性、安全性の保証を提供している」と主張した。^{[ 56 ]}自らを「分散システム安全性研究会社」と称するJepsenは、Twitterで両方の主張に異議を唱え、「そのレポートでは、MongoDBはデータを失い、デフォルトで因果関係に違反した」と述べた。Jepsenは、2020年5月のMongoDBバージョン4.2.6に関するレポートで、MongoDBはバージョン3.6.4が合格したテストについてのみ言及しており、バージョン4.2.6ではさらに多くの問題が発生したと記した。^{[ 57 ]} Jepsenのテスト概要の一部は次のとおりである。

Jepsen は MongoDB バージョン 4.2.6 を評価し、読み取りと書き込みの懸念を最も強く設定した場合でもスナップショットの分離を維持できないことを発見しました。その代わりに、Jepsen は読み取りの偏り、循環的な情報フロー、重複書き込み、内部整合性違反を観察しました。弱いデフォルト設定により、トランザクションは書き込みを失い、ダーティ リードを許容し、データベース レベルとコレクション レベルで要求された安全レベルをダウングレードすることさえありました。さらに、読み取り専用のトランザクションであっても、書き込み懸念の過半数と組み合わせない限り、スナップショットの読み取り懸念はスナップショットを保証しませんでした。これらの設計上の選択により、MongoDB トランザクションの安全な使用が複雑になります。^{[ 58 ]}

5月26日、Jepsenはレポートを更新し、「MongoDBはトランザクション再試行メカニズムにバグがあることを発見しました。このバグが本レポートで観察された異常の原因であると考えています。パッチは4.2.8でリリースされる予定です。」と述べています。^{[ 58 ]}この問題はそのバージョンで修正され、「デフォルトの書き込みに関する懸念事項に対するJepsenの批判も対処され、デフォルトの書き込みに関する懸念事項はMongoDB 5.0から多数決の懸念事項（w:majority）に格上げされました。」^{[ 59 ]}