Category: Amazon DynamoDB

この記事では、Amazon DynamoDB のテーブル構造がスキャンパフォーマンスにどのように影響するかについて説明し、テーブルのスキャン時間を最適化する方法をご紹介します。 Amazon DynamoDB は、柔軟なスキーマを使用できる NoSQL データベースです。これは、項目それぞれにどのような属性が存在するかという点で、同じテーブル内の項目が互いに異なることを意味します。 DynamoDB のスキーマとアクセスパターンの大部分は GetItem 操作と Query 操作を中心に方向づけと最適化が行われ、これによってテーブルまたはインデックスから単一項目にアクセスするときに一貫した 1 桁台のミリ秒での応答時間が提供されますが、ユースケースとアクセスパターンには、テーブルとインデックスのスキャンが必要なものもあります。 概要 柔軟なスキーマを持つデータベースでは、データベーススキャンから返されたすべての項目について、ネットワーク応答にデータだけでなく、メタデータも含まれています。このメタデータには、各属性の属性名とデータタイプが含まれる場合があります。 各項目により多くの属性を追加すると、クライアントオーバーヘッドもいくらか追加されます。これは、ネットワーク応答の各列が、適切なクライアントデータ構造にマーシャルされる必要があるからです。その例は Python ディクショナリー、Node.js マップ、Java オブジェクトなどです。 属性メタデータは容量を消費するため、DynamoDB 応答の 1 MB 上限に収まる項目数が少なくなります。その結果として、データのスキャンに必要な往復回数が増えることになります。 テスト方法 パーティションキーとソートキー (どちらも文字列) で構成されるプライマリキーというシンプルな構造のテーブルを 1 つ作成しました。144 個のランダムな文字の文字列が含まれる field1 という名前の 3 番目の文字列属性もあります。 また、3 文字および 6 文字の属性値の両方を持つ、7 文字の属性名 (field01… field24) の異なる組み合わせを使ったテーブルも作成しました。これらのテーブルには、最初のテーブルと同じプライマリキー構造があります。 柔軟なスキーマを持つ NoSQL データベースは、項目ごとに属性名を保存する必要があります。項目の属性が増える、または属性名が長くなると、項目は属性名を保存するためにより多くの容量を消費します。 最後に、24 個の属性 (それぞれが同じ 7 文字の属性名と […]

広告技術 (アドテック) 企業は、Amazon DynamoDB を使用して、ユーザープロファイル、ユーザーイベント、クリック数、訪問済みリンクなどのさまざまな種類のマーケティングデータを保存します。用途としては、リアルタイム入札 (RTB)、広告ターゲティング、アトリビューションなどがあります。このブログ記事では、DynamoDBを使用するアドテック企業の最も一般的なユースケースと設計パターンを特定します。 こうしたユースケースでは、高いリクエスト率 (1 秒あたり数百万件のリクエスト)、低くて予測可能なレイテンシー、および信頼性が必要です。大規模な読み取りボリュームがある場合、またはミリ秒未満の読み取りレイテンシーが必要な場合、企業は DynamoDB Accelerator (DAX) によるキャッシングを利用します。ますます多くのアドテック企業が、複数の地域で RTB や広告ターゲティングプラットフォームをデプロイしており、これには AWS リージョン間でのデータレプリケーションが必要になります。 完全マネージド型サービスである DynamoDB を使用すると、アドテック企業はデータベースの運用にリソースを投資することなく、こうした要件をすべて満たすことができます。また、こうした企業は、DynamoDB への移行によってデータベースの支出が削減されるため、DynamoDB の費用対効果も高いことに気付きます。たとえば、GumGum が自社のデジタル広告プラットフォームを DynamoDB に移行したとき、古いデータベースに比べてコストが 65〜70％ 削減されたと推定しています。 この記事で使用される用語 この記事では、以下のデータモデリングと設計パターンの用語を使用します。 1:1 モデリング: パーティションキーをプライマリキーとして使用する 1 対 1 関係のモデリング。 1:M モデリング: パーティションキーとソートキーをプライマリキーとして使用する 1 対多関係のモデリング。 DAX によるキャッシング: DynamoDB の前で読み取りキャッシュとして DAX を使用すると、読み取りのレイテンシーを短縮できるだけでなく、頻繁にアクセスされるアイテムに対する高い読み取り負荷を費用効果の高い方法で処理することができます。 アドテックのユースケースと設計パターン ユースケース データモデリングまたは設計パターン RTB および広告ターゲティングでのユーザープロファイルの保存 1:1 モデリング、1:M モデリング […]

7 年前の今日、AWS の CTO であった Werner Vogels が Amazon DynamoDB のリリースを発表しました。そこで、2018 年と 2017 年の「最新情報」の記事を振り返って、DynamoDB の最近の成長を示すのもおもしろいだろうと考えました。こうした記事は、トランザクション、オンデマンドキャパシティモード、ポイントインタイムリカバリ、グローバルテーブル、バックアップとリストア、Auto Scaling など、さまざまな機能リリースをすべて説明しています。

このブログ記事では、お使いのアプリケーションに対するデータベースサービスの候補として DynamoDB を評価する方法を説明してから、DynamoDB への移行を計画する方法を、ベストプラクティスを含めて説明します。

従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増えつづけ、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか? このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。

AWS ではこの 2019 年、DynamoDB での作業時にミッションクリティカルなワークロードのパフォーマンスを最大化して、コストを最適化するために役立つ Amazon DynamoDB のベストプラクティスに従うことをお勧めします。この記事は、このような抱負の維持を助ける DynamoDB のコンテンツに焦点を当てて行きます。

このブログ記事では、リソースをひとつ、または複数のタグに基づいてグループ化し、スケーリングプランを使用することによって AWS Auto Scaling ポリシーを集約、設定、および管理する方法をご紹介します。スケーリングプランを使用すると、タグを用いることによって AWS Auto Scaling ポリシーの作成を自動化し、これらのポリシーを簡単に変更できます。

先日 (2018/12/25) 開催しました AWS Black Belt Online Seminar「Amazon DynamoDB Advanced Design Pattern」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 「時系列データが必要なアプリケーション」のスライドで GSIKey Rand(0-N) というのがありましたが、これはどのような目的がありますか？ A. こちらにあるような形で、書き込み後の検索効率向上の為のテクニックになります。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております！ AWS Black Belt Online Seminar 1月分申込先 ≫ Redshift Recently Features Update 2019 年 […]

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

このブログ記事では、データを保護する一般的なデータセキュリティパターンとそれに対応する AWS セキュリティコントロールに焦点を当てます。クラウド内の機密データを保護するための効果的な戦略を立てるには、一般的なデータセキュリティパターンをよく理解し、これらのパターンを明確にマッピングしてクラウドセキュリティコントロールに活かすことが必要です。