AWS Black Belt Techシリーズ Amazon DynamoDB

20,159 views

Published on

AWS Black Belt Tech Webinar 2014
(旧マイスターシリーズ)

Amazon DynamoDB

Published in: Technology

AWS Black Belt Techシリーズ Amazon DynamoDB

  1. 1. Amazon DynamoDB AWS Black Belt Tech Webinar 2014 Yuta Imai Solutions Architect, Amazon Data Services Japan, K.K.
  2. 2. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計とサンプル • 運用関連 • ツールとエコシステム • まとめ
  3. 3. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計とサンプル • 運用関連 • ツールとエコシステム • まとめ
  4. 4. よく見かけるNoSQLデータベース • Neo4j • Couchbase • DynamoDB • MongoDB • Riak • HBase • Cassandra
  5. 5. NoSQL vs RDB トランザクション特性 ➔BASE 得意/メリット ➔スケーラビリティ 不得意/デメリット ➔複雑なクエリ ➔トランザクション トランザクション特性 ➔ACID 得意/メリット ➔柔軟なクエリ ➔トランザクション 不得意/デメリット ➔スケーラビリティ NoSQL RDB
  6. 6. BASE?
  7. 7. Basically Available, Soft-state, Eventually consistent • 主に分散システム上でのスケーラビリティを確保するた めに厳密なトランザクションをあきらめている – Basically Available:サービス提供中であっても、古いデータが返ることや、 データ更新作業のためにクエリが失敗する可能性がある – Soft-state:入力がない状態でも、結果整合性をたもつためのデータ更新作業に より、状態の変化がある可能性がある – Eventually consistent:データ更新モデルは結果整合性が取られており、入力後 の即時更新は保証されない • すべてのNoSQLが完全にBASEとは限らない(実装によ る)
  8. 8. CAP定理?
  9. 9. CAP定理とは • 分散データベースにおいて、次の3つを同時に保証する ことはできない (2つを保証すると、残り1つを妥協しなければならない) – Consistency = 一貫性 – Availability = 可用性 – Partition-tolerance = ネットワーク分断耐性 参考 http://ja.wikipedia.org/wiki/CAP定理 DynamoDBはAとPを優先したデータベース ただしオプションでCの特性も確保可能
  10. 10. NoSQLの使いドコロ?
  11. 11. NoSQLの使いドコロ 一般的にNoSQLの特徴として、下記の点があげられる – ストレージ容量をスケールさせやすい – スループットをスケールさせやすい – 実際にストレージやスループットが増えてきた時に性能劣化しにく い これらの特徴が必要とされるところがNoSQLの使いドコロ。 ただし、これもNoSQLの一般的な特徴として、自前で運用する のにはかなりの労力が必要とされる。
  12. 12. DynamoDBはNoSQL as a Serviceなので 運用作業を最小化できる
  13. 13. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計 • テーブル設計サンプル • 運用関連 • ツールとエコシステム • まとめ
  14. 14. DynamoDBとは • NoSQL as a Service • 超高速・予測可能な一貫したパフォーマンス • シームレスなスケーラビリティ、そして低コスト 運用管理必要なし 低レイテンシ、SSD プロビジョンスループット 無限に使えるストレージ
  15. 15. DynamoDBの生い立ち • Amazon.comではかつて全てのアクセスパターン をRDBMSで処理していた • 規模が大きくなるにつれて、RDBMSの課題に直面 – スケーラビリティ • 処理能力を向上させるのが難しい。データの再配置、より大きなHWを 導入するなどの対処が必要。 – 可用性 • RDBMSは可用性よりもデータの整合性を重視する設計 • トランザクション処理が不要な場面でも、全てはトランザクションと して処理される パフォーマンスのオーバーヘッド大
  16. 16. DynamoDBの生い立ち • RDBMSの課題に対処するため、Amazon Dynamo (DynamoDBの先祖)を設計・開発 • Amazon Dynamoの特長 – ベネフィット • 結果整合性モデル採用による可用性向上 • HWを追加する毎に性能が向上するスケーラビリティ • クエリーモデルが単純なためパフォーマンスが予測できる – 妥協点 • 強い整合性モデルではない • スケールアップの際にHWの追加やクラスタのリバランスが必要 • 開発者がDB管理作業から開放されるわけではない Amazon S3のように”サービスとして使いたい”という声
  17. 17. DynamoDBの誕生 • AWS上に「サービス」として実装 • Amazon Dynamoをサービス化したものではないので注意 • パフォーマンスのために堅牢性・可用性を妥協しない • 常に低レイテンシーで応答を返す • 開発者(利用者)はスケーラビリティを気にしなくて良く、 いつでも簡単に増減できる • サーバーやディスク台数ではなく、シンプルに必要な読み書 きの性能数値を指定するだけ • 管理作業が不要
  18. 18. DynamoDBの特長 • 管理不要で信頼性が高い • プロビジョンドスループット • ストレージの容量制限がない
  19. 19. 特長1:管理不要で信頼性が高い • SPOFの存在しない構成 • データは3箇所のAZに保存されるので信頼性が高い • ストレージは必要に応じて自動的にパーティショニング される クライアント
  20. 20. 特長2:プロビジョンドスループット • テーブルごとにReadとWriteそれぞれに対し、必要な分 だけのスループットキャパシティを割り当てる(=プロ ビジョンする)ことができる • 例えば下記のようにプロビジョンする – Read : 1,000 – Write : 100 • 書き込みワークロードが上がってきたら – Read : 500 – Write : 1,000 • この値はDB運用中にオンラインで変更可能 – ただし、スケールダウンに関しては日に4回までしかできないので注意
  21. 21. 特長3:ストレージの容量制限がない • 使った分だけの従量課金制のストレージ • データ容量の増加に応じたディスクやノードの増設作業 は一切不要
  22. 22. DynamoDBの整合性モデル • Write • 少なくとも2つのAZでの書き込み完了が確認とれた時点でAck • Read • デフォルト • 一貫性保証のないRead • Consistent Readオプションを付けたリクエスト • Readリクエストを受け取る前までのWriteがすべて反映されたレス ポンスを保証 • ただし、Capacity Unitを2倍消費する
  23. 23. DynamoDBの料金体系 • プロビジョンドスループットで決まる時間料金 – Read/Writeそれぞれプロビジョンしたスループットによって時 間あたりの料金がきまる – 大規模に利用するのであればリザーブドキャパシティによる割 引もあり • ストレージ利用量 – 保存したデータ容量によって決まる月額利用料金 – 計算はGBあたりの単価が適用される – GBあたり$0.285(2014/05現在@東京リージョン) http://aws.amazon.com/jp/dynamodb/pricing/
  24. 24. DynamoDBの料金体系 • プロビジョンドスループット – 書き込み • $0.00742 :10 ユニットの書き込み容量あたり/1 時間 – 読み込み • $0.00742 : 50 ユニットの読み込み容量あたり/1 時間 • キャパシティユニット 上記で「ユニット」と呼ばれている単位のこと – 書き込み • 1ユニット:最大1KBのデータを1秒に1回書き込み可能 – 読み込み • 1ユニット:最大4KBのデータを1秒に1回読み込み可能(強一貫性 を持たない読み込みであれば1秒辺り2回)
  25. 25. DynamoDBが使われているユースケース • KVSとして – Webアプリケーションのセッションデータベース – ユーザー情報の格納するデータベース • 広告やゲームなどのユーザー行動履歴DBとして – ユーザーIDごとに複数の行動履歴を管理するためのデータベース • ソーシャルアプリのバックエンドとして – モバイルアプリから直接参照できるデータベースとして • 他にも – バッチ処理のロック管理 – フラッシュマーケティング – ストレージのインデックス
  26. 26. DynamoDBを使い始めるには 1. テーブルのKeyやIndexを決める 2. Read/Writeそれぞれのスループットを決める That’s it, write your code!
  27. 27. DynamoDBの構成要素 API SDK オペレーションはHTTPベースのAPIで提供されている Database ClientSideServiceSide Client application
  28. 28. 提供されているAPI • PutItem • UpdateItem • GetItem • DeleteItem • Query • Scan • BatchWriteItem • BatchGetItem • CreateTable • DescribeTable • UpdateTable • DeleteTable
  29. 29. 提供されているAPI • PutItem • UpdateItem • GetItem • DeleteItem • Query • Scan • BatchWriteItem • BatchGetItem • CreateTable • DescribeTable • UpdateTable • DeleteTable SDK経由で利用するのが楽。 もちろん、自前実装も可能です。
  30. 30. AWS SDKs and CLI • 各種言語むけのオフィシャルSDKやCLIを利用 Java Python PHP .NET Ruby nodeJS iOS Android Javascript in the Browser AWS CLI
  31. 31. オフィシャルSDK以外にも • Perl – Net::Amazon::DynamoDB • Erlang – wagerlabs/ddb • https://github.com/wagerlabs/ddb • Go – goamz • https://github.com/crowdmob/goamz
  32. 32. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計とサンプル • テーブル設計サンプル • 運用関連 • ツールとエコシステム • まとめ
  33. 33. DynamoDBのテーブルのプライマリキーの持ち方は2種類 • Hash key • Hash key & Range key
  34. 34. テーブル設計のための基礎知識(1/2) • Table – いわゆるテーブル – プライマリキーの持ち方が2つあり、Hash keyをプライマリキーと するパターンと、Hash keyとRange keyの複合キーをプライマリ キーとするパターンがある • Hash key – 順序を指定しないハッシュインデックスを構築するためのキー – 単体でプライマリキーとして利用されることがある • Range key – Hash keyに該当する複数のデータの順序を保証するためのキー – Hash + Rangeでプライマリキーとすることもできる
  35. 35. テーブル設計のための基礎知識(2/2) • Item – RDBで言ういわゆるレコード – 1つ以上のAttributeを持つ • Attributes – データの中身。RDBで言うカラム。 – Hash key, Range keyに該当するAttributes以外は事前に定義する必要はない。 – レコード間でAttributesが不揃いであっても問題ない。 • Attributesの型 – String – Number – Binary – Set of String – Set of Number – Set of Binary
  36. 36. • Hash keyをプライマリキーとして定義したテーブルの例 DynamoDBのデータモデル(1/2) Table Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Table Item Attribute1 (Number) Hash key Item Attribute1 (Number) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Hash key Itemは必ずHash keyに指定された Attributeを持ち、これがプライマリ キーになる プライマリキー以外のAttributeは事 前定義の必要はなくput時に指定し たものを格納できる
  37. 37. プライマリキーがハッシュキーのサンプル1: ユーザー情報データベース
  38. 38. ユーザー情報データベース ユーザーIDをプライマリキーとしたKVS的なテーブル – UserIdで一意のItemを特定し情報の参照や更新、削除を行う UserId (Hash) Name Nicknames Mail Address Interests aed9d Bob [ Rob, Bobby ] foo@example.com some address [ Car, Motor Cycle] edfg12 Alice [ Allie ] a8eesd Carol [ Caroline ] f42aed Dan [ Daniel, Danny ] Users Table ※DynamoDBにはauto_increment等でユニークIDを払い出す機能はないので注意
  39. 39. プライマリキーがハッシュキーのテーブルサンプル2: セッションデータベース
  40. 40. セッションデータベース セッションIDをプライマリキーとしたKVS的なテーブル – 新規セッションごとにItemを払いだしてExpire管理を行う – PHP SDKにはDynamoDBを利用したSession Handlerも同梱され ている • http://docs.aws.amazon.com/aws-sdk- php/guide/latest/feature-dynamodb-session-handler.html SessionId (Hash) Expiry _a12fh 2014-02-01 00:00:00 _ee12a 2014-02-02 00:00:00 Sessions Table
  41. 41. • Hash keyとRange keyをプライマリキーとして定義した テーブルの例 DynamoDBのデータモデル(2/2) Table Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Item Attribute1 (Number) Attribute2 (String) Attribute3 (Binary) Hash key Table Item Attribute1 (Number) Hash key Item Attribute1 (Number) Attribute3 (Binary) Hash key Item Attribute1 (Number) Hash key Itemは必ずHash keyとRange keyに指定されたAttributeを持 ち、これがプライマリキーになる プライマリキー以外のAttributeは事 前定義の必要はなくput時に指定し たものを格納できる Range key Range key Range key Attribute2 (String) Attribute2 (String) Attribute2 (String) Range key Range key Range key
  42. 42. プライマリキーはハッシュ&レンジのテーブルサンプル: ゲームの行動履歴管理データベース
  43. 43. ゲームの行動履歴管理データベース User (Hash) Timestamp (Range) Opponent Result Alice 2014-02-21 12:21:20 Bob Lost Alice 2014-02-21 12:42:01 Bob Won Alice 2014-02-24 09:48:00 Dan Won Alice 2014-02-25 16:21:11 Charlie Won Battle History 自分のバトル履歴を確認するケースを想定 – Userに自分(Alice)を指定し、更にTimestampが7日以内のデータ をクエリしたりできる Charlie 02-25 16:21 Won! Your Battle History Dan 02-24 09:48 Won! Alice 02-21 12:42 Won!
  44. 44. A,D B,E C,F 123456789 Parition1 Partition2 ParitionN Range key Partition内での データの並びを 保証する Hash key Partition間での データ分散に利 用される Partition DynamoDBでは、性 能を確保するために データはパーティショ ンに分散して格納され る Hash keyとRange keyの概念(1/2)
  45. 45. A,D B,E C,F 123456789 Parition1 Partition2 PartitionN Hash keyとRange keyの概念(2/3) Partition • DynamoDBはプロビジョンされたスルー プットを確保するためにデータを複数の Partitionに分散して格納している • Partitionは格納データ容量やプロビジョ ンされたスループットによって自動的に リパーティショニングが実施される • いま現在のPartition数を確認することは できない
  46. 46. A,D B,E C,F 123456789 Parition1 Partition2 ParitionN Hash keyとRange keyの概念(3/3) スループットはPartitionに均等に付与される • プロビジョンしたスループットは各パー ティションに均等に付与され、全体で合 計値の性能が出るように設計されている • アクセスされるキーに偏りが発生すると 思うように性能がでないという自体を招 くため、Hash keyの設計には注意が必要 プロビジョンドスループット: x x/N x/N x/N
  47. 47. テーブル設計のための基礎知識+1 • Partitions – ここまで説明してきたパーティションについて、パーティション数やそ れぞれのパーティションのキャパシティへの理解を深めることが重要 • Local Secondary Index – Range key以外に絞り込み検索のためのキーを持つことができる – Hash keyが同一のアイテム群の中からの検索のために利用 – インデックスもテーブルにプロビジョンしたスループットを利用する • Global Secondary Index – Hash Keyをまたいで検索を行うためのインデックス – インデックスにテーブルとは独立したスループットをプロビジョンして 利用する
  48. 48. Partitions: Partitions パーティションの数はDynamoDBがマネージ するので、ユーザーはパーティション数を気に することなく運用できるようになっている。逆 に言うと直接知る方法はない。しかし、パー ティション分割の特性を理解しておくことでよ り便利にDynamoDBを活用できるようになる。
  49. 49. Partitions: Partitions パーティション数の決まり方はストレージ容量とスループットで決まる – ストレージ – スループット 例1. read:1000, write:500だと1パーティションで収容可能 例2. read:1000, write:1000だと2パーティション必要になる numPartitionstableSize = tableSizeInBytes / 10 GB numPartitionsthroughput = ( readCapacityUnits / 3000 ) + ( writeCapacityUnits / 1000 ) (1000/3000) + (500/1000) = 0.8333 (1000/3000) + (1000/1000) = 1.333
  50. 50. Partitions: Partitions 最終的なパーティション数はストレージとスループットによる計算結果 の大きい方が採用される そしてこれまで説明してきたとおり、ここで決まったパーティション数 に対して、キャパシティが均等に割り振られる numPartitionstotal = MAX ( numPartitionstableSize | numPartitionsthroughput ) 500 GB / 10 GB = 50 partitions 100,000 read capacity units / 50 partitions = 2000 read capacity units per partition
  51. 51. A,D B,E C,F 123456789 Parition1 Partition2 ParitionN 各パーティションには、 テーブルの総スルー プットをパーティショ ン数で割った分が均等 にわりあてられている。 Table プロビジョンドスループット: x x/N x/N x/N Partitions: Capacity変更時の注意事項
  52. 52. Parition1 Partition2 Table プロビジョンドスループット: 2x x/2 x/2 Parition1 Partition2 2x/4 2x/4 Parition3 Partition4 Table 2x/4 2x/4 プロビジョンドスループット: x キャパシティのプロビジョンを 増やすと、前述の計算式にした がってパーティション数も増え ていく 前述の計算式の値をMAXとし、各 パーティションにキャパシティが Allocateされていき、MAXを超えると パーティションが追加される Partitions: Capacity変更時の注意事項
  53. 53. プロビジョンドスループット: 2x Parition1 Partition2 2x/4 2x/4 Parition3 Partition4 Table 2x/4 2x/4 キャパシティを減らすときはパー ティション数は減らずに、各パー ティションのキャパシティが減る ので注意! プロビジョンドスループット: x Parition1 Partition2 x/4 x/4 Parition3 Partition4 Table x/4 x/4 ひとつひとつのパーティションのキャ パシティが低い状態になる。結果とし てキャパシティエラーを起こしやすい 状態になる。 Partitions: Capacity変更時の注意事項
  54. 54. Partitions: Burst Capacity – DynamoDBはテーブルにプロビジョンされたキャパシティのう ち、利用されなかった分を過去300秒分までリザーブしておき、 プロビジョン分を超えたバーストラフィックを処理するために 利用する – ただしこのバースト用にリザーブされているキャパシティは、 バックグラウンドでのメンテナンスやテーブルのキャパシティ 変更などにも利用されており、完全な利用保証はないので注意。
  55. 55. Local Secondary Indexes(LSI) • 任意のアトリビュートに張れるQuery用Index – 各テーブルに5つまで – Hash key内のローカルのセカンダリインデックスを貼る仕組み LSIナシだと、QueryできるのはRange keyのみ ForumName=S3 && Subnect=‘aaa’ LSIを定義すればKeyでないアトリビュートに関して もQuery可能に(ただしテーブル作成時にAttributeを LSIとして事前設定する必要あり) ForumName=S3 && Replies >= 10 ForumName=S3 && LastPostDateTime >=.. Forumの投稿を保持するテーブルの例:
  56. 56. • LSIの実体 – 元のテーブルのRange keyがAttributeのテーブルが作成される – インデックスのスループット/ストレージ費用もかかる Local Secondary Indexes(LSI) テーブルとインデックスはPartitionの スループットを共用する
  57. 57. Local Secondary Indexes(LSI) • なぜ”Local” Secondary Indexesなの? ハッシュキーが一致する範囲の中のSecondary Indexであるため ハッシュキーが異なるアイテムを横断的にQueryすることは出来ない RepliesIndexを使って Query可能なのは? • ForumNameがS3で Repliesが9以上 • 任意のForumNameで Repliesが9以上  3つハッシュキーがある ので3 Query必要 RepliesIndex
  58. 58. Local Secondary Indexes(LSI) • Attributeのプロジェクション – 指定したAttributeをインデックスにプロジェクションできる – 元テーブルへのアクセスを減らすことでReadキャパシティの節約とレ イテンシの改善が望める。 – 一方、Write時のキャパシティやストレージ利用量は増える
  59. 59. テーブルのスループット テーブルのスループット Local Secondary Indexes(LSI) • LSIの読み書きモデル Table Index インデックスのみで データを返せるRead Write Table Index Table Index インデックスのみで データを返せないRead 1 read 2 read 2 write テーブルのスループット
  60. 60. Global Secondary Indexes(GSI) • Hash keyをまたいでAttributeに貼れるインデックス Range keyもしくはLSIだけでは、UserIdをまたいだ Queryはできない。例えば下記のようにGameTitleで のQueryはできない。 GameTitle=‘Galaxy Invaders’ & TopScore >= 100 ゲームのスコアを保持するテーブルの例:
  61. 61. Global Secondary Indexes(GSI) • GSIの実体 – 元のテーブルのHash keyがAttributeのテーブルが作成される – インデックスのスループット/ストレージ費用もかかる – LSIと違い、スループットは独自に定義する – GSI自体もHash keyによるPartitionを持つ テーブルとインデックスはPartitionのスループットを共用しない
  62. 62. Global Secondary Indexes(GSI) • Attributeのプロジェクション – 指定したAttributeをインデックスにプロジェクションできる – GSIの場合、インデックスにないAttributeはテーブルから自動取得されない – Write時のキャパシティやストレージ利用量は増える
  63. 63. Global Secondary Indexes(GSI) • GSIの読み書きモデル Table Index インデックスのみで データを返せるRead Write インデックスのみで データを返せないRead 1 read テーブルの スループット インデックスの スループット Table Index 1 write テーブルの スループット インデックスの スループット 1 write
  64. 64. LSI/GSIも使ったテーブルサンプル ソーシャル画像共有アプリ
  65. 65. ソーシャル画像共有アプリ Home My Posts My Profile Bob Steak! 10:18 Carol BBQ! w/Alice 10:12 Dan Riajuee… 10:11 Alice Beer! 10:21 Alice BBQ! w/Carol 10:12 Alice Starting BBQ! 10:09 Name: Alice Mail: foo Profile: some texts
  66. 66. テーブル設計 Users TableFriends Table 2つのテーブルを定義 • ユーザ情報テーブル • 友達リストテーブル
  67. 67. User (Hash) Nicknames Bob [ Rob, Bobby ] Alice [ Allie ] Carol [ Caroline ] Dan [ Daniel, Danny ] 友達一覧を取得 Users Table Item Attribute (string, number, binary, set) Primary Key (Hash)
  68. 68. User (Hash) Nicknames Bob [ Rob, Bobby ] Alice [ Allie ] Carol [ Caroline ] Dan [ Daniel, Danny ] 友達一覧を取得 Friends Table User (Hash) Friend (Range) Bob Alice Alice Bob Alice Carol Alice Dan Users Table Hash + Range Primary Key
  69. 69. Friends Table Users Table User (Hash) Nicknames Bob [ Rob, Bobby ] Alice [ Allie ] Carol [ Caroline ] Dan [ Daniel, Danny ] User (Hash) Friend (Range) Bob Alice Alice Bob Alice Carol Alice Dan 友達一覧を取得 Aliceの友達一覧を取得 1. Query (Table = Friends, Hash = Alice, Range = *) 2. BatchGetItem(Bob, Carol, Dan)
  70. 70. 投稿画像の保存と検索 Images Table User (Hash) Image (Range) Date Link Bob aed4c 2013-10-01 s3://… Bob cf2e2 2013-09-05 s3://… Bob f93bae 2013-10-08 s3://… Alice ca61a 2013-09-12 s3://… Bob Bobの投稿画像一覧を取得 Query (Table=Images, Hash= Bob, Range=*) でもある時刻以降の画像を取得し たかったら…?
  71. 71. ある日時の画像取得 Images Table User Image Date Link Bob aed4c 2013-10-01 s3://… Bob cf2e2 2013-09-05 s3://… Bob f93bae 2013-10-08 s3://… Alice ca61a 2013-09-12 s3://… User Date Image Bob 2013-09-05 cf2e2 Bob 2013-10-01 aed4c Bob 2013-10-08 f93bae Alice 2013-09-12 ca61a Table ByDate Local Secondary Index Local Secondary Index をDateに張る
  72. 72. 画像にユーザのタグ付け ImageTags Table Image User aed4c Alice aed4c Bob f93bae Alice f93bae Bob Image f93baeにAliceをタグ付け PutItem(Table = ImageTags, Hash = f93bae, Range = Alice) Bob でもあるユーザがタグ付けされてる 画像の一覧を取得したかったら …? Image f93baeにタグ付けされたユーザ一覧 Query(Table = ImageTags, Hash = f93bae, Range = *)
  73. 73. ユーザのタグ付き画像一覧 ImageTags Table UserにImageをRangeキーとした Global Secondary Indexを張る User (Hash) Image (Range) Bob aed4c Bob f93bae Alice aed4c Alice f93bae ByUser Global Secondary Index Image (Hash) User (Range) aed4c Alice aed4c Bob f93bae Alice f93bae Bob Table Bob Aliceがタグ付けされた画像一覧
  74. 74. LSI/GSIを使う際の注意点 • LSI/GSIは便利だが、スループットやストレージ容量を追加で必 要とする • 特にインデックスの数が増えれば増えるほど書き込みコストが上 がる • セカンダリインデックスに強く依存するようなテーブル設計にな るようであれば、一度RDBで要件を満たせないかを確認してみる のがベター
  75. 75. テーブル操作についての基礎知識(1/3) • GetItem • Hash keyを条件として指定し、 一件のアイテムを取得 • PutItem • 1件のアイテムを書き込む • Update • 1件のアイテムを更新 • Delete • 1件のアイテムを削除 • Query • Hash keyとRange keyの複合条件に マッチするアイテム群を取得 • BatchGet • 複数のプライマリキーを指定して マッチするアイテム群を取得 • Scan • テーブル総ナメする よく使われるオペレーションは以下のとおり
  76. 76. テーブル操作についての基礎知識(2/3) • 強一貫性を持ったReadオペレーション • GetItem、QueryにはConsistent Readというオプションを指定することができ、 これを利用すると、Readリクエストを受け取るよりも前に成功しているすべて のWriteリクエストが反映された結果が返る。Read Capacity Unitを通常の2倍 消費するので注意。 • Conditional Write • 「キーにマッチするレコードが存在したら/しなかったら」や「この値が○○以 上/以下だったら」という条件付き書き込み/更新ができる より高度なオペレーション
  77. 77. テーブル操作についての基礎知識(3/3) • UpdateItemにおけるAttributeへの操作 • Attributeに対して、UpdateItemでPut、Add、Deleteという3種類の操作が可 能 • Put:Attributeを指定した値で更新 • Add:AttributeがNumber型なら足し算/引き算、Set型ならそのセットに対して値を 追加する • Delete:当該Attributeを削除する • Atomic Counter • 上記のAddを利用することによって、Atomicなカウンターを実現することもで きる より高度なオペレーション
  78. 78. Conditional Writeを使ったテーブルサンプル バッチ処理のロック管理
  79. 79. バッチ処理のロック管理 S3 S3 S3 EMR EMR 処理1 処理2 ジョブのロック管理
  80. 80. テーブル設計 1つのテーブルを定義 • ジョブテーブル Jobs Table JobID (Hash) Created Time(Range) Process1 Process2 aed4c 2014-01-01 00:00:00 Done InProcess aed4c 2014-01-01 00:01:00 NotYet NotYet
  81. 81. バッチ処理のロック管理 S3 S3 Worker1 Jobs Table JobID (Hash) Created Time(Range) Process1 Process2 aed4c 2014-01-01 00:00:00 Done InProcess aed4c 2014-01-01 00:01:00 NotYet NotYet Worker2も処理のジョブ一 覧を取得 Scan (Table = jobs, Process1 = ‘NotYet’) Worker1が未処理のジョ ブ一覧を取得 Scan (Table = jobs, Process1 = ‘NotYet’) ワーカーが複数クラスタいるので、 複数箇所で同じデータが取得される Worker2
  82. 82. バッチ処理のロック管理 S3 S3 処理1 Jobs Table JobID (Hash) Created Time(Range) Process1 Process2 aed4c 2014-01-01 00:00:00 Done InProcess aed4c 2014-01-01 00:01:00 NotYet NotYet Worker2もProcess1をLockしようとする UpdateItem (Table = jobs, Key={JobID:aed4c}, AttributeUpdates={Process1:{Action:’ Put’,Value:InProcess’}}, Expected:{Process1:‘NotYet’}) 片方だけUpdateに成功する (Lockできる) Worker1がProcess1をLockしようとする UpdateItem (Table = jobs, Key={JobID:aed4c}, AttributeUpdates={Process1:{Action:’ Put’,Value:InProcess’}}, Expected:{Process1:‘NotYet’})
  83. 83. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計とサンプル • 運用関連 • ツールとエコシステム • まとめ
  84. 84. 性能監視はCloudWatchで(1/2)
  85. 85. 性能監視はCloudWatchで(2/2) • CloudWatchで監視できる項目 – Read Capacity • 消費されているRead Capacity Unit – Throttled Read Requests • Capacity Overでエラーを返したReadリクエスト数 – Write Capacity • 消費されているWrite Capacity Unit – Throttled Write Requests • Capacity Overでエラーを返したWriteリクエスト数 – Get Latency – Put Latency – Query Latency – Scan Latency – User Errors
  86. 86. データのレプリカ • DynamoDBではRDBのように静止点をとってバックアップすると いう機能は提供されていないが、下記のいくつかの方法でデータの レプリカを保持することができる 1. AWS Data Pipelineを使ったCross Region Replication • 別のリージョンのDynamoDBのテーブルに対して完全コピーもしくは Incrementalコピー、選択したAttributeのみの完全コピー、選択した AttributeのみのIncrementalコピーのジョブを実行することが可能 2. Amazon Elastic MapReduceを使ったコピー • S3や別のDynamoDBに対してAmazon Elastic MapReduceのhiveを使っ てデータをコピーすることができる 3. ダブルライトパターン • アプリケーションからデータを書き込む時点で複数のDynamoDBテーブル に対して書き込む
  87. 87. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計とサンプル • 運用関連 • ツールとエコシステム • まとめ
  88. 88. データ操作はマネージメントコンソールで • テーブルに対してSCANやQUERY、PutItemをマネージ メントコンソールから実行することができる
  89. 89. DynamoDB Local • 開発/テスト用のツール – 今までは開発やテストをするために実際のDynamoDBのテーブルを作る必要が あった。これには”費用が発生する”、”静的なテスト環境を作れない”、”オフラ インで開発できない”などの問題があった。 – このツールを利用することにより、開発やCIをより便利に行うことができる • JARファイルで提供され、ローカルにインストールして動か すことができる(要Java7) • あくまでAPIの機能的を再現しているテストツールなので本 番では利用しない • プロビジョンスループットは再現されていないので注意 • 詳細は http://bit.ly/1d9fN5c を参照
  90. 90. Transaction Library for DynamoDB • AWS SDK for Javaのひとつの機能としての実装 – このSDKを使うことでDynamoDB上でTransactionを利用できる – ライブラリ側でTransaction管理テーブルを作成することにより Transactionを実現している • 使い方は次のページのサンプルコードを参照 • 詳細は http://bit.ly/16KbppP
  91. 91. Amazon EMRのHiveから利用する CREATE EXTERNAL TABLE Audience ( AudienceId Int, ActionTimestamp string, Action string ) STORED BY 'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler' TBLPROPERTIES ( "dynamodb.table.name" = ”Audience2", "dynamodb.column.mapping" = ”AudienceId:AudienceId, ActionTimestamp:Timestamp, Aciton:Action“ ); • hiveのExternal Tableとして利用可能 – DynamoDB上のデータを集計したいときなどに利用 – 詳細は http://amazn.to/19goT17
  92. 92. 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;
  93. 93. • COPYコマンドでRedshiftにデータをロード – 詳細は http://amazn.to/19goT17 Amazon 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;
  94. 94. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計とサンプル • 運用関連 • ツールとエコシステム • まとめ
  95. 95. まとめ • NoSQLはRDBとは全く特性が異なるので、それらを理 解した上で適所でうまく活用する! • 運用はゼロではないが、拡張性の面や性能面ではとても 楽ができるのがNoSQLの中でのDynamoDBの特徴。 • 思い通りの性能を出すにはキー設計、特にHash keyの 設計が重要。
  96. 96. ご参加ありがとうございました。

×