グローバル書き込みロックなど、MongoDBにはまだまだ改善すべき点がたくさんあります。この記事では、ビッグデータ（この場合は100GB）に対応するためのスケール方法に焦点を当てます。
基本的なストレージの実装を見れば、もっとよくわかります。基本的にMongoDBは、シンプルなB-treeインデックスを使用するBSONドキュメントのmmap（メモリマップド）リンクテーブルの束と、ストレージの耐久性メカニズムとしての基本的なロギングで構成されています。最終的には、OSがディスクに書き込み、OSがメモリにロードしたデータの結果をページ単位で読み出します。
当初はキラー・アドバンテージとして説明されていたスピード面は、実際にはページ・キャッシングを使用することによる効果に過ぎません。単なるmmap "であり、BSアーキテクチャに関連するすべての最適化は、作業セットをよりRAMに優しくしているだけであり、スライス上で削除やレコードの追加などを行うと、大きな影響を与えることになることにすぐに気づくでしょう。 OSはあなたがデータベースを実行していることを知りません。あなたが何かをMMAPしたいことを知り、それに***アクセス効果を与えるだけです。幸いなことに、このアルゴリズムは非常に賢い人たちによって書かれたものなので、検索結果がキャッシュにヒットする限りは問題なく動作しますが、OSはストレージのレイアウトやインデックスとデータの違いすら考慮せずに書き込みをスケジュールします。どのようなデータがキャッシュに残るのか、あるいはプリロードされるのかを推測することはできません。
実際、MongoDB Taoのような天才はたくさんいて、そのほとんどは本当に優れたアイデアを使っています。Cassandraの一貫性プロトコル、Redisのクレイジーなデータ構造、Hadoopのデータ処理能力などです。MongoDBにはmmapがあり、独自のキャッシュアルゴリズムや書き込み戦略を考案する必要がなく、できるだけシンプルなものをすべて活用しています。MongoDBにはmmapがあり、独自のキャッシュアルゴリズムや書き込み戦略を考案する必要がありません。比較対象がより魅力的になります。その頃には、本当の意味でのデータベースを実現したり、書いたりしているかもしれませんし、いずれにせよ、顧客は固定化され、設計上の決定に100％準拠するようになります。しかし、オラクルやIBMと肩を並べるのは偶然ではないという事実を見失わないでください。
前述したように、MongoDBには多くの不満が残ります。懸念されるのは、ストレージエンジンにフォーカスし、より広範な永続化戦略の問題を無視した場合、キラーアプリケーションはオンラインゲームでユーザーデータを扱うのと似ていなければならないということです。より柔軟なデータ構造スキーマを取得したい場合は、リレーショナルモデルに変換してhstoreやJSONカラムのようなものを使ってグラフに入力したり、HBaseやCassandraのようにblob/textを使ってドキュメントを保存したりできますが、MongoDBを使うほど悪くはありません。
