# AWS DataBase
## RDS
### 1−1　RDSの特徴
* リレーショナルデータベース
* トランザクション処理をサポート
* データ量：小〜大(Auroraは大規模でも対応できる！他はそうでもないから注意)
* アクセス速度：中
* **SQLトランザクション処理：可能**
* ユースケース：トランザクション処理が必要な業務DB

### 1−2　RDSのストレージタイプ
* ストレージ容量

| DB名 | Aurora,MariaDB,<br>MySQL,Oracle,PostgretDB| SQL Server |
| -------- | -------- | -------- |
| DB容量 | 20 GiB - 64 TiB | 20 GiB - 16 TiB |

* RDSのストレージタイプ
**　汎用SSD：様々なワークロード
**　プロビジョンIOPS：IO処理重視のワークロード
**　Magnetic：下位互換性のため

| | 汎用SSD | プロビジョンIOPS | Magnetic |
| -------- | -------- | -------- | -------- |
| ストレージ種類 | SSD | SSD | HDD |
| キャパシティー課金 |　なし | あり（プロビジョンした<br>IOPS単位） | なし |
| IOリクエスト課金 | なし | なし | あり |
| 性能 | 100〜16,000 | 1,000〜80,000 | 100〜1,000 |

### 1−3　RDSのインスタンス
* 　プライマリーDBインスタンス：書込み用ワークロードはプライマリーDBにアクセス
* 　リードレプリカDBインスタンス：読み込み用ワークロードはリードレプリカDBにアクセスする。最大５台（Auroraは１５台）まで構成できる
* 　DB読込みのパフォーマンスを向上させるにはリードレプリカDBを構成するべし

### 1−4　MultiーAZ構成

* Auroraは必須でMulti-AZ構成になる。それ以外はオプション
* 異なるAZでデータを複製する事
* 通常時は常にデータ複製を行う
* 障害が発生した時、最新のスタンバイBDインスタンスにフェイルオーバーを開始し、完了するとDBの動作が再開する（スタンバイDBはプライマリDBに切り替わる）
* メンテナンスの時：スタンバイDBにメンテナンス→スタンバイDBをプライマリDBに昇格させる→旧プライマリDBにメンテナンス→旧プライマリDBは新しいスタンバイDBになる

### 1−5　バックアップ
* 自動バックアップ（手動も可能）
* ストレージボリュームのスナップショットを作成
* DBインスタンスを削除すると自動バックアップスナップショットは消えるが、手動は削除されない
* 保存期間：デフォルト７日、最大３５日

### 1−6　Aurora DB
MySQLとPostgreSQLと互換性のあるRelational DataBase

| 特徴 | Aurora | 他DB |
| -------- | -------- | -------- |
| MultiAZ構成 | ３つのAZに２つずつの<br>レプリケーションを構成<br>（デフォルト機能） | ２つのAZを使用 |
|DBストレージサイズ | 64 TiB | 64 TiB（SQL Server：16 TiB） |
|最大リードレプリカ数|最大15|最大5|
|自動フェイルオーバー|ある|なし|

---

## DynamoDB
### 2−1　DynamoDBの特徴
* 高速なNoSQL
* 連続した高速なデータ蓄積
* データ量：無制限、自動的にスケールアップ、スケールダウン
* アクセス速度：高速
* SQLトランザクション処理：なし（APIを使う）
* ユースケース：履歴ログ、属性情報、メタデータ、データ収集（IoTなど）

### 2−2　DynamoDBの整合性
* １つのリージョン内の３つのAZでデータを書き込む
* ３つの内２つのAZへ書込みが確認できたら書き込み終了と見なす
* デフォルト仕様では書込みを行った直後に読込みをすると、古いデータが返される可能性あり
* 強力な整合性のある読込みオプション：↑の問題を無くすために２つのAZのデータを比較し、一致したらデータを返す。
* なので応答速度が低下＆オプション付きでのコスト発生

---

## ElastiCache
### 3−1　ElastiCacheの特徴
* インメモリデータストア
* メモリをストレージとするもっとも高速なアクセス
* データ量：小〜中
* アクセス速度：超高速
* SQLトランザクション処理：なし
* ユースケース：セッション情報、一時データ保存

### 3−2　ElastiCache for Memcached
↓このような場合に向いてます
* シンプルなデータモデル
* マルチスレッド

### 3−3　ElastiCache for Redis
↓このような場合に向いてます
* 複雑なデータモデル
* 暗号化
* 高可用性構成（レプリケーション）
* 自動フェイルオーバー
* バックアップと復元
* コンプライアンス認証

クラスタを組むことで、170.6TBまでいけるらしい
https://aws.amazon.com/jp/elasticache/redis/

---

## RedShift
### 4−1　RedShiftの特徴
* ペタバイト規模に拡張できるデータウェアハウス
* 複雑なSQLを並例処理で高速に処理
* データ量：無制限サイジングと拡張操作が必要
* アクセス速度：高速
* ユースケース：データ分析、BI、DWH

### 4−2　RedShiftに適したシチュエーション
Redshiftに適したワークロード
* 巨大なデータを扱うケース（数百GiB〜PB）
* １つのSQLが複雑であり、かつ同時実行は少ないケース
* データ更新を一括で実行するケース

RedShiftに適したシナリオ
* BIツールによるデータ分析
* Data Warehouse
* データ集計、でポート作成

### 4−3　列指向性
列指向性ストレージ：列単位でデータベースにアクセスするため、同じ分類のデータの集計や分析を高速に実行できる。

* 一般的なRDBは行指向性

* Redshiftは列指向性

### 4−4　RedShiftのアーキテクチャ

* Redshiftはクラスターで構成される
* リーダーノード：Only One、コンピューティングノードとの通信管理、DB操作に対する実行計画、コードコンパイル、コンピューティングノードへのコード配布
* コンピューティングノード：１〜複数、リーダーノードから配布されたコードの実行、実行後の中間結果の返送
* 各コンピューティングノードはメモリー、CPU、ディスクストレージで構成されてる
* それぞれのサイズはノードのタイプによって異なる
* コンピューティングノードのタイプ

| ノードタイプ | 特徴 |
| -------- | -------- |
| Dense Compute | SSDを使用した高パフォーマンスなData Warehouse作成<br>500GiB未満のデータ量の場合|
|Dense Storage|HDDを使用した大規模なData Warehouse作成<br>コスト削減やスケール拡大が見込まれる場合|

### 4−5　ノードの障害対処及びバックアップ
* 障害が発生した場合、自動的に障害ノードを探知し、交換が行われる
* ノードが単一である場合、障害が発生した時S3にバックアップされたスナップショットからクラスターを復元させる（安全性のためにもノードは２つ以上使用する事）
* 自動バックアップ（手動も可能）
* ストレージボリュームのスナップショットを作成、S3に保存
* DBインスタンスを削除すると自動バックアップスナップショットは消えるが、手動は削除されない
* 保存期間：デフォルト７日、最大３５日

### 4−6　Redshift Spectrum
* S3のExaByte単位の非構造化データに対してSQL Queryを直接実行できる
* S3上に配置されたファイルを外部テーブルとして定義し、アクセスを可能とする
* 追加料金発生