あなたが言及しているものは、しばしば「キー圧縮」*と呼ばれます。実装されていない理由はいくつかあります。
- 必要に応じて、現在、アプリケーション/ ORM/ODMレベルで非常に簡単に実行できます。
- すべての場合において、必ずしもパフォーマンス**の利点であるとは限りません。キー名が多数あるコレクションや、ドキュメント間で大きく異なるキー名を含むコレクションを考えてください。
- 数百万のドキュメントが作成されるまで、測定可能なパフォーマンス**の利点がまったく得られない可能性があります。
- サーバーがそれを行う場合でも、完全なキー名をネットワーク経由で送信する必要があります。
- 圧縮されたキー名がネットワークを介して送信される場合、読みやすさは本当に javascriptコンソールの使用に苦しんでいます。
- JSONドキュメント全体を圧縮すると
提供される可能性がありますさらに優れたパフォーマンス上の利点を提供します。
すべての機能と同様に、それを実装するための費用便益分析があり、（少なくともこれまでのところ）他の機能はより多くの「費用対効果」を提供しています。
将来のMongoDBバージョンでは、完全なドキュメント圧縮が[検討中][1]です。 バージョン3.0以降で利用可能（以下を参照）
*キー名のメモリ内ルックアップテーブルは、基本的にLZWスタイルの圧縮の特殊なケースです。これは多かれ少なかれほとんどの圧縮アルゴリズムが行うことです。
**圧縮は、スペースの利点とパフォーマンスの利点の両方を提供します。ドキュメントが小さいということは、IOごとにより多くのドキュメントを読み取ることができることを意味します。つまり、固定IOを備えたシステムでは、1秒あたりにより多くのドキュメントを読み取ることができます。
更新
MongoDBバージョン3.0以降では、WiredTigerを使用して完全なドキュメント圧縮機能を利用できるようになりました。 ストレージエンジン。
2つの圧縮アルゴリズムを使用できます： snappy 、および zlib 。その目的は、snappyがオールラウンドなパフォーマンスのための最良の選択であり、zlibが最大のストレージ容量のための最良の選択であることです。
私の個人的な（非科学的ですが、商業プロジェクトに関連する）実験では、スナッピー圧縮（zlibを評価しませんでした）は、目立った正味のパフォーマンスコストなしで大幅に改善されたストレージ密度を提供しました。実際、以前のコメント/予測とほぼ一致して、場合によってはパフォーマンスがわずかに向上しました。