多くの開発チームは、イベント駆動型アーキテクチャとユーザーフレンドリーで高性能なアプリケーションを大規模に構築するために DynamoDB を利用しています。運用データベースである DynamoDB は、複数の地理的な場所に展開されている場合でも、リアルタイム トランザクションに最適化されています。ただし、検索や分析のアクセス パターンに対しては優れたパフォーマンスを提供しません。 DynamoDB での検索と分析 DynamoDB などの NoSQL データベースは、一般的に優れたスケーリング特性を備えていますが、オンライン トランザクション処理に重点を置いた限られた操作セットのみをサポートしています。そのため、効率的なインデックス作成戦略に大きく依存せずに、データの検索、フィルタリング、集計、結合を行うことは困難です。 DynamoDB は、各項目にあるユーザー指定のパーティション キー フィールドに基づいて、データを多数のノードにパーティション分割して内部に格納します。この オプションでソート キーと組み合わせてプライマリ キーを表すことができます。プライマリ キーはインデックスとして機能するため、クエリ操作のコストが安くなります。クエリ操作では、パーティション キーに対して等価比較 (=) を実行でき、ソート キーに対しては、指定されている場合は比較操作 (>、<、=、BETWEEN) を実行できます。 ユーザー指定のパーティション キーは、 上記のスキームでカバーされていない分析クエリを実行するには、スキャン操作を使用する必要があります。これは通常、DynamoDB テーブル全体を並列にスキャンすることによって実行されます。これらのスキャンは、テーブル全体の完全な読み取りを必要とするため、読み取りスループットの点で遅く、コストがかかる可能性があります。また、テーブルのサイズが大きくなると、結果を生成するためにスキャンするデータが増えるため、スキャンの速度が低下する傾向があります。法外なスキャンコストをかけずに分析クエリをサポートしたい場合は、次に説明するセカンダリインデックスを活用できます。 DynamoDB でのインデックス作成 DynamoDB では、頻繁にクエリされるフィールドにインデックスを付けることでアプリケーションのパフォーマンスを向上させるために、セカンダリ インデックスがよく使用されます。セカンダリ インデックスに対するクエリ操作は、明確に定義された要件を持つ分析クエリを通じて特定の機能を強化するためにも使用できます。 セカンダリ インデックスは、クエリを実行するフィールドに対してパーティション キーとオプションのソート キーを作成することから構成されます。セカンダリ インデックスには 2 つの種類があります。 ローカル セカンダリ インデックス (LSI): LSI は、単一のパーティションのハッシュ キー属性と範囲キー属性を拡張します。 グローバル セカンダリ インデックス (GSI): GSI は、単一のパーティションではなくテーブル全体に適用されるインデックスです。 しかし、 ように、DynamoDB で GSI を過剰に使用するとコストが高くなる可能性があります。DynamoDB での分析は、非常に単純なポイント検索や小さな範囲のスキャンにのみ使用されない限り、セカンダリ インデックスの過剰使用と高コストにつながる可能性があります。 Nike が発見した インデックスを使用する場合、プロビジョニングされた容量のコストはすぐに増加する可能性があります。これは、ベーステーブルへのすべての更新が対応する GSI でも行われる必要があるためです。実際、AWS では アドバイスしています。プロビジョニングされた書き込み容量のコストは、設定された GSI の数に比例して増加するため、多くのアクセスパターンをサポートするために多くの GSI を使用するとコストがかかりすぎます。 、ベーステーブルへの書き込みが抑制され、アプリケーションが機能しなくなるのを避けるために、グローバルセカンダリインデックスのプロビジョニングされた書き込み容量は、ベーステーブルの書き込み容量以上である必要があると DynamoDB は、配列やオブジェクトなどのネストされた構造のデータのインデックス作成にも適していません。データのインデックス作成前に、ユーザーはデータを非正規化し、ネストされたオブジェクトと配列をフラット化する必要があります。これにより、書き込み回数と関連コストが大幅に増加する可能性があります。 分析に DynamoDB セカンダリ インデックスを使用する方法の詳細については、ブログ「 を参照してください。 DynamoDB での分析のためのセカンダリ インデックス」 つまり、分析ユースケースでは、複雑な分析を効率的に実行するための外部セカンダリインデックスとして機能する別のツールまたはサービスと DynamoDB テーブルを同期することで、パフォーマンスとコストの面で大きなメリットを得ることができます。 DynamoDB + Elasticsearch データにセカンダリ インデックスを構築する 1 つの方法は、Elasticsearch で DynamoDB を使用することです。Elastic Cloud や Amazon OpenSearch Service などのクラウドベースの Elasticsearch を使用すると、インデックスのサイズ、レプリケーション、その他の要件に応じてノードをプロビジョニングおよび構成できます。マネージド クラスターでは、アップグレード、セキュリティ保護、パフォーマンスの維持のためにいくつかの操作が必要ですが、EC2 インスタンスで完全に自分で実行するよりも操作は少なくなります。 を使用するアプローチはサポートされておらず、セットアップも難しいため、代わりに DynamoDB ストリームと AWS Lambda 関数を使用して DynamoDB から Elasticsearch に書き込みをストリーミングすることができます。このアプローチでは、次の 2 つの手順を別々に実行する必要があります。 Amazon DynamoDB の Logstash プラグイン まず、DynamoDB ストリームで呼び出され、DynamoDB で発生する各更新を Elasticsearch に投稿する Lambda 関数を作成します。 次に、Lambda 関数 (または、Lambda 実行タイムアウトよりも時間がかかる場合はスクリプトを実行する EC2 インスタンス) を作成し、DynamoDB の既存のコンテンツをすべて Elasticsearch に投稿します。 テーブルへの書き込みを見逃さないようにするには、これらの Lambda 関数の両方を適切な権限で作成して接続する必要があります。必要な監視とともに設定すると、DynamoDB から Elasticsearch でドキュメントを受信し、Elasticsearch を使用してデータに対して分析クエリを実行できるようになります。 このアプローチの利点は、Elasticsearch がフルテキスト インデックスと複数の種類の分析クエリをサポートしていることです。Elasticsearch は、さまざまな言語のクライアントと、ダッシュボードをすばやく構築できる視覚化のための Kibana などのツールをサポートしています。クラスターが正しく構成されている場合、クエリのレイテンシを調整して、Elasticsearch に流入するデータに対する高速な分析クエリを実行できます。 デメリットとしては、ソリューションのセットアップとメンテナンスのコストが高くなる可能性があることが挙げられます。マネージド Elasticsearch でも、基盤となるインスタンスのレプリケーション、リシャーディング、インデックスの拡張、パフォーマンス チューニングに対処する必要があります。 Elasticsearch は、コンピューティングとストレージを分離しない密結合アーキテクチャを採用しています。つまり、リソースは個別にスケーリングできないため、過剰にプロビジョニングされることがよくあります。さらに、読み取りや書き込みなどの複数のワークロードが同じコンピューティング リソースを競合することになります。 Elasticsearch は更新を効率的に処理することもできません。フィールドを更新すると、ドキュメント全体の再インデックスがトリガーされます。Elasticsearch ドキュメントは不変であるため、更新を行うには、新しいドキュメントをインデックス化し、古いバージョンを削除済みとしてマークする必要があります。その結果、変更されていないフィールドも再インデックス化し、更新時にドキュメント全体を書き込むために、追加のコンピューティングと I/O が消費されます。 Lambda は DynamoDB ストリームで更新が検出されると起動するため、 原因でレイテンシーが急上昇する可能性があります。セットアップには、DynamoDB ストリームからのイベントが正しく処理され、Elasticsearch に書き込めることを確認するためのメトリックと監視が必要です。 コールド スタートが 機能的には、分析クエリに関して、 。結合は、複数のインデックスを含む複雑な分析クエリに役立ちます。Elasticsearch ユーザーは、この制限を回避するために、多くの場合、データを非正規化したり、アプリケーション側で結合を実行したり、ネストされたオブジェクトや親子関係を使用したりする必要があります。 Elasticsearch は結合をサポートしていません 利点 全文検索サポート 複数の種類の分析クエリのサポート DynamoDBの最新データで作業できる デメリット 取り込み、インデックス作成、レプリケーション、シャーディングのためのインフラストラクチャの管理と監視が必要 密結合アーキテクチャはリソースの過剰プロビジョニングとコンピューティングの競合を引き起こす 非効率的な更新 DynamoDBとElasticsearch間のデータの整合性と一貫性を確保するために別のシステムが必要 異なるインデックス間の結合はサポートされていません このアプローチは、DynamoDB のデータと Kibana を使用したダッシュボードに全文検索を実装する場合に適しています。ただし、運用環境で Elasticsearch クラスターを調整および維持するために必要な操作、リソースの非効率的な使用、結合機能の欠如が課題となる場合があります。 DynamoDB + ロックセット 、主に高い QPS 要件を持つリアルタイム アプリケーションをサポートするために構築された、完全に管理された検索および分析データベースです。OLTP データベースのデータの外部セカンダリ インデックスとしてよく使用されます。 Rockset は Rockset には DynamoDB との組み込みコネクタがあり、これを使用して DynamoDB と Rockset の間でデータを同期させることができます。同期する内容の元となる DynamoDB テーブルと、そのテーブルにインデックスを付ける Rockset コレクションを指定できます。Rockset は完全なスナップショットで DynamoDB テーブルの内容をインデックスし、新しい変更が発生するとそれを同期します。Rockset コレクションの内容は常に DynamoDB ソースと同期されており、安定した状態では数秒以内の差しかありません。 Rockset は、ストリームの状態を監視し、DynamoDB からのストリーミングの変更を可視化することで、DynamoDB テーブルと Rockset コレクション間のデータの整合性と一貫性を自動的に管理します。 スキーマ定義がない場合でも、フィールドが追加/削除されたとき、または DynamoDB でデータの構造/タイプ自体が変更されたときに、Rockset コレクションは自動的に適応できます。これは、追加の ETL の必要性を排除する と によって可能になります。 強力な動的型付け スマート スキーマ DynamoDB から取得した Rockset コレクションは、クエリ用の SQL をサポートしており、開発者はドメイン固有の言語を習得しなくても簡単に使用できます。また、REST API 経由でアプリケーションにクエリを提供したり、複数のプログラミング言語のクライアント ライブラリを使用したりすることもできます。Rockset がサポートする ANSI SQL のスーパーセットは、深くネストされた JSON 配列とオブジェクトでネイティブに動作し、すべてのフィールドに対して自動的に構築されるインデックスを活用して、複雑な分析クエリでもミリ秒単位のレイテンシを実現します。 Rockset は、同じ基礎となるリアルタイム データを共有しながら、別々のコンピューティング ユニットでワークロードを分離できる 先駆者です。これにより、同時取り込みとクエリ、または同じデータ セットでの複数のアプリケーションをサポートするときに、ユーザーはリソース効率が向上します。 コンピューティング分離の さらに、Rockset は、セキュリティ、データの暗号化、およびデータへのアクセスを管理するためのロールベースのアクセス制御も行います。Rockset ユーザーは、Rockset で設定できる 利用して、コレクションに到着したデータを変更することで、ETL の必要性を回避できます。また、ユーザーは、古いデータを自動的に消去する保持ポリシーを設定することで、データのライフサイクルをオプションで管理することもできます。データの取り込みとクエリの提供は両方とも自動的に管理されるため、インフラストラクチャの管理と運用の必要性を排除しながら、ライブ ダッシュボードとアプリケーションの構築と展開に集中できます。 取り込み変換を DynamoDB との同期に特に関連して、Rockset はコストのかかる再インデックスを避けるために、インプレース フィールド レベルの更新をサポートしています。取り込み、クエリ、効率の観点から ジョブに適したツールを選択してください。 Rockset と Elasticsearch を比較して、 まとめ 高いQPSを実現し、リアルタイムアプリケーションに対応するように構築されています 完全にサーバーレス。インフラストラクチャやデータベースの操作やプロビジョニングは不要 予測可能なパフォーマンスと効率的なリソース利用を実現するコンピューティングとコンピューティングの分離 DynamoDBとRocksetコレクション間のライブ同期により、数秒以上の差がなくなる DynamoDBとRockset間の一貫性を確保するための監視 データ上に自動インデックスを構築し、低レイテンシのクエリを実現 高価な再インデックスを回避し、データのレイテンシを短縮するインプレース更新 Amazon Kinesis、Apache Kafka、Amazon S3 などの他のソースからのデータと結合します。 Rockset を使用すると、運用、スケーリング、メンテナンスの心配をすることなく 実装できます。これにより、リアルタイム アプリケーションの開発を大幅にスピードアップできます。Rockset を使用して DynamoDB データ上にアプリケーションを構築したい場合は、 から無料で開始できます。 、DynamoDB のデータに対してリアルタイム分析を こちら
