顧客の期待とそれに伴うアプリケーションに対する要求は、かつてないほど高まっています。ユーザーは、アプリケーションが高速で、信頼性が高く、可用性があることを期待しています。さらに、データは王様であり、ユーザーは必要に応じて集約されたデータをスライスして細分化して洞察を見つけられることを望んでいます。ユーザーは、データ エンジニアが新しいインデックスをプロビジョニングしたり、新しい ETL チェーンを構築したりするのを待ちたくありません。彼らは利用可能な最も新しいデータへの自由なアクセスを望んでいます。 しかし、アプリケーションのニーズをすべて処理するのは、単一のデータベースにとって大変な作業です。データベースの場合、個々のレコードに対する頻繁で低遅延の操作を最適化することは、頻度の低い集計や多数のレコードにわたる強力なフィルタリングを最適化することとは異なります。多くの場合、同じデータベースで両方のパターンを処理し、アプリケーションの規模が拡大するにつれて一貫性のないパフォーマンスに対処しようとします。私たちは最小限の労力やコストで最適化していると思っていますが、実際にはその逆を行っています。 OLTP データベースで分析を実行するには、通常、トラフィックのピークに対応してデータベースをオーバープロビジョニングする必要があります。これには最終的に多額の費用がかかり、通常は満足のいくエンド ユーザー エクスペリエンスを提供できません。 このチュートリアルでは、これらの両方のアクセス パターンを持つユーザーの高い要求に対処する方法を見ていきます。私たちは、ユーザーが取引を記録し、最近の取引を表示しながら、過去の取引に対する複雑なフィルタリングや集計も必要とする金融アプリケーションを構築する予定です。 ハイブリッドアプローチ アプリケーションのニーズに対応するために、 と を使用します。 DynamoDB は、当社の中核となるトランザクション アクセス パターンを処理します。つまり、トランザクションを記録し、ユーザーが閲覧できるように最近のトランザクションのフィードを提供します。 Rockset は DynamoDB を補完して、データ量の多い「楽しい」アクセス パターンを処理します。ユーザーが時間、販売者、カテゴリ、またはその他のフィールドでフィルタリングして、関連する取引を見つけたり、強力な集計を実行して時間の経過に伴う支出の傾向を確認したりできるようにします。 Amazon DynamoDB Rockset これらのパターンを検討すると、これらのシステムがそれぞれの仕事にどのように適しているかがわかります。 DynamoDB は、個々の項目の読み取りまたは書き込み、または既知のフィルターに基づいた一連の一連の項目のフェッチなど、中核となる OLTP 操作に優れています。主キーに基づいてデータを分割する方法により、DynamoDB は、あらゆる規模でこれらのタイプのクエリに対して一貫したパフォーマンスを提供できます。 逆に、Rockset は、大量のデータの継続的な取り込みと、そのデータに対する複数のインデックス付け戦略を採用して、選択性の高いフィルタリング、リアルタイムまたはクエリ時の集計、および DynamoDB では簡単に処理できないその他のパターンを提供することに優れています。 この例を進めるにつれて、2 つのシステムの基礎となる基本概念と、目標を達成するための実際的な手順の両方を学びます。 を使用してアプリケーションを追跡できます。 GitHub リポジトリ DynamoDB を使用したコア機能の実装 このウォークスルーは、アプリケーションのコア機能を実装することから始めます。これは、標準の「CRUDL」操作を構築して、個々のレコードを操作し、関連するレコードのセットを一覧表示する機能を提供するため、どのアプリケーションでも共通の開始点になります。 電子商取引アプリケーションの場合、これは注文を行ったり、以前の注文を表示したりする機能になります。ソーシャル メディア アプリケーションの場合、これは投稿の作成、友達の追加、フォローしている人の表示などです。この機能は通常、少数の行に対する多数の同時操作を重視する ワークフローに特化したデータベースによって実装されます。 オンライン トランザクション処理 (OLTP) この例では、ユーザーが支払いを送受信したり、取引履歴を表示したりできるビジネス財務アプリケーションを構築しています。 このチュートリアルでは例を意図的に単純化していますが、アプリケーションには 3 つの主要なアクセス パターンが考えられます。 。企業が行ったまたは受け取った支払いの記録を保存します。 取引の記録 。これにより、ユーザーは企業が行った、または受け取った最新の支払いを確認できるようになります。そして 取引を日付範囲別に表示します 。これにより、ユーザーは単一のトランザクションの詳細を詳しく調べることができます。 個別のトランザクションの表示 これらのアクセス パターンはそれぞれ、重要な大量のアクセス パターンです。ユーザーのトランザクションは常に記録されており、ユーザーがアプリケーションを開いたときにトランザクション フィードが最初に表示されます。さらに、これらのアクセス パターンはそれぞれ、既知の一貫したパラメータを使用して、関連するレコードをフェッチします。 DynamoDB を使用してこれらのアクセス パターンを処理します。 DynamoDB は AWS が提供する NoSQL データベースです。これはフルマネージド データベースであり、大規模アプリケーションとサーバーレス アプリケーションの両方で人気が高まっています。 DynamoDB の最もユニークな機能の 1 つは、あらゆる規模で一貫したパフォーマンスを提供する方法です。テーブルが 1 メガバイトであっても 1 ペタバイトであっても、操作の応答時間は同じであるはずです。これは、ここで実装しているようなコアの OLTP ユースケースにとって望ましい品質です。これはエンジニアリング上の素晴らしく貴重な成果ですが、適切に実行されるクエリの種類を選択することによって達成されたことを理解することが重要です。 DynamoDB は、2 つの主要な設計上の決定を通じて、この一貫したパフォーマンスを提供できます。まず、DynamoDB テーブルの各レコードに主キーが含まれている必要があります。この主キーは、パーティション キーとオプションのソート キーで構成されます。 DynamoDB の 2 番目の重要な設計上の決定は、API が主キーの使用を大幅に強制することです。これについては後ほど詳しく説明します。 下の画像には、FinTech アプリケーションにサンプルのトランザクション データが含まれています。このテーブルでは、アプリケーション内の組織名のパーティション キーに加えて、UUID の一意性特性と、時間ベースのクエリを作成できる作成時間による並べ替え機能を提供する ベースの並べ替えキーを使用します。 ULID テーブル内のレコードには、販売者名、カテゴリ、金額などの他の属性が含まれており、これらはアプリケーションでは役立ちますが、DynamoDB の基礎となるアーキテクチャにとってはそれほど重要ではありません。重要な部分は主キー、特にパーティション キーにあります。 DynamoDB は内部的にデータを複数のストレージ パーティションに分割し、それぞれのパーティションにテーブル内のデータのサブセットが含まれます。 DynamoDB は、主キーのパーティション キー要素を使用して、特定のレコードを特定のストレージ パーティションに割り当てます。 テーブル内のデータ量またはテーブルに対するトラフィックが増加すると、DynamoDB はデータベースを水平方向にスケーリングする方法としてパーティションを追加します。 前述したように、DynamoDB の 2 番目の重要な設計上の決定は、API が主キーの使用を強く強制することです。 DynamoDB のほぼすべての API アクションには、少なくとも主キーのパーティション キーが必要です。このため、DynamoDB は、パーティションの数やテーブルの合計サイズに関係なく、あらゆるリクエストを適切なストレージ パーティションに迅速にルーティングできます。 これら 2 つのトレードオフにより、DynamoDB の使用方法には必然的に制限が生じます。主キーはアクセス パターンに関与する必要があるため、アクセス パターンを事前に慎重に計画および設計する必要があります。後でアクセス パターンを変更するのは困難な場合があり、手動による移行手順が必要になる場合があります。 ユースケースが DynamoDB のコア コンピテンシーに該当する場合、メリットを享受できます。規模に関係なく、一貫した予測可能なパフォーマンスが得られ、時間の経過によるアプリケーションの長期的な低下は見られません。さらに、運用負荷が低く、フルマネージドのエクスペリエンスが得られるため、ビジネスにとって重要なことに集中できます。 この例の中核となる操作は、このモデルに完全に適合します。組織のトランザクションのフィードを取得する場合、アプリケーションで組織 ID を利用できるため、DynamoDB オペレーションを使用して、同じパーティション キーを持つ連続したレコードのセットをフェッチできるようになります。特定のトランザクションに関する追加の詳細を取得するには、組織 ID とトランザクション ID の両方を使用して、DynamoDB リクエストを作成して目的のアイテムを取得します。 Query GetItem を使用して、これらの操作の動作を確認できます。指示に従ってアプリケーションをデプロイし、サンプル データをシードします。次に、デプロイされたサービスに HTTP リクエストを送信して、個々のユーザーのトランザクション フィードを取得します。これらの操作は、同時リクエストの数や DynamoDB テーブルのサイズに関係なく、高速で効率的な操作になります。 サンプル アプリケーション Rockset による DynamoDB の補完 これまで、DynamoDB を使用してコアのアクセス パターンを処理してきました。 DynamoDB は、キーベースのパーティショニングがあらゆる規模で一貫したパフォーマンスを提供するため、これらのパターンに最適です。 ただし、DynamoDB は他のアクセス パターンの処理にはあまり優れていません。 DynamoDB では、主キー以外の属性によって効率的にクエリを実行することはできません。 使用して、追加の属性によってデータのインデックスを再作成できますが、データのインデックスに使用される可能性のあるさまざまな属性が多数ある場合には、依然として問題が発生する可能性があります。 DynamoDB のセカンダリ インデックスを さらに、DynamoDB は、そのままでは集計機能を提供しません。 DynamoDB を使用して独自の集計を計算することもできますが、事前に集計を設計するソリューションと比較すると、柔軟性が低下したり、読み取り消費量が最適化されていない可能性があります。 これらのパターンを処理するために、 ます。 DynamoDB を Rockset で補完し Rockset は、データの二次的なインデックス セットとして考えるのが最も適切です。 Rockset はクエリ時にこれらのインデックスのみを使用し、読み取り中に DynamoDB に負荷を戻しません。 Rockset は、アプリケーション クライアントからの個別のトランザクション更新ではなく、プライマリ データ ストアからの継続的なストリーミング取り込みを行うように設計されています。 DynamoDB、MongoDB、Kafka、および多くのリレーショナル データベースを含む、多数のプライマリ データ ストアへの直接コネクタがあります。 Rockset はプライマリ データベースからデータを取り込むと、行インデックス、転置インデックス、列指向インデックスの概念を借用した でデータのインデックスを作成します。範囲、タイプ、地理空間などの追加のインデックスは、取り込まれたデータ タイプに基づいて自動的に作成されます。これらのインデックスの詳細については以下で説明しますが、この統合インデックスを使用すると、データに対するより柔軟なアクセス パターンが可能になります。 Converged Index これは Rockset の背後にある中心的な概念です。これは、プライマリ データストアからのフルマネージドのほぼリアルタイムの取り込みパイプラインを使用した、データのセカンダリ インデックスです。 チームは長い間、追加のユースケースを処理するために DynamoDB からデータを抽出して別のシステムに挿入してきました。 Rockset がテーブルからデータを取り込む方法の詳細に進む前に、Rockset がこの分野の他のオプションとどのように異なるかについて簡単に説明します。 Rockset と他のアプローチの間には、いくつかの重要な違いがあります。 まず、Rockset はフルマネージドです。データベース インフラストラクチャを管理する必要がないだけでなく、データを抽出、変換し、Rockset にロードするためのパイプラインを維持する必要もありません。他の多くのソリューションでは、システム間の「接着」コードを担当する必要があります。これらのシステムは重要ですが、データ構造の変更を防御する必要があるため、障害が発生しやすくなります。上流の変更は、これらのシステムを維持している担当者にとって下流の苦痛につながる可能性があります。 次に、Rockset はリアルタイム データを変更可能な方法で処理できます。他の多くのシステムでは、どちらか一方が得られます。データの定期的なエクスポートと一括ロードを実行することを選択できますが、その場合、ロード間のデータが古くなります。あるいは、追加専用の方法でデータをデータ ウェアハウスにストリーミングすることもできますが、変更されたデータに対してインプレース更新を実行することはできません。 Rockset は、新しいデータを挿入するのと同じくらい迅速かつ効率的に既存のアイテムの更新を処理できるため、変化するデータをリアルタイムで確認できます。 第三に、Rockset はインデックスを自動的に生成します。他の「フルマネージド」ソリューションでは、新しいクエリをサポートするために必要に応じてインデックスを構成する必要があります。 Rockset のクエリ エンジンは、1 セットのインデックスを使用してあらゆるクエリをサポートするように設計されています。システムにクエリを追加するたびに、インデックスを追加する必要がなく、スペースと計算リソースがどんどん占有されます。これは、アドホック クエリでもインデックスを最大限に活用できるため、管理者がサポートするオーダーメイドのインデックスを追加するのを待たずにクエリを高速化できることを意味します。 Rockset が DynamoDB からデータを取り込む方法 Rockset とは何か、そしてそれがどのように役立つのかについての基本を理解したので、DynamoDB テーブルを Rockset に接続しましょう。そうすることで、Rockset の取り込みプロセスがどのように機能するのか、また他のオプションとどのように異なるのかを学びます。 Rockset には多数のデータ ソース用の専用コネクタがあり、特定のコネクタの実装は上流のデータ ソースの仕様に応じて異なります。 DynamoDB と接続するために、Rockset は に依存します。 DynamoDB ストリームは、DynamoDB テーブルに対する各書き込み操作の詳細がストリームに記録される、DynamoDB の変更データ キャプチャ機能です。ストリームのコンシューマは、テーブルに対して発生したのと同じ順序でこれらの変更を処理し、ダウンストリーム システムを更新できます。 DynamoDB Streams DynamoDB ストリームは、Rockset が DynamoDB テーブルをほぼリアルタイムで最新の状態に保つのに最適ですが、これがすべてではありません。 DynamoDB ストリームには、テーブルでストリームが有効になった後に発生した書き込み操作のレコードのみが含まれます。さらに、 。ストリームが有効になる前、または 24 時間以上前に発生した操作はストリームには存在しません。 DynamoDB ストリームはレコードを 24 時間しか保持しません ただし、Rockset がクエリに正しく答えるためには、最新のデータだけでなく、データベース内のすべてのデータも必要です。これを処理するために、最初の一括エクスポート (テーブル サイズに応じて DynamoDB スキャンまたは 使用) を実行して、テーブルの初期状態を取得します。 S3 へのエクスポートを したがって、Rockset の DynamoDB 接続プロセスには 2 つの部分があります。 Rockset に取り込むために完全なテーブルをエクスポートする最初の プロセス。 ブートストラップ DynamoDB ストリームからの更新を消費し、Rockset 内のデータを更新する後続の プロセス。 継続的な これらのプロセスはどちらも Rockset によって完全に管理されており、ユーザーには透過的であることに注意してください。これらのパイプラインを保守したり、エラーが発生した場合のアラートに対応したりする責任はありません。 さらに、最初の取り込みプロセスで S3 エクスポート方法を選択した場合、Rockset 取り込みプロセスのいずれもメイン テーブルからの読み取りキャパシティー ユニットを消費しません。したがって、Rockset はアプリケーションのユースケースから消費を取り込んだり、実稼働の可用性に影響を与えたりすることはありません。 アプリケーション: DynamoDB を Rockset に接続する アプリケーションでの Rockset の使用に進む前に、Rockset を DynamoDB テーブルに接続しましょう。 まず、Rockset とテーブルの間に新しい統合を作成する必要があります。以下では大まかな手順を説明しますが、必要に応じて 確認できます。 、アプリケーション リポジトリでさらに詳しい手順を Rockset コンソールで、 に移動して、このプロセスを開始します。 新しい統合ウィザード 統合ウィザードで、統合タイプとして を選択します。次に、 をクリックして次のステップに進みます。 Amazon DynamoDB 「開始」 DynamoDB 統合ウィザードには、Rockset に DynamoDB テーブルへのアクセスを許可するための段階的な手順が記載されています。これには、テーブル エクスポート用の IAM ポリシー、IAM ロール、S3 バケットを作成する必要があります。 必要に応じて、これらの手順に従ってリソースを手動で作成できます。サーバーレスの世界では、できる限り を介して作成することを好みます。これには、これらのサポート リソースも含まれます。 コードとしてのインフラストラクチャ サンプル リポジトリには、Rockset 統合リソースの作成に必要なコードとしてのインフラストラクチャが含まれています。これらを使用するには、まず Rockset 統合ウィザードの下部で Rockset アカウント ID と外部 ID の値を見つけます。 これらの値をコピーして、serverless.yml ファイルの ブロック に貼り付けます。次に、 これらのリソースを作成します。 custom の関連セクション serverless.yml の 71 ～ 122 行目のリソースのコメントを解除して、 アプリケーションを再デプロイして、これらの新しいリソースを作成します。デプロイからの出力で、S3 バケット名と IAM ロール ARN をコピーして、Rockset コンソールの適切な場所に貼り付けます。 次に、「統合を保存」ボタンをクリックして統合を保存します。 統合を作成した後、統合から を作成する必要があります。 Rockset コンソールで に移動し、手順に従って統合を使用してコレクションを作成します。アプリケーション リポジトリに も記載されています。 Rockset コレクション コレクション作成ウィザード コレクションを作成するための段階的な手順 この接続が完了すると、通常、適切なサイズのインスタンスのセットで、DynamoDB 内のデータの挿入、更新、または削除が Rockset のインデックスに反映され、2 秒以内にクエリできるようになります。 Rockset を使用した複雑なフィルタリング Rockset を DynamoDB テーブルに接続したので、Rockset が既存のデータに対して新しいアクセス パターンをどのように有効にするかを見てみましょう。 コア機能のセクションで、DynamoDB が主キーに重点を置いていることを思い出してください。データに効率的にアクセスするには、主キーを使用する必要があります。したがって、主キーに組織名とトランザクション時間を使用するようにテーブルを構造化しました。 この構造は当社の中核的なアクセス パターンで機能しますが、ユーザーがトランザクションを閲覧するためのより柔軟な方法を提供したい場合があります。カテゴリ、販売者名、金額など、フィルタリングに役立つ属性が多数あります。 DynamoDB のセカンダリ インデックスを使用して、より多くの属性のフィルタリングを有効にすることもできますが、それでもここではあまり適していません。 DynamoDB の主キー構造では、多くのオプション属性の組み合わせを含む柔軟なクエリを簡単に実行できません。販売者名と日付でフィルタリングするためのセカンダリ インデックスを作成できますが、販売者名、日付、金額でフィルタリングできるようにするには、別のセカンダリ インデックスが必要になります。カテゴリでフィルタリングするアクセス パターンには、3 番目のセカンダリ インデックスが必要になります。 ここではその複雑さに対処するのではなく、Rockset に頼ることにします。 Rockset が Converged Index を使用して、複数の方法でデータにインデックスを付けることを以前に説明しました。それらの方法の 1 つは転置インデックスです。逆インデックスを使用すると、Rockset は各属性に直接インデックスを付けます。 このインデックスがどのように構成されているかに注目してください。各属性名と値はインデックスのキーとして使用され、値は対応する属性名と値を含むドキュメント ID のリストになります。キーは、自然な並べ替え順序で範囲クエリを効率的にサポートできるように構築されています。 転置インデックスは、選択的なフィルター条件を持つクエリに最適です。ユーザーがトランザクションをフィルタリングして、特定の条件に一致するトランザクションを見つけられるようにしたいと想像してください。 Vanlay Industries 組織の誰かが、最近チポトレを注文した回数に興味を持っています。 これは、次のようなクエリで見つけることができます。 SELECT * FROM transactions WHERE organization = 'Vandelay Industries' AND merchant_name = 'Chipotle' 顧客名と販売者名に対して選択フィルターを実行しているため、逆索引を使用して一致するドキュメントをすばやく見つけることができます。 Rockset は、逆索引内の属性名と値のペアの両方を検索して、一致するドキュメントのリストを見つけます。 これら 2 つのリストを取得すると、それらをマージして両方の条件セットに一致するレコードのセットを見つけ、結果をクライアントに返すことができます。 DynamoDB のパーティションベースのインデックス作成がパーティション キーを使用する操作に効率的であるのと同様に、Rockset の逆インデックスを使用すると、データセット内の任意のフィールド (埋め込みオブジェクトの属性や埋め込み配列内の値であっても) を効率的に検索できます。 アプリケーション: アプリケーションでの Rockset API の使用 Rockset がデータセットに対して選択的なクエリを効率的に実行する方法がわかったので、Rockset クエリをアプリケーションに統合する実践的な側面を見ていきましょう。 Rockset は、認可トークンによって保護された RESTful サービスを公開します。一般的なプログラミング言語用の SDK も利用できます。これにより、データベースにアクセスするために複雑なプライベート ネットワーク構成をセットアップする必要がないため、サーバーレス アプリケーションとの統合に最適になります。 アプリケーションで Rockset API と対話するには、Rockset API キーが必要です。 Rockset コンソールの で作成できます。それが完了したら、その値をserverless.yml ファイルにコピーし、再デプロイしてアプリケーションで使用できるようにします。 API キー セクション 補足: 簡単にするために、この API キーを環境変数として使用します。実際のアプリケーションでは、 や を使用してシークレットを保存し、環境変数を回避する必要があります。 パラメータ ストア AWS Secrets Manager など を見て、Rockset API とどのように対話するかを確認してください。クラスの初期化では、Rockset への呼び出しに使用される Rockset クライアント オブジェクトが取り込まれます。 TransactionService クラス には、Rockset と対話するための次のクエリがあります。 サービス クラスの filterTransactions メソッド const response = await this._rocksetClient.queries.query({ sql: { query: ` SELECT * FROM Transactions WHERE organization = :organization AND category = :category AND amount BETWEEN :minAmount AND :maxAmount ORDER BY transactionTime DESC LIMIT 20`, parameters: [ { name: "organization", type: "string", value: organization, }, { name: "category", type: "string", value: category, }, { name: "minAmount", type: "float", value: minAmount, }, { name: "maxAmount", type: "float", value: maxAmount, }, ], }, }); このやり取りについては、注意すべき点が 2 つあります。まず、ユーザーからの入力を処理するときに、クエリで名前付きパラメーターを使用しています。これは、SQL インジェクション攻撃を回避するために SQL データベースで一般的に行われる方法です。 2 番目に、SQL コードがアプリケーション コードと混在しているため、時間の経過とともに追跡するのが困難になる可能性があります。これでも機能しますが、もっと良い方法があります。次のユースケースを適用する際に、アプリケーションで Rockset Query Lambda を使用する方法を見ていきます。 Rockset を使用した集約 ここまで、データベースが特定のフィルター述語に一致する個々のレコードまたはレコードのセットを見つける方法について説明する中で、DynamoDB と Rockset のインデックス作成戦略を確認してきました。たとえば、DynamoDB ではレコードの検索に主キーの使用が推奨されるのに対し、Rockset の転置インデックスでは、高度に選択されたフィルター条件を使用して効率的にレコードを検索できることがわかりました。 この最後のセクションでは、少しギアを切り替えて、直接インデックスを作成するのではなく、データ レイアウトに焦点を当てます。データ レイアウトを考える際に、行ベースと列ベースの 2 つのアプローチを比較します。 行ベースのデータベースは、その名前が示すように、データをディスク上に行に配置します。 PostgreSQL や MySQL などのほとんどのリレーショナル データベースは行ベースのデータベースです。 DynamoDB などの多くの NoSQL データベースも同様です。たとえそのレコードが技術的にリレーショナル データベースの意味での「行」ではないとしてもです。 行ベースのデータベースは、これまで見てきたアクセス パターンに最適です。 ID によって個々のトランザクションを取得するとき、またはいくつかのフィルター条件に従って一連のトランザクションを取得するときは、通常、各トランザクションのすべてのフィールドが返されることが必要です。レコードのすべてのフィールドが一緒に格納されるため、通常は 1 回の読み取りでレコードを返します。 (注: これについては若干のニュアンスが含まれます)。 集約はまったく別の話です。集計クエリでは、すべてのトランザクションの数、トランザクション合計の合計、または一連のトランザクションの月ごとの平均支出などの集計を計算します。 Vanlay Industries 組織からユーザーに戻って、過去 3 か月を調べて、各月のカテゴリ別の合計支出を見つけたいと想像してください。このクエリの簡略版は次のようになります。 SELECT category, EXTRACT(month FROM transactionTime) AS month, sum(amount) AS amount FROM transactions WHERE organization = 'Vandelay Industries' AND transactionTime > CURRENT_TIMESTAMP() - INTERVAL 3 MONTH GROUP BY category, month ORDER BY category, month DESC このクエリの場合、結果を計算するために大量のレコードを読み取る必要がある可能性があります。ただし、各レコードには多くのフィールドが必要ないことに注意してください。この結果を決定するには、カテゴリ、トランザクション時間、組織、金額の 4 つだけが必要です。 したがって、このクエリを満たすためにより多くのレコードを読み取る必要があるだけでなく、行ベースのレイアウトは結果に不要なフィールドを大量に読み取ることになります。 逆に、列ベースのレイアウトでは、ディスク上のデータが列に格納されます。 Rockset の Converged Index は、列指向のインデックスを使用して、列ベースのレイアウトでデータを保存します。列ベースのレイアウトでは、データは列ごとにまとめて保存されます。個々のレコードは、インデックス作成のためにその構成列に分割されます。 クエリで多数のレコードの「amount」属性を合計する集計を行う必要がある場合、Rockset は列指向インデックスの「amount」部分をスキャンするだけでそれを実行できます。これにより、行ベースのレイアウトと比較して、読み取られて処理されるデータの量が大幅に削減されます。 デフォルトでは、Rockset の列指向インデックスは列内の属性を順序付けしないことに注意してください。特定の顧客のデータを操作するユーザー向けのユースケースがあるため、列指向インデックスの使用中にスキャンするデータの量を減らすために、列指向インデックスを顧客ごとに整理したいと考えています。 Rockset は、これを支援するために を提供します。クラスタリングを使用すると、列指向インデックスを「組織」属性によってクラスタリングすることを指定できます。これにより、すべての列値が列指向インデックス内の構成ごとにグループ化されます。したがって、Vandlay Industries がデータの集計を実行しているとき、Rockset のクエリ プロセッサは他の顧客の列指向インデックスの部分をスキップできます。 列指向インデックスでのデータ クラスタリング Rockset の行ベースのインデックスが処理にどのように役立つか アプリケーションでの列指向インデックスの使用に進む前に、Rockset の Converged Index の別の側面について話したいと思います。 先ほど、完全なレコードを取得するときに行ベースのレイアウトが使用されると述べ、DynamoDB と Rockset の逆インデックス クエリの両方がこれらのレイアウトを使用していることを示しました。 それは部分的にしか真実ではありません。逆インデックスは、任意の属性による効率的な検索のために列名と値を一緒に格納するため、列ベースのインデックスといくつかの類似点があります。各インデックス エントリには、指定された列名と値の組み合わせを含むレコードの ID へのポインタが含まれています。関連する ID が転置インデックスから検出されると、Rockset は行インデックスを使用して完全なレコードを取得できます。 Rockset は、辞書エンコードやその他の高度な圧縮技術を使用して、データ ストレージ サイズを最小限に抑えます。 これで、Rockset の Converged Index がどのように組み合わされるかがわかりました。 集計のために特定の列内の多数の値を迅速にスキャンするために使用されます。 列ベースのインデックスは、 列名と値に対する選択フィルターに使用されます。 逆インデックスは、 句で参照される可能性のある追加の属性をフェッチするために使用されます。 行ベースのインデックスは、射影 内部では、Rockset の強力なインデックス作成およびクエリ エンジンがデータの統計を追跡し、クエリを効率的に実行するための最適な計画を生成します。 アプリケーション: アプリケーションで Rockset クエリ Lambda を使用する 列指向インデックスを使用する Rockset 集計クエリを実装してみましょう。 前のクエリでは、SQL クエリを Rockset API に直接書きました。これは、高度にカスタマイズ可能な一部のユーザー インターフェイスから行うには正しいことですが、SQL コードがより静的である場合には、より良いオプションがあります。アプリケーション ロジックの途中で乱雑な SQL コードを維持することは避けたいと考えています。 これを支援するために、Rockset にはクエリ ラムダと呼ばれる機能があります。クエリ ラムダは、Rockset コンソールに登録され、名前が付けられ、バージョン付けされ、パラメーター化されたクエリです。 Rockset でクエリ Lambda を構成すると、クエリ Lambda のフルマネージドでスケーラブルなエンドポイントを受け取ります。このエンドポイントは、Rockset によって実行されるパラメータを使用して呼び出すことができます。さらに、各クエリ ラムダの監視統計も取得できるため、変更を加えた際のクエリ ラムダのパフォーマンスを追跡できます。 ことができますが、集計クエリを処理するために最初のクエリ ラムダを設定してみましょう。 。 クエリ ラムダの詳細については、ここで学ぶ 完全なチュートリアルは、アプリケーション リポジトリにあります Rockset コンソールの に移動します。次のクエリをエディタに貼り付けます。 [クエリ エディター] セクション SELECT category, EXTRACT( month FROM transactionTime ) as month, EXTRACT( year FROM transactionTime ) as year, TRUNCATE(sum(amount), 2) AS amount FROM Transactions WHERE organization = :organization AND transactionTime > CURRENT_TIMESTAMP() - INTERVAL 3 MONTH GROUP BY category, month, year ORDER BY category, month, year DESC このクエリは、特定のカテゴリとトランザクションの月に基づいて、特定の組織の過去 3 か月間のトランザクションをバケットにグループ化します。次に、カテゴリの値を月ごとに合計して、各月に費やされた合計金額を求めます。 クエリの「:organization」構文で示されているように、「organization」属性のパラメーターが含まれていることに注意してください。これは、クエリを実行するには組織値を渡す必要があることを示します。 Rockset コンソールにクエリをクエリ Lambda として保存します。次に、 を確認します。 Query Lambda を名前で呼び出し、ユーザーが指定した「組織」プロパティを渡します。 TransactionService クラスの fetchTransactionsByCategoryAndMonth コード これは、アプリケーションで処理するのに非常に簡単なコードです。さらに、Rockset は、各クエリ Lambda のバージョン管理とクエリ固有のモニタリングを提供します。これにより、長期にわたるクエリの保守が容易になり、クエリ構文の変更がパフォーマンスにどのような影響を与えるかを理解することが容易になります。 結論 この投稿では、DynamoDB と Rockset を一緒に使用して、ユーザーにとって高速で快適なアプリケーション エクスペリエンスを構築する方法について説明しました。そうすることで、概念的な基礎とアプリケーションを実装するための実践的な手順の両方を学びました。 まず、DynamoDB を使用してアプリケーションのコア機能を処理しました。これには、特定の顧客のトランザクション フィードの取得や個々のトランザクションの表示などのアクセス パターンが含まれます。 DynamoDB の主キーベースのパーティショニング戦略により、あらゆる規模で一貫したパフォーマンスを提供できます。 ただし、DynamoDB の設計により柔軟性も制限されます。任意のフィールドに対する選択的なクエリや、多数のレコードにわたる集計は処理できません。 これらのパターンを処理するために、Rockset を使用しました。 Rockset は、データ量の多いアプリケーションを強化するフルマネージドのセカンダリ インデックスを提供します。 Rockset がプライマリ データ ストアからの継続的な取り込みパイプラインをどのように維持し、反転インデックス、列インデックス、行インデックスを組み合わせた Converged Index でデータのインデックスを作成するのかを見てきました。パターンを確認していくうちに、Rockset の各インデックス作成技術がどのように連携して快適なユーザー エクスペリエンスを処理するかがわかりました。最後に、Rockset を DynamoDB テーブルに接続し、アプリケーション内で Rockset と対話するための実践的な手順を実行しました。 にも登場します。 ここ
