DynamoDBを導入した話
4 likes11,025 views
数ある NoSQL のなかでも人気のある Amazon DynamoDB。 ビズリーチでは、日々大きくなる MySQL のデータベースを縮小する一つの手段として、いくつかのテーブルを DynamoDB に移行しました。 今回はその経験をもとに、DynamoDB の仕様や特徴から具体的な移行方法までをお話いたします。
![データ型
● スカラ型
数値、文字列（UTF-8）、バイナリ、ブール、null
● ドキュメント型
リスト：[“Bizreach”, “CareerTreck”, 2009]
マップ：JSONオブジェクト
● セット型
数値セット、文字セット、バイナリセット
文字列の長さは０より大きい必要があるため、空文字は格納できない。](https://image.slidesharecdn.com/dynamodb-170614092441/85/DynamoDB-10-320.jpg)
DynamoDBを導入した話
- 2. 自己紹介 ● 北川 俊広 ● 2016/03 ビズリーチ入社 ● DBA ● ビズリーチサービスの DB 周りを担当 ● 使ったことがある DB PostgreSQL, MySQL, DynamoDB
- 5. DynamoDBとは ● 完全マネージド型の NoSQL データベースサービス ● ユーザは以下を心配する必要なし ○ ハードウェア ○ 設定、構成 ○ レプリケーション ○ ソフトウェア修正プログラムの適用 ○ クラスターのスケーリング ● 高速で予測可能なパフォーマンス ● 高いスケーラビリティ ● ストレージの容量制限なし
- 6. DynamoDBの概念 ● テーブル 一般的なデータベースと同様にテーブルにデータを格納する。 ● アイテム（項目） テーブルには複数のアイテム（項目）が含まれる。 RDBMSでいうところのレコード。最大400KBまで。 ● 属性 アイテムは１つ以上の属性で構成される。 RDBMSでいうところのフィールド。 ● プライマリキー アイテムを一意に識別するためのキー。省略不可。
- 7. プライマリーキーの種類 ● パーティションキー（Hash key） １つの属性で構成されるシンプルなプライマリーキー。 ハッシュ関数によってパーティションが決まる。 ２つ以上のアイテムで同じパーティションキーを使用することはできない。 ● パーティションキー（Hash key）とソートキー（Range key） ２つの属性で構成される複合プライマリーキー。 パーティションキーにより保存されるパーティションが決まり、ソートキーでソートさ れてデータが格納される。一意性は、パーティションキーとソートキーの組み合わせ で判断される。
- 9. テーブルの具体例 ● Primary key ○ RId_CId (Partition key) ○ AccessTM (Sort Key) ● GSI ○ RId (Partition key) ○ AccessTM (Sort key) RId_CId AccessTM AccessDate RId Footprint テーブル
- 10. データ型 ● スカラ型 数値、文字列（UTF-8）、バイナリ、ブール、null ● ドキュメント型 リスト：[“Bizreach”, “CareerTreck”, 2009] マップ：JSONオブジェクト ● セット型 数値セット、文字セット、バイナリセット 文字列の長さは０より大きい必要があるため、空文字は格納できない。
- 11. 日付・時刻は？ ● ISO 8601 形式（文字列） ○ 2017-06-13 ○ 2017-06-13T19:45:00Z ○ 20170613T194500Z ● UNIX 時間（数値） ○ エポック時間: 1970 年 1 月 1 日 12:00:00 AM UTC からの経過秒数 ○ Time To Live(TTL)機能を使用する場合は必須の属性
- 13. プロビジョニングされたスループット ＝キャパシティーユニット ● 読み込みキャパシティーユニット１ 最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込 み、あるいは 1 秒あたり 2 回の結果的に整合性のある読み込みを表す。 ● 書き込みキャパシティーユニット１ 最大サイズ 1 KB の項目について、1 秒あたり 1 回の書き込みを表す。 プロビジョニングされたスループットを超えると、リクエストは HTTP 400 コード (Bad Request) と ProvisionedThroughputExceededException で失敗する。ただし、バースト キャパシティという予備のキャパシティがあるので、必ず失敗するわけではない。
- 14. キャパシティー設定
- 15. Scan
- 16. Query
- 17. ScanとQueryのスループット消費 ● 処理された項目の累計サイズをもとにスループットが計算される。 ● たとえば1KBの項目を100個取り出した場合 (100 * 1024 bytes = 100 KB) / 4 KB = 25 読み込みキャパシティーユニット ● 項目サイズは属性名と属性値の長さの合計 「キャパシティーユニットの消費を最適化するには、属性名の長さをできるだけ短く することをお勧めします。」開発者ガイドより
- 18. 料金（東京リージョン） ● 書き込みスループット 書き込みキャパシティー 10 ユニットごとに 0.00742USD/hour ● 読み込みスループット 読み込みキャパシティー 50 ユニットごとに 0.00742USD/hour ● 毎月最初の 25 GB の保管は無料、それ以降は月額 0.285USD/GB
- 20. 移行しづらいテーブル ● １行のサイズが大きい ● バッチ処理などで大量にデータを取得する ● RDBMSの特性を多用している ○ Join ○ サブクエリ ○ 集約関数
- 24. 書き込みキャパシティーの調整
- 27. インポート
- 29. インポート結果の確認 Redshift にコピーして確認するのが便利 CREATE TABLE operator_login_log_temp (opid BIGINT, lt TEXT, ….); COPY operator_login_log_temp FROM 'dynamodb://OperatorLoginLog' credentials 'aws_access_key_id=<Your-Access-Key-ID>;aws_secret_access_key=<Your-Secret- Access-Key>' readratio 50; ※ DynamoDB の属性名に Redshift の予約語を使用しないように注意
- 30. 読み込みキャパシティーの調整
- 31. 日々の運用
- 32. キャパシティー調整 ● バッチ処理 ● Redshift へのデータコピー ● バックアップ 弊社では、キャパシティを調整する仕組みを Lambda で自前実装。 キャパシティは aws cli でも変更できるので、一番お手軽なのは cron での変更。 スループットに応じて自動調整を行いたい場合は、Dynamic DynamoDB が便利。 https://dynamic-dynamodb.readthedocs.io/
- 33. スループットの変動に注意 ● 日々スループットを確認 ● 新機能のリリースなどは注意 ● メンテナンス明けのスループット変動に注意
- 34. ご静聴ありがとうございました