LoginSignup
3
1

More than 5 years have passed since last update.

DynamoDB TIPS

Last updated at Posted at 2018-08-19

AWSのDynamoDBについて学んだ事を勉強用に記述していきます。

1 結果整合性

DynamoDBなどのNoSQLDBは可用性を上げるために複数のサーバで重複してデータを管理する。
3台に分散して管理しているとすると3つ全てのサーバに書き込みが完了するまでにはタイムラグが生じる。
そのため、書き込みが終了した直後に読み込みを行った際にまだ書き込みが終了していないサーバに読みに行ってしまうと書き込んだ内容が取得できない可能性がある。
少し時間を置いて再度読み込みを行うと解消される。
これを結果参照性という。

2 強い整合性

上記の結果整合性による現象を防ぐために強い整合性を設定することができる。
強い整合性とは書き込みを行う対象の3台のサーバのうち2台からデータを取得し、一致すればそれを返す。一致しなければもう一台からも取得して多数決を行う。というもの。
DynamoDBが書き込み完了とするのは2台のサーバに書き込みが完了した時点なのでこれによって結果整合性によるデータが取得できない現象を解決できる。
デメリットとして強い整合性を設定しない場合と比べるとスループットが低下する。

3 スループットの調整

テーブルの作成時にスループットを設定できる。

  • 読み込みキャパシティーユニット(RCU)
  • 書き込みキャパシティユニット(WCU)

これらを個別に設定することができ、読み込み頻度が高いデータが保存されるテーブルならRCUを大きめに設定することが可能。
スループットに対して閾値を設定し、その閾値を超えた際にCloudWatchから
アラートを出すことも可能。
(スループットの監視機能)

RCU

RCUの1つ当たりのスループットは4kB/秒。
ただし、DBに強い整合性を持たせてる場合は1つ当たり2kBになる。
また、データサイズは4kBの倍数に切り上げて計算される。
例えば、

  • 1kBのデータを読み込むためには1RCUが必要
  • 5kBのデータを読み込むためには2RCUが必要

WCU

WCUは1つ当たりのスループットは1kB/秒。
データサイズは4kBの倍数に切り上げて計算される。
例えば、

  • 300Bのデータを読み込むためには1RCUが必要
  • 1.2kBのデータを読み込むためには2RCUが必要

4 ローカル・セカンダリ・インデックスとグローバル・セカンダリ・インデックス

ローカル・セカンダリ・インデックス(LSI)

  • テーブルの作成時に設定可能。
  • DynamoDBのテーブルには主キーがパーティションキーのみのものとパーティションキーとソートキーを組み合わせるものがあるが、パーティションキーとソートキーを組み合わせるタイプのテーブルでのみ設定可能。
  • 通常の検索ではプライマリキーとソートキーを条件にして検索条件を設定するが、プライマリキー+任意の属性で検索条件を作成できるようにするもの。
  • 結果整合性と強い整合性の両方をサポート。
  • 指定した属性のみを射影する
  • テーブルに入っているデータとは別にLSIで取得する属性分のデータを新しいテーブルとして保持するようなイメージ。合計容量が10GBを超えないようにする必要があるのであまり不要な属性を射影しないようにする。

グローバル・セカンダリ・インデックス

  • 作成はテーブル作成時でも作成後でも任意のタイミングで可能。
  • テーブルの主キーもパーティションキーのみでもパーティションキー+ソートキーでもよい。
  • 任意のキーを使用して検索条件を作成できるようになる。
  • 結果整合性のみをサポートする。
  • 容量の制限はLSIと同じ。

5 読み込み-変更-書き込み設計パターン(オプティミスティック同時実行制御)

いわゆる楽観排他制御を実装可能。
バージョン番号等を用いて自分の読み込み⇒書き込みまでの間に誰かが書き込みを行っていないか検出する。

6 ホットパーティションの回避

DynamoDBではパーティションキーの値によってデータが保存されるパーティションが決定される。
毎回同じパーティションになるようなパーティションキーを設定してしまうと特定のパーティションに読み書きが集中するのでパーティションが分散されるようにパーティションキーの末尾に乱数を設定するなどするのがベストプラクティス。

7 ホットデータとコールドデータの分離

トランザクションデータだと

  • 作成日時が新しいものほどアクセス頻度が高い。(ホットデータ)
  • 作成日時が古いものほどアクセス頻度は低い。(コールドデータ)

これらを期間ごとにテーブルを切り替えるなどして別テーブルになるように保存し、ホットデータが入れられるテーブルのスループットを高くしてコールドデータのテーブルのスループットを低くするのがベストプラクティス。

8 DynamoDB Accelerator(DAX)

  • DynamoDB用のキャッシュサービス。
  • 通常DynamoDBのレイテンシは1ミリ秒単位だが、1マイクロ秒単位に縮小可能。
  • DAXを使用することでRCUやWCUを必要以上に大きく設定することなくスループットを確保できるのでコスト削減になる。
3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1