DynamoDB Streamも聞いてきた！

それと、db showcaseで、
AWSのDynamoDBやDynamoDB Streamの話も聞いてきたので、メモメモ

---

Dynamo:
DynamoDB：完全マネージ度型のNoSQL
Table
Item=レコード
アトリビュート→カラム
ハッシュキー：必須
レンジキー

Table API
　DDL,DMLを用意している
Stream API
　あとで紹介

AWS SDKとCLI(コマンドライン）

データタイプ：ストリング、数値、バイナリ、JSON用

HashTable
　HashKeyは単体でプライマリーキーとして利用できる
データは３か所にレプリケーション
Hash-Renge
　ハッシュキーの複数データの順序保証をするため

DynamoDBの整合性
　２つのレプリカでAck
　Read
　　　デフォルト
　　　ConsistentRead:３つ一緒の時

LSI(Local Secandary　Index（LSI)
GSI（Global Secondary Index)

GSIの更新フロー
　非同期で更新

スケーリンフ
　　スループット：指定できる
　　
スループット
　テーブルレベルによってプロ美女にんぐ
　　Writeキャパシティーユニット
　　Readキャパシティーユニット
　→どくりつ

パーティショニング算出
　　スループット
　　ストレージ　テーブルサイズを１０Gでわる
　の大きいほう

DynamoDBの課金
　スループットで決まる時間料金
　ストレージの価格

キーが偏らないように

バースト処理：超過するとエラー

データモデリング
　１：Nリレージョン　親子
　N:MクエリAPIでアクセス

JSON型：昨年１０月から
　Document

ユースケース、ベストプラクティス
・イベントログ
　　ホットテーブルとコールドデータとして別テーブル（混在させない）
　　アーカイブしたらS3
・メッセージアプリ
　　メタデータを別テーブル
　　大きいデータを分けて配置
　　書き込み処理を単純化
・ソーシャルゲーム
　　HashKeyとRengeキーのみインデックス大正
　　→２つ以上ある場合
　　１．HashKeyを１項目、RengeKeyを残りの項目にしてフィルター
　　２．複合キーとして指定
・スパースなインデックス

リアルタイム投票システム
　　スケールすることによるボトルネック→シャーディんグでの書き込み
　　正確な投票

DynamoDB Stream
　　すべての更新保持。
　　シリアライズされる
　　２４時間
　View Type:Old image,New Image,old+New,key
つかいみち
　Kinesis Client Libraryからとか
　クロスリージョンレプリケーション→海外にバックアップ
　DynameDBStream+らむだ
　ラムダ：イベントをトリガーにレコード実行
リアルタイム投票

ユースケース
・セッション管理
・ユーザー情報
・行動履歴
・ソーシャルのバックエンド

ユースケースに合わせてDB製品を選択
キャパシティ→クラウドウォッチでわかる
ダイナミックDynamoDB（オープンソース）で自動化できる

AWSでMySQL５．６互換、性能５倍？のAurora話を聞いてきた

db showcaseに行って、

Amazon Aurora Deep Dive

で、MySQL５．６互換、性能５倍？のAurora話を聞いてきたので、メモメモ

---

現在プレビュー中。今日現在のもの（改善はいるかも）

Amazon　Aurora
そのまえに、Amazon RDSの説明
　→AuroraはRDSの１つとして提供

RDS
・データベースを数分で作成可能
・セキュリティパッチなども自動
・S3への継続的バックアップ
・フェイルオーバーも

Aurora
・re:invent2014で発表された新しいRDS
・新しい技術的チャレンジ
・RDSが提供するエンジンのうちの１つ
・ばーじにあ、おれごん、あいるらんどリージョンで
・プロダクション環境へ移行
・ライセンス料金
・MySQL５．６と互換性→ロックインなし

・クエリ性能の向上
・スケーラブル
・セキュリティ
・コストパフォーマンス

MySQL５．６との完全互換
・接続先をオーロラへむけるだけ
・１０GByteから６４TByteへシームレスにスケールアウト
・３とつのアベイラビリティゾーンに２つづつ、計６個＋S3にバックアップ
・VPCないに起動

なぜAmazonがデータベースを再設計したのか
・１９７０年の概念が生きている
　　現在のモノリシックなDB→このセットで増やしていくしかなかった

クラウド時代のDB
・ハイエンド
・オープンソースなコストメリット
・MySQL互換
・利用した分だけ
・フルマネージドサービスとして提供

MariaDBConnectorはAuroraとシームレスに動作
　Tableau,TalendもMySQL用でOKだった

アーキテクチャ
　Service Oriented Archtecture
・ログとストレージレイヤ
・ルート５３、なんかをつかって管理されている
　　S3をつかって

キャッシュレイヤの分離

ストレージ：
　SSD利用、使った分だけ課金
　故障に対して耐性
　ログ・ストラクチャード・ストレージ
　６つ中、４つ書き込みで戻る
　ホットスポットを取り除く
　スレーブもマスターと同じディスクを参照
　S3へ増分バックアップ

Log Structured Storage
　追記型ストレージ
　→シーケンシャルリード

ディスクの障害検知と修復
・３本XでWriteできなくなる（Readはできる）
・MySQLのレプリケーション　スレーブ遅延
　Aurora：遅延おこらない100ms未満
・１５台のリードレプリカを作成可能

セキュリティ
・標準的な認証は取っている
・データの暗号化

DBクラスタ
・マスタとスレーブをひとまとまりにしたもの
・クラスタエンドポイント

新しいメトリクス画面

フェイルオーバーとリカバリー
・リードレプリカがあると、１分ほどでフェイルオーバー可能
・優先的にフェイルオーバーさせるノード
　　→スレーブとして使える

クラスタエンドポイント

データ修復も高速

Streaming snapshotとPITR(ぽいんといんたいむりかばり）
・５ふんまえから
・SQLによるフェイルオーバーのテスト

パフォーマンス
・５倍のパフォーマンスが独り歩き？
・クエリの並列度が高く、データサイズが大きいと効果発揮
　　→分散ロックメカニズム
・クエリレスポンスタイム、スループットに注目
　（CPU使用率が高くてもスループットよいことも）

パフォーマンス測定

・性能５倍
　TPC-Cだと２．５倍？→改善中

Auroraの移行
RDS for MySQLからは、ボタン1個
・InnoDBしかサポートしていない
　　MyISAMがある場合、コンバートするので、

使いどころ
・クエリ同時実行数やテーブルサイズが大きいとき
・複数サーバーにシャーディング