Amazon DocumentDB (MongoDB 互換) のよくある質問

Amazon DocumentDB では、ストレージに書き込む際、先行書き込みログの保持のみを行い、バッファページの同期全体の書き込みを必要としません。この耐久性を損なわない最適化の結果、Amazon DocumentDB では、通常は従来のデータベースよりも高速に書き込みを行います。Amazon DocumentDB クラスターは、毎秒数百万回の読み込みを実行するために、最大 15 個までのリードレプリカを使用してスケールアウトできます。

リージョンと料金の最新情報については、Amazon DocumentDB の料金ページを参照してください。

はい、Amazon DocumentDB を 1 か月の無料トライアルで試用することができます。Amazon DocumentDB を利用したことがない場合、1 か月の無料トライアルをご利用いただけます。お客様の組織は、月間 750 時間の t3.medium インスタンスの使用、3,000 万回の IO、5 GB のストレージ、5 GB のバックアップストレージが 30 日間無料でご利用いただけます。1 か月間の無料トライアルが終了するか、使用量が無料許容量を超えた場合は、クラスターをシャットダウンして料金を請求されないようにできます。または、標準のオンデマンド料金で利用を続けることもできます。詳しくは、DocumentDB 無料トライアルのページをご覧ください。

Amazon DocumentDB I/O 最適化は、予測可能なコストが必要な場合や I/O 集約型のアプリケーションが必要な場合に最適です。I/O コストが Amazon DocumentDB データベースの総コストの 25% を超えると予想される場合は、このオプションを使用すると価格パフォーマンスが向上します。開始方法など、詳細については、 Amazon DocumentDB I/O 最適化ドキュメントを参照してください。

30 日に 1 回、既存のデータベースクラスターを Amazon DocumentDB I/O 最適化に切り替えることができます。いつでも Amazon DocumentDB 標準ストレージ設定に戻すことができます。

はい。リージョン間でデータをリプリケーションするために必要な I/O オペレーションの料金は引き続き適用されます。Amazon DocumentDB I/O 最適化は、データリプリケーションとは異なり、読み取りと書き込み I/O オペレーションには課金しません。詳細については、 Amazon DocumentDB 入出力最適化ドキュメントを参照してください。

Amazon DocumentDB エラスティッククラスターは、ペタバイトのストレージ容量で数百万の書き込みと読み取りを処理するようにドキュメントデータベースを弾力的にスケーリングできます。エラスティッククラスターは、基礎とするインフラストラクチャを自動的に管理できるため、インスタンスを作成、削除、アップグレード、スケーリングする必要がなくなり、Amazon DocumentDB の操作を容易にします。

エラスティッククラスターは、Amazon DocumentDB API、SDK、CLI、CloudFormation (CFN)、AWS コンソールで作成できます。クラスターをプロビジョニングするときは、ワークロードに必要なシャード数、およびシャードごとの計算方法を指定します。クラスターを作成したら、エラスティッククラスターの柔軟なスケーラビリティの利用を開始できます。これで、エラスティッククラスターに接続し、アプリケーションからデータを読み書きできるようになりました。エラスティッククラスターには伸縮性 (エラスティック) があります。ワークロードのニーズに応じて、AWS コンソール、API、CLI、SDK を使用して、シャード数やシャードごとのコンピューティング設定を変更することで、コンピューティングを追加したり削除したりできます。エラスティッククラスターは、基盤となるインフラストラクチャを自動的にプロビジョニング/プロビジョニング解除でき、データの調整を行うことができます。

エラスティッククラスターでは、Amazon DocumentDB の分散ストレージシステム全体で、シャードを通じてデータをパーティション分割できます。シャーディング (「パーティション分割」とも呼ばれます) は、大規模なデータセットを、複数のノードを使用した小さなデータセットに分割します。それにより、1 つのデータベースの垂直スケーリングの制限を超えて、データベースのスケールアウトが使用可能になります。エラスティッククラスターは、Amazon DocumentDB のコンピューティングとストレージの分離を利用します。エラスティッククラスターは、計算ノード間で小さなデータ チャンクを移動してコレクションを再パーティション化するのではなく、分散ストレージシステム内でデータを効率的にコピーすることができます。

エラスティッククラスターは、ハッシュベースのパーティショニングをサポートしています。

エラスティッククラスターを使用すると、データサイズに関係なく、アプリケーションのダウンタイムやパフォーマンスへの影響が、通常、ほとんどまたはまったく生じることなく、Amazon DocumentDB 上のワークロードを簡単にスケールアウトまたはスケールインできます。MongoDB で同様の操作をした場合、アプリケーションのパフォーマンスに影響を与え、時間も、数時間、場合によっては数日かかります。エラスティッククラスターは、影響のないバックアップと迅速なポイントインタイムリストアなどの卓越した管理機能も提供します。お客様は、データベースの管理ではなくアプリケーションにより多くの時間を費やすことができます。

いいえ。エラスティッククラスターを使用する上で、アプリケーションに変更を加える必要はありません。

いいえ、短期的に、AWS Database Migration service (DMS) を利用して、既存の Amazon DocumentDB クラスターから Elastic Clusters クラスターにデータを移行することが可能です。

エラスティッククラスターに最適なシャードキーを選択しても、他のデータベースと同じです。優れたシャードキーの場合、高頻度と高カーディナリティという 2 つの特性があります。たとえば、アプリケーションが DocumentDB にuser_orders を格納する場合、通常は、ユーザーがデータを取得する必要があります。したがって、特定のユーザーに関連するすべての注文を、1 つのシャードに含めなければなりません。この場合、user_id が適切なシャードキーです。詳細について読む。 

• エラスティッククラスター: Amazon DocumentDB クラスターを使用すると、読み取り/書き込みでワークロードのスループットを毎秒数百万回スケーリングでき、ペタバイトで保管できます。エラスティッククラスターは、コンピューティング用の 1 つ以上のシャードとストレージボリュームで構成され、デフォルトで、複数の可用性ゾーンで高可用性を実現します。
• シャード: シャードは、エラスティッククラスターの計算性能を提供します。シャードには、既定で 3 つのノード、1 つの書き込みノード、2 つの読み込みノードがあります。最大 32 個のシャードを所有でき、各シャードでは最大 64 個の vCPU を持つことができます。
• シャードキー : シャードキーは、エラスティッククラスターが一致するシャードに読み取りおよび書き込みトラフィックを分散するために使用される JSON ドキュメントのオプションのフィールドです。一意の値が多数存在するキーを選択することをお勧めします。適切なシャード キーを使用すると、基になるシャード間でデータが均等に分割されるため、ワークロードに最高のスループットと性能が提供されます。 
• シャードコレクション : データがエラスティッククラスタークラスター全体に分散されている集合体 (コレクション) を意味します。

エラスティッククラスターは、現在の DocumentDB と同じ方法で、他の AWS サービスと統合されます。まず最初に、AWS Database Migration Service (DMS) を使用して、MongoDB やその他のリレーショナルデータベースからエラスティッククラスターに移行することができます。次に、Amazon CloudWatch を使用して、エラスティッククラスターの状態とパフォーマンスをモニタリングします。第 3 に、AWS IAM ユーザーと、ロールを介して認証と承認を設定することで、AWS VPC を使用し、 VPC のみの安全な接続を行うことができます。最後に、AWS Glue を使用して、S3、Redshift、OpenSearch など、その他の AWS サービスとの間でデータをインポート/エクスポートします。

はい。既存の MongoDB シャードワークロードを、エラスティッククラスターに移行できます。お客様は、AWS Database Migration Service またはネイティブの MongoDB ツール (mongodump や mongorestore など) を使用して、MongoDB ワークロードをエラスティッククラスターに移行することができます。エラスティッククラスターは、shardCollection() などの MongoDB の一般的に使用されている API もサポートしており、Amazon DocumentDB で既存のツールやスクリプトを柔軟に再利用できます。

ストレージの下限は 10 GB です。クラスターの使用量に応じて、Amazon DocumentDB ストレージは 10 GB 単位で最大 128 TiB まで、パフォーマンスに影響を与えることなく自動的に拡張します。Amazon DocumentDB エラスティッククラスターを使用すると、ストレージは自動的に 10 GB 単位で最大 4 PiB まで拡張します。いずれにしても、ストレージを事前にプロビジョニングする必要はありません。

Amazon DocumentDB では、ストレージとコンピューティングという 2 つの面でスケーリングが行われます。Amazon DocumentDB のストレージは、インスタンスベースのクラスターでは10 GB から 128 TiB に、Amazon DocumentDB エラスティッククラスターの場合は最大 4 PiB まで自動的に拡張します。Amazon DocumentDB のコンピューティング性能は、より大きなインスタンスを作成することでスケールアップでき、クラスターにレプリカインスタンスを追加することで水平方向に（読み取りスループットを向上させるために）拡張することができます。

インスタンスに割り当てるコンピューティングリソースは、AWS マネジメントコンソールから任意のインスタンスを選択して [Modify] ボタンをクリックすることでスケーリングできます。メモリおよび CPU リソースはインスタンスのクラスを変更することで調整できます。

インスタンスのクラスを変更すると、その変更は指定したメンテナンスウィンドウの間に適用されます。あるいは、"Apply Immediately" フラグを使用して、スケーリングリクエストをすぐに適用することができます。これらのオプションはいずれも、スケーリング操作が実行されている数分間の可用性に影響を与えます。保留中の他のシステム変更も適用されることにご注意ください。

Amazon DocumentDB クラスターでは常に自動バックアップが有効です。Amazon DocumentDB のシンプルなデータベースバックアップ機能により、クラスターのポイントインタイムリカバリが可能です。ポイントインタイムの復元のためのバックアップウィンドウは、最大 35 日まで拡大できます。バックアップはデータベースのパフォーマンスに影響を与えません。

はい。手動によるスナップショットはバックアップウィンドウを超えても保持可能であり、スナップショットを取得してもパフォーマンスに影響はありません。クラスタースナップショットからデータを復元する場合は新しくクラスターを作成する必要があることに注意してください。

Amazon DocumentDB では、リージョン内の 3 つのアベイラビリティーゾーン (AZ) にわたってデータの耐久性が自動的に保持され、データ損失のない正常なアベイラビリティゾーンのインスタンスの復旧が自動的に試みられます。万一、Amazon DocumentDB ストレージでデータが利用不可になった場合には、クラスタースナップショットから復元するか、ポイントインタイムの復元オペレーションを新しいクラスターに対して実行できます。ポイントインタイムの復元オペレーションを実行する場合、最新の復元可能時間は直近で 5 分前までです。

インスタンスを削除する際に、最終スナップショットを作成することができます。スナップショットを作成した場合、後日そのスナップショットを使用して、削除したインスタンスを復元することができます。Amazon DocumentDB では、インスタンスが削除された後に、このユーザーが作成した最終的なスナップショットと、手動で作成されたその他のスナップショットをすべて保持します。インスタンスが削除された後はスナップショットのみが保持されます (つまり、ポイントインタイムの復元のために作成された自動バックアップは保持されません)。

AWS アカウントを削除すると、そのアカウントに含まれるすべての自動バックアップおよびスナップショットバックアップは削除されます。

はい。Amazon DocumentDB では、クラスターのスナップショットを作成できます。これを使用して、後でクラスターを復元できます。スナップショットは別の AWS アカウントと共有でき、受取人アカウントの所有者は、そのスナップショットを使用して、お客様のデータを含むクラスターを復元できます。スナップショットを公開して、誰でもお客様の公開データを含むクラスターを復元できるように選択することもできます。この機能を使用して、異なる AWS アカウントを持つさまざまな環境 (本番、開発/テスト、ステージングなど) でデータを共有できます。また、メインの AWS アカウントが侵害された場合でも、すべてのデータのバックアップを別個のアカウントで安全に保持できます。

アカウント間のスナップショットの共有に対して課金されることはありません。しかし、スナップショット自体、および共有スナップショットから復元するクラスターに対して課金される場合があります。

自動クラスタースナップショットの共有はサポートされていません。自動スナップショットを共有するには、手動でスナップショットのコピーを作成してから、コピーを共有する必要があります。

いいえ。共有された Amazon DocumentDB スナップショットは、それを共有したアカウントと同じリージョン内のアカウントからのみアクセスできます。

はい。暗号化された Amazon DocumentDB スナップショットは共有できます。共有されたスナップショットの受取人は、そのスナップショットを暗号化するのに使用した KMS キーにアクセスできる必要があります。

いいえ。Amazon DocumentDB スナップショットはサービス内でのみ使えます。

クラスターを削除する際に、最終スナップショットを作成することができます。スナップショットを作成した場合、後日そのスナップショットを使用して、削除したクラスターを復元することができます。Amazon DocumentDB では、クラスターが削除された後に、このユーザーが作成した最終的なスナップショットと、手動で作成されたその他のスナップショットをすべて保持します。

Amazon DocumentDB ではストレージボリュームを多数のディスクにまたがる 10 GB のセグメントに自動的に分割します。10 GB 単位の各ストレージボリュームが、3 つのアベイラビリティーゾーン (AZ) にわたって 6 つの方法でレプリケートされます。Amazon DocumentDB は、データコピーの損失について、2 つまでなら書き込み性能に影響を与えることなく、また 3 つまでなら読み込み性能に影響を与えることなく、透過的に処理するように設計されています。Amazon DocumentDB のストレージボリュームも自己修復機能を備えています。データブロックおよびディスクはエラー検出のために継続的にスキャンされ、自動的に修復されます。

他のデータベースとは異なり、データベースのクラッシュ後、Amazon DocumentDB では、データベースを利用できるようにする前に最後のデータベースチェックポイント (通常 5 分前) から REDO ログを再生して、すべての変更が適用されていることを確認する必要はありません。これにより、多くの場合データベースの再起動時間を 60 秒以内に短縮します。Amazon DocumentDB では、キャッシュをデータベース処理から除外し、再起動時にすぐ利用できるようにしています。そのため、ブラウンアウトを避けるためにキャッシュが再生成されるまでアクセスを調整する必要がなくなります。

Amazon DocumentDB では、プライマリインスタンスと同じ基本ストレージボリュームを共有するリードレプリカがサポートされています。プライマリインスタンスにより実行された更新は、すべての Amazon DocumentDB レプリカで確認できます。

• 機能: Amazon DocumentDB リードレプリカ
• レプリカの数: 最大 15 個
• レプリケーションタイプ: 非同期 (通常は数ミリ秒)
• プライマリへのパフォーマンスの影響: 低
• フェイルオーバーターゲットとして機能: 可 (データ損失なし)
• 自動フェイルオーバー: 可

はい、グローバルクラスター機能を使用して、リージョン間でデータをレプリケートすることができます。グローバルクラスターは、複数の AWS リージョンにまたがって機能します。グローバルクラスターは、お客様のデータを最大 5 つのリージョンのクラスターにレプリケートし、パフォーマンスにほとんどまたはまったく影響を与えません。グローバルクラスターは、リージョン全体の機能停止からの迅速な復旧と、低レイテンシーでリージョン間の読み取りを可能にします。詳細については、ブログ記事を参照してください。

はい。クラスターの各インスタンスに昇格優先階層を割り当てることができます。プライマリインスタンスが失敗した場合、Amazon DocumentDB では最も優先度の高いレプリカがプライマリに昇格します。同じ優先階層において、複数のレプリカ間での不一致が存在する場合、Amazon DocumentDB ではプライマリインスタンスと同じサイズのレプリカが昇格します。

インスタンスへの優先階層はいつでも変更できます。優先階層を変更するだけでは、フェイルオーバーはトリガーされません。

プライマリインスタンスに昇格させたくないレプリカを低い優先階層に割り当てることができます。しかし、クラスターの高い優先度のレプリカが正常でない、または何らかの理由により利用できない場合、Amazon DocumentDB では低い優先階層のレプリカが昇格します。

Amazon DocumentDB は、複数の AWS アベイラビリティーゾーンでレプリカインスタンスをフェイルオーバーターゲットとして使用することにより、高い可用性を備えた構成でデプロイすることが可能となっています。プライマリインスタンスに障害が発生した場合でも、レプリカインスタンスが新しいプライマリへと自動的に昇格することにより、サービスの停止時間は最小に抑えられます。

Amazon DocumentDB レプリカを追加できます。Amazon DocumentDB レプリカは基盤となるストレージをプライマリインスタンスと共有します。任意の Amazon DocumentDB レプリカをデータを損失することなくプライマリに昇格できるため、プライマリインスタンスに障害が発生した際の耐障害性を向上するために使用できます。複数のアベイラビリティーゾーンに 1 個から 15 個のレプリカを作成するだけで、インスタンスの停止時に Amazon DocumentDB によってフェイルオーバーのプライマリ対象としてそれらのレプリカが自動的に認識されるため、クラスターの可用性が向上します。

フェイルオーバーは Amazon DocumentDB によって自動的に処理されるため、アプリケーションは管理上の手動介入なく、可能な限り迅速にデータベースオペレーションを再開することができます。

• 同一の、または異なるアベイラビリティゾーンに Amazon DocumentDB レプリカインスタンスを作成している場合、フェイルオーバーが発生すると Amazon DocumentDB では、インスタンスの Canonical Name Record (CNAME) を切り替えて正常なレプリカを指定するようにします。このレプリカが新しいプライマリに昇格します。フェイルオーバーは開始から終了まで通常 30 秒以内に完了します。 
• Amazon DocumentDB レプリカインスタンスを作成していない場合 (単一インスタンスクラスターの場合)、Amazon DocumentDB では、元のインスタンスと同じアベイラビリティーゾーンに新しいインスタンスを作成することを試行します。オリジナルのインスタンスの置換処理はベストエフォート型であり、アベイラビリティーゾーンで広範囲に影響を及ぼす問題がある時などは失敗する可能性があります。 

接続が切断された場合、通常アプリケーションはデータベースへの接続を再試行します。

Amazon DocumentDB ではプライマリインスタンスの問題を自動的に検知し、読み込み/書き込みトラフィックを Amazon DocumentDB レプリカインスタンスにルーティングします。このフェイルオーバーは平均 30 秒以内に完了します。さらに、Amazon DocumentDB レプリカインスタンスによって処理されていた読み込みトラフィックは一時的に中断されます。

Amazon DocumentDB レプリカではプライマリインスタンスと同じデータボリュームを共有しているため、実質的にレプリケーションラグはありません。通常、ラグは数十ミリ秒です。

はい。すべての Amazon DocumentDB クラスターが VPC で作成される必要があります。Amazon VPC では、お客様がデータセンターで運用しているような従来のネットワークに非常によく似た仮想ネットワークのトポロジーを定義することができます。これにより、Amazon DocumentDB クラスターにアクセスするユーザーを完全に制御できます。

Amazon DocumentDB は組み込みのロールを使用できる RBAC をサポートしています。RBAC を使用すると、ユーザーに実行権限を付与するアクションを制限できます。これによって、最小限の権限を付与するというベストプラクティスを適用できます。詳細については、「Amazon DocumentDB ロールベースのアクセスコントロール」を参照してください。

Amazon DocumentDB では、VPC の厳格なネットワークと認可範囲を利用します。Amazon DocumentDB 管理 API の認証と認可は、IAM ユーザー、ロール、ポリシーによって提供されます。Amazon DocumentDB データベースの認証は、Salted Challenge Response Authentication Mechanism (SCRAM) を備えた標準の MongoDB ツールおよびドライバーによって行われます。SCRAM は MongoDB 向けのデフォルトの認証メカニズムです。

はい。Amazon DocumentDB では、AWS Key Management Service (KMS) で管理するキーを使用してクラスターを暗号化することもできます。Amazon DocumentDB 暗号化を使って実行するクラスターでは、基盤となるストレージに保存される保管中のデータが、同じクラスター内の自動バックアップ、スナップショット、レプリカと同様に暗号化されます。暗号化と復号はシームレスに処理されます。Amazon DocumentDB での KMS の使用に関する詳細は、「Amazon DocumentDB で保管中のデータの暗号化」を参照してください。

現在のところ、暗号化されていない既存の Amazon DocumentDB クラスターの暗号化はサポートされていません。暗号化されていない既存のクラスターで Amazon DocumentDB 暗号化を使用するには、暗号化を有効にした新しいクラスターを作成し、データを移行してください。

Amazon DocumentDB は、最高のセキュリティ基準を満たし、ユーザーが当社のセキュリティを検証し、ユーザー自身の規制およびコンプライアンス義務を容易に満たすことができるように設計されました。Amazon DocumentDB は HIPAA 対応であることに加え、PCI DSS、ISO 9001、27001、27017、27018、SOC 1、2、3、Health Information Trust Alliance (HITRUST) Common Security Framework (CSF) 認定に準拠していると評価されています。AWS コンプライアンスレポートは、AWS Artifact からダウンロードできます。

インプレースメジャーバージョンアップグレード (MVU) では、AWS コンソール、Software Development Kit (SDK)、またはコマンドラインインターフェイス (CLI) を使用して Amazon DocumentDB 3.6 または 4.0 クラスターを Amazon DocumentDB 5.0 にアップグレードできます。インプレース MVU では、新しいクラスターを作成したり、エンドポイントを変更したりする必要はありません。インプレース MVU は、Amazon DocumentDB 5.0 を利用可能なすべてのリージョンで利用できます。インプレース MVU の使用を開始するには、インプレース MVU のドキュメントを参照してください。

インプレース MVU を使用すると、Amazon DocumentDB 3.6 または 4.0 クラスターをバージョン 5.0 にシームレスにアップグレードできます。別のクラスターにバックアップや復元を実行したり、他のデータ移行ツールを使用したりする必要はありません。そうすることで、ソースとターゲットのエンドポイントの設定、インデックスとデータの移行、アプリケーションコードの変更などを伴う通常のアップグレードプロセスに関連する時間と労力を削減できます。

アップグレード後にアプリケーションのエンドポイントを変更する必要はありません。データは同じクラスター内にあるため、機能を使用してアップグレードしても追加コストは発生しません。

ダウンタイムは、コレクション、インデックス、データベース、インスタンスの数に応じて、クラスターごとに異なる場合があります。本番クラスターでインプレースメジャーバージョンアップグレードを実行する前に、ダウンタイムやパフォーマンスをテストし、アップグレード後にアプリケーションが期待どおりに動作することを確認するために、より低い環境で実行することを強くお勧めします。

Amazon DocumentDB の高速クローン機能を利用して、テスト用にクラスターデータを複製することもできます。Amazon DocumentDB の実装の複雑さによっては、当社のデータベースソリューションアーキテクトに追加の支援を求めることができます。

インプレース MVU は、Amazon DocumentDB 3.6 または 4.0 をソースとして、バージョン 5.0 をターゲットとする場合にのみサポートされます。Amazon DocumentDB グローバルクラスターやエラスティッククラスター、または DocumentDB 4.0 をターゲットとする場合はサポートされていません。

Amazon DocumentDB は Amazon SageMaker Canvas と統合されているため、Amazon DocumentDB に保存されているデータを使用して機械学習 (ML) モデルを簡単に構築し、基礎モデルをカスタマイズできます。コードを 1 行も記述する必要はありません。Amazon DocumentDB と SageMaker Canvas 間でカスタムデータと ML パイプラインを開発する必要はもうありません。Amazon DocumentDB コンソール内から SageMaker Canvas を起動し、既存の Amazon DocumentDB データベースをデータソースとして追加して、機械学習モデルの構築を開始できます。SageMaker Canvas の DocumentDB のデータを使用して、顧客離れの予測、不正行為の検出、メンテナンス障害の予測、財務指標と売上の予測、在庫の最適化、コンテンツの要約、コンテンツの生成を行うモデルを構築できます。

Amazon SageMaker Canvas には、Amazon DocumentDB を含むさまざまなデータソースからのデータを使用して機械学習モデルを構築するためのコード不要のインターフェイスが用意されています。SageMaker Canvas の使用料と、SageMaker Canvas が Amazon DocumentDB インスタンスからデータを読み取る際の I/O に対して課金されます。Amazon SageMaker Canvas のデータソースとして DocumentDB を使用しても追加料金はかかりません。詳細については、Amazon DocumentDB の料金ページと SageMaker Canvas の料金ページをご覧ください。

ベクトル検索は、機械学習 (ML) で使用される方法で、距離または類似度メトリックを使用してベクトル表現を比較することにより、特定のデータポイントに類似したデータポイントを検索します。2 つのベクトルがベクトル空間に近いほど、基になるアイテムはより類似していると見なされます。この手法は、データの意味やセマンティクスを把握するのに役立ちます。このアプローチは、レコメンデーションシステム、自然言語処理、画像認識など、さまざまなアプリケーションで役立ちます。

Amazon DocumentDB のベクトル検索は、JSON ベースのドキュメントデータベースの柔軟性と豊富なクエリ機能と、ベクトル検索の機能を組み合わせたものです。既存の Amazon DocumentDB データまたは柔軟なドキュメントデータ構造を使用して、セマンティック検索エクスペリエンス、製品レコメンデーション、パーソナライゼーション、チャットボット、不正検出、異常検出などの機械学習や生成系 AI のユースケースを構築できます。詳細については、Amazon DocumentDB ドキュメントのベクトル検索をご覧ください。

Amazon DocumentDB のベクトル検索は、Amazon DocumentDB 5.0 インスタンスベースのクラスターで利用できます。

Amazon DocumentDB のベクトル検索では、セマンティック検索を使用できるため、データの背後にある意味、コンテキスト、意図を把握できます。キーワード検索では、実際のテキストまたは事前定義されたシノニムマッピングに基づいてドキュメントが検索されます。たとえば、従来の e コマースアプリケーションでは、赤いドレスを購入すると、説明に「赤」と「ドレス」という単語が含まれている商品が返されることがあります。セマンティック検索では、さまざまな赤の色合いのドレスで結果が得られるため、ユーザーエクスペリエンスが向上します。 

Amazon DocumentDB のベクトル検索を使用しても追加料金は発生しません。Amazon DocumentDB にベクトルを保存、インデックス作成、検索すると、標準のコンピューティング、I/O、ストレージ、およびバックアップ料金が適用されます。詳細については、Amazon DocumentDB の料金ページをご覧ください。

Amazon DocumentDB は Amazon SageMaker Canvas と統合されているため、Amazon DocumentDB に保存されているデータを使用して、生成型人工知能 (AI) および機械学習 (ML) アプリケーションを簡単に構築できます。Amazon DocumentDB と SageMaker Canvas 間でカスタムデータと ML パイプラインを開発する必要はもうありません。コンソール内統合により、データへの接続とアクセスにかかる未分化の重労働が取り除かれ、LCNC (Low Code No Code) エクスペリエンスで ML 開発が加速します。Amazon DocumentDB コンソール内から SageMaker Canvas を起動し、既存の Amazon DocumentDB データベースをデータソースとして追加できます。

この Amazon OpenSearch Service とのゼロ ETL 統合は、Amazon DocumentDB コレクションからデータを抽出し、変換して、Amazon OpenSearch が管理するクラスターやサーバーレスコレクションにロードする運用上の複雑性を取り除きます。この統合により、データパイプラインを構築または管理したり、データを変換したりする必要がなくなります。

MongoDB API を使用する場合は、Amazon DocumentDB のネイティブデータベース機能を使用して、ドキュメントでベクトル検索を実行する必要があります。Amazon DocumentDB と Amazon OpenSearch Service のゼロ ETL 統合は、コレクション全体の検索や、2,000 次元を超えるベクトルの保存とインデックス付けに最適です。

Amazon DocumentDB の Amazon OpenSearch Service とのゼロ ETL 統合は、Amazon OpenSearch Ingestation を使用して、運用データを Amazon DocumentDB から Amazon OpenSearch Service にシームレスに移動させます。これを開始するには、レプリケートする必要がある Amazon DocumentDB コレクションの変更ストリーム機能を有効にします。ゼロ ETL 統合機能が、ユーザーのアカウント内に Amazon OpenSearch Ingeston パイプラインをセットアップします。これは、Amazon OpenSearch Service が管理するクラスターまたはサーバーレスコレクションにデータを自動レプリケートします。

Amazon OpenSearch Ingestion は、Amazon DocumentDB コレクション内のデータの形式を自動的に理解し、そのデータを Amazon OpenSearch Service にマップして、最も精度の高い検索結果を生成します。複数の Amazon DocumentDB コレクションからのデータを、複数のパイプライン経由で Amazon OpenSearch が管理する 1 つのクラスターまたはサーバーレスコレクションに同期して、複数のアプリケーション全体の総合的なインサイトを提供することができます。オプションで、Amazon OpenSearch Service での取り込み設定の定義時に、カスタムデータプロセッサを指定することが可能です。DocumentDB コレクションへの後続の更新も、手動操作なしで Amazon OpenSearch Service にレプリケートされます。

このゼロ ETL は、Amazon OpenSearch Ingestion パイプラインのネイティブデータ変換機能を利用して、移動中のデータを集約し、フィルタリングします。

カスタマイズされた変換機能を希望する場合は、カスタム変換ロジックを記述することもでき、変換プロセスは Amazon OpenSearch Ingestion が管理します。あるいは、カスタマイズせずにデータ全体をソースからシンクに移動したいなら、Amazon OpenSearch Ingestion が追加設定不要のブループリントを提供するので、ボタンを数回クリックするだけで統合を実行できます。

ゼロ ETL 統合機能は、Amazon OpenSearch Ingestion が Amazon DocumentDB からのデータをレプリケートするために必要な許可を持っていることを確実にするために、Amazon DocumentDB コレクションからデータを読み取って、Amazon OpenSearch ドメインまたはコレクションに書き込むために必要な許可を持つ IAM ロールを作成します。その後、OpenSearch Ingestistion パイプラインがこの役割を引き受け、データをソースからターゲットに移動する際に常に適切なセキュリティ体制が維持されるようにします。

Amazon DocumentDB とのゼロ ETL 統合に関連するすべてのメトリクスは、Amazon DocumentDB および OpenSearch Ingestion パイプラインが提供するコンソールダッシュボードで確認できます。また、Amazon CloudWatch のリアルタイムログをクエリしたり、Amazon CloudWatch を使用して、ユーザー定義のしきい値を超過したときにトリガーされるカスタムアラートをセットアップしたりすることも可能です。