必要に応じて、コンテンツの保存と分類を行います。リファレンスとしてご利用ください。リソースに最も近いデータベースのロケーションを選択してください。ホップはエラーが発生しやすく、クエリのレイテンシを増加させます。つのリージョンに配置します。ロケーションを選択します。使用しないでください。/(スラッシュ)は使用しないでください。使用しないでください。使用すると、レイテンシに影響を与えるホットスポットが生じる可能性があります。追加のエスケープが必要になるため、フィールド名に次の文字は使用しないでください。ピリオド(.)左角かっこ([)右角かっこ(])アスタリスク(*)バッククォート(`)インデックスインデックスを過剰に使用しないでください。コストが増加する可能性があります。レベルのインデックス除外を検討してください。読み取りレートや書き込みレートが高いアプリケーションの場合、タイムスタンプのように単調に増加する値を持つフィールドにインデックスを作成すると、レイテンシに影響を与えるホットスポットが生じる可能性があります。メッセージのリンクでインデックスを管理できます。次のようなケースでは、単一フィールド除外を追加したほうがよい場合があります。大きな文字列フィールド文字列フィールドに長い文字列値を保持することが多く、その文字列値がクエリには使用されない場合、インデックス作成からそのフィールドを除外することでストレージの費用を削減できます。連続した値を持つフィールドに基づいてクエリを実行することがない場合は、そのフィールドをインデックス作成から除外すれば、この上限を回避できます。回/秒の書き込み上限に近づく可能性があります。フィールドをタイムスタンプにする必要があります。レートが高くなるとパフォーマンスに影響する可能性があります。フィールドには、単一フィールド除外を追加することをおすすめします。件に近づく可能性があります。フィールドに基づいてクエリを実行することがない場合は、そのフィールドをインデックス作成から除外してください。書き込みオペレーションアプリが単一ドキュメントを更新できる正確な最大レートは、ワークロードによって大きく異なります。詳しくは、同一ドキュメントに対する更新をご覧ください。可能な場合は、同期呼び出しではなく非同期呼び出しを使用します。非同期呼び出しでは、レイテンシの影響が最小限に抑えられます。ドキュメントの検索結果とクエリの結果に従ってレスポンスをレンダリングするアプリケーションについて考えてみましょう。検索とクエリにデータの依存関係がない場合、検索が完了するまでクエリの開始を同期的に待機する必要はありません。オフセットは使用しないでください。その代わりにカーソルを使用します。オフセットを使用すると、スキップされたドキュメントがアプリケーションに返されなくなりますが、内部ではスキップされたドキュメントも引き続き取得されています。スキップされたドキュメントはクエリのレイテンシに影響し、このようなドキュメントの取得に必要な読み取りオペレーションは課金対象になります。ライブラリは、一時的なエラーに対処するために、失敗したトランザクションを自動的に再試行します。アクセスする場合は、信頼性を高めるために、アプリケーションによるトランザクションの再試行を実装してください。クエリを理解するをご覧ください。プラクティスについて説明します。単一ドキュメントに対する更新アプリを設計する際は、アプリが単一ドキュメントを更新するのに要する時間を考慮してください。ワークロードのパフォーマンスを判断する最良の方法は、負荷テストを実行することです。アプリが単一ドキュメントを更新できる正確な最大レートは、ワークロードによって大きく異なります。このような要素には、書き込みレート、リクエスト間の競合、影響を受けるインデックスの数などがあります。ドキュメントの書き込みオペレーションでは、ドキュメントとその関連インデックスを更新します。よって、レプリカのクォーラムに書き込みオペレーションが同期的に適用されます。書き込みレートが高いと、データベースで競合、高レイテンシ、その他のエラーが発生するようになります。辞書順で近い一連のドキュメントに対して、高頻度で読み取りや書き込みを行わないでください。この問題はホットスポットといいます。次のいずれかを行うと、アプリケーションにホットスポットが生じる可能性があります。