1. 四
⽉月
⼗十
三
⽇日
CloudDesignPattern night

2. Counter Table ⽬目的

3. ⽬目的 実装
データ件数に関わらず変わらぬ
パフォーマンスで
合計、countなどの集計が欲しい
KVSを利⽤用しているとGROUP化が出来ないため、
条件に合うデータの数や、数値の合計、数値の平均
等を求めるためには、アプリケーション側で実装す
る必要があった。
データの件数が増えても、変わらぬパフォーマンス
KVSの弱点
でこれら集計結果の値を取得したい。

4. 実装 構造
集計専⽤用のテーブルを作る
ItemのUpdate,Put,Deleteの際に
集計専⽤用
集計専⽤用のテーブルを作成する。
ItemのUpdate,Put,Deleteを⾏行う際
同時に集計専⽤用テーブルの値もUPDATEする
(CAS操作)
アイテム数に制限のないDynamoDBなら可能
データ本体はSimpleDBでも良い

5. 構造 利点
sum
count
data

6. 利点 注意点
データ量が増えたとしても集計の処理がなくなり、
時間は1回のReadの時間になるので、集計のパ
フォーマンスが保証される

7. 注意点 利⽤用事
予めGROUP化するAttributeを決める必要がある。
必要なWriteUnitが単純に2倍以上になる。
但し、集計するためにReadを6回以上しそうなデー
タ量であればコストは安くなる。

8. 利⽤用事例 寄贈し
データ
マイニング
データマイニングでは、⼤大量のデータを扱う
⼤大量のデータ使うなら、なにも考えずに
DynamoDB使いたい。
だけどDynamoDBだとSUM,AVG,COUNTとか⾟辛
い。そんな時

9. 寄贈したアーキテクト
好きなAWS
DyamoDB
SimpleDB JAWS-‑UG Osaka
CloudSearch @tottokug
⼀一⾔言 わざわざTableを作らなくても、同じテーブルの
Itemでやったらいいんじゃないか？という説もある
けれど、
CounterTableと⾔言いたかっただけです。

10. もうひとつ

11. Temporary Table ⽬目的

12. ⽬目的 実装
データベースのコストを下げる
集計処理がしたいようなデータを扱っています。
時間課⾦金のデータベースを利⽤用していると、もしア
クセスが無くても費⽤用が掛かってしまう。
スペックの⾼高いものを使うようだと、もう⼤大変

13. 実装 構造
CPU使⽤用時間や、データ量に
よって課⾦金されるサービスに
⼀一時的に書込
RDBMSに⼊入れるはずのデータを
⼀一旦仮でQueueや単価の低いストレージに⼊入れ、
その後、定期的にバッチ処理などでデータベースに
格納する。
バッチ処理⽤用のサーバはScheduled Autoscalingパ
ターンを利⽤用

14. 構造 利点

15. 利点 注意点
RDBMSは読込が必要な時とtemporaryからデータ
を移す時だけたちあげておけば良い。
書込がぐんと減るので、RDBMSのスペックを⼀一つ
下げられるかもしれない。
コストダウン出来る。

16. 注意点 利⽤用事
リアルタイムでの集計は出来ない。
タイムラグがあっても問題ないデータの集計をする
のに向いている。

17. 利⽤用事例 寄贈し
Webサービスの
課⾦金
APIコールがある毎に課⾦金情報をRDBMSに⼊入れて
いたら⼤大変。
⼀一時テーブルに⼊入れておいて、⽉月次の〆の処理をす
るのも⼤大変
そんな時にTemporary Table Pattern
1⽇日⼀一回とかRDBMSに移す。

18. 寄贈したアーキテクト
好きなAWS
DyamoDB
SimpleDB JAWS-‑UG Miyazaki
CloudSearch @tottokug
⼀一⾔言 c1.mediumより上のインスタンス使ったら負けかな
と思ってます。
microしか使わないのが理想