翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon DocumentDB (MongoDB 互換) とは Amazon DocumentDB (MongoDB 互換) は高速で信頼性が高く、完全マネージド型のデータベースサービスです。Amazon DocumentDB は、クラウド内で MongoDB と互換性のあるデータベースを簡単にセットアップ、運用、スケールすることができます。Amazon DocumentDB では、同じアプリケーションコードを実行し、MongoDB で使用するのと同じドライバーとツールを使用できます。 Amazon DocumentDB を使用する前に、「[仕組み](how-it-works.md)」で説明されている概念と機能を確認しておく必要があります。その後で、「[入門ガイド](get-started-guide.md)」の各ステップを実行します。 **Topics** + [概要:](#overview) + [クラスター](#what-is-db-clusters) + [インスタンス](#what-is-db-instances) + [リージョンと AZ](#what-is-regions-and-azs) + [料金](#docdb-pricing) + [モニタリング](#what-is-monitoring) + [インターフェイス](#what-is-interfaces) + [次のステップ](#what-is-next) + [仕組み](how-it-works.md) + [ドキュメントデータベースとは](what-is-document-db.md) ## Amazon DocumentDB の概要 次に示すのは Amazon DocumentDB の主な機能の一部です。 + Amazon DocumentDB は、インスタンスベースのクラスターとエラスティッククラスターの 2 種類のクラスターをサポートしています。エラスティッククラスターは、1 秒あたり数百万回の読み取り/書き込みとペタバイトのストレージ容量を持つワークロードをサポートします。エラスティッククラスターの詳細については、「[Amazon DocumentDB のエラスティッククラスター](docdb-using-elastic-clusters.md)」を参照してください。以下の内容は Amazon DocumentDB インスタンスベースのクラスターに関するものです。 + Amazon DocumentDB は、データベースのストレージニーズが増大すると自動的にストレージボリュームのサイズを拡張します。ストレージボリュームは 10 GB ごとに最大 128 TiB まで拡張されます。将来の拡張に備えてクラスターに余分なストレージをプロビジョニングする必要はありません。 + Amazon DocumentDB では、最大 15 個のレプリカインスタンスを作成して、大量のアプリケーションリクエストをサポートように読み取りスループットを増やすことができます。Amazon DocumentDB レプリカは同じ基盤となるストレージを共有しているため、コストを削減でき、レプリカノードで書き込みを実行する必要はありません。この機能により、読み取り要求を処理するための処理能力が解放され、レプリカのラグタイム (多くの場合、一桁ミリ秒に短縮されます) が短縮されます。ストレージボリュームのサイズに関係なく、レプリカを数分で追加できます。Amazon DocumentDB にはリーダーエンドポイントも提供するため、アプリケーションは追加および削除されるときにレプリカを追跡することなく接続できます。 + Amazon DocumentDB では、各インスタンスを拡大または縮小するため、コンピューティングおよびメモリリソースをスケールすることができます。通常、コンピューティングのスケーリングは数分以内に完了します。 + Amazon DocumentDB は Amazon VPC (Amazon Virtual Private Cloud) で実行されるため、独自の仮想ネットワークでデータベースを分離することができます。また、ファイアウォール設定を指定して、クラスターへのネットワークアクセスを制御することができます。 + Amazon DocumentDB はクラスターの正常性を継続的にモニタリングします。インスタンスに障害が発生すると、Amazon DocumentDB はインスタンスと関連するプロセスを自動的に再起動します。Amazon DocumentDB では、データベース REDO ログのクラッシュリカバリのリプレイが必要ないため、再起動時間が大幅に短縮されます。Amazon DocumentDB は、データベースキャッシュをデータベースプロセスから分離し、インスタンスの再起動後もキャッシュを有効にします。 + インスタンスに障害が発生した場合、Amazon DocumentDB は、他のアベイラビリティーゾーンで作成する最大 15 個の Amazon DocumentDB レプリカの 1 つに自動的にフェイルオーバーします。レプリカがプロビジョニングされていない場合に障害が発生すると、Amazon DocumentDB は自動的に新しい Amazon DocumentDB インスタンスの作成を試みます。 + Amazon DocumentDB のバックアップ機能により、クラスターのポイントインタイムリカバリが可能です。この機能によって、最大 5 分前まで、保持期間内の任意の時点にクラスターを復元させることができます。自動バックアップ保持期間は、最大 35 日間まで設定できます。自動化されたバックアップは、99.999999999% の耐久性を持つように設計された Amazon S3 (Amazon Simple Storage Service) に保存されます。Amazon DocumentDB バックアップは自動、増分、継続的であり、クラスターのパフォーマンスへの影響はありません。 + Amazon DocumentDB では、 AWS Key Management Service () を使用して作成および管理するキーを使用してデータベースを暗号化できますAWS KMS。Amazon DocumentDB 暗号化を使用して実行されているデータベースクラスターでは、基盤となるストレージに保存されている保管中のデータは暗号化されます。同じクラスター内の自動バックアップ、スナップショット、およびレプリカも暗号化されます。 + Amazon DocumentDB は、「連邦リスク承認管理プログラム (FedRAMP)」の認可事業者です。これには、 AWS GovCloud (米国) リージョンの FedRAMP High 認可と AWS 、米国東部/西部リージョンの FedRAMP Moderate 認可があります。 AWS とコンプライアンスの取り組みの詳細については、[AWS 「コンプライアンスプログラムによる対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/)」を参照してください。 AWS サービスを初めて使用する場合は、次のリソースを使用して詳細を確認してください。 + AWS は、コンピューティング、データベース、ストレージ、分析、その他の機能のためのサービスを提供します。すべての AWS サービスの概要については、[「Amazon Web Services によるクラウドコンピューティング](https://aws.amazon.com/what-is-aws/)」を参照してください。 + AWS は、多数のデータベースサービスを提供します。使用している環境に最適なサービスに関するガイダンスについては、「[AWSでのデータベース](https://aws.amazon.com/products/databases/)」を参照してください。 ## クラスター *クラスター* は、0 ～ 16 のインスタンスと、これらのインスタンスのデータを管理する 1 つのクラスターストレージボリュームで構成されます。すべての書き込みはプライマリインスタンスを介して行われます。すべてのインスタンス (プライマリとレプリカ) は読み込みをサポートします。クラスターのデータはクラスターボリュームに保存され、3 つの異なるアベイラビリティーゾーンにコピーが保存されます。 ![\[アベイラビリティーゾーン 1 のプライマリインスタンスを含む Amazon DocumentDB クラスター、およびゾーン 2 と 3 のレプリカのクラスターボリュームへの書き込み。\]](http://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/images/how-it-works-01c.png) Amazon DocumentDB 5.0 インスタンスベースのクラスターは、Amazon DocumentDB 標準と Amazon DocumentDB I/O 最適化の 2 つの Amazon DocumentDB ストレージ設定をサポートしています。詳細については、「[Amazon DocumentDB クラスターストレージ設定](db-cluster-storage-configs.md)」を参照してください。 ## インスタンス Amazon DocumentDB インスタンスは、クラウド内の独立したデータベース環境です。インスタンスには、複数のユーザーが作成したデータベースを含めることができます。または を使用してインスタンスを作成および変更できます AWS マネジメントコンソール AWS CLI。 インスタンスの計算とメモリの容量は、*インスタンスクラス* によって決まります。お客様のニーズに最も合うインスタンスを選択できます。時間の経過とともにニーズが変化した場合は、別のインスタンスクラスを選択できます。インスタンスクラスの仕様については、「[インスタンスクラスの仕様](db-instance-classes.md#db-instance-class-specs)」を参照してください。 Amazon DocumentDB インスタンスは、Amazon VPC 環境でのみ実行されます。Amazon VPC により仮想ネットワーク環境を管理できます。独自の IP アドレスの範囲を選択し、サブネットを作成して、ルーティングおよびアクセスコントロールリスト (ACL) を設定できます。 Amazon DocumentDB インスタンスを作成する前に、クラスターを作成してインスタンスを含める必要があります。 すべてのインスタンスクラスがすべてのリージョンでサポートされているわけではありません。次の表では、どのインスタンスクラスが各リージョンでサポートされているかを示しています。 **注記** 各インスタンスクラスの Amazon DocumentDB でサポートされているインスタンスタイプの詳細なリストについては、「[インスタンスクラスの仕様](db-instance-classes.md#db-instance-class-specs)」を参照してください。 **リージョン別のサポートされるインスタンスクラス** | | インスタンスクラス | リージョン | R8G | R6GD | R6G | R5 | R4 | T4G | T3 | サーバーレス | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 米国東部 (オハイオ) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート | | 米国東部 (バージニア北部) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート | | 米国西部 (オレゴン) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート | | アフリカ (ケープタウン) | | | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | 南米 (サンパウロ) | | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | アジアパシフィック (香港) | | | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | アジアパシフィック (ハイデラバード) | | | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | アジアパシフィック (マレーシア) | | | サポート対象 | | | サポート対象 | サポート | | | アジアパシフィック (ムンバイ) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | アジアパシフィック (大阪) | | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート | | | アジアパシフィック (ソウル) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | アジアパシフィック (シドニー) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | アジアパシフィック (ジャカルタ) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート | | | アジアパシフィック (メルボルン) | | | サポート対象 | サポート対象 | | サポート対象 | サポート | | | アジアパシフィック (シンガポール) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | アジアパシフィック (タイ) | | | サポート対象 | | | サポート対象 | サポート対象 | | | アジアパシフィック (東京) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | カナダ (中部) | | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | 欧州 (フランクフルト) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | 欧州 (チューリッヒ) | | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | | | 欧州 (アイルランド) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | 欧州 (ロンドン) | | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | 欧州 (ミラノ) | | | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | 欧州 (パリ) | | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | 欧州 (スペイン) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | 欧州 (ストックホルム) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | | | メキシコ (中部) | | | サポート対象 | | | サポート対象 | サポート対象 | | | 中東 (アラブ首長国連邦) | | | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | 中国 (北京) | | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | 中国 (寧夏) | | | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート対象 | | イスラエル (テルアビブ) | | | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | AWS GovCloud (米国西部) | サポート対象 | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | | AWS GovCloud (米国東部) | | サポート対象 | サポート対象 | サポート対象 | | サポート対象 | サポート対象 | サポート | ## リージョンとアベイラビリティーゾーン リージョンとアベイラビリティーゾーンは、クラスターとインスタンスの物理的な場所を定義します。 ### Regions AWS クラウドコンピューティングリソースは、世界中のさまざまな地域 (北米、欧州、アジアなど) にある高可用性データセンター施設に収容されています。各データセンターの場所は、*リージョン*と呼ばれます。 各 AWS リージョンは、他の AWS リージョンから完全に分離されるように設計されています。各リージョン内には複数のアベイラビリティーゾーンがあります。別のアベイラビリティーゾーンでノードを起動して、最大限の耐障害性を実現できます。次の図は、 AWS リージョンとアベイラビリティーゾーンの仕組みの概要を示しています。 ![\[Amazon DocumentDB の AWS リージョンとアベイラビリティーゾーンの概要。\]](http://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/images/docdb-regions-and-azs.png) ### アベイラビリティーゾーン 各 AWS リージョンには、*アベイラビリティーゾーンと呼ばれる複数の異なる場所が含まれています*。各アベイラビリティーゾーンは、他のアベイラビリティーゾーンにおける障害の影響は受けず、同じリージョン内の他のアベイラビリティーゾーンには、低コスト、低レイテンシーでネットワーク接続できるように設計されています。複数のアベイラビリティーゾーンで特定のクラスターのインスタンスを起動することにより、アベイラビリティーゾーンが失敗するというまれなイベントからアプリケーションを保護できます。 Amazon DocumentDB アーキテクチャは、ストレージとコンピューティングを分離します。ストレージレイヤーの場合、Amazon DocumentDB は 3 つの AWS アベイラビリティーゾーンにデータの 6 つのコピーをレプリケートします。例えば、2 つのアベイラビリティーゾーンのみをサポートするリージョンで Amazon DocumentDB クラスターを起動している場合、データストレージは 3 つのアベイラビリティーゾーンにわたって 6 つの方法でレプリケートされますが、コンピューティングインスタンスは 2 つのアベイラビリティーゾーンでしか使用できません。 次の表に、特定の でクラスターのコンピューティングインスタンスをプロビジョニング AWS リージョン するために使用できるアベイラビリティーゾーンの数を示します。 | リージョン名 | リージョン | アベイラビリティーゾーン (コンピューティング) | | --- | --- | --- | | 米国東部 (オハイオ) | `us-east-2` | 3 | | 米国東部 (バージニア北部) | `us-east-1` | 6 | | 米国西部 (オレゴン) | `us-west-2` | 4 | | アフリカ (ケープタウン) | `af-south-1` | 3 | | 南米 (サンパウロ) | `sa-east-1` | 3 | | アジアパシフィック (香港) | `ap-east-1` | 3 | | アジアパシフィック (ハイデラバード) | `ap-south-2` | 3 | | アジアパシフィック (マレーシア) | `ap-southeast-5` | 3 | | アジアパシフィック (ムンバイ) | `ap-south-1` | 3 | | アジアパシフィック (大阪) | `ap-northeast-3` | 3 | | アジアパシフィック (ソウル) | `ap-northeast-2` | 4 | | アジアパシフィック (シンガポール) | `ap-southeast-1` | 3 | | アジアパシフィック (シドニー) | `ap-southeast-2` | 3 | | アジアパシフィック (ジャカルタ) | `ap-southeast-3` | 3 | | アジアパシフィック (メルボルン) | `ap-southeast-4` | 3 | | アジアパシフィック (タイ) | `ap-southeast-7` | 3 | | アジアパシフィック (東京) | `ap-northeast-1` | 3 | | カナダ (中部) | `ca-central-1` | 3 | | 中国 (北京) リージョン | `cn-north-1` | 3 | | 中国 (寧夏) | `cn-northwest-1` | 3 | | 欧州 (フランクフルト) | `eu-central-1` | 3 | | 欧州 (チューリッヒ) | `eu-central-2` | 3 | | 欧州 (アイルランド) | `eu-west-1` | 3 | | 欧州 (ロンドン) | `eu-west-2` | 3 | | 欧州 (ミラノ) | `eu-south-1` | 3 | | 欧州 (パリ) | `eu-west-3` | 3 | | 欧州 (スペイン) | `eu-south-2` | 3 | | 欧州 (ストックホルム) | `eu-north-1` | 3 | | メキシコ (中部) | `mx-central-1` | 3 | | 中東 (アラブ首長国連邦) | `me-central-1` | 3 | | イスラエル (テルアビブ) | `il-central-1` | 3 | | AWS GovCloud (米国西部) | `us-gov-west-1` | 3 | | AWS GovCloud (米国東部) | `us-gov-east-1` | 3 | ## Amazon DocumentDB の料金 Amazon DocumentDB クラスターは、以下のコンポーネントに基づいて請求されます。 + **インスタンス時間 (1 時間あたり)** - インスタンスのインスタンスクラスに基づきます (例: `db.r5.xlarge`)。料金は 1 時間単位で表示されますが、請求の計算方法には秒単位が適用され、時間は 10 進形式で表示されます。Amazon DocumentDB の使用料は 1 秒ごとに課金され、10 分未満の場合は 10 分の料金が発生します。詳細については、「[インスタンスクラスの管理](db-instance-classes.md)」を参照してください。 + **I/O リクエスト (1 か月あたりの 100 万リクエストごと)** - 請求サイクル内で行ったストレージ I/O リクエストの合計数。 + **バックアップストレージ (1 か月当たりの GiB)** - バックアップストレージは、自動データベースバックアップおよび作成したアクティブなデータベースのスナップショットに関連付けられているストレージです。バックアップ保持期間を延長するか、追加のデータベーススナップショットを撮ると、データベースが消費するバックアップストレージが増加します。バックアップストレージは GB 月単位で計算され、1 秒単位は適用されません。詳細については、「[Amazon DocumentDB でのバックアップと復元](backup_restore.md)」を参照してください。 + **データ転送 (GB あたり)** — インターネットまたは他の AWS リージョンとの間でインスタンスとの間で送受信されるデータ転送。 詳細については、「[Amazon DocumentDB の料金](https://aws.amazon.com/documentdb/pricing/)」を参照してください。 ### 無料トライアル Amazon DocumentDB は、1 か月間の無料トライアルを使用して無料でお試しいただけます。詳細については、「[Amazon DocumentDB の料金](https://aws.amazon.com/documentdb/pricing/)」の「無料トライアル」または「[Amazon DocumentDB 無料トライアルのよくある質問](https://aws.amazon.com/documentdb/free-trial/)」を参照してください。 ## モニタリング インスタンスのパフォーマンスと正常性を追跡する方法は複数あります。無料の Amazon CloudWatch サービスを使用して、インスタンスのパフォーマンスと正常性をモニタリングできます。Amazon DocumentDB コンソールでパフォーマンスチャートを見つけることができます。インスタンス、スナップショット、パラメータグループ、セキュリティグループで変更が発生したときに通知される Amazon DocumentDB のイベントにサブスクライブできます。 詳細については次を参照してください: + [Amazon DocumentDB と CloudWatch のモニタリング](cloud_watch.md) + [AWS CloudTrail での Amazon DocumentDB API コールのログ記録](logging-with-cloudtrail.md) ## インターフェイス Amazon DocumentDB を操作するには、 AWS マネジメントコンソール や など、複数の方法があります AWS CLI。 ### AWS マネジメントコンソール AWS マネジメントコンソール はシンプルなウェブベースのユーザーインターフェイスです。プログラミングなしでコンソールからクラスターとインスタンスを管理できます。Amazon DocumentDB コンソールにアクセスするには、 にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) で Amazon DocumentDB コンソールを開きます。 ### AWS CLI AWS Command Line Interface (AWS CLI) を使用して、Amazon DocumentDB クラスターとインスタンスを管理できます。最小限の設定で、使い慣れたターミナルプログラムから、Amazon DocumentDB コンソールで提供されるすべての機能の使用を開始できます。 + をインストールするには AWS CLI、[AWS 「 コマンドラインインターフェイスのインストール](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)」を参照してください。 + Amazon DocumentDB AWS CLI の の使用を開始するには、[AWS Amazon DocumentDB のコマンドラインインターフェイスリファレンス](https://docs.aws.amazon.com/cli/latest/reference/docdb/index.html)」を参照してください。 ### MongoDB ドライバー Amazon DocumentDB クラスターに対するアプリケーションの開発と作成に、MongoDB ドライバーを Amazon DocumentDB で使用することもできます。詳細については、 [TLS が有効な場合の接続](connect_programmatically.md#connect_programmatically-tls_enabled) または [TLS が無効な場合の接続](connect_programmatically.md#connect_programmatically-tls_disabled) の MongoDB シェルタブを参照してください。 ## 次のステップ 前のセクションでは、Amazon DocumentDB が提供する基本的なインフラストラクチャのコンポーネントを紹介しました。次に実行すべきこと 状況に応じて、以下のトピックの 1 つを参照し、使用を開始してください。 + を使用してクラスターとインスタンスを作成して、Amazon DocumentDB の使用を開始します CloudFormation [を使用した Amazon DocumentDB クイックスタート CloudFormation](quick_start_cfn.md)。 + 「[入門ガイド](get-started-guide.md)」の手順を使用してクラスターとインスタンスを作成することにより、Amazon DocumentDB の使用を開始します。 + [Amazon DocumentDB エラスティッククラスターの開始方法](elastic-get-started.md) の手順を使用してエラスティッククラスターを作成することにより、Amazon DocumentDB を開始します。 + [Amazon DocumentDB への移行](docdb-migration.md) のガイダンスを使用して、MongoDB 実装を Amazon DocumentDB に移行します。 # Amazon DocumentDB の 仕組み Amazon DocumentDB (MongoDB 互換) は、フルマネージドの MongoDB と互換性のあるデータベースサービスです。Amazon DocumentDB では、MongoDB と同じアプリケーションコードを実行し、同じドライバーとツールを使用できます。Amazon DocumentDB は MongoDB 3.6、4.0、5.0、8.0 と互換性があります。 **Topics** + [Amazon DocumentDB エンドポイント](#how-it-works.endpoints) + [TLS サポート](#how-it-works.ssl) + [Amazon DocumentDB のストレージ](#how-it-works.storage) + [Amazon DocumentDB レプリケーション](#how-it-works.replication) + [Amazon DocumentDB の信頼性](#how-it-works.reliability) + [読み込み設定のオプション](#durability-consistency-isolation) + [TTL 削除](#how-it-works.ttl-deletes) + [有料リソース](#billing) Amazon DocumentDB を使用するときは、最初に *クラスター* を作成します。クラスターは、ゼロ以上のデータベースインスタンスと、これらのインスタンスのデータを管理する 1 つのクラスターボリュームで構成されます。Amazon DocumentDB の *クラスターボリューム* は、複数のアベイラビリティーゾーンにまたがる仮想データベースストレージボリュームです。アベイラビリティーゾーンごとに、クラスターデータのコピーがあります。 Amazon DocumentDB クラスターは、主要な 2 つのコンポーネントで構成されています。 + **クラスターボリューム** - クラウドネイティブなストレージサービスを使用して、3 つのアベイラビリティーゾーンにわたって 6 つの方法でデータをレプリケートし、耐久性と可用性に優れたストレージを提供します。Amazon DocumentDB クラスターには 1 個のクラスターボリュームがあり、最大 128 TiB のデータを格納できます。 + **インスタンス** - データベースの処理能力を提供し、クラスターストレージボリュームとの間でデータの書き込みと読み取りを行います。Amazon DocumentDB クラスターには 0 ～ 16 のインスタンスを持つことができます。 インスタンスは以下の 2 つのロールのいずれかを提供します。 + **プライマリインスタンス** - 読み書きオペレーションをサポートし、クラスターボリュームに対するすべてのデータ変更を実行します。各 Amazon DocumentDB クラスターには１つのプライマリインスタンスがあります。 + **レプリカインスタンス** - 読み取りオペレーションのみをサポートします。Amazon DocumentDB クラスターには、プライマリインスタンスに加えて 15 個までのレプリカを含めることができます。複数のレプリカがあると、読み取りワークロードを分散させることができます。さらに、別のアベイラビリティーゾーンにレプリカを配置することによって、クラスターの可用性を高めることもできます。 次の図は、Amazon DocumentDB クラスター内のクラスターボリューム、プライマリインスタンス、およびレプリカの関係を示しています。 ![\[クラスター、リーダー、インスタンスのエンドポイントを含む Amazon DocumentDB エンドポイント構成図。\]](http://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/images/docdb-endpoint-types.png) クラスターインスタンスは、同じインスタンスクラスである必要はなく、必要に応じてプロビジョニングおよび終了することができます。このアーキテクチャでは、ストレージとは無関係にクラスターのコンピューティング性能をスケールできます。 アプリケーションがプライマリインスタンスにデータを書き込むときに、プライマリはクラスターボリュームに堅牢な書き込みを実行します。次に、その書き込み (データではありません) の状態がアクティブな各レプリカにレプリケートされます。Amazon DocumentDB レプリカは書き込み処理に関与しないため、Amazon DocumentDB レプリカは読み取りスケーリングにとって有利となります。Amazon DocumentDB レプリカからの読み取りは、最短のレプリカラグで結果整合性があります。通常、プライマリインスタンスがデータを書き込んだ後、100 ミリ秒未満になります。レプリカからの読み込みは、プライマリに書き込まれた順序で読み込まれることが保証されます。レプリカラグは、データ変更のレートによって異なり、書き込みアクティビティが多い期間はレプリカラグが大きくなる可能性があります。詳細については、「[Amazon DocumentDB のメトリクス](cloud_watch.md#cloud_watch-metrics_list)」で `ReplicationLag` のメトリクスを参照してください。 ## Amazon DocumentDB エンドポイント Amazon DocumentDB は複数の接続オプションを提供し、幅広いユースケースに対応します。Amazon DocumentDB クラスターのインスタンスに接続するには、インスタンスのエンドポイントを指定します。*エンドポイント*では、ホストアドレスとポート番号がコロンで区切られています。 リーダーエンドポイントまたはインスタンスエンドポイントに接続する特定のユースケースがない限り、クラスターエンドポイントを使用してレプリカセットモード（「[レプリカセットとしての Amazon DocumentDB に接続する](connect-to-replica-set.md)」を参照）でクラスターに接続することをお勧めします。レプリカにリクエストをルーティングするには、アプリケーションの読み込み整合性要件に合わせて読み取りスケーリングを最大化する、ドライバー読み込み設定を選択します。`secondaryPreferred` 読み込み設定を使用すると、レプリカの読み取りを有効にし、プライマリインスタンスを解放してより多くの作業を行うことができます。 次のエンドポイントは、Amazon DocumentDB クラスターから取得できます。 ### クラスターエンドポイント *クラスターエンドポイント*はクラスターの現在のプライマリインスタンスに接続します。このクラスターエンドポイントは、読み取りと書き込みの両方のオペレーションに使用できます。Amazon DocumentDB クラスターには、厳密には 1 つのクラスターエンドポイントがあります。 クラスターエンドポイントは、クラスターへの読み取り/書き込み接続のフェイルオーバーサポートを提供します。クラスターの現在のプライマリインスタンスが失敗し、クラスターに少なくとも 1 つのアクティブなリードレプリカがある場合、クラスターエンドポイントは自動的に接続リクエストを新しいプライマリインスタンスにリダイレクトします。Amazon DocumentDB クラスターに接続するときは、クラスターエンドポイントを使用し、レプリカセットモード（「[レプリカセットとしての Amazon DocumentDB に接続する](connect-to-replica-set.md)」を参照）でクラスターに接続することをお勧めします。 Amazon DocumentDB クラスターエンドポイントの例を以下に示します。 ``` sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017 ``` 次の接続文字列は、このクラスターエンドポイントを使用した例です。 ``` mongodb://username:password@sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017 ``` クラスターのエンドポイントを見つける方法については、「[クラスターのエンドポイントの検索](db-cluster-endpoints-find.md)」を参照してください。 ### リーダーエンドポイント *リーダーエンドポイント*は、クラスター内の使用可能なすべてのレプリカ間で、読み取り専用接続の負荷分散を行います。クラスターリーダーエンドポイントは、`replicaSet` モードで接続する場合、クラスターエンドポイントとして機能します。つまり、接続文字列では、レプリカセットパラメータは `&replicaSet=rs0` となります。この場合、プライマリに対して書き込みオペレーションを実行できます。ただし、`directConnection=true` を指定してクラスターに接続した後、リーダーエンドポイントへの接続を経由して書き込みオペレーションを実行しようとすると、エラーが発生します。Amazon DocumentDB クラスターには、厳密には 1 つのリーダーエンドポイントがあります。 クラスターに 1 つの (プライマリ) インスタンスのみが含まれている場合、リーダーみエンドポイントはプライマリインスタンスのみに接続します。Amazon DocumentDB クラスターにレプリカインスタンスを追加した場合、リーダーエンドポイントは、アクティブになった時点で新しいレプリカへの読み取り専用接続を開きます。 Amazon DocumentDB クラスターのリーダーエンドポイントの例を以下に示します。 ``` sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com:27017 ``` 次の接続文字列は、リーダーエンドポイントを使用した例です。 ``` mongodb://username:password@sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com:27017 ``` リーダーエンドポイントは、読み込みリクエストではなく、読み取り専用接続の負荷分散を行います。一部のリーダーエンドポイント接続が他のリーダーエンドポイント接続よりも多く使用されている場合、読み込みリクエストはクラスター内のインスタンス間で均等に分散されない可能性があります。クラスターエンドポイントにレプリカセットとして接続し、secondaryPreferred 読み込み設定オプションを使用して、リクエストを分散することをお勧めします。 クラスターのエンドポイントを見つける方法については、「[クラスターのエンドポイントの検索](db-cluster-endpoints-find.md)」を参照してください。 ### インスタンスエンドポイント クラスター内で特定のインスタンスに接続する*インスタンスエンドポイント*です。現在のプライマリインスタンスのインスタンスエンドポイントは、読み込み/書き込みオペレーションに使用できます。ただし、リードレプリカのインスタンスエンドポイントに書き込みオペレーションを実行しようとすると、エラーが発生します。Amazon DocumentDB クラスターは、アクティブなインスタンスごとに 1 つのインスタンスのエンドポイントを持ちます。 インスタンスエンドポイントは、クラスターエンドポイントやリーダーエンドポイントが適切でないシナリオ向けに、特定のインスタンスへの接続の直接制御を提供します。ユースケースの例として、定期的な読み取り専用分析ワークロード用のプロビジョニングがあります。通常よりも大きいレプリカインスタンスのプロビジョニング、インスタンスエンドポイントを使用した新しいより大きなインスタンスへの直接接続、分析クエリの実行を行った後で、インスタンスを終了できます。インスタンスエンドポイントを使用すると、分析トラフィックが他のクラスターインスタンスに影響を与えるのを防ぐことできます。 次の例では、Amazon DocumentDB クラスターの 1 つのインスタンスのインスタンスエンドポイントを示します。 ``` sample-instance.123456789012.us-east-1.docdb.amazonaws.com:27017 ``` 次の接続文字列は、このインスタンスエンドポイントを使用した例です。 ``` mongodb://username:password@sample-instance.123456789012.us-east-1.docdb.amazonaws.com:27017 ``` **注記** プライマリまたはレプリカとしてのインスタンスのロールは、フェイルオーバーイベントが原因で変更される可能性があります。アプリケーションで、特定のインスタンスエンドポイントがプライマリインスタンスであることを前提にしないでください。本番稼働アプリケーションのインスタンスエンドポイントに接続することはお勧めしません。代わりに、クラスターエンドポイントを使用し、レプリカセットモード（「[レプリカセットとしての Amazon DocumentDB に接続する](connect-to-replica-set.md)」を参照）でクラスターに接続することをお勧めします。インスタンスのフェイルオーバー優先度をより高度に制御する方法については、「[Amazon DocumentDB クラスターの耐障害性について理解する](db-cluster-fault-tolerance.md)」を参照してください。 クラスターのエンドポイントを見つける方法については、「[インスタンスのエンドポイントの検索](db-instance-endpoint-find.md)」を参照してください。 ### レプリカセットモード レプリカセット名 `rs0` を指定して、レプリカセットモードで Amazon DocumentDB クラスターエンドポイントに接続できます。レプリカセットモードで接続すると、[読み取り保証]、[書き込み保証]、および [読み取り設定] のオプションを指定できます。詳細については、「[読み込み整合性](#durability-consistency-isolation.read-consistency)」を参照してください。 レプリカセットモードで接続する接続文字列の例を次に示します。 ``` mongodb://username:password@sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017/?replicaSet=rs0 ``` レプリカセットモードで接続するときは、Amazon DocumentDB クラスターはドライバーとクライアントに対してレプリカセットとして表示されます。Amazon DocumentDB クラスターに対して追加、削除したインスタンスは、レプリカセット設定に自動的に反映されます。 各 Amazon DocumentDB クラスターは、デフォルト名が `rs0` の 1 つのレプリカセットで構成されます。レプリカセットの名前を変更することはできません。 レプリカセットモードでのクラスターエンドポイントへの接続は、一般的な使用に推奨される方法です。 **注記** Amazon DocumentDB クラスター内のすべてのインスタンスは、同じ TCP ポートで接続をリッスンします。 ## TLS サポート TLS (Transport Layer Security) を使用した Amazon DocumentDB への接続方法については、「[転送中のデータの暗号化](security.encryption.ssl.md)」を参照してください。 ## Amazon DocumentDB のストレージ Amazon DocumentDB のデータは *クラスターボリューム* に保存されます。これは、SSD (Solid State Drive) を使用する単一の仮想ボリュームです。クラスターボリュームはお客様のデータの 6 つのコピーで構成されます。これらのデータは、単一の AWS リージョンの複数のアベイラビリティーゾーン間で自動的にレプリケートされます。このレプリケーションにより、データの高い耐久性が保証され、データ損失の可能性が低くなります。また、データのコピーが他のアベイラビリティーゾーンにすでに存在するため、フェイルオーバー中のクラスターの可用性が高まります。これらのコピーは、継続して Amazon DocumentDB クラスター内のインスタンスに対するデータリクエストを処理できます。 ### データストレージに対する請求方法 Amazon DocumentDB は、データ量が増えるにつれて、クラスターボリュームのサイズを自動的に増やします。Amazon DocumentDB クラスターボリュームは最大サイズの 128 TiB まで拡張できますが、Amazon DocumentDBクラスターボリュームで使用する領域に対してのみ課金されます。Amazon DocumentDB 4.0 以降では、コレクションやインデックスの削除などでのデータを削除すると、割り当てられた領域全体が相応に減少します。したがって、不要になったコレクション、インデックス、データベースを削除することで、ストレージ料金を削減できます。Amazon DocumentDB バージョン 3.6 では、データを削除したときに解放されたスペースをクラスターボリュームで再利用できますが、ボリューム自体のサイズが小さくなることはありません。バージョン 3.6 での結果として、解放された領域が再利用されていても、コレクションやインデックスを削除したときにストレージの変更が見られない場合があります。 **注記** Amazon DocumentDB 3.6 では、ストレージコストは「高水準点 (high water mark)」 (任意の時点で Amazon DocumentDB クラスター用に割り当てられた最大量) に基づきます。大量の一時情報を作成したり、古い不要データの削除前に新規データを大量にロードする ETL プラクティスを避けることによってコストを管理できます。Amazon DocumentDB クラスターからデータを削除したことによって大量の割り当て済み未使用領域が発生した場合に、高水準点をリセットするには、`mongodump` や `mongorestore` などのツールを使用して論理データダンプを作成し、新しいクラスターに復元する必要があります。スナップショットを作成および復元しても、割り当てられたストレージは削減されません。これは、基になるストレージの物理的なレイアウトが、復元されたスナップショットでも変更されないためです。 **注記** `mongodump` や `mongorestore` などのユーティリティを使用すると、ストレージボリュームに対して読み書きするデータのサイズに応じた I/O 料金が発生します。 Amazon DocumentDB データストレージおよび I/O の料金に関する情報は、「[Amazon DocumentDB (MongoDB 互換性) の料金](https://aws.amazon.com/documentdb/pricing)] と [[料金のよくある質問](https://aws.amazon.com/documentdb/faqs/#Pricing)」を参照してください。 ## Amazon DocumentDB レプリケーション Amazon DocumentDB クラスターでは、各レプリカインスタンスが独立したエンドポイントを公開します。これらのレプリカエンドポイントは、クラスターボリュームのデータへの読み取り専用アクセスを提供します。また、複数のレプリケートされたインスタンス経由で、データの読み取りワークロードをスケールできます。さらに、データ読み取りのパフォーマンスを向上させ、Amazon DocumentDB クラスター内のデータの可用性を高めるためにも有効です。Amazon DocumentDB レプリカはフェイルオーバーターゲットでもあり、Amazon DocumentDB クラスターのプライマリインスタンスに障害が発生した場合は迅速に昇格されます。 ## Amazon DocumentDB の信頼性 Amazon DocumentDB は、信頼性、耐久性、および耐障害性を持つように設計されています。(可用性を高めるため、Amazon DocumentDB クラスターを設定し、異なるアベイラビリティーゾーンに複数のレプリカインスタンスを存在させる必要があります。) Amazon DocumentDB には、信頼性の高いデータベースソリューションとなるいくつかの自動機能も含まれています。 ### ストレージの自動修復 Amazon DocumentDB では、データの複数のコピーを 3 つのアベイラビリティーゾーンに保持し、ストレージの障害によってデータが失われる可能性を最小限に抑えます。Amazon DocumentDB は、クラスターボリュームの障害を自動的に検出します。クラスターボリュームのセグメントで障害が発生すると、Amazon DocumentDB はすぐにそのセグメントを修復します。クラスターボリュームを構成する他のボリュームからのデータを使用して、修復されたセグメントのデータが最新であるようにします。その結果、Amazon DocumentDB ではデータ損失が回避され、インスタンス障害から回復するためのポイントインタイム復元を実行する必要性が低減します。 ### 存続できるキャッシュのウォームアップ Amazon DocumentDB はそのページキャッシュをデータベースとは別のプロセスで管理するため、ページキャッシュはデータベースとは無関係に存続できます。予期できないデータベース障害が発生した場合でも、ページキャッシュはメモリに保持されます。これにより、バッファプールはデータベースの再起動時に最新の状態にウォームアップされます。 ### クラッシュ回復 Amazon DocumentDB は、クラッシュからほぼ瞬時に回復し、アプリケーションデータを提供し続けるように設計されています。Amazon DocumentDB は、クラッシュ回復を並列スレッドで非同期に実行します。これにより、クラッシュのほぼ直後にデータベースを開き、使用できるようにします。 ### リソースガバナンス Amazon DocumentDB は、ヘルスチェックなど、サービス内で重要なプロセスを実行するために必要なリソースを保護します。これを行うには、インスタンスのメモリ負荷が高い場合、Amazon DocumentDB はリクエストをスロットルします。その結果、一部のオペレーションは、メモリ負荷が低下するのを待つためにキューに入れられる場合があります。メモリ負荷が続くと、キューに入れられたオペレーションがタイムアウトすることがあります。次の CloudWatch メトリクスを使用して、メモリ不足によるサービススロットリングオペレーションを監視できます: `LowMemThrottleQueueDepth`、`LowMemThrottleMaxQueueDepth`、`LowMemNumOperationsThrottled`、`LowMemNumOperationsTimedOut`。詳細については、「CloudWatch によるAmazon DocumentDB のモニタリング」を参照してください。LowMem CloudWatch メトリクスの結果として、インスタンスに持続的なメモリ負荷が見られる場合は、インスタンスをスケールアップしてワークロードに追加のメモリを提供することをお勧めします。 ## 読み込み設定のオプション Amazon DocumentDB は、3 つのアベイラビリティーゾーンにわたってデータを 6 回レプリケートするクラウドネイティブな共有ストレージサービスを使用して、高レベルの耐久性を提供します。Amazon DocumentDB は、耐久性を実現するためにデータを複数のインスタンスにレプリケートすることに依存しません。クラスターのデータは、1 つのインスタンスが含まれているか、15 個のインスタンスが含まれているかにかかわらず、耐久性に優れています。 **Topics** + [書き込みの耐久性](#durability-consistency-isolation.write-durability) + [読み込みの分離](#durability-consistency-isolation.read-isolation) + [読み込み整合性](#durability-consistency-isolation.read-consistency) + [高可用性](#durability-consistency-isolation.high-availability) + [読み取りスケーリング](#durability-consistency-isolation.scaling-reads) ### 書き込みの耐久性 Amazon DocumentDB は、独自の分散型の耐障害性がある自己修復機能を備えたストレージシステムを使用します。このシステムは、データの 6 つのコピー (V=6) を 3 つの AWS アベイラビリティーゾーンにレプリケートして、高可用性と耐久性を実現します。Amazon DocumentDB はデータを書き込む際、クライアントへの書き込みを確認する前に、すべての書き込みが大半のノードに永続的にレコードされることを確認します。3 ノードの MongoDB レプリカセットを実行している場合は、書き込み確認として `{w:3, j:true}` を使用すると、Amazon DocumentDB と比較したときに可能な限り最高の設定を得られます。 Amazon DocumentDB クラスターへの書き込みは、クラスターのライターインスタンスによって処理される必要があります。リーダーに書き込もうとすると、エラーが発生します。Amazon DocumentDB プライマリインスタンスからの確認済みの書き込みは耐久性が高く、ロールバックすることはできません。Amazon DocumentDB はデフォルトで高い耐久性に優れており、耐久性に優れない書き込みオプションはサポートされていません。耐久性レベルを変更することはできません (これは、書き込みについてです)。Amazon DocumentDB は w=anything を無視し、事実上 w: 3 と j: true となります。この設定を減らすことはできません。 Amazon DocumentDB アーキテクチャではストレージとコンピューティングが分離されているため、単一インスタンスのクラスターは高い耐久性を持ちます。耐久性はストレージレイヤーで処理されます。その結果、1 つのインスタンスと 3 つのインスタンスを持つ Amazon DocumentDB クラスターは、同じレベルの耐久性を実現します。データの高い耐久性を保持しながら、具体的なユースケースに対してクラスターを設定できます。 Amazon DocumentDB クラスターへの書き込みは、1 つのドキュメント内でアトミックです。 Amazon DocumentDB は `wtimeout` オプションをサポートしておらず、値が指定された場合はエラーを返しません。プライマリ Amazon DocumentDB インスタンスへの書き込みは、無期限にブロックしないことが保証されます。 ### 読み込みの分離 Amazon DocumentDB インスタンスからの読み取りでは、クエリが開始される前に、耐久性があるデータのみが返されます。読み込みで、クエリの実行が開始された後で変更されたデータが返されることはなく、どのような状況でもダーティーリードが可能になることもありません。 ### 読み込み整合性 Amazon DocumentDB クラスターから読み取られたデータは耐久性があり、ロールバックされません。Amazon DocumentDB 読み取りの読み取り整合性は、リクエストまたは接続の読み取り設定を指定して変更できます。Amazon DocumentDB は、耐久性に優れない読み取りオプションをサポートしていません。 Amazon DocumentDB クラスターのプライマリインスタンスからの読み取りは、通常のオペレーション条件下では整合性が高く、書き込み後読み取りの整合性を実現します。書き込みとそれ以降の読み取りの間にフェイルオーバーイベントが発生した場合、システムは高い整合性を持たない読み取りを一時的に返すことがあります。リードレプリカからのすべての読み取りは、結果的に整合性を持ち、同じ順序でデータを返します。レプリカラグは多くの場合、100 ミリ秒未満です。 #### Amazon DocumentDB 読み取り設定 Amazon DocumentDB は、レプリカセットモードのクラスターエンドポイントからデータを読み取るときのみ、読み取り設定オプションをサポートします。読み取り設定オプションの設定により、MongoDB クライアントまたはドライバーが Amazon DocumentDB クラスターでインスタンスに読み取りリクエストをルーティングする方法に影響が生じます。特定のクエリ用に読み込み設定オプションを指定するか、MongoDB ドライバーの全般オプションとして指定できます。(読み込み設定オプションの設定方法については、クライアントまたはドライバーのドキュメントを参照してください。) クライアントまたはドライバーがレプリカセットモードの Amazon DocumentDB クラスターエンドポイントに接続していない場合、読み取り設定の指定結果は定義されていません。 Amazon DocumentDB は、読み取り設定としての *タグセット* の設定はサポートしていません。 **サポートされている読み込み設定オプション** + **`primary`** - `primary` 読み取り設定を指定すると、すべての読み取りがクラスターのプライマリインスタンスにルーティングされます。プライマリインスタンスが使用できない場合、読み込みオペレーションは失敗します。`primary` 読み込み設定により、書き込み後読み取りの整合性が得られ、高可用性および読み込みスケーリングよりも書き込み後読み取りの整合性を優先するユースケースに適しています。 次の例では、`primary` 読み取り設定を指定します。 ``` db.example.find().readPref('primary') ```   + **`primaryPreferred`** - `primaryPreferred` 読み取り設定を指定すると、通常のオペレーションでは読み取りがプライマリインスタンスにルーティングされます。プライマリフェイルオーバーが発生した場合、クライアントはレプリカにリクエストをルーティングします。`primaryPreferred` 読み取り設定により、通常のオペレーションで書き込み後読み取り整合性と、フェイルオーバーイベント中の結果整合性のある読み込みが得られます。`primaryPreferred` 読み取り設定は、読み込みスケーリングよりも書き込み後読み取り整合性を優先するが、それでも高可用性を必要とするユースケースに適しています。 次の例では、`primaryPreferred` 読み取り設定を指定します。 ``` db.example.find().readPref('primaryPreferred') ```   + **`secondary`** - `secondary` 読み取り設定を指定すると、読み取りはレプリカのみにルーティングされ、プライマリインスタンスにルーティングされることはありません。クラスター内のレプリカインスタンスがない場合、読み込みリクエストは失敗します。`secondary` 読み取り設定では、結果整合性のある読み込みが得られ、高可用性および書き込み後の読み取り整合性よりもプライマリインスタンスの書き込みスループットを優先するユースケースに適しています。 次の例では、`secondary` 読み取り設定を指定します。 ``` db.example.find().readPref('secondary') ```   + **`secondaryPreferred`** - `secondaryPreferred` 読み取り設定を指定すると、1 つ以上のレプリカがアクティブになったときに、読み取りはリードレプリカにルーティングされます。クラスター内にアクティブなレプリカインスタンスがない場合、読み取りリクエストはプライマリインスタンスにルーティングされます。`secondaryPreferred` 読み取り設定では、読み取りがリードレプリカによって対応されたときに、結果整合性のある読み込みが得られます。これにより、読み取りがプライマリインスタンスによって処理されたときに (フェイルオーバーイベントがなければ)、書き込み後読み取り整合性が得られます。`secondaryPreferred` 読み取り設定は、書き込み後読み取り整合性よりも読み取りスケーリングや高可用性を優先するユースケースに適しています。 次の例では、`secondaryPreferred` 読み取り設定を指定します。 ``` db.example.find().readPref('secondaryPreferred') ```   + **`nearest`** - `nearest` 読み取り設定を指定すると、クライアントと Amazon DocumentDB クラスター内のすべてのインスタンス間で測定されたレイテンシーのみに基づいて、読み取りがルーティングされます。`nearest` 読み取り設定では、読み取りがリードレプリカによって対応されたときに、結果整合性のある読み込みが得られます。これにより、読み取りがプライマリインスタンスによって処理されたときに (フェイルオーバーイベントがなければ)、書き込み後読み取り整合性が得られます。`nearest` 読み取り設定は、書き込み後読み取り整合性と読み込みスケーリングよりも、可能な限り低い読み取りレイテンシーと高可用性の達成を優先するユースケースに適しています。 次の例では、`nearest` 読み取り設定を指定します。 ``` db.example.find().readPref('nearest') ``` ### 高可用性 Amazon DocumentDB は、レプリカをプライマリインスタンスのフェイルオーバーターゲットとして使用して、可用性の高いクラスター設定をサポートします。プライマリインスタンスが失敗すると、Amazon DocumentDB レプリカが新しいプライマリとして昇格します。ここでは、プライマリインスタンスに対して行われた読み取り要求と書き込み要求が失敗して例外が発生するときに、短時間の中断が発生します。 Amazon DocumentDB クラスターにレプリカが含まれていない場合は、障害の発生時にプライマリインスタンスが再作成されます。ただし、Amazon DocumentDB レプリカの昇格は、プライマリインスタンスを再作成するよりもより高速です。したがって、1 つ以上の Amazon DocumentDB レプリカをフェイルオーバーターゲットとして作成することが推奨されます。 フェイルオーバーターゲットとして使用することを目的としたレプリカは、プライマリインスタンスと同じインスタンスのものである必要があります。これらは、プライマリとは別のアベイラビリティーゾーンでプロビジョニングする必要があります。フェイルオーバーターゲットとして設定されるレプリカを制御できます。高可用性のための Amazon DocumentDB の設定に関するベストプラクティスについては、「[Amazon DocumentDB クラスターの耐障害性について理解する](db-cluster-fault-tolerance.md)」を参照してください。 ### 読み取りスケーリング Amazon DocumentDB レプリカは、読み取りスケーリングに最適です。これらは、クラスターボリュームでの読み取りオペレーション専用です。つまり、レプリカは書き込みを処理しません。データのレプリケーションは、インスタンス間ではなくクラスターボリューム内で行われます。したがって、各レプリカのリソースはクエリの処理専用となり、データのレプリケートおよび書き込み用とはなりません。 アプリケーションがより多くの読み取り容量を必要とする場合、すぐにクラスターにレプリカを追加できます (通常は 10 分未満)。読み取り容量要件が減少した場合、不要なレプリカを削除できます。Amazon DocumentDB レプリカを使用すると、必要な読み取り容量のみのお支払いで済みます。 Amazon DocumentDB は、読み取り設定オプションの使用を通じて、クライアント側の読み取りスケーリングをサポートします。詳細については、「[Amazon DocumentDB 読み取り設定](#durability-consistency-isolation.read-preferences)」を参照してください。 ## TTL 削除 バックグラウンドプロセスによって達成された TTL インデックスエリアからの削除は、ベストエフォートであり、特定の期間内に保証されるものではありません。インスタンスサイズ、インスタンスリソースの使用率、ドキュメントサイズ、全体的なスループットなどの要因は、TTL 削除のタイミングに影響を与える可能性があります。 TTL モニタがドキュメントを削除すると、削除ごとに IO コストが発生するため、請求額が増加します。スループットおよび TTL 削除のレートが増加した場合、IO 使用量が増加するため、請求の増加が予想されます。 既存のコレクションに TTL インデックスを作成する場合、インデックスを作成する前に、期限切れのドキュメントをすべて削除する必要があります。現在の TTL 実装は、コレクション内のドキュメントのごく一部を削除するために最適化されています。これは、最初からコレクションでTTLが有効化されていた場合であり、一度に多数のドキュメントを削除する必要がある場合、必要以上に高い IOPS が発生する可能性があるからです。 TTL インデックスを作成してドキュメントを削除する代わりに、時間に基づいてドキュメントをコレクションにセグメント化し、ドキュメントが不要になったときにそれらのコレクションをドロップすることができます。例えば、週に 1 つのコレクションを作成し、IO コストをかけずにドロップできます。これは、TTL インデックスを使用するよりもコスト効率が大幅に向上します。 ## 有料リソース ### 有料 Amazon DocumentDB リソースの特定 Amazon DocumentDB はフルマネージドデータベースサービスであるため、インスタンス、ストレージ、I/O、バックアップ、およびデータ転送が有料です。詳細については、「[Amazon DocumentDB (MongoDB 互換) の料金](https://aws.amazon.com/documentdb/pricing/)」を参照してください。 アカウント内の請求対象リソースを検出し、そのリソースを削除する場合は、 AWS マネジメントコンソール または を使用できます AWS CLI。 #### の使用 AWS マネジメントコンソール を使用して AWS マネジメントコンソール、特定の に対してプロビジョニングした Amazon DocumentDB クラスター、インスタンス、スナップショットを検出できます AWS リージョン。 **クラスター、インスタンス、およびスナップショットを検出するには** 1. にサインインし AWS マネジメントコンソール、[https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) で Amazon DocumentDB コンソールを開きます。 1. デフォルトリージョン以外のリージョンで請求対象リソースを検出するには、画面の右上隅で、検索 AWS リージョン する を選択します。 ![\[リージョンセレクタ上のバージニア北部リージョン。\]](http://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/images/db-cluster-console-region.png) 1. ナビゲーションペインで、該当する有料リソースのタイプ ([**クラスター**]、[**インスタンス**]、または [**スナップショット**]) を選択します。 ![\[ナビゲーションペインにクラスター、インスタンス、およびスナップショットが表示されているコンソールのスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/documentdb/latest/developerguide/images/db-navigation-pane-clusters-instances-snapshots.png) 1. そのリージョンについてプロビジョニングされたすべてのクラスター、インスタンス、またはスナップショットが右側のペインに表示されます。クラスター、インスタンス、およびスナップショットにたいして料金が発生します。 #### の使用 AWS CLI を使用して AWS CLI、特定の に対してプロビジョニングした Amazon DocumentDB クラスター、インスタンス、スナップショットを検出できます AWS リージョン。 **クラスターおよびインスタンスを見つけるには** 次のコードは、指定されたリージョンのすべてのクラスターとインスタンスをリスト表示しています。デフォルトのリージョンでクラスターとインスタンスを検索する場合は、`--region` パラメータを省略できます。 **Example** Linux、macOS、Unix の場合: ``` aws docdb describe-db-clusters \ --region us-east-1 \ --query 'DBClusters[?Engine==`docdb`]' | \ grep -e "DBClusterIdentifier" -e "DBInstanceIdentifier" ``` Windows の場合: ``` aws docdb describe-db-clusters ^ --region us-east-1 ^ --query 'DBClusters[?Engine==`docdb`]' | ^ grep -e "DBClusterIdentifier" -e "DBInstanceIdentifier" ``` このオペレーションによる出力は、次のようになります。 ``` "DBClusterIdentifier": "docdb-2019-01-09-23-55-38", "DBInstanceIdentifier": "docdb-2019-01-09-23-55-38", "DBInstanceIdentifier": "docdb-2019-01-09-23-55-382", "DBClusterIdentifier": "sample-cluster", "DBClusterIdentifier": "sample-cluster2", ``` **スナップショットを見つけるには** 次のコードは、指定されたリージョンのすべてのスナップショットをリスト表示しています。デフォルトのリージョンでスナップショットを検索する場合は、`--region` パラメータを省略できます。 Linux、macOS、Unix の場合: ``` aws docdb describe-db-cluster-snapshots \ --region us-east-1 \ --query 'DBClusterSnapshots[?Engine==`docdb`].[DBClusterSnapshotIdentifier,SnapshotType]' ``` Windows の場合: ``` aws docdb describe-db-cluster-snapshots ^ --region us-east-1 ^ --query 'DBClusterSnapshots[?Engine==`docdb`].[DBClusterSnapshotIdentifier,SnapshotType]' ``` このオペレーションによる出力は、次のようになります。 ``` [ [ "rds:docdb-2019-01-09-23-55-38-2019-02-13-00-06", "automated" ], [ "test-snap", "manual" ] ] ``` 削除する必要があるのは、`manual` スナップショットのみです。`Automated` スナップショットは、クラスターを削除すると削除されます。 ### 不要な有料リソースの削除 クラスターを削除するには、まずクラスター内のインスタンスをすべて削除する必要があります。 + インスタンスを削除するには、「[Amazon DocumentDB インスタンスの削除](db-instance-delete.md)」を参照してください。 **重要** クラスター内のインスタンスを削除しても、そのクラスターに関連付けられているストレージとバックアップの使用量に対して料金が発生します。すべての課金を停止するには、クラスターと手動スナップショットも削除する必要があります。 + クラスターを削除するには、「[Amazon DocumentDB クラスターの削除](db-cluster-delete.md)」を参照してください。 + 手動スナップショットを削除するには、「[クラスタースナップショットの削除](backup_restore-delete_cluster_snapshot.md)」を参照してください。 # ドキュメントデータベースとは データモデルを正規化された行や列の観点から考えない開発者もいます。通常、アプリケーション層では、データは JSON ドキュメントとして表されます。これは、開発者にとって、データモデルをドキュメントとして考える方が直感的であるためです。 アプリケーションコードで使用するのと同じドキュメントモデル形式を使用してデータをデータベースに保持できるため、ドキュメントデータベースの人気が高まっています。ドキュメントデータベースは、柔軟でアジャイルな開発のための強力で直感的な API を提供します。 **Topics** + [ユースケース](document-database-use-cases.md) + [ドキュメントについて理解する](document-database-documents-understanding.md) + [ドキュメントでの作業](document-database-working-with-documents.md) # ドキュメントデータベースのユースケース ユースケースにより、ドキュメントデータベースが必要か、またはデータを管理するためのその他の種類のデータベースが必要かが決まります。ドキュメントデータベースは、迅速で反復性のある開発のための柔軟なスキーマを必要とするワークロードに適しています。以下では、ドキュメントデータベースに大きな利点があるユースケースの例をいくつか示します。 **Topics** + [ユーザープロファイル](#document-databases-use-cases.user-profiles) + [リアルタイムのビッグデータ](#document-databases-use-cases.big-data) + [コンテンツ管理](#document-databases-use-cases.content-management) ## ユーザープロファイル ドキュメントデータベースには柔軟性が高いスキーマがあるため、属性とデータ値が異なるドキュメントを保存できます。ドキュメントデータベースは、さまざまなユーザーがさまざまな種類の情報を提供するオンラインプロファイルに対する実用的なソリューションです。ドキュメントデータベースを使用して、各ユーザーに固有の属性のみを保存し、各ユーザーのプロファイルを効率的に保存することができます。 ユーザーが自分のプロファイル情報を追加または削除したとします。この場合、ドキュメントは、最近追加された属性とデータを含むか、新しく省略された属性とデータが省略された、更新されたバージョンに簡単に置き換えることができます。ドキュメントデータベースは、このようなレベルの個性や流動性を簡単に管理することができます。 ## リアルタイムのビッグデータ 従来、運用データから情報を抽出する能力は、運用データベースと分析データベースがそれぞれ異なる環境 (運用環境およびビジネス/レポート作成) で維持されているという事実によって妨げられていました。リアルタイムで動作情報を抽出できることは、競争の激しいビジネス環境において非常に重要です。ドキュメントデータベースを使用することで、企業は任意の送信元からの運用データを保存して管理し、同時に分析のため任意の BI エンジンにデータをフィードできます。2 つの環境を持つ必要はありません。 ## コンテンツ管理 コンテンツを効果的に管理するために、さまざまなソースからコンテンツを収集して集計し、お客様に提供する必要があります。ドキュメントデータベースは、柔軟性の高いスキーマがあるため、あらゆる種類のデータの収集および保存に最適です。それらを使用して、イメージ、コメント、ビデオなど、ユーザーが生成したコンテンツを含めて、新しい種類のコンテンツを作成し、組み込むことができます。 # ドキュメントについて理解する ドキュメントデータベースは、セミ構造化データをドキュメントとして格納するために使用されます。リレーショナルデータベースのように、それぞれが固有の固定構造を持つ複数のテーブルにわたってデータを正規化するのではなく、ドキュメントとして格納します。ドキュメントデータベースに保存されているドキュメントは、ネストされたキーと値のペアを使用して、ドキュメントの構造またはスキーマを提供します。ただし、さまざまな種類のドキュメントを同じドキュメントデータベースに保存できるため、形式が異なる類似したデータの処理要件を満たします。たとえば、各ドキュメントは自己記述型であるため、トピック「[ドキュメントデータベースのドキュメントの例](#document-database-documents)」で説明しているオンラインストアの JSON でエンコードされたドキュメントは、同じドキュメントデータベースに保存することができます。 **Topics** + [SQL 用語と非リレーショナル用語の比較](#document-database-sql-vs-nosql-terms) + [シンプルなドキュメント](#document-database-documents-simple) + [埋め込まれたドキュメント](#document-database-documents-embeded) + [ドキュメントデータベースのドキュメントの例](#document-database-documents) + [ドキュメントデータベースの正規化について](#document-database-normalization) ## SQL 用語と非リレーショナル用語の比較 次の表は、SQL データベースによって使用される用語とドキュメントデータベース (MongoDB) で使用される用語を比較したものです。 | SQL | MongoDB | | --- | --- | | [テーブル] | 収集 | | Row | ドキュメント | | 列 | フィールド | | プライマリキー | ObjectId | | [Index] (インデックス) | [Index] (インデックス) | | 表示 | 表示 | | ネストされたテーブルまたはオブジェクト | 埋め込まれたドキュメント | | 配列 | 配列 | ## シンプルなドキュメント ドキュメントデータベースのすべてのドキュメントは自己記述型です。このドキュメントでは、JSON に似た形式のドキュメントを使用しますが、エンコードの他の方法も使用できます。 単純ドキュメントには、ドキュメント内ですべてが同じレベルの 1 つ以上のフィールドがあります。次の例では、フィールド `SSN`、`LName`、`FName`、`DOB`、`Street`、`City`、`State-Province`、`PostalCode`、および `Country` はすべてドキュメント内の兄弟です。 ``` { "SSN": "123-45-6789", "LName": "Rivera", "FName": "Martha", "DOB": "1992-11-16", "Street": "125 Main St.", "City": "Anytown", "State-Province": "WA", "PostalCode": "98117", "Country": "USA" } ``` 情報を単純ドキュメントに整理すると、各フィールドは個別に管理されます。ユーザーのアドレスを取得するには、`Street`、`City`、`State-Province`、`PostalCode`、および `Country` を個別のデータ項目として取得する必要があります。 ## 埋め込まれたドキュメント 複合ドキュメントは、ドキュメント内に埋め込まれたドキュメントを作成してデータを整理します。埋め込まれたドキュメントでは、データをグループまたは個別のデータ項目として管理するために役立ちます。ケース別に、どちらか効率的なほうを選択できます。前の例を使用すると、メインドキュメントに `Address` ドキュメントを埋め込むことができます。この操作を行うと、次のドキュメント構造になります。 ``` { "SSN": "123-45-6789", "LName": "Rivera", "FName": "Martha", "DOB": "1992-11-16", "Address": { "Street": "125 Main St.", "City": "Anytown", "State-Province": "WA", "PostalCode": "98117", "Country": "USA" } } ``` ドキュメント内のデータは、個別のフィールド (`"SSN":`)、埋め込まれたドキュメント (`"Address":`)、または埋め込まれたドキュメントのメンバー (`"Address":{"Street":}`) としてアクセスできるようになりました。 ## ドキュメントデータベースのドキュメントの例 前に説明したように、ドキュメントデータベース内の各ドキュメントは自己記述型であるため、ドキュメントデータベース内のドキュメントの構造は、相互に異なる可能性があります。次の 2 つのドキュメント (1 つは書籍用、もう 1 つは定期刊行物用) は、構造的に異なります。ただし、両方とも同じドキュメントデータベースに存在できます。 書籍ドキュメントの例を次に示します。 ``` { "_id" : "9876543210123", "Type": "book", "ISBN": "987-6-543-21012-3", "Author": { "LName":"Roe", "MI": "T", "FName": "Richard" }, "Title": "Understanding Document Databases" } ``` 2 つの記事を含む定期刊行物の例を以下に示します。 ``` { "_id" : "0123456789012", "Publication": "Programming Today", "Issue": { "Volume": "14", "Number": "09" }, "Articles" : [ { "Title": "Is a Document Database Your Best Solution?", "Author": { "LName": "Major", "FName": "Mary" } }, { "Title": "Databases for Online Solutions", "Author": { "LName": "Stiles", "FName": "John" } } ], "Type": "periodical" } ``` これら 2 つのドキュメントの構造を比較します。リレーショナルデータベースでは、別々の「定期刊行物」と「書籍」テーブル、または `null` の値として「刊行物」、「問題」、「記事」、「MI」など未使用のフィールドを持つ 1 つのテーブルが必要です。ドキュメントデータベースが半構造化され、各ドキュメントが独自の構造を定義しているため、それらの 2 つのドキュメントは `null` フィールドなしで同じドキュメントデータベースに共存できます。ドキュメントデータベースは、スパースデータの処理に適しています。 ドキュメントデータベースに対する開発により、迅速で反復的な開発が可能になります。これは、動的にドキュメントのデータ構造を変更でき、コレクション全体のスキーマを変更する必要がないためです。ドキュメントデータベースが適しているのは、アジャイル開発と動的に変化する環境です。 ## ドキュメントデータベースの正規化について ドキュメントデータベースは正規化されていません。そのため、1 つのドキュメントで見つかったデータを別のドキュメントで繰り返すことができます。さらに、ドキュメント間で一部のデータに相違が発生する場合があります。たとえば、オンラインストアで購入を行い、購入のすべての詳細が 1 つのドキュメントに保存されるシナリオを考えてみます。このドキュメントは、たとえば次の JSON ドキュメントのようになります。 ``` { "DateTime": "2018-08-15T12:13:10Z", "LName" : "Santos", "FName" : "Paul", "Cart" : [ { "ItemId" : "9876543210123", "Description" : "Understanding Document Databases", "Price" : "29.95" }, { "ItemId" : "0123456789012", "Description" : "Programming Today", "Issue": { "Volume": "14", "Number": "09" }, "Price" : "8.95" }, { "ItemId": "234567890-K", "Description": "Gel Pen (black)", "Price": "2.49" } ], "PaymentMethod" : { "Issuer" : "MasterCard", "Number" : "1234-5678-9012-3456" }, "ShopperId" : "1234567890" } ``` この情報は、トランザクションコレクションでドキュメントとして保存されます。後で、1 つのアイテムの購入を忘れていることに気付きます。そのため、再度同じストアにログオンし、別の購入を行います。これもトランザクションコレクションの別のドキュメントとして保存されます。 ``` { "DateTime": "2018-08-15T14:49:00Z", "LName" : "Santos", "FName" : "Paul", "Cart" : [ { "ItemId" : "2109876543210", "Description" : "Document Databases for Fun and Profit", "Price" : "45.95" } ], "PaymentMethod" : { "Issuer" : "Visa", "Number" : "0987-6543-2109-8765" }, "ShopperId" : "1234567890" } ``` この 2 つのドキュメント、つまり名前と買い物客 ID (同じクレジットカードを使用した場合はクレジットカード情報) の冗長性に注目してください。しかし、ストレージは安価であり、各ドキュメントは結合が必要ない単純なキーと値のクエリで迅速に取得できる単一のトランザクションを完全に記録するため、問題はありません。 また、2 つの文書の間には、クレジットカード情報という明らかな相違があります。これは明らかな相違であるのは、各購入で別のクレジットカードを使用した可能性が高いためです。各ドキュメントは、記録されるトランザクションについては正確です。 # ドキュメントでの作業 ドキュメントデータベースとしての Amazon DocumentDB は、JSON データの保存、クエリ実行、インデックス作成を容易にします。Amazon DocumentDB において、コレクションはリレーショナルデータベースのテーブルに似ています。ただし、すべてのドキュメントに適用される単一のスキーマが存在しない点が異なります。コレクションでは、すべてのドキュメントを同じデータベースに保持しながら類似したドキュメントを一緒にグループ化でき、構造が類似している必要はありません。 前のセクションのドキュメント例を使用すると、`reading_material` および `office_supplies` のコレクションがあります。ソフトウェアは、ドキュメントが属するコレクションを適用する必要があります。 以下の例では、MongoDB API を使用して、ドキュメントを追加、クエリ、更新、および削除する方法を示します。 **Topics** + [ドキュメントの追加](#document-database-adding-documents) + [ドキュメントのクエリ](#document-database-queries) + [ドキュメントの更新](#document-database-updating) + [ドキュメントの削除](#document-database-deleting) ## ドキュメントの追加 Amazon DocumentDB では、コレクションにドキュメントを最初に追加したときにデータベースが作成されます。次の例では、`example` という名前のコレクションを `test` データベースに作成しています。これは、クラスターに接続するときのデフォルトのデータベースです。最初のドキュメントの挿入時に接続が暗黙で作成されるため、コレクション名のエラーチェックはありません。したがって、コレクション名にタイプミス (`example` の代わりに `eexample` など) があると、正しいコレクションの代わりに `eexample` コレクションが作成され、このコレクションにドキュメントが追加されます。エラーチェックはアプリケーションで処理する必要があります。 次の例では、MongoDB API を使用してドキュメントを追加します。 **Topics** + [単一のドキュメントの追加](#document-database-adding-documents-single) + [複数のドキュメントの追加](#document-database-adding-documents-multiple) ### 単一のドキュメントの追加 単一のドキュメントをコレクションに追加するには、コレクションに追加したドキュメントで `insertOne( {} )` オペレーションを使用します。 ``` db.example.insertOne( { "Item": "Ruler", "Colors": ["Red","Green","Blue","Clear","Yellow"], "Inventory": { "OnHand": 47, "MinOnHand": 40 }, "UnitPrice": 0.89 } ) ``` このオペレーションによる出力は、次のようになります (JSON 形式)。 ``` { "acknowledged" : true, "insertedId" : ObjectId("5bedafbcf65ff161707de24f") } ``` ### 複数のドキュメントの追加 複数のドキュメントをコレクションに追加するには、コレクションに追加したドキュメントのリストで `insertMany( [{},...,{}] )` オペレーションを使用します。この特定のリストのドキュメントのスキーマは異なりますが、すべてのドキュメントを同じコレクションに追加できます。 ``` db.example.insertMany( [ { "Item": "Pen", "Colors": ["Red","Green","Blue","Black"], "Inventory": { "OnHand": 244, "MinOnHand": 72 } }, { "Item": "Poster Paint", "Colors": ["Red","Green","Blue","Black","White"], "Inventory": { "OnHand": 47, "MinOnHand": 50 } }, { "Item": "Spray Paint", "Colors": ["Black","Red","Green","Blue"], "Inventory": { "OnHand": 47, "MinOnHand": 50, "OrderQnty": 36 } } ] ) ``` このオペレーションによる出力は、次のようになります (JSON 形式)。 ``` { "acknowledged" : true, "insertedIds" : [ ObjectId("5bedb07941ca8d9198f5934c"), ObjectId("5bedb07941ca8d9198f5934d"), ObjectId("5bedb07941ca8d9198f5934e") ] } ``` ## ドキュメントのクエリ ときどきオンラインストアのインベントリを検索し、販売商品を顧客が表示して購入できることを確認する必要があります。コレクションのクエリは、コレクションのすべてのドキュメントを対象とするか、特定の条件を満たすドキュメントのみを対象とするかにかかわらず、比較的簡単です。 ドキュメントのクエリを実行するには、`find()` オペレーションを使用します。この `find()` コマンドには、返すドキュメントを選択するために使用する条件を定義する単一のドキュメントパラメータがあります。`find()` からの出力は、改行のない 1 行のテキストとしてフォーマットされたドキュメントです。読みやすくするために出力ドキュメントをフォーマットするには、`find().pretty()` を使用します。このトピックのすべての例では、`.pretty()` を使用して出力を書式設定しています。 `example` と `insertOne()` の 2 つの演習で `insertMany()` コレクションに挿入した 4 つのドキュメントを使用してください。 **Topics** + [コレクション内のすべてのドキュメントの取得](#document-database-queries-all-documents) + [フィールドの値に一致するドキュメントの取得](#document-database-queries-match-criteria) + [埋め込みドキュメントに一致するドキュメントの取得](#document-database-queries-entire-embedded-document) + [埋め込まれたドキュメントのフィールド値に一致するドキュメントの取得](#document-database-queries-embeded-document-field) + [配列に一致するドキュメントの取得](#document-database-queries-array-match) + [配列値に一致するドキュメントの取得](#document-database-queries-array-value-match) + [演算子を使用したドキュメントの取得](#document-database-query-operators) ### コレクション内のすべてのドキュメントの取得 コレクション内のすべてのドキュメントを取得するには、`find()` オペレーションで、空のクエリドキュメントを指定します。 以下のクエリは、`example` コレクション内のすべてのドキュメントを返します。 ``` db.example.find( {} ).pretty() ``` ### フィールドの値に一致するドキュメントの取得 フィールドおよび値に一致するすべてのドキュメントを取得するには、`find()` オペレーションで、一致するフィールドおよび値を識別するクエリドキュメントを指定します。 上記のドキュメントを使用して、このクエリは、「Item」フィールドが「Pen」に等しいすべてのドキュメントを返します。 ``` db.example.find( { "Item": "Pen" } ).pretty() ``` ### 埋め込みドキュメントに一致するドキュメントの取得 埋め込みドキュメントに一致するすべてのドキュメントを検索するには、`find()` オペレーションで、埋め込みドキュメントの名前と、その埋め込みドキュメントのすべてのフィールドおよび値を識別するクエリドキュメントを指定します。 埋め込みドキュメントに一致するには、そのドキュメントの埋め込みドキュメントの名前が、クエリで指定した名前と同じであることが必要です。さらに、埋め込みドキュメントのフィールドおよび値も、クエリで指定したものと同じであることが必要です。 次のクエリでは、「Poster Paint」ドキュメントのみ返ります。これは、「Pen」の値は「`OnHand`」や「`MinOnHand`」とは異なり、「Spray Paint」には、クエリドキュメントよりもフィールドが 1 つ (`OrderQnty`) 多いためです。 ``` db.example.find({"Inventory": { "OnHand": 47, "MinOnHand": 50 } } ).pretty() ``` ### 埋め込まれたドキュメントのフィールド値に一致するドキュメントの取得 埋め込みドキュメントに一致するすべてのドキュメントを検索するには、`find()` オペレーションで、埋め込みドキュメントの名前と、その埋め込みドキュメントのすべてのフィールドおよび値を識別するクエリドキュメントを指定します。 上記のドキュメントでは、以下のようにクエリで「ドット表記」を使用して埋め込みドキュメントと目的のフィールドを指定しています。埋め込みドキュメント内に他のフィールドがある場合でも、これらに一致するすべてのドキュメントが返されます。クエリは「Poster Paint」と「Spray Paint」を返します。それらはいずれも、指定したフィールドおよび値と一致するためです。 ``` db.example.find({"Inventory.OnHand": 47, "Inventory.MinOnHand": 50 }).pretty() ``` ### 配列に一致するドキュメントの取得 配列に一致するすべてのドキュメントを検索するには、`find()` オペレーションで、目的の配列名とその配列内のすべての値を指定します。クエリは、配列値の名前および順序がクエリで指定したものと一致するすべてのドキュメントを返します。 以下のクエリは「Pen」のみを返します。「Poster Paint」では追加の色 (White) があり、「Spray Paint」では色の順序が異なるためです。 ``` db.example.find( { "Colors": ["Red","Green","Blue","Black"] } ).pretty() ``` ### 配列値に一致するドキュメントの取得 特定の属性配列を含むすべてのドキュメントを見つけるには、`find()` オペレーションで、目的の配列名と値を指定します。 ``` db.example.find( { "Colors": "Red" } ).pretty() ``` 上記のオペレーションは、すべてのドキュメントを返します。3 つのドキュメントのそれぞれで、`Colors` という配列があり、その配列のどこかに「`Red`」という値があるためです。値として「`White`」を指定すると、クエリからは「Poster Paint」のみが返されます。 ### 演算子を使用したドキュメントの取得 以下のクエリは、「`Inventory.OnHand`」値が 50 未満のすべてのドキュメントを返します。 ``` db.example.find( { "Inventory.OnHand": { $lt: 50 } } ) ``` サポートされているクエリ演算子のリストについては、「[クエリおよびプロジェクション演算子](mongo-apis.md#mongo-apis-query)」を参照してください。 ## ドキュメントの更新 通常、ドキュメントは静的ではなく、アプリケーションワークフローの一部として更新されます。以下の例では、ドキュメントを更新する方法のいくつかを示します。 既存のドキュメントを更新するには、`update()` オペレーションを使用します。`update()` オペレーションには 2 つのドキュメントパラメータがあります。最初のドキュメントでは、更新するドキュメントを識別しています。2 番目のドキュメントでは、行う更新を指定しています。 既存のフィールド ( シンプルなフィールド、配列、または埋め込みドキュメントは関係ありません) を更新する場合 フィールド名とその値を指定します。オペレーションの最後では、古いドキュメントのフィールドが新しいフィールドおよび値に置き換えられたようになります。 **Topics** + [既存のフィールドの値の更新](#document-database-updating-existing-fields) + [新しいフィールドの追加](#document-database-updating-adding-field) + [埋め込みドキュメントの置き換え](#document-database-replacing-embedded-document) + [埋め込みドキュメントへの新しいフィールドの挿入](#document-database-updating-adding-field-embedded) + [ドキュメントからのフィールドの削除](#document-database-remove-field) + [複数のドキュメントからのフィールドの削除](#document-database-remove-field-all) ### 既存のフィールドの値の更新 先ほど追加した次の 4 つのドキュメントを以下の更新オペレーションに使用します。 ``` { "Item": "Ruler", "Colors": ["Red","Green","Blue","Clear","Yellow"], "Inventory": { "OnHand": 47, "MinOnHand": 40 }, "UnitPrice": 0.89 }, { "Item": "Pen", "Colors": ["Red","Green","Blue","Black"], "Inventory": { "OnHand": 244, "MinOnHand": 72 } }, { "Item": "Poster Paint", "Colors": ["Red","Green","Blue","Black","White"], "Inventory": { "OnHand": 47, "MinOnHand": 50 } }, { "Item": "Spray Paint", "Colors": ["Black","Red","Green","Blue"], "Inventory": { "OnHand": 47, "MinOnHand": 50, "OrderQnty": 36 } } ``` **シンプルなフィールドを更新するには** シンプルなフィールドを更新するには、`update()` で `$set` を使用してフィールド名と新しい値を指定します。以下の例では、`Item` を「Pen」から「Gel Pen」に変更します。 ``` db.example.update( { "Item" : "Pen" }, { $set: { "Item": "Gel Pen" } } ) ``` このオペレーションの結果は、次のようになります。 ``` { "Item": "Gel Pen", "Colors": ["Red","Green","Blue","Black"], "Inventory": { "OnHand": 244, "MinOnHand": 72 } } ``` **配列を更新するには** 以下の例では、既存の色の配列を、色のリストに `Orange` を含み `White` を含まない新しい配列に置き換えます。新しい色のリストは、`update()` オペレーションで指定された順序になります。 ``` db.example.update( { "Item" : "Poster Paint" }, { $set: { "Colors": ["Red","Green","Blue","Orange","Black"] } } ) ``` このオペレーションの結果は、次のようになります。 ``` { "Item": "Poster Paint", "Colors": ["Red","Green","Blue","Orange","Black"], "Inventory": { "OnHand": 47, "MinOnHand": 50 } } ``` ### 新しいフィールドの追加 1 つ以上の新しいフィールドを追加してドキュメントを変更するには、挿入先のドキュメントと、`$set` 演算子を使用して挿入する新しいフィールドと値を識別するクエリドキュメントで、`update()` オペレーションを使用します。 以下の例では、値 `3.99` を含むフィールド `UnitPrice` を Spray Paints ドキュメントに追加します。値 `3.99` は数字であり、文字列ではありません。 ``` db.example.update( { "Item": "Spray Paint" }, { $set: { "UnitPrice": 3.99 } } ) ``` このオペレーションの結果は、次の (JSON フォーマット) のようになります。 ``` { "Item": "Spray Paint", "Colors": ["Black","Red","Green","Blue"], "Inventory": { "OnHand": 47, "MinOnHand": 50, "OrderQnty": 36 }, "UnitPrice": 3.99 } ``` ### 埋め込みドキュメントの置き換え 埋め込みドキュメントを置き換えてドキュメントを変更するには、`update()` オペレーションで、埋め込みドキュメントと、`$set` 演算子を使用して挿入する新しいフィールドおよび値を識別するドキュメントを指定します。 以下のドキュメントがあるとします。 ``` db.example.insert({ "DocName": "Document 1", "Date": { "Year": 1987, "Month": 4, "Day": 18 } }) ``` **埋め込みドキュメントを置き換えるには** 以下の例では、現在の Date ドキュメントを、フィールド `Month` と `Day` のみを含み `Year` を含まない新しいドキュメントに置き換えます。 ``` db.example.update( { "DocName" : "Document 1" }, { $set: { "Date": { "Month": 4, "Day": 18 } } } ) ``` このオペレーションの結果は、次のようになります。 ``` { "DocName": "Document 1", "Date": { "Month": 4, "Day": 18 } } ``` ### 埋め込みドキュメントへの新しいフィールドの挿入 **埋め込みドキュメントにフィールドを追加するには** 埋め込みドキュメントに 1 つ以上の新しいフィールドを追加してドキュメントを変更するには、`update()` オペレーションで、「ドット表記」を使用して、埋め込みドキュメントと、`$set` 演算子を使用して挿入する新しいフィールドおよび値を識別するドキュメントを指定します。 以下のドキュメントでは、コードに「ドット表記」を使用して `Year` フィールドと `DoW` フィールドを埋め込み `Date` ドキュメントに挿入し、`Words` フィールドを親ドキュメントに挿入しています。 ``` { "DocName": "Document 1", "Date": { "Month": 4, "Day": 18 } } ``` ``` db.example.update( { "DocName" : "Document 1" }, { $set: { "Date.Year": 1987, "Date.DoW": "Saturday", "Words": 2482 } } ) ``` このオペレーションの結果は、次のようになります。 ``` { "DocName": "Document 1", "Date": { "Month": 4, "Day": 18, "Year": 1987, "DoW": "Saturday" }, "Words": 2482 } ``` ### ドキュメントからのフィールドの削除 ドキュメントからフィールドを削除することでドキュメントを変更するには、`update()` オペレーションで、フィールドを削除するドキュメントを識別するクエリドキュメントを指定し、`$unset` 演算子で、削除するフィールドを指定します。 以下の例では、上記のドキュメントから `Words` フィールドを削除します。 ``` db.example.update( { "DocName" : "Document 1" }, { $unset: { Words:1 } } ) ``` このオペレーションの結果は、次のようになります。 ``` { "DocName": "Document 1", "Date": { "Month": 4, "Day": 18, "Year": 1987, "DoW": "Saturday" } } ``` ### 複数のドキュメントからのフィールドの削除 複数のドキュメントからフィールドを削除してドキュメントを変更するには、`update()` オペレーションを使用します (`$unset` 演算子を指定し、`multi` オプションを `true` に設定します)。 次の例では、コレクション例のすべてのドキュメントから `Inventory` フィールドを削除します。ドキュメントに `Inventory` フィールドがない場合、そのドキュメントに対して実行されるアクションはありません。`multi: true` が省略された場合、アクションは条件を満たす最初のドキュメントでのみ実行されます。 ``` db.example.update( {}, { $unset: { Inventory:1 } }, { multi: true } ) ``` ## ドキュメントの削除 データベースからドキュメントを削除するには、`remove()` オペレーションを使用します。これにより、削除するドキュメントを指定します。以下のコードは `example` コレクションから「Gel Pen」を削除します。 ``` db.example.remove( { "Item": "Gel Pen" } ) ``` データベースからすべてのドキュメントを削除するには、`remove()` オペレーションで空のクエリを使用します。 ``` db.example.remove( { } ) ```