17

Kyle Banker の MongoDB In Action からの次の引用に興味があります。

キー名はドキュメント自体に保存されるため、選択するキー名の長さを考慮することが重要です。これは、列名が参照する行から常に分離されている RDBMS とは対照的です。したがって、BSON を使用する場合、キー名として date_of_birth の代わりに dob を使用できれば、ドキュメントごとに 10 バイト節約できます。大したことではないように聞こえるかもしれませんが、このようなドキュメントが 10 億個になると、短いキー名を使用するだけで 10 GB 近くのストレージ スペースを節約できます。これは、キー名を小さくするために無理な長さを使用する必要があるという意味ではありません。賢明であること。ただし、大量のデータが予想される場合は、キー名を節約することでスペースを節約できます。

これがデータベースサーバー側で最適化されていない理由に興味があります。コレクション内のすべてのキー名を持つインメモリ ルックアップ テーブルは、潜在的な領域の節約に見合わないほどのパフォーマンス ペナルティになるでしょうか?

4

3 に答える 3

11

あなたが言及しているものは、しばしば「キー圧縮」と呼ばれます*。実装されていない理由はいくつかあります。

  1. やりたい場合は、現在、アプリケーション/ORM/ODM レベルで非常に簡単に実行できます。
  2. すべてのケースで必ずしもパフォーマンスが向上するわけではありません**。多くのキー名を持つコレクションや、ドキュメント間で大幅に異なるキー名を考えてみてください。
  3. 何百万ものドキュメントを作成するまでは、測定可能なパフォーマンス** の利点はまったく得られない可能性があります。
  4. サーバーがそれを行う場合でも、完全なキー名をネットワーク経由で送信する必要があります。
  5. 圧縮されたキー名がネットワーク経由で送信される場合、javascript コンソールを使用すると読みやすさが大幅に低下します。
  6. JSON ドキュメント全体を圧縮すると、パフォーマンスがさらに向上する可能性があります。

すべての機能と同様に、それを実装するための費用便益分析があり、(少なくともこれまでのところ) 他の機能はより多くの「費用対効果」を提供しています。

完全なドキュメント圧縮は、将来の MongoDB バージョンで [検討中][1] です。バージョン 3.0 以降で利用可能 (下記参照)

* キー名のメモリ内ルックアップ テーブルは、基本的に LZW スタイルの圧縮の特殊なケースです。これは、多かれ少なかれ、ほとんどの圧縮アルゴリズムが行うことです。

** 圧縮は、スペースの利点とパフォーマンスの利点の両方を提供します。ドキュメントが小さいということは、IO ごとにより多くのドキュメントを読み取ることができることを意味します。これは、IO が固定されているシステムでは、1 秒あたりにより多くのドキュメントを読み取ることができることを意味します。

アップデート

MongoDB バージョン 3.0 以降には、WiredTigerストレージ エンジンによる完全なドキュメント圧縮機能が搭載されています。

snappyとzlibの2 つの圧縮アルゴリズムを使用できます。その意図は、snappy が総合的なパフォーマンスの最良の選択であり、zlib が最大のストレージ容量の最良の選択であることです。

私の個人的な (非科学的ですが、商用プロジェクトに関連する) 実験では、きびきびした圧縮 (zlib は評価していません) により、顕著な正味のパフォーマンス コストなしでストレージ密度が大幅に向上しました。実際、以前のコメント/予測とほぼ一致して、場合によってはわずかにパフォーマンスが向上しました。

于 2012-07-11T10:19:29.253 に答える
3

キー名をドキュメントとともに保存する本来の理由の 1 つは、スキーマのないデータベースをより簡単に拡張できるようにするためだと思います。各ドキュメントは、ドキュメントを別のサーバーに移動した場合 (レプリケーションやシャーディングなどを介して)、ドキュメントのコンテンツをインデックス化できるという点で、かなり自己完結型です。キー名をよりコンパクトなキー ID に変換します。

MongoDB コレクションには強制スキーマがないため、同じコレクション内のすべてのドキュメントでフィールド名が異なる可能性があります。シャード環境では、各シャードへの挿入は (意図的に) 独立しているため、ドキュメント レベルでは、キー マッピングがシャードごとに一貫していない限り、生データが異なってしまう可能性があります。

ユースケースに応じて、キー名は付随するデータに比べてかなりの量のスペースを消費する場合と消費しない場合があります。YourFriendlyKeyNames をより短い DB キーの同等物にマッピングすることにより、アプリケーション/ODM 実装からのストレージの問題をいつでも回避できます。

未解決の MongoDB Jira の問題と、サーバーでフィールド名をトークン化するためのさらなる議論があり、将来のリリースでこの機能を優先的に含めるために投票できます。

MongoDB の現在の設計目標には、動的スキーマ、レプリケーションと高可用性、自動シャーディング、およびインプレース更新によるパフォーマンスが含まれます.. 潜在的なトレードオフの 1 つは、余分なディスク使用量です.

于 2012-07-11T10:36:16.710 に答える
1

クエリごとにデータベース内でこれを調べなければならないことは、深刻なペナルティになります。
ほとんどのドライバーでは、ElementName を指定できるためMyLongButReadablePropertyName、ドメイン モデルがmlbrpnmongodb になります。

したがって、アプリケーションでクエリを実行すると、次のようになるクエリを変換するのはアプリケーションです。

db.myCollection.find({"MyLongButReadablePropertyName" : "some value"})

の中へ

db.myCollection.find({"mlbrpn" : "some value"})

C# ドライバーなどの効率的なドライバーは、このマッピングをキャッシュするため、クエリごとにこれを検索する必要はありません。

質問のタイトルに戻ります。

キー名が MongodDB のドキュメントに保存されるのはなぜですか

これは文書を検索できる唯一の方法ですか?
キー名が保存されていなければ、検索するキーはありません。

お役に立てれば

于 2012-07-11T09:50:32.917 に答える