序文
ソリューションアーキテクトのMongoDBとして、内とMongoDBの私の時間のほとんどは、顧客やユーザーインタラクションです。ここでは、私が収集したときに知っておく価値を維持するか、皆のためのいくつかのベストプラクティスに従うことを常に更新、ライブ記事を通してのMongoDB開発者を整理したいと思います。私は（年末までにマイクロ・シグナル接点私）の利益をより多くのユーザことを、本当にあなたが関与することができることを願って、共同文書を保護します
この記事では、次の側面が含まれています。
- 安全措施
- 部署架构
- 系统优化
- 监控与备份
- 索引
- 开发与模式
あなたがベースのMongoDBコアビジネスアプリケーションのライン上またはオンライン持ってしようとしている場合は、グレーターチャイナとMongoDBの（でチームにお問い合わせください[email protected]コンサルタントチームの公式機関から専門家の助言を得るために）。
セキュリティについて
認証認証を有効にするには、MongoDBのクラスター
MongoDBのサーバー認証はデフォルトのインストールで有効になっていません。誰もがのmongodインスタンスに直接接続し、任意のデータベース操作を実行できることをこれが意味。文書によると、あなたが有効にすることをお勧め認証http://docs.mongoing.com/manual-zh/tutorial/enable-authentication.html
ユーザごとに異なる役割を割り当てられた権限
MongoDBは役割定義することによって、システム権限をサポートしています。あなたは、「最小特権」のガイドラインだけで、ユーザーのニーズに合わせて、明示的に割り当て権に基づくべきです。
中央の認証サーバーを使用します
LDAP、中央の認証サーバなどのKerberoとして使用し、強力なパスワードポリシーを使用します。
MongoDBは、アプリケーション・サーバーにアクセスする必要がホワイトリスト（ファイアウォールの設定）を作成しています
お使いのサーバが複数のネットワークカードを持っている場合は、それが唯一の内部ネットワークIP上のサービスを聴くことをお勧めします。
暗号化エンジンを使用して機密データ
MongoDBのEnterprise Editionは、ストレージの暗号化、データを保護するための暗号化エンジンを使用する必要があり、顧客に関連する機密データをサポートしています。
展開について
データコピーノードの少なくとも三つのセットを使用して
MongoDBの展開推奨最小値は、データ・セットのコピーを構成する3つのノードです。コピーセットは、次のような利点を提供することができます：
-システムの可用性99.999％
-自動フェイルオーバー
-データの冗長性
-災害の展開
-別の読み取りと書き込みを
断片化するのは時期尚早ではありません
断片化は、読み書きするには、システムの容量を拡張するために使用することができますが、断片化は、例えば、多くの新たな課題をもたらし、管理の複雑さのコストを増加させ、適切なピースキーの課題を選択するというようになります。ハードウェアリソース、IOの最適化を最適化し、たとえば、インデックスの最適化、モデルの最適化、コードの最適化のために、断片化を検討し始めた後に、一般的には、まず、パフォーマンス・チューニングのための他のオプションを使い果たし必要があります。
断片の適切な数を選択します
トリガ条件のいくつかの断片：
- 単一のサーバー上で管理されるデータの量が大きすぎます
- 並行処理は、単一のサーバーできないプロセスが高すぎます
- ディスクIOあまりにも多くの圧力
- スタンドアローンのシステムメモリは、ホットデータを保持するのに十分な大きさではありません
- サーバーNIC処理能力のボトルネック
- 多くの状況下では、ローカライズリテラシーの展開をサポートしたいです
あなたのトリガ条件のスライスに応じて、従うことができ、その後、必要なフラグメントの数を決定するために、各サーバーの容量の総需要で割った値。
各スライスの展開に十分なレプリカセットメンバー
各データスライス間でコピーされません。各スライスのデータは、スライス内の高可用性を確保しなければなりません。データは、ダウンタイムに起因利用できないため、このように、タイムスライスの大部分を確実にするために少なくとも3つのデータノードを展開項MongoDBの各断片のマスタノードではありません。
適切なキーシートを選択
断片化のシナリオでは、最も重要な考慮事項は、適切なキーシートを選択することです。読み書きモードのアプリケーションを検討するキーシートの必要性を選択します。最適化のいずれかの読み取り操作の最適化に一般的には、重要な部分のいずれかの書き込み。そして、もっと頻繁に作動するかに応じて、適切なトレードオフを行います。
- キーシートは、例えば、_id、セット内の多数の異なる値がある非常に高いベース、または、キーシートを有するべきであるベースシートがキー値は繰返さない_idため高いです
- 一般的に重要な部分が成長すべきではない、例えば、タイムスタンプは、持続的な成長の重要な部分です。そのようなキーシート、すなわち、新たな書き込み1つのスライスに集中し、熱断片化現象を引き起こすことは容易です
- 良いキーシートは、効率を改善するために、クエリに向けたスライス上のクエリ（または複数）を行う必要があります。シートはキーフィールド最も一般的に使用されるクエリを含める必要があり、一般的に、この手段
- これは、同時書き込みの速度を高めるために複数のスライスを介して配布することができるので、新たに挿入されたことを、十分に良好な分散キーシートでなければなりません。
- 複数のフィールドの組み合わせは、いくつかの異なるオブジェクト（ベース、分散、およびクエリが向けられている、など）を達成するために、からなる接着シートを使用することができます
システムについて
IOPSの能力を向上させるために使用またはRAID10 SSDストレージ
MongoDBは、そのランダムIO操作更新のほとんどを高性能同時データベースです。一般機械は、SSDに来る最高のストレージソリューションです。あなたは普通のハードドライブを使用する場合、我々は同時実行IOチャネルを改善するために、RAID10ストライピングを使用することをお勧めします。
別の物理ボリュームのデータとジャーナル/ログを使用します
IOのボトルネックとパフォーマンス関連のMongoDBのロット。ログディスク（ジャーナルおよびシステムログ）データディスクIOのフットプリントを削減する物理ボリュームの単一のセット、のための勧告。
システムログには、コマンドラインまたは構成パラメータの指定の用紙に直接することができます。ジャーナルログが別のディレクトリに直接サポートされていません指定された、それはジャーナルディレクトリモードへのシンボルリンクを作成することによって解決することができます。
使用XFSファイルシステム
MongoDBのがWiredTigerストレージエンジンに推奨されてはXFSファイルシステムを使用しています。Ext4のが最も一般的ですが、理由は内部ジャーナルとWiredTigerのextファイルシステムの、競合が存在しているので、大きなIO圧力状況でパフォーマンスの低下。
WiredTigerの下には注意ウルトラで使用
ディスクを削除するWiredTiger書き込みは非同期に発生します。デフォルトでは、チェックポイントを行うには60秒です。整理するために横断するメモリ内のすべてのダーティデータを行い、その後、ハードディスクにデータを書き込むためのチェックポイントが必要。キャッシュが大きい場合（例えば、128Gより大きい）、その後、このチェックポイントは、長い時間がかかります。チェックポイントデータ書き込み性能の間に影響を受けることになります。実際のキャッシュ設定は、現在、64ギガバイト以下を推奨します。
閉じる透明な巨大ページ
透明な巨大ページ（THP）より多くのメモリページを使用して、オーバーヘッド変換索引バッファ（TLB）を低減するために、Linuxのメモリ管理を最適化する手段です。ほとんどのMongoDBデータベースは、より少量のデータを分散している読み取りおよび書き込み、THPは、MongoDBのこの状態に悪影響を与えるの近くにお勧めします。
http://docs.mongoing.com/manual-zh/tutorial/transparent-huge-pages.html
ログローテーションを有効にします
MongoDBはあまりにも多くのディスクスペースを取って、無限に成長するためにログファイルを防ぎます。グッドプラクティスは、ログのローテーションを有効にし、速やかに履歴ログファイルをクリーンアップすることです。
http://docs.mongoing.com/manual-zh/tutorial/rotate-log-files.html
十分なスペースを割り当てOplog
あなたはより多くの時間のかかるメンテナンス作業の一部を実行するノードから、またはノードから最初から回復するのに十分な時間があることを確認するために十分なスペースをOplog。あなたが組立ラインの保守操作のHの時間オフ最長を必要とし、その後、あなたの一般的なOplogは、少なくとも保存することができますHようにしたい2またはH 3時間oplog。
あなたのMongoDB展開時刻が正しく設定されていない場合Oplogサイズは、以下のリンクを参照して調整することができます。
http://docs.mongoing.com/manual-zh/tutorial/change-oplog-size.html
データベースファイルのatimeを閉じます
ファイル・システム・アップデートのアクセス時間を禁止することは、ファイルの読み込みのパフォーマンスが向上します。これは、/ etc / fstabのファイルにnoatimeオプションパラメータを増加させることによって達成することができます。例えば：
/dev/xvdb /data ext4 noatime 0 0
再マウントすることができますにファイルを変更した後：
＃ mount -o remount /data
デフォルトのファイルディスクリプタやプロセス/スレッドの上限数を増やします
Linuxのデフォルトのファイルディスクリプタ番号とMongoDBのためのプロセスの最大数は、一般的に低すぎます。この値が64000に設定されていることをお勧めします。MongoDBのデータベースの各ファイルのサーバーと各クライアントが接続されているファイル記述子を使用する必要がありますので。この数が小さすぎると間違っているか、大規模な同時操作の場合に対応するために失敗することがあります。あなたは、次のコマンドを使用して、これらの値を変更できます。
ulimit -n 64000
ulimit -u 64000
禁止 NUMA
NUMA技術は、マルチプロセッサのLinuxシステムでの使用には、あなたは、NUMAの使用を禁止すべきです。MongoDBの業績は、特に高負荷プロセスの下で、NUMA環境では遅く、時にはかもしれません。
提供プリフェッチ値（先読み）
先読みプログラムがおおよそのページを読むことを要求されたときに、オペレーティング・システム・ファイルを最適化するための手段であり、ファイルシステムは、同じ時間とリターンで次のいくつかのページを読み込みます。非常に多くの場合、最も時間のかかるディスクIOを求めるためです。先読みにより、システムは直前のデータとリターンのことができます。それは、ディスクの多くはシーク時間節約ので、プログラムはシーケンシャルな読み取り操作を行っていると仮定すると。
MongoDBは、多くの場合、ランダムアクセスを行います。ランダムアクセスの場合、この値はセット小さい先読みしなければならない方がよい。一般的に32は良い選択です。
あなたは先読みシステムの現在の値を表示するには、次のコマンドを使用することができます。
sudo blockdev --report
先読みを変更するには、次のコマンドを使用することができます。
sudo blockdev --setra 32
記憶装置に適しています。
使用NTPタイムサーバ
MongoDBのレプリケーションセットまたはクラスタの断片化を使用する場合は、注意がNTPタイムサーバを使用する必要があります。これは、MongoDBのクラスタへの原則との間に適切な同期を保証します。
監視とバックアップについて
監視警報のための重要な指標のデータベース
主な指標は以下のとおりです。
- Disk Space 磁盘空间
- CPU
- RAM 使用率
- Ops Counter 增删改查
- Replication Lag 复制延迟
- Connections 连接数
- Oplog Window
スロークエリログを監視するには
MongoDBは（mongod.log）デフォルトでは、ログファイルで100ms以上のデータベース操作を記録します。
インデックスについて
あなたのすべてのクエリに適切なインデックスを確立
これは、例えば、データの収集、大量の、大きさの（文書の数）数千万以上の受注のためです。あなたはより大きな圧力のMongoDBサーバーを引き起こし、他の要求の実行に影響を与えるであろう、ディスクからメモリにすべてのインデックスMongoDBのドキュメントを必要としない場合。
適切な複合インデックスを作成し、クロスインデックスさに依存しません
あなたが複数のフィールドを照会するために使用する場合は、MongoDBは2つのインデックス技術を使用することができました：インデックスと相互参照の組み合わせを。相互参照は、フィールド毎に別々の単一フィールドインデックスを作成し、単一のクロスフィールドインデックスindex得られた結果の適切なクエリの実行時間を使用することです。クロスリファレンスは、クエリが通常の使用のインデックス複合インデックスを保証することが推奨されたときに複数のフィールドを持っているそうだとすれば、現在の低金利を引き起こしました。
例えば、アプリケーションは、深セン市のマラソンランナーにすべてのより若い30歳見つけるために必要がある場合：
db.athelets.find({sport: "marathon", location: "sz", age: {$lt: 30}}})
そして、あなたは、このような指標が必要になる場合があります。
db.athelets.ensureIndex({sport:1, location:1, age:1});
組み合わせインデックスフィールドの順序：最初に一致した条件、条件の範囲（範囲平等まず、後）
組合せ条件やポイントの範囲と一致する場合、インデックスを作成する場合の例として説明し、整合条件（スポーツ、「マラソン」）は、複合インデックスの前にあるべきです。範囲条件（年齢：<30）フィールドが複合インデックスの背面にする必要があります。
可能な限り、カバーするインデックスを使用します（インデックスを対象）
時には、あなただけのクエリが返す非常に少ないかだけでも、フィールドには、たとえば、あなたはすべての宛先虹橋空港の出発にすべてのフライトを検索する必要があります。既存のインデックスは次のとおりです。
{origin: 1, dest: 1}
通常のクエリは、この（唯一の目的地の空港に戻る必要がある）のようになる場合：
db.flights.find({origin:"hongqiao"}, {dest:1});
このようなクエリは、文書をスキャンして、マッチング結果を取得する必要があり、デフォルト_idフィールドが含まれます。逆に、このクエリを使用する場合：
db.flights.find({origin:"hongqiao"}, {_id:0, dest:1});
MongoDBは、あなたが（ドキュメントがメモリにハードディスクから転送する必要があるかもしれない）すべての値が実際の文書をスキャンせずに、索引から直接返す必要が得ることができます
バックグラウンドでインデックスを構築するには
コレクションのインデックスを作成する場合は、コレクションのデータベースが存在するが、他の読み取りおよび書き込み操作を受け付けません。データ量の建設インデックスのコレクションは、バックグラウンドオプション{：真の背景を}使用することをお勧めします
開発について
デザインモード
リレーショナルテーブル構造を設計するために従わないでください。
MongoDBはあなたが設計通りに、リレーショナルデータベースのテーブル構造のような気分にさせることができますが、それは外部キーをサポートしていません。また、参加洗練されたサポートしています！あなたのプログラムは、実用的な多数のを発見した場合は、あなたのデザイン、最初からやり直す必要があること、場所を登録しよう。パターンに関連する次のような設計の推奨事項を参照してください。
データベースコレクション（コレクション）の数が多すぎるではありません
柔軟性の豊かなJSONドキュメントモードに基づいてMongoDBのスキーマ設計。多くの場合、MongoDBのデータベース・アプリケーションのコレクション（テーブル）の数がはるかに少ないリレーショナルデータベースを使用するアプリケーションの同じタイプよりもする必要があります。MongoDBのテーブルの設計は、第三のパラダイムに準拠していません。MongoDBのデータモデルは、構造のセットに対応するプライマリドメインオブジェクトの数に応じて基本的に、非常に近いオブジェクトモデルです。経験によると、10まで、通常いくつかのアプリケーション内の数平均小さなセット、アプリケーション中規模および大規模またはより数十よりもあろう。
データの冗長性を恐れてはいけません
第三のパラダイムに従い、MongoDBのパターン設計ではないが、データが複数の文書に何回も繰り返すことができるように、例えば、各部門のスタッフ文書で彼の名前を繰り返すことは許容練習です。部門名を変更する場合は、アップデートを実行することができます（{}、{}、{マルチ：真}）は、複数の文書では、1回の更新に部門名を更新します。
適切なデータの冗長性のタイプには適していません
一般的には、多くの場合になるフィールドのデータ値ならば、それは他の文書、または他のコレクションの内部への冗長多数のには適していません。我々は株式資産管理のいくつかの種類を行っている場合たとえば、Apple社の株式を購入する多くの人々があるかもしれないが、株価が頻繁に変わるため、株価の変動、顧客のドキュメントに頻繁に冗長性ならば、それはにつながります更新操作の数が多いです。それは冗長shi'yangことができますが、別の観点からは、頻繁に、など顧客の名前、住所、部署、などいくつかのフィールドを、変更した場合ではありません
N（の一部）埋め込まれたすべての使用との関係：1
多くの関係については、そのような人は、いくつかの情報を持っているように、本は10章を持っている、というように、のような、Nの配列内のデータが記述されている組み込みモードを使用することをお勧めします。
> db.person.findOne()
{
user_id: 'tjworks',
name: 'TJ Tang',
contact : [
{ type: 'mobile', number: '1856783691' },
{ type: 'wechat', number: 'tjtang826'}
]
}
1：1の関係NN（多くの）埋め込まれたIDの使用
時には、多くのマルチ端末の大多数、例えば、どのように多くの従業員が部門内。3階層の部門ではHuawei社は、直接部門内に埋め込まれ、すべての従業員情報は、16メガバイト文書の制限を超えることが可能である場合には、この時間は確かに良い選択ではない、従業員の数千人を有することができます。参照IDを使用することができ、この時間は次のとおりです。
> db.departments.findOne()
{
name : 'Enterprise BG',
president: 'Zhang San',
employees : [ // array of references to Employee colletion
ObjectID('AAAA'),
ObjectID('F17C'),
ObjectID('D2AA'),
// etc
]
}
あなたは、従業員関連の情報の下に部門を照会する必要がある場合は、従業員情報とリターンを関連付けるために$ルック集計演算子を使用することができます。
NNN（ロット）の使用との関係：1組
次対多の例の場合、この無限の成長の数を多く倍と頻繁に、例えば、この時間はIDに置かれていても毎分、数千人の何百もあるダウン年間を、検針は不便アレイ管理されます、この時間は、マルチ端末データ収集を作成し、のような文書コレクションの参照、中にメイン文書に接続を追加する必要があります：
> db.sensors.findOne()
{
_id : ObjectID('AAAB'),
name : 'engine temperature',
vin : '4GD93039GI239',
engine_id: '20394802',
manuafacture: 'First Motor',
production_date: '2014-02-01'
...
}
>db.readings.findOne()
{
time : ISODate("2014-03-28T09:42:41.382Z"),
sensor: ObjectID('AAAB'),
reading: 67.4
}
大規模なバイナリファイルとメタデータ保存収集ポイント
あなたが管理するために、PDFファイル、写真、ビデオ、さらには小さなバイナリファイルを持っている必要がある場合、我々は、手動でバイナリデータとメタデータの別のサブセットを管理するMongoDB GridFS APIのかに使用することをお勧めします。
頻繁に更新されたデータは、ネストされた配列に配置されていません
配列は、対多リレーションシップの武器を表現するために使用されますが、MongoDBは、ネストされた配列要素内の直接の更新機能の欠如します。例えば：
{
name: "Annice",
courses: [
{ name: "English", score: 97 },
{ name: "Math", score: 89 },
{ name: "Physics", score: 95 }
]
}
この設計では、我々が直接99の数学のスコアを変更することができ、ネストされた配列を持っていません。
db.students.update({name: "Annice"， "courses.name":"Math"}, {$set:{"courses.$.score": 99 }})
ロケータ$のアレイの使用は、$配列内の現在の試合の最初の配列要素のインデックスを表しています。
ただし、この場合は、次のようにネストされた配列が含まれます。
{
name: "Annice",
courses: [
{ name: "Math", scores: [
{term: 1, score: 80} ,
{term: 2, score: 90}
]
},
{ name: "Physics", score: 95 }
]
}
この時間変更を行うために1つの数学のコースの期間をスコアしたい場合は、メモリのスコアの配列を介して転送する必要があり、この要素を変更するには、コード内でネストされた配列です。$ MongoDBの配列ロケータは、層の最初のグループに対してのみ有効であるためです。
もちろん、あなたのモデルは、ネストされた配列要素内の変更を必要としない場合、これは適用されません。
コンフィギュレーション
適したセットMongoDBの接続プールのサイズ（ホストあたりの接続）
Javaの駆動のデフォルトの接続プールのサイズは100です。アプリケーションの実際の状況に応じて推奨の調整。小さなアプリケーションのために適切にアプリケーションサーバの小さなフットプリントを低減するための圧力を調整することができます。
書き込みの適切な使用を懸念セット（書き込み懸念）
最小推奨される展開MongoDBは、複製セットが3つのデータ・ノードが含まれています。書き込み（更新、挿入、または削除）は、デフォルトのアプリケーション上のマスターノードの完了後すぐに戻ります。書き込み動作はバックグラウンドで非同期双方向OPLOGによって他のノードに複製されます。極端な例では、これらのノードがマスターノードを複製する時間から見える書き留めする必要はないかもしれません。アクティブおよびスタンバイスイッチングノードは、書き込み動作がファイルに元のプライマリノードにロールバックし、アプリケーションに見えないであろう場合に発生します。オプション：このような状況を防ぐために、MongoDBは{「marjority」W}重要なデータを使用することをお勧めします。{W：「大多数の」}の前に大部分のノードで成功した結果を返すためにコピーしたデータを確保することができます。このメカニズムを使用すると、効果的にロールバックデータの発生を防止することができます。
（ワット缶：「majrotiy」の組み合わせ）：また、あなたは{1} jで使用することができ、アプリケーションに返されるデータを指定するために成功裏に書き込みログWAL後に確認されました。これは、減少した書き込み性能につながりますが、重要なデータのために使用することを検討することができます。
適切な使用読まオプション設定（読み取り優先）
それは分散システムであるためMongoDBは、データが複数のノードにコピーされます。上のノードからのリードデータ、アプリケーションデータの必要に応じて読み出すことができません。以下は、フォーカスは、オプションを読み取るように構成することができますされています。
- デフォルトでは、プライマリノード上の読み出しデータ：主要
- priaryPreferred：それが成功した場合、ノードRenyiyitaiから読み込まれ、プライマリノード上で読み始めます
- 二次：（ランダムスレーブノードを使用する場合、複数のノード）ノードから読み出されたデータ
- secondaryPreferred：まず、ノードからの読み取りから、ノードがサービスを提供することはできませんいくつかの理由からすれば、マスターノードから読み取ります
- 最寄り：最も近いノードから読み取ります。距離は、ping操作の時間によって決定されます。
最初のオプションに加えて、現在ではないかもしれない読み出したデータを読み取るための他のオプションがあります。その理由は、データ複製がバックグラウンドで非同期に行われることです。
インスタンス化しない複数のMongoClientを実行します。
MongoClientは、スレッドセーフなクラスであるスレッドプールを付属しています。通常、JVM MongoClient内のリソースの無駄遣いと、あまりにも多くの接続を回避するために、複数のインスタンスをインスタンス化していません。
書き込みへの再試行メカニズムの使用
MongoDBのレプリケーションは、99.999％の可用性を実現できる技術を使用して設定します。マスタノードが書き込むことができない場合、システムは、別のノードに自動的にフェイルオーバーします。転送には時間がかかり、数秒間、対応するアプリケーションが例外をキャッチして、操作を再試行する必要があり、その間かもしれません。存在すべきバックオフリトライメカニズム、例えば、それぞれ、リトライ1S、2S、4S、8S、等時間。
長いフィールド名を使用しないでください
MongoDBの無いテーブル構造定義。各文書の構造は、各フィールドの内部文書によって決定されます。すべてのフィールド名は、各ドキュメント内で繰り返されます。あまりにも長い間、メモリへのネットワーク帯域幅より多くの需要をリードしますされ、フィールド名を使用してください。（圧縮技術のため、ハードディスクに保存され、長いフィールド名はあまり取りません）
定期的なネーミングを使用します
以下のような：学校、コース、StudentRecord
か：学校、もちろん、stuent_record
適切な使用の更新ステートメント
MongoDBのデータベースと共通鍵（KV）は同等であると考えられるしないでください。MongoDBは、リレーショナルデータベースの更新や場所の更新で同様の文をサポートしています。あなただけのUPDATE文で更新するフィールド、全体ではなく、ドキュメントオブジェクトを指定する必要があります。
例えば、私は、ユーザーの名前がTJ唐Jianfaから変更されました参加したいと思います。
練習を推奨しません。
user = db.users.findOne({_id: 101});
user.name="Tang Jianfa"
db.users.save(user);
推奨プラクティス：
user = db.users.findOne({_id: 101});
// do certain things
db.users.update({_id:101}, {$set: {name: "Tang Jianfa"}});
使用投影（プロジェクション）が返さ含量を減少させます
MongoDBのサポートを選択内のステートメントSQL-のように、あなたは、フィールドをフィルタリングすることができます返さ。使用投影戻されたコンテンツは、コードの量を減少、低下及びネットワークを対象に必要な時間に変換され介して送信することができます。
自動的に期限切れのデータを削除するには、TTLの使用
何度も私たちは、このような7日間のデータを監視などのデータの適時の一部を、保存するためにMongoDBを使用しています。自分のスクリプトを作成し、その背景には、定期的に古いデータをクリーンアップする、あなたが期限切れのデータのMongoDBのTTL自動削除を行うために、インデックスを使用することができます。
db.data.ensureIndex({create_time:1}, {expireAfterSeconds: 7*24*3600})
アップサートを達成するために実行するコマンドを使用します
時には、文書データが既にライブラリに存在するかどうかわかりません。この時間は、あなたのいずれかの最初のお問い合わせ、またはUPSERTステートメントを使用しています。UPSERT文の下にSpringDataでは、各フィールドの値をフォーマットする必要がアップサート文で出ています。フィールドとより多くの時間が多少面倒です。MongoTemplate内部SpringData MongoDBはそこに方法は例からすべてのフィールドを一覧表示するに退屈していない、DBの呼び出しを実装するために使用することができます実行します。
public boolean persistEmployee(Employee employee) throws Exception {
BasicDBObject dbObject = new BasicDBObject();
mongoTemplate.getConverter().write(employee, dbObject);
mongoTemplate.execute(Employee.class, new CollectionCallback<Object>() {
public Object doInCollection(DBCollection collection) throws MongoException, DataAccessException {
collection.update(new Query(Criteria.where("name").is(employee.getName())).getQueryObject(),
dbObject,
true, // means upsert - true
false // multi update – false
);
return null;
}
});
return true;
}
SpringData MongoDBの次_classフィールドを削除します。
SpringDataのMongoDBのデフォルトでは、このような「com.mongodb.examples.Customer」として、完全修飾クラス名に格納されたMongoDBのドキュメントで_classフィールドを追加します。いくつかの小さな文書の場合、このフィールドは、ストレージスペースの小さな部分を占めるないかもしれません。あなたがしたくない場合はSpringDataが自動的にこのフィールドに追加、次のことができます。
1）カスタムMongoTypeMapper
@Bean
public MongoTemplate mongoTemplate() throws UnknownHostException {
MappingMongoConverter mappingMongoConverter = new MappingMongoConverter(new DefaultDbRefResolver
(mongoDbFactory()), new
MongoMappingContext());
mappingMongoConverter.setTypeMapper(new DefaultMongoTypeMapper(null));
return new MongoTemplate(mongoDbFactory(), mappingMongoConverter );
}
検索文を使用している場合2）明示的にクラス/タイプの名前を指定します。
MongoTemplate.find(new Query(), Inventory.class))
转载自：
http://www.mongoing.com/archives/3895