モンゴモスクワカンファレンスのビデオを見ました。
ここに、レビューから残った可能性に関する論文があります。
翻訳はそれほど熱くはなく、英語で見たが、何かを混乱させる可能性があった。
それがうまくいかない場合、私は客観的にしようとしました-書き込み:)
- MongoDBのデータは、ネストされた配列とハッシュを含むJSONハッシュのリストです。
- ドキュメントはそのようなハッシュの1つです。
- したがって、ALTER TABLEはありません。レコード構造は互いに独立しています。
- 現在、照合順序のサポートは不十分で、UTFは優れています。
- MongoDBでは、wherewhere> sの代わりに 'db.schema.find（{"s"、{$ gt： "a"}}）を記述します。
- トランザクションはありません。 ただし、ドキュメントに対する操作はアトミックであることが保証されています。
- getLastErrorを呼び出すと、エラーが発生したかどうかが確認されます。 セーフモード（多くのドライバーではデフォルト）では、各レコードの後に呼び出されます。 頻繁に呼び出すことはできません-オーバーヘッドは少なくなりますが、エラーが発生した場合は、すぐに多数のレコードを上書きする必要があります。
- getLastErrorは、すべてのサーバーからではなく、いくつかのサーバーからのみ発生します。
- 彼らは、非常に複雑なドキュメントを作成することを提案しています（たとえば、1つのドキュメントは、コメントツリーが添付された投稿が添付されたブログです）。 これは悪い考えです。1つの要素の負荷が非常に大きくなる可能性があります。
- 参加しません。 必要のないようにデータ構造を作成するだけです。 マウス、ハリネズミになります。
- レプリケーション、レプリケーションログ（バイナリまたはコマンドがわからない）があります。
- レプリケーションマスターが停止している場合、10〜20秒で新しいスレーブがスレーブから選択されます。
- 破片があります。 ハッシュではなく、範囲ごと。 各シャードの範囲は構成で設定されます。
- これらの範囲を調整することで、リシャーディングが実行されます。 この場合、転送中は可変シャードのレコードがブロックされます。
- 100個のデータは約200Mのチャンクに分割されます。
- MapReduceインターフェースがありますが、それについては簡単に言及しています。
- 空間インデックスがあります。
- カスタムfsync周波数のmmappedストレージがあります。
- メモリ内にのみインデックスを保持しているようですが、おそらくそうではありません。 したくない
- インデックスは、Bツリーに似たツリーです。 定期的に再構築することをお勧めしますが、バージョン1.8以降では非常にまれです。
- 興味深いことに、クエリフィルタでは、条件$ whereを設定し、JSでフィルタ条件を記述できます。
- 確かに、インデックスは（まだ）使用されません。
- スパースインデックスがあります-属性が少数のドキュメントにのみ設定されている場合、インデックスのみになります。
- 対象インデックスはIOTです。つまり、 インデックスには他の属性が含まれているため、クエリはインデックスからのデータのみを使用して結果を返すことができ、ドキュメント自体のチャンクにはアクセスできません。
- インデックスの1つのエントリは、約40バイトのオーバーヘッドです。
- 経験的なクエリオプティマイザー。
- 返されるドキュメントの数に対するインデックススキャンの比率を最適化します。
- いずれの場合でも、使用されるインデックスはヒントで指定できます。