質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Amazon RDS

Amazon RDSは、米アマゾン社が提供しているRDBMSサービス。クラウド上でのリレーショナルデータベースの構築および運用が可能です。MySQL/PostgreSQL/Oracle/SQL Serverのインストールを容易にすることができます。

AWS Lambda

AWS Lambdaは、クラウド上でアプリを実行できるコンピューティングサービス。サーバーのプロビジョニングや管理を要せず複数のイベントに対してコードを実行します。カスタムロジック用いた他AWSサービスの拡張やAWSの規模やパフォーマンスを用いたバックエンドサービスを作成できます。

Amazon DynamoDB

Amazon DynamoDBは、 AWS上のNoSQLデータベースサービスです。フルマネージド型のサービスで、スキーマレス、高速且つ安定性のある動作、自動的に容量を変更する自動スケーリングなどの特徴を持ちます。

NoSQL

NoSQL(not only SQL)は、リレーショナルデータベース管理システムとは異なるデータベースシステムを指す言葉です。

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

Q&A

0回答

760閲覧

DynamoDBについてセカンダリインデックスとテーブル分割について

caturra

総合スコア6

Amazon RDS

Amazon RDSは、米アマゾン社が提供しているRDBMSサービス。クラウド上でのリレーショナルデータベースの構築および運用が可能です。MySQL/PostgreSQL/Oracle/SQL Serverのインストールを容易にすることができます。

AWS Lambda

AWS Lambdaは、クラウド上でアプリを実行できるコンピューティングサービス。サーバーのプロビジョニングや管理を要せず複数のイベントに対してコードを実行します。カスタムロジック用いた他AWSサービスの拡張やAWSの規模やパフォーマンスを用いたバックエンドサービスを作成できます。

Amazon DynamoDB

Amazon DynamoDBは、 AWS上のNoSQLデータベースサービスです。フルマネージド型のサービスで、スキーマレス、高速且つ安定性のある動作、自動的に容量を変更する自動スケーリングなどの特徴を持ちます。

NoSQL

NoSQL(not only SQL)は、リレーショナルデータベース管理システムとは異なるデータベースシステムを指す言葉です。

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

0グッド

0クリップ

投稿2019/08/07 04:45

RDSにて開発を行っておりましたが、VPCでの遅延やコネクション数などの諸事情もある上にビジネス的な要件よりDynamodbに移行が決まりました。
そこでDynamodbについてのawsが発行している文献を読み、テーブル設計をしてある程度運用して一ヶ月くらい経ったのですが、いくつか概念についての質問があります。厳密さを重視というよりは、大まかなイメージ把握をご教示いただければ幸いでございます。

具体的には、wordpressのようなブログサイトのデータ構造をdynamodbに置換したイメージです。
hash key: articleId
sort key: create_at
attribute: category, tagList, authorId, itemId, authorAttributes{}, otherAttributes{}

この中でarticleId, category, tagList, authorId, itemIdが検索に使用するキーです。
今のところ、

  • cateogryは事前に組み合わせ(親カテゴリーと小カテゴリーなどの800パターンくらい)があるため、文字列でGSIとしています。
  • tagListは別テーブルに保持(tagId(P), counts(S), articlesList{})しておりまして、タグの検索にあたってarticlesListを取得して、戻してaritcleのテーブルにbatchgetを行って複数取得しております。GSIでもLSIでもないです。こちらを参考にしました。
  • authorId, itemId はGSIでして、=を使用してgetするのがメインで、普通の使い方です。

##LSIとGSIなどのセカンドインデックスは、tableの中にindexをよしなにハッシュキーないしソートキーにしたようなtableを別に持つイメージでしょうか?
awsのqueryについての文献では、料金について

  • インデックスのプロビジョニングされた読み込みキャパシティー
  • ベーステーブルのプロビジョニングされた読み込みキャパシティー

と記述されています。例えばdataAを保存する際に、表現がわからないため普通のテーブルのことをメインテーブルと呼ぶと、メインテーブルにももちろん保存され、LSIとしてハッシュキーとソートキーが保存もされる場所、GSIではそこで選択されているattribute達が保存される場所が別に存在するという意味なのでしょうか?
それともそもそも保存形式としてのセカンダリインデックスであり、単にdataAというデータに新規にリレーションデータベースでいうprimary keyのようなものが保存されるという意味合いなのでしょうか?

##そもそもアクセスパターンが多くデータ数も多いためscanを使いたくないと考えている場合、queryを使うとしてGSIを増やすのは得策でしょうか?
今のところGSIを3つ使用しております。これ以上増えることも考えられますし、何よりテーブル設計をもう少し正規化のように綺麗にすることができたらなと思うこと多く、お尋ねしたいです。
具体的には、tagListのように検索するパターン別に(今回では、categoryなど)別途テーブルを用意するのは得策なのでしょうか?
ケースバイケースだと思うのですが、そのケースバイケースにて考慮すべき内容をご教示いただけると幸いでございます。

初めての質問になりまして、正しくないフォーマットでしたら申し訳ございません、
何卒よろしくお願いいたします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだ回答がついていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問