まず、リンゴとリンゴを比較してみましょう。 MongoDBを使用した読み取りと書き込みは、RDBMSに非クラスター化インデックスがないテーブルでの主キーによる単一の読み取りと書き込みのようなものです。
それでは、正確にベンチマークを行いましょう：http://mysqlha.blogspot.de/2010/09/mysql-versus-mongodb-yet-another-silly.html
そして、まったく同じプリミティブ操作を公正に比較した場合の速度差は大きくありません。 実際、MySQLはわずかに高速です。 同等だと思います。
なんで？実際、この特定のベンチマークでは、両方のシステムが同様のことを行っているためです。主キーで検索された単一の行を返すことは、実際にはそれほど多くの作業ではありません。非常に高速な操作です。クロスプロセス通信のオーバーヘッドがその大きな部分を占めていると思います。
私の推測では、MySQLでより調整されたコードは、MongoDBのわずかに体系的なオーバーヘッドよりも重要です（論理ロックやその他の小さなものはありません）。
これは興味深い結論につながります。MySQLをドキュメントデータベースのように使用して、優れたパフォーマンスを引き出すことができます。
インタビュアーが「ドキュメントやスタイルは気にしない。もっと高速なデータベースが必要なだけだ。MySQLとMongoDBのどちらを使うべきだと思うか」と答えた場合、私は何に答えますか？
パフォーマンスを少し無視して、2つのシステムの相対的な強さを確認することをお勧めします。 MongoDBでは、スケーリング（ウェイアップ）やレプリケーションなどが思い浮かびます。 MySQLの場合、豊富なクエリ、同時実行モデル、より優れたツールと成熟度など、さらに多くの機能があります。
基本的に、機能をパフォーマンスと交換することができます。それを喜んでしますか？それは一般的にはできない選択です。とにかくパフォーマンスを選択する場合は、別のテクノロジーを追加する前に、まずMySQLを調整することを検討してください。
クライアントが主キーで単一の行/ドキュメントを取得すると、次のようになります。両方のシステムの違いに注釈を付けます：
- クライアントはバイナリコマンドを作成します（同じ）
- クライアントはTCP経由で送信します（同じ）
- サーバーはコマンドを解析します（同じ）
- サーバーはキャッシュからクエリプランにアクセスします（SQLのみ、MongoDBではなく、HandlerSocketではありません）
- サーバーはB-Treeコンポーネントに行へのアクセスを要求します（同じ）
- サーバーは、行につながるBツリーパスで物理的な読み取り専用ロックを取得します（同じ）
- サーバーは行を論理的にロックします（SQLのみ、MongoDBではなく、HandlerSocketではありません）
- サーバーは行をシリアル化し、TCP経由で送信します（同じ）
- クライアントはそれを逆シリアル化します（同じ）
一般的なSQLベースのRDBMSには、追加の手順が2つだけあります。 だからこそ、実際には違いはありません。