四⽉月⼗十三⽇日

CloudDesignPattern night

⽬目的Counter  Table

実装

KVSの弱点

データ件数に関わらず変わらぬ

パフォーマンスで

合計、countなどの集計が欲しい

⽬目的

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

構造

集計専⽤用のテーブルを作る

ItemのUpdate,Put,Deleteの際に

集計専⽤用

実装

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

利点構造

sumcount

data

注意点利点

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

利⽤用事例注意点

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

寄贈したアーキテクト

データ

マイニング

利⽤用事例

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

⼀一⾔言

JAWS-‑UG  Osaka

@tottokug

好きなAWS

DyamoDB

SimpleDB

CloudSearch

寄贈したアーキテクト

わざわざTableを作らなくても、同じテーブルのItemでやったらいいんじゃないか？という説もあるけれど、

CounterTableと⾔言いたかっただけです。

もうひとつ

⽬目的Temporary  Table

実装

データベースのコストを下げる

⽬目的

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

構造

CPU使⽤用時間や、データ量に

よって課⾦金されるサービスに

⼀一時的に書込

実装

RDBMSに⼊入れるはずのデータを⼀一旦仮でQueueや単価の低いストレージに⼊入れ、その後、定期的にバッチ処理などでデータベースに格納する。バッチ処理⽤用のサーバはScheduled  Autoscalingパターンを利⽤用

利点構造

注意点利点

RDBMSは読込が必要な時とtemporaryからデータを移す時だけたちあげておけば良い。書込がぐんと減るので、RDBMSのスペックを⼀一つ下げられるかもしれない。

コストダウン出来る。

利⽤用事例注意点

リアルタイムでの集計は出来ない。タイムラグがあっても問題ないデータの集計をするのに向いている。

寄贈したアーキテクト

Webサービスの

課⾦金

利⽤用事例

APIコールがある毎に課⾦金情報をRDBMSに⼊入れていたら⼤大変。⼀一時テーブルに⼊入れておいて、⽉月次の〆の処理をするのも⼤大変そんな時にTemporary  Table  Pattern1⽇日⼀一回とかRDBMSに移す。

⼀一⾔言

JAWS-‑UG  Miyazaki

@tottokug

好きなAWS

DyamoDB

SimpleDB

CloudSearch

寄贈したアーキテクト

c1.mediumより上のインスタンス使ったら負けかなと思ってます。microしか使わないのが理想