[AWSマイスターシリーズ] Amazon DynamoDB

re:G
ene

AWS マイスターシリーズ

rate

Amazon DynamoDB
2013.10.02
アマゾンデータサービスジャパン株式会社
ソリューションアーキテクト　今井雄太

© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.

アジェンダ
! NoSQLとRDB
! DynamoDBとは
! DynamoDBを使ってみる
!   ツールとエコシステム
!   When to use
!   まとめ

2

NoSQLとRDB

3

世の中はNoSQLブーム？

!
!
!
!

MongoDB
Riak
HBase
 Cassandra

!  Neo4j
! CounchDB
! DynamoDB

他にもたくさん

http://ja.wikipedia.org/wiki/NoSQL
4

NoSQL vs RDB

! NoSQL

•  BASE属性
•  ⼤大容量量データ
•  スケールしやすい
•  書き込みが速い
•  スキーマが柔軟

!  RDB

•  ACID属性
•  Atomicity
•  Consistency
•  Isolation
•  Durability
•  トランザクション
•  クエリがリッチ
•  ジョインも得意

5

BASE?

6

Basically Availabl, Soft state,
Eventually consistent
!   RDBの提供するACID属性と対⽐比するためによく使われ
る
!   厳密な⼀一貫性やデータの即時反映などをあきらめる代わ
りに、スケーラビリティを取る。というような意味。
!   すべてのNoSQLが完全にBASEとは限らないが、⼀一貫性
やトランザクションなど、従来のACIDなRDBと⽐比べて、
諦めている要件がある。

7

NoSQL、裏裏を返すと・・

• ⼀一貫性を保持するのは苦⼿手
• トランザクション苦⼿手
• クエリはシンプル
• 運⽤用が⼤大変
8

NoSQL書き込み速いと⾔言っても・・・

MySQLでも1,000QPSくらい
普通に出ます。
NoSQLの真価は、データ量量が
巨⼤大になってきても性能が落落
ちないところ。
9

RDBでやってきたことをそ
のままできるわけではない
ことに注意してNoSQLを使
いましょう！

10

DynamoDBとは

11

DynamoDBとは
!   ・NoSQL as a Service
!   ・超⾼高速・予測可能な⼀一貫したパフォーマンス
!   ・シームレスなスケーラビリティ、そして低コスト
運⽤用管理理必要なし
低レイテンシ、SSD
プロビジョンスループット

無限に使えるストレージ
12

DynamoDBの特徴

!  管理理不不要で信頼性が⾼高い
!  プロビジョンスループット
!  ストレージの容量量制限がない

13

特⻑⾧長１：管理理不不要で信頼性が⾼高い
!   SPOFの存在しない構成
!   データは3箇所のAZに保存されるので信頼性が⾼高い
!   ストレージは必要に応じて⾃自動的にパーティショニング
される

クライアント

14

特⻑⾧長２：プロビジョンスループット
!   ReadとWrite、それぞれに対して必要な分だけのスルー
プットキャパシティをプロビジョンする（割り当てる）
ことができる
!   例例えば⼀一般的なReadヘビーなDBなら
•  Read : 1,000
•  Write : 100

!   ライトヘビーなDBなら
•  Read : 500
•  Write : 500

!   この値はDB運⽤用中にオンラインで変更更可能

•  ただし、スケールダウンに関しては⽇日に４回までしかできない
ので注意

15

特⻑⾧長３：ストレージの容量量制限がない
!   使った分だけの従量量課⾦金金制のストレージ
!   データ容量量が増えてきたのでディスクを⾜足したり、ノー
ドを⾜足したりという作業が不不要

16

DynamoDBの料料⾦金金体系

!  プロビジョンスループットで決
まる時間料料⾦金金

•  Read/Writeそれぞれプロビジョンしたスループットによって時
間あたりの料料⾦金金がきまる
•  ⼤大規模に利利⽤用するのであればリザーブ度度による割引もあり

!  ストレージ利利⽤用量量

•  保存したデータ容量量によって決まる⽉月額利利⽤用料料⾦金金
•  計算はGBあたりの単価が適⽤用される　

実際の料料⾦金金については下記を参照
http://aws.amazon.com/jp/dynamodb/pricing/ 　
17

DynamoDBを使い始めるには

1.  テーブルのKeyやIndexを決める
2.  Read/Writeそれぞれのスループッ
トを決める

Thatʼ’s it, write your code!
18

DynamoDBを使ってみる

19

DynamoDBの構成要素
オペレーションはHTTP APIで提供されている
Client Side

SDK

HTTP API

Distributed Storage

Service Side

API Servers

20

提供されているAPI
!
!
!
!
!
!

PutItem
UpdateItem
GetItem
DeleteItem
 Query
 Scan

!
!
!
!
!
!

BatchWriteItem
BatchGetItem
CreateTable
DescribeTable
UpdateTable
DeleteTable

21

提供されているAPI
!
!
!
!
!
!

PutItem
! BatchWriteItem
UpdateItem
! BatchGetItem
SDK経由で利利⽤用するのが楽。
GetItem
! CreateTable
もちろん、⾃自前実装も可能です。
DeleteItem
! DescribeTable
 Query
! UpdateTable
 Scan
! DeleteTable

22

実際によく使う操作
•  Get/Put/Update/Delete/BatchGet
•  Scan
•  テーブル総ナメする
•  Query
•  ハッシュ+レンジキーのみ

23

AWS SDKs

!  各種⾔言語むけのオフィシャルSDKを利利⽤用

Java

Python

PHP

.NET

iOS

Ruby

nodeJS

Android

24

オフィシャルSDK以外にも
!   Perl

•  Net::Amazon::DynamoDB

! Erlang

•  wagerlabs/ddb

•  https://github.com/wagerlabs/ddb

!   Go

•  go-‐‑‒dynamodb

•  https://github.com/fabiokung/go-‐‑‒dynamodb

25

テーブル設計のための要素（１）
!   Table

•  Primary Keyとして”Hash key”もしくは”Hash key & Range
key”を選択する

!   プライマリキー：Hash key

•  Hash key単体でデータを⼀一意に識識別できるケースに使う

!   プライマリキー：Hash key & Range key

•  Hash keyに該当する複数のデータからRange keyで絞り込み検
索索ができる

!   Local Secondary Indexes

•  Range key以外に絞り込み検索索のためのキーを持つことができ
る

26

テーブル設計のための要素（２）
!   Attributes

•  データの中⾝身。Hash key, Range keyに該当するAttributes以
外は事前に定義する必要はない。また、レコード間でAttributes
が不不揃いであっても問題ない。

!   Attributesの型
• 
• 
• 
• 
• 
• 

String
Number
Binary
String Set
Number Set
Binary Set

27

DynamoDBのデータモデル
テーブル

Hash keyまたはHash key & Range key

アイテム
プライマリキー

アトリビュート

28

DynamoDBのプライマリキー
•  ハッシュキー
•  シンプルなキーバリュー
•  ハッシュ値なので、ソートなし
•  ハッシュキー+レンジキー
•  コンポジットプライマリーキー
•  レンジキーはソートあり

29

サンプル（１）商品カタログ
!   スキーマのイメージ

•  テーブル名はProducts
•  商品ID(ProductId)をHash keyとするテーブル

ProductId
(Hash key)

ProductName Price

・・・

・・・

1

Pen

100

・・・

・・・

2

Pencil

50

・・・

・・・

3

Eraser

100

・・・

・・・

30

DynamoDBデータモデル
ハッシュキーのみの場合
アイテム

ハッシュキー

A1-‐‑‒1

31

!   テーブルの作成

•  商品IDをHash keyとするテーブル

•  Primary KeyにHashを選択して、Hash keyの名前と型を決め
る
32

!   node.jsのSDKで触ってみる
•  データを投⼊入

var aws = require(‘aws-sdk’);
aws.config.loadFromPath(‘PATH/TO/CREDENTIAL’);
var dynamoDb = new aws.DynamoDB.Client();

33

dynamoDb.putItem(
{
TableName:"Products",
Item: {
ProductId : {N:"1"},
ProductName: {S:"Pen"},
Price: {N:"100"}
}
},
function(err,data){
if(err){ console.log(err); }else{
console.log(data);
}
}
);

•  データを１件取得する

dynamoDb.getItem(
{
TableName:"Products",
Key: {
ProductId : {N:"1"},
},
function(err,data){
if(err){ console.log(err); }else{
console.log(data);
}
}
);

34

サンプル（２）⾏行行動ログ
!   スキーマのイメージ

•  テーブル名はAudience
•  ユーザーID(AudienceId)をHash key、TimestampをRange
keyとするテーブル

AudienceId
(Hash key)

Action

Url

・・・

1

2013-10-01
00:01:01

Login

・・・

・・・

2

2013-10-01
00:02:02

Login

・・・

・・・

1

2013-10-01
00:21:00

Login

・・・

・・・

1

35

Timestamp
(Range key)

2013-10-01
00:42:00

ViewHoge

1

2013-10-01
00:56:22

PostHoge


DynamoDBデータモデル
!   ハッシュキー+レンジキーの場合

アイテム
レンジキー1
レンジキー2

A2-‐‑‒1

レンジキー3

ハッシュ
キーA

A1-‐‑‒1

A3-‐‑‒1

36

!   テーブルの作成

37

•  データを投⼊入

var data = new Array(
{ AudienceId: { N:"1" }, Timestamp: { S:"2013-‐‑‒10-‐‑‒01 00:01:01" }, Action: { S:"Login" } },
{ AudienceId: { N:"1" }, Timestamp: { S:"2013-‐‑‒10-‐‑‒01 00:42:00" }, Action: { S:"ViewHoge" } },
{ AudienceId: { N:"1" }, Timestamp: { S:"2013-‐‑‒10-‐‑‒01 00:56:22" }, Action: { S:"PostHoge" } }
);

38

for (var i =0; i < data.length; i++){
dynamoDb.putItem(
{
TableName:"Audience",
Item: data[i]
},
function(err,data){
if(err){
console.log(err);
}else{
console.log(data);
}
}
);
}


•  あるユーザーの10⽉月1⽇日 0時10分以降降の⾏行行動ログを取得する

39

dynamoDb.query(
{
TableName:"Audience",
KeyConditions: {
"AudienceId": {
ComparisonOperator:"EQ",
AttributeValueList:[ {N:"1"} ]
},
"Timestamp": {
ComparisonOperator:"GT",
AttributeValueList:[ {S:"2013-‐‑‒10-‐‑‒01 00:10:00"} ]
}
}
},
function(err,data){
if(err){
console.log(err);
}else{
console.log(data);
}
}
);


サンプル（３） LSI付き⾏行行動ログ
!   ユーザーのアクティビティログにLocal Secondary
Indexes(LSI)をつけてみる
AudienceId
(Hash key)

Action
Url
(Action-Index)

・・・

1

2013-10-01
00:01:01

Login

・・・

・・・

2

2013-10-01
00:02:02

Login

・・・

・・・

1

2013-10-01
00:21:00

Login

・・・

・・・

1

40

Timestamp
(Range key)

2013-10-01
00:42:00

ViewHoge

1

2013-10-01
00:56:22

PostHoge


Local Secondary Indexes（LSI)
•  Get/Put/Update/Delete/BatchGet
•  Scan
•  テーブル総ナメする
•  Query
•  ハッシュ+レンジキーのみ
この制限を取り除くのがLocal Secondary Index！
41

Local Secondary Indexes (LSI)
!   任意のアトリビュートに張れるQuery⽤用Index
•  各テーブルに5つまで

Forumの投稿を保持するテーブルの例：

LSIを定義すればKeyで
ないアトリビュートに関し
てもQuery可能に
例：
　- Repliesが10件以上
　- 最後の投稿がXX以降
LSIなしのテーブルでは
QueryはRange Keyのみ
42

RepliesIndex
LastPostIndex

LSI


なんで”Local” Secondary Indexesなの？
!   ハッシュキーが⼀一致する範囲の中のSecondary Indexで
あるため
àハッシュキーが異異なるアイテムを横断的にQueryすることは出
来ない
RepliesIndex

RepliesIndexを使って１
Queryで取得可能なのは？
•  ForumNameがS3で
Repliesが9以上
•  任意のForumNameで
Repliesが９以上
à 3つハッシュキーがある
ので3 Query必要
43

LSIを設定した場合の実際
Threadテーブルの
LastPostDateTimeに
LSIを設定すると

44

LastPostIndex

対応するIndexテーブルが裏で
作成/管理される
•  指定したアトリビュートがレンジキー
•  元のテーブルのレンジキーがアトリ
ビュートに


アトリビュートのプロジェクション
!   Index⽤用テーブルに指定したアトリビュートを複製保存
する機能
•  例例：ThreadテーブルのRepliesをLastPostIndexにプロジェク
ション

LastPostIndex
45

Query時にRepliesを取得する場合は読み込みコストが低減
à性能の向上、ReadThroughputの節約

サンプル（３）LSI付き⾏行行動ログ
!   ユーザーのアクティビティログにLocal Secondary
Indexes(LSI)をつけてみる

•  ⼀一度度作ったテーブルのLSIは変更更できないので、新たに
Audience2というテーブルを作って設定する
•  今回はAction-‐‑‒IndexというLSIを作って、”Action”というアトリ
ビュートに設定する

46

サンプル（３）LSI付き⾏行行動ログ
!   Action-‐‑‒Index(LSI)を使ってデータを取得する

47

dynamoDb.query(
{
TableName:"Audience2",
IndexName: “Action-‐‑‒Index”,
KeyConditions: {
"AudienceId": {
ComparisonOperator:"EQ",
AttributeValueList:[ {N:"1"} ]
},
“Action": {
ComparisonOperator:“EQ",
AttributeValueList:[ {S:“Login"} ]
}
}
},
function(err,data){
if(err){
console.log(err);
}else{
console.log(data);
}
}
);

テーブル設計で気をつけること: プライマリキー
!   Hash keyとRange keyの概念念
Parition1 Partition2 Parition3
1 　2　 3　 4　 5　 6　 7　 8　 9

Range key
Partition内での
データの並びを
保証する

DynamoDBのスループッ
トは、各Partitionに負荷
が分散されたときに想定通
りの数字がでるように設計
されている。ひとつの
Paritionだけではプロビ
ジョンしたスループットの
数字はでないので注意。

Hash key
Partition間での
データ分散に利利
48
⽤用される
A,D

B,E

C,F

テーブル設計で気をつけること: プライマリキー
!   Hot Key問題：特定のHash keyに対してデータ
が集中すると性能が劣劣化する（想定通りに性能
がでない）ので注意。
!   前述のAudienceテーブルでのAudienceIdのよ
うに、データが特定のキーに集中しにくいもの
を選ぶ。
!   例例えば、「年年⽉月」みたいなデータが集中しやす
いキーをHash keyにするのはアンチパターン。
49

テーブル設計で気をつけること: LSI
!   Local Secondary IndexesはストレージとIOの
コストを押し上げる
•  LSIはいわゆる”射影”で実装されている
•  射影されるアトリビュートのストレージコストが膨らむ
•  Write時の書き込みコストも上がる

!   本当に必要なものだけに絞ってLSIを適⽤用する
!   射影(Projection)するAttributesも必要なものに絞る

50

ツールとエコシステム

51

データ操作は
マネージメントコンソールで
!   テーブルに対してSCANやQUERY、PutItemをマネージ
メントコンソールから実⾏行行することができる

52

DynamoDB Local
!   開発/テスト⽤用のツール

•  今までは開発やテストをするために実際のDynamoDBのテーブ
ルを作る必要があった。これには”費⽤用が発⽣生する”、”静的なテ
スト環境を作れない”、”オフラインで開発できない”などの問題
があった。
•  このツールを利利⽤用することにより、開発やCIをより便便利利に⾏行行う
ことができる

!   JARファイルで提供され、ローカルにインストールして
動かすことができる(要Java7)
!   あくまでAPIの機能的を再現しているテストツールなの
で本番では利利⽤用しない
!   プロビジョンスループットは再現されていないので注意
!   詳細は http://bit.ly/1d9fN5c を参照
53

Transaction Library for DynamoDB
!   AWS SDK for Javaのひとつの機能としての実装

•  このSDKを使うことでDynamoDB上でTransactionを利利⽤用できる
•  ライブラリ側でTransaction管理理テーブルを作成することにより
Transactionを実現している

!   使い⽅方は次のページのサンプルコードを参照
!   詳細は http://bit.ly/16KbppP

54


55


56

Amazon EMRのHiveから利利⽤用する

!   hiveのExternal Tableとして利利⽤用可能

•  DynamoDB上のデータを集計したいときなどに利利⽤用

CREATE EXTERNAL TABLE Audience
( AudienceId Int, ActionTimestamp string, Action string )
STORED BY
'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHa
ndler'
TBLPROPERTIES (
"dynamodb.table.name" = ”Audience2",
"dynamodb.column.mapping" =
”AudienceId:AudienceId,
ActionTimestamp:Timestamp,
Aciton:Action“ 　);
57

•  詳細は http://amazn.to/19goT17

hiveを使ってS3へデータをバックアップする
EMR上のhiveはDynamoDBだけでなくS3も
External Tableとして利利⽤用できるのを活かし、
DynamoDBバックのExternal Tableから
SelectしたデータをS3バックのExternal Table
にInsertする。
INSERT OVERWRITE TABLE
s3_̲as_̲external_̲table
SELECT *
FROM dynamodb_̲as_̲external_̲table;

58

Amazon Redshiftにデータをロードする
!  COPYコマンドでRedshiftにデータをロード
COPY audience
FROM ʻ‘dynamodb://Audience2ʼ’
CREDENTIALS
'aws_̲access_̲key_̲id=<Your-‐‑‒Access-‐‑‒Key-‐‑‒
ID>;aws_̲secret_̲access_̲key=<Your-‐‑‒Secret-‐‑‒Access-‐‑‒
Key>'
READRATIO 50;
•  詳細は http://amazn.to/19goT17
59

When to use

60

いつDynamoDBを使うべきか
!  RDBをそのまま置き換えるのはあまりう
まい使い⽅方ではない
!  システムすべてをDynamoDBだけで構成
する必要はない
!  RDBとうまい棲み分けを
!  例例えばシャーディングしないと格納でき
ないような巨⼤大なデータだけを
DynamoDBに⼊入れるなど
61

RDBで、性能を保ちつつ巨⼤大なデータを格
納するには

62

MySQLのシャード構成で
データを運⽤用する⼿手順の例例（１）

シャードインデックス

データインデックス

マテリアライズド・ビュ
ー

シャードされた実データテーブル

63

データを運⽤用する⼿手順の例例（２）
取得したいデータ⼀一覧を取る



ー


64

データを運⽤用する⼿手順の例例（３）
欲しいデータが⼊入っている
シャードノードを取得



ー


65

データを運⽤用する⼿手順の例例（３）
実データを取得



ー


66

データを運⽤用する⼿手順の例例（４）
ビューをキャッシュ



ー


67

スケーラビリティ（性能 x データ量量)を
RDBで確保しようとすると
とても⼤大変

68

そういうところにこそDynamoDB

69

シャードノードとシャードインデックスが
不不要になって運⽤用が楽に！


ー

DynamoDB
70

DynamoDBにマッチするユースケースを
考えてみる
!   ユーザーの⾏行行動ログを格納

•  Hash keyにユーザーID、Range keyにタイムスタンプ
•  広告のターゲティングのための⾏行行動ログ
•  ゲーム内のユーザーの⾏行行動を記録するためのログ

!   ストレージのためのインデックス
•  Hash keyにObject名

•  S3に格納したデータのインデックスとして

!   投票システムやフラッシュマーケティング
•  投票や応募対象のIDをHash key

•  短期間でスパイクするトラフィックを捌くために

71

ユースケース

72

逆に、マッチしないユースケースは？
!   集計

•  データを全件SCANするようなユースケースはあまり向かない
•  やるのであればHiveやRedshiftと組み合わせる

!   トランザクション

•  ライブラリの提供はあるが、NoSQLの特性としてもともと得意
ではない(できるがコストが⾼高い)

73

まとめ

74

まとめ

!
!
!
!

DynamoDBはNoSQL as a Service
 運⽤用の⼿手間がかからない。
NoSQLはRDBとは⽤用途が違う
 システムを全部DynamoDBで構築す
る必要はない。適材適所でRDBと組
み合わせて使う。

75

参考資料料
!   Amazon DynamoDB のベストプラクティス、使⽤用⽅方法、
およびツールなどの情報がこちらにまとまっています。
•  http://aws.amazon.com/jp/dynamodb/resources/

76

参考資料料

Yahooの開発したPeanutsというNoSQLと、Dynamo(オリジナル)、Cassandra、
HBaseとのコンセプトや実装の⽐比較が書かれていて、NoSQLの中⾝身や実装につ
いて⾮非常に参考になります。

77

ありがとうございました！

78

[AWSマイスターシリーズ] Amazon DynamoDB

More Related Content

What's hot

Similar to [AWSマイスターシリーズ] Amazon DynamoDB

More from Amazon Web Services Japan

[AWSマイスターシリーズ] Amazon DynamoDB