More Related Content Similar to SimpleDB, SQS, SNS詳細 - AWSマイスターシリーズ Similar to SimpleDB, SQS, SNS詳細 - AWSマイスターシリーズ (20) More from SORACOM, INC (20) SimpleDB, SQS, SNS詳細 - AWSマイスターシリーズ10. 動作イメージ
1.キューの作成/4.キューの削除
(http://sqs.ap-northeast-1.amazonaws.com/123456789012/queue2)
3.メッセージ受信
2.メッセージ送信
メッセージ受信者
メッセージ送信者 (Reader
(Writer or Consumer)
or Producer)
11. メッセージの到達保障
1.キューの作成/4.キューの削除
(http://sqs.ap-northeast-1.amazonaws.com/123456789012/queue2)
3.メッセージ受信
2.メッセージ送信
Visibility
Timeout
13. Visibility Timeoutとは(2)
あるReader-Aが あるReader-Dが
メッセージ1を依頼 あるReader-Bが あるReader-Cが
メッセージ1を依頼
依頼 依頼
メッセージは メッセージは
返却されない 返却されない
メッセージの返却 削除されてい
ない場合
(メッセージの
返却)
この間にReader-Aは、
17. SQSのキューのセキュリティ
IAMまたはポリシーベースでユーザ
とアクションを制限する事が可能
{ "Statement":[{
"Effect":"Allow",
"Action":"sqs:SendMessage",
"Resource":"arn:aws:sqs:*:123456789012:SampleQueue" }
,{
"Effect":"Deny",
"NotAction":"sqs:SendMessage",
"NotResource":"arn:aws:sqs:*:123456789012:SampleQueue"
}]}
28. 動作イメージ
1.トピックの作成/5.トピックの削除
2.トピック購読
3.メッセージ配信
4.メッセージ受信
メッセージ配信者 メッセージ購読者
(Publisher) (Subscriber)
41. One Size Does Not Fit All
RDBMSが全てではない
EC2+EBSまたはRDSは汎用的
より目的特化なデータベース
ケールさせる
低コスト
45. SimpleDBの位置づけ
CAP
一貫性(C)、可用性(A) 、ネット
ワーク分断耐性(P)のうち、分散
環境では実質上ネットワーク分断
耐性が必須のため、一貫性か可用
性のどちらかを取らなくてはいけ
ない。
47. SimpleDBのデータモデル
ドメイン
アイテムを保持する器=テーブル
アイテム
アトリビュートを保持する1
アトリビュート
アイテム内にあるKey-Valueまたは
Key-[Value]
51. SimpleDBで出来る操作
ドメインへの操作
CreateDomain/DeleteDomain/ListDomains
アイテム/アトリビュートの追加
PutAttributes/BatchPutAttributes
アイテム/アトリビュートの削除
DeleteAttributes/BatchDeleteAttributes
アイテム/アトリビュートの
GetAttributes/Select
52. SimpleDBでSelect
SQLライクなシンプルなクエリが書ける
select Year from ‘mydb’ where ItemName() = ‘Akio'
レンジクエリ
select Name, category, Year from `mydb` where
every(Year) Between '2005' and '2008'
=, !=, >, <, >=, <=などの演算子
like, not like, in, between, inなどの演算子
order by
count
53. RDBMSとSimpleDBの違い
RDBMS SimpleDB
事前定義したスキーマ スキーマフリー
コスト高い コスト低い
1台で稼働する事が前提 オートスケール
SQLによるアクセス SQLライクなクエリ
リニアにはスケールしない スケールする
トランザクションあり トランザクションなし
インデックスは明示的 自動インデックス
構造化データ 半構造化データ
汎用的 やや目的特化型
54. SimpleDBの制約
ドメインサイズ -> 10GB/domain or 10億アトリビュート
ドメイン名 -> 3-255(a-zA-Z0-9_-.) characters
1アカウント100ドメインまで
1アイテム256アトリビュートまで
アトリビュートのname/value < 1024 bytes
< 1024 bytes
1回のPutAttributesで登録できるのは256個まで
1回のSelectで できるアトリビュートは256個まで
1回のSelect 2500まで
1 5秒まで
1回のレスポンスサイズは1024 bytesまで
56. SimpleDBのベストプラクティス
ソート
ソートのため、数値データは0パディングしてやる
日付はISO 8601フォーマットを使う
Selectクエリ
WHERE
• Name=“Firstname:Lastname”
AND
LIMITを設定し、レンジクエリを極小化する。LIMIT
2500など
57. SimpleDBのベストプラクティス
シャーディング
書き込みのスループットを上げるため
一貫性
• イベンチュアルコンシステンシ
• read-after-writeコンシステンシ
書き込みはなるべく非同期書き込み or
ConditionalPutを使う
パフォーマンス
BatchPutまたはBatchDeleteをデフォルト使う
• 25アイテムの書き込みで20-25%
58. SimpleDBのベストプラクティス
巨大データの扱い
BLOB的に使うのではなくS3に保存して、ポインタを
SimpleDBに保存する
• 2ホップかかるがわかりやすい
データを分割し、複数のアトリビュートに圧縮して
押し込める
• 1ホップだが複雑
設計
データは非正規化する前提
スキーマフリーな点を有効に使う
• 分割によるスケールメリット