Database
Database
Databaseの概要
DBとは。DBMS
CRUDとは。
DBとストレージの違い
DBの意味
障害や復旧
複数人のアクセス
大量データの検索
データベースの役割
トランザクション
同時アクセス
処理に失敗するとrollbackする
復旧
データモデル
トランザクションのACID特性
A: Atomicity(原始性)
すべて実行か、一つも実行されないかどちらかの状態。
C: Consistency(整合性)
データの整合性。
整合性モデル
結果整合性（データが古い可能性）
強い整合性（データ更新中は参照できない）
I: Isolation(独立性)
実行中の過程を隠蔽し他の処理に影響を与えない。
D: Durability(耐久性)
トランザクション中にクラッシュしてもデータが失われない。
データモデル
様々なモデルがある
リレーショナルモデル
グラフモデル
キーバリューストア
オブジェクト
ドキュメント
ワイドカラム
階層型
最適なデータベースの選択
RedShift
RDS
DynamoDB
Aurora
Elastic Search
大きな区分け
リレーショナルDB
通常のDB
ER図などで表現する構造化データ
会計データや顧客データなど
SQLで操作
NoSQL
ビッグデータ向け
構造化されていないKey,Valueのみ
非構造化データ（文書、動画、音声）
半構造化データ（XML, JSON, 文書）
SQLを使わないが、SQLに似た操作ができるものもある。
NoSQLの種類
キーバリューストア
高速なパフォーマンスと分散拡張に優れている
読み込みが高速
ワイドカラムストア
列指向データベース
行ごとに任意のカラムを無数に格納できる。
ドキュメントデータベース
Valueではなく、JSONやXMLそのものを格納
グラフデータベース
グラフ理論を用いたデータベース
高速な横断検索が可能
ビッグデータの活用
DWH
構造化データ
売り上げ・財務分析などのデータ分析
アーカイブデータ
構造化アーカイブデータ
DWHだけでは不可能な長期過去データを分析
半構造化
IoTなど膨大なビッグデータを活用した分析・AI構築
非構造化
非構造化データを活用した分析・AI構築
RDB
AWSのサービスではRDSが該当
DWH
概要
BIツールなどと連携した分析向けのデータベース
AWSのサービスではRedshiftが該当
オンプレであれば、Exadata, Teradataなど。
読み込みデータ構造をあらかじめ設計して蓄積していく。
レスポンス重視でデータ抽出・集計が速いが、更新・トランザクションは遅い。
アーキテクチャ
データをパーティショニングし、複数ディスクから読み込む
列指向
分散型DB/データレイク
高速処理を可能にするDBとストレージの組み合わせ
AWSであれば、S3がデータレイクに相当（するが、分散DBと言えるか？？）
オンプレではApache Hive, Apache Hadoopなど
KVS
AWSサービスではElastiCacheやDynamoDB
オンプレであれば、Redisなど。
結果整合性を採用。高速なデータ処理を重視。
用途
webサイトのバックエンドデータ（ユーザーセッションなど）
twitterなどのメッセージングシステム
キーに応じてデータを分散して保存し分散処理できる。
ワイドカラム型
AWSサービスではDynamoDB
オンプレではcassandra, Apache HBASEなど
データ取得の際に結合しなく良いように、可能な限り多くのデータを同じ行に保持する。
KVSと異なり、SQLライクなデータ操作が可能。
更新はできず、挿入による上書きで実現する。
用途
ソーシャルデータの位置情報データ
データマイニング処理
キーとカラムが入れ子構造となっている。
ここがワイドカラムについては分かりやすいかも。
https://future-architect.github.io/articles/20190718/
ドキュメントDB
AWSサービスでは、DocumentDB(MongoDB)が該当。
JSONやXMLデータを格納
様々なデータ構造を混ぜて保存できる
構造が違ってもOK
KVSよりもクエリが豊富なため操作しやすい
shardingによるデータベース分散化が可能
インメモリデータグリッド
AWSでは、Redis ElastiCacheやMemcached ElastiCacheが該当
KVSをメモリ上で実現し高性能にしたDB
データを多数のサーバーで分散して処理可能
金融の取引データなどが利用対象
全検索型エンジンと分散DB
AWSではElasticSearch
オンプレではElasticSearchやkibana
合分析の柔軟性や速度が高く、分析・蓄積・可視化環境を容易に構築可能
半構造化データを対象
サイト内の全データ検索や検索自身の可視化など。
グラフDB
AWSではAmazon Neptune
オンプレでは、Neo4j
グラフ演算に特化したDB
データ間のつながり方の検索・可視化に利用
利用対象としては、最短経路・金融取引の詐欺検出・ソーシャルネットワークの計算
RDB以上にスケールアウトすることはできない。
レコードが増えると検索に時間がかかる。
分散OLTP(RDB)
AWSでAuroraで提供される。
分散型の次世代RDB。
高い高可用性と高性能なトランザクションと強整合性が実現
利用対象としては大規模な業務データ処理など
DynamoDB
DynamoDBの特徴
完全マネージド型のNoSQLデータベースサービス
ハイスケーラブル
無制限に性能を拡張でき、ストレージの増加なども不要
低レイテンシー
負荷が高くなっても応答速度を維持
高可用
SPOFなしでデータを３つのAZに保存
メンテナンス不要
マネージド型のためCloudWatchで運用
プロビジョンドスループット設定
テーブルごと、Read/Writeごとに必要なスループットキャパシティの割り当てが可能。
DynamoDBでできること
ワイドカラム型のデータベース
できること
キーに対するバリュー（値）のCRUD 操作
簡易なクエリやオーダー
数万人が同時にアクセスするようなセッションデータの管理など
できないこと
JOIN, TRANSACTION, COMMIT, ROLLBACKは負荷
詳細なクエリやオーダー(検索など)に不向き
大量のデータIOにはコストがかかる。
DynamoDBの整合性モデル
デフォルトは結果整合性
Write
2つのAZで書き込み完了された時点で完了
Read
デフォルト
結果整合性
オプション
強い整合性モデル
GetItem, Query, Scanでは強い整合性のある読み込みオプションが指定できる。
DynamoDBのパーティショニング
一つのテーブルを複数のパーティションに分けるなど。
DynamoDBのユースケース
ビッグデータ向けの処理
大量のデータを収集・蓄積・分析(Kinesis連携など)
Hadoopと連携したビッグデータ処理
アプリケーション向け
大規模サービスで高速処理が必要なアプリケーション向け
ユーザー数が多いアプリケーションのデータ処理
ユーザー行動管理
ゲーム、広告などのユーザー行動のDB
transactionやrollebackがあまりいらない
バックエンドデータ処理
モバイルアプリのバックエンド
適用分析
JOIN, TRANSACTION, COMMIT, ROLLEBACKがあるか
検索, 大量の読み書きがあるかないかで判断
テーブル設計
テーブル
項目(Item): 例としてはPersonalなど
属性: 1つ以上の属性を持つ。Personalの属性として、姓、名など。
属性はVALUE型でもJSON型でも不揃いでよい。
DynamoDBのインデックス
暗黙的なキー
データを一意に特定するため、ハッシュキーやレンジキーを宣言して検索に利用するキー
１テーブルに１つ宣言
明示的なキー
LSI(local secondary Index)
追加でレンジキーを増やすイメージ
1テーブルに５つ作成可能、テーブル作成時に作成
検索を詳細にしたい場合などに使用。
GSI(global secondary Index)
データに対して別のハッシュキーを設定できる。
1テーブルに５つ作成可能、テーブル作成後に作成
プライマリーキー
ハッシュキー
テーブル作成時に一つの属性を選択し、ハッシュキーとして宣言
ハッシュ関数によってパーティションを決定するためハッシュキーと呼ぶ
単独での重複は許さない
レンジキー(複合キー)
ハッシュキーにレンジを加えたもの
2つの値の組み合わせにより項目を特定
複合キーは、単独であれば重複が許される。
ハッシュキーにもレンジキーにも、アイテムの属性を使用する。
明示的に利用するインデクス
ハッシュキーやレンジキーだけで検索が満たせない場合に使用
LSIは複合キーテーブルのに設定できる。
GSIはハッシュキーの代わりとなるため、ハッシュキーテーブル、複合キーテーブルどちらにも設定可能
使用するとスループットやストレージ容量の追加が必要なため、多用すべきではない。
テーブル操作
代表的なもの
GetItem
ハッシュキーを条件に一定の項目を取得
PutItem
1件書き込み
Update
1件更新
Delete
1件削除
Query
ハッシュキーやレンジキーを元にした検索(最大1MB)
Scan
テーブルの全件検索(最大1MB)
BatchGet
複数のプライマリーキーに対してマッチする項目を取得
DynamoDB Streams
DynamoDBテーブルに保存された項目の追加・変更・削除の発生時の履歴をキャプチャできる機能
過去24時間以内のデータ変更履歴を保存し、24時間経過すると消去される
同じハッシュキーに基づくデータの順番は維持されるが、異なるハッシュキーの場合順番が前後する可能性がある。
ユースケース
クロスリージョンレプリケーション
streamsのキャプチャをトリガにしてレプリケーションを実行できる
データ更新をトリガーとしたアプリケーション機能
データ更新に応じた通知処理などのアプリケーション処理の実行
lambda関数の実行などで、別テーブルの自動更新やログ保存、プッシュ通知などを実現できる。
DynamoDB Accelerator (DAX)
DynamoDBにインメモリキャッシュ型の機能を付加する。
DAXクラスタを使用して読み込む。
マルチAZDAXクラスタを構成できる。
マイクロ秒単位まで結果整合性のある読み込みワークロードの応答時間を短縮。
金融系などが想定される用途である。
DAXは運用上そしてアプリケーションの複雑性に影響なく容易に導入できる。
グローバルテーブル
DynamoDBはリージョン単位で作成するが、リージョン間で同期されるマルチマスターテーブルを作成可能
複数のリージョンにエンドポイントを持つことができる。
レプリケーションにかかるデータ転送料金が必要
強い整合性を設定することはできなくなる。
オンデマンドバックアップ
パフォーマンスに影響なく数百TB のバックアップを実行可能
任意のタイミングで利用可能な長期間データ保存用バックアップ
従来はデータパイプラインを利用して取得したバックアップを容易に実施できるようになった。
Read/Writeキャパシティオンデマンド
キャパシティ設定不要でリクエストに応じた課金設定を選択できるようになった。
トラフィック量の予測が困難な場合にリクエストの実績数に応じて課金
オンデマンドで Read Write 処理に自動スケーリングを実施
プロビジョンドキャパシティ設定への変更は無制限
オンデマンドへの変更は 1 日 1 回まで
DynamoDB活用
既存のRDB 中心のアーキテクチャを見直して DynamoDB とLambda などの組合せでサービスが実現できないか検証する
DynamoDBのデモ
DynamoDBはテーブルを作成する。
RDBはデータベースを作る。
S3と同様、リージョンに作成される（AZではない）。
テーブル作成
テーブル名の作成
パーティションキーの設定
プライマリーキー。これがハッシュになる。
例：社員ID
ソートキーの設定
プライマリーキーのレンジキーとなる。
例：部署名
テーブルクラス
標準と標準の低頻度アクセスが選択できる。
キャパシティ計算ツール
後述のキャパシティの見積もりができるツール
キャパシティモード
オンデマンドとプロビジョンドを選択可能
読み込みキャパシティ
Auto Scalingを有効にすると、最大、最小のキャパシティユニットを設定可能
書き込みキャパシティ
同上。
セカンダリインデックス
LSI
ソートキーを追加できる。
ただしよりキャパシティを消費する
途中で追加することができないので要注意
GSI
テーブル全体をスキャンして全体で何かを算出したい場合に使用
パーティションキーとソートキーが必要になる。
GSIは後で作成できる。
ただしよりキャパシティを消費する
保管時の暗号化設定
暗号化自体は必ず設定する。
データ追加
パーティションキー、ソートキーは空にすることができない。
セカンダリは空でも実施できる。
マネコンでも追加可能だが、基本はプログラムで追加していく。
その他の機能
モニタリング
CloudWatchのメトリクスを確認できる。
アラーム等も設定可能。
グローバルテーブル
レプリカを作成することができる
これを作成すると、付随してDynamoDB Streamsが自動的に有効化される。
バックアップ
オンデマンドバックアップを設定したり、スケジューリングすることが可能。
AWS Backupを使用したり、DynamoDBで実施することが可能
スケジューリングの場合は、AWS Backupと連携して実現する。
ポイントタイムリカバリ(PITR)
データを誤って削除した場合に時点を指定して復元できる。
追加の料金が必要。
エクスポート(DynamoDB Stream)
DynamoDB Streamの設定。
Kinesisと連携してまずStreamが作成される。
その後、ストリームを有効化する。
S3へのエクスポート
PITRを有効化すれば、S3バケットに保存することが可能。
PartiQL
SQLのようなクエリを実行することができるようになっている。
リザーブドキャパシティ
リザーブドで予約して購入することが可能。
割引された状態で購入することができる。
DAX
クラスターを設定する
T型とR型を選択できる。
サブネットに対して作るため、サブネットを指定する必要がある。
サブネットグループを選択(新規作成)する。
VPCを指定する。
その中のサブネットを選択する。
アクセスコントロール
セキュリティグループを設定する。
AZ割り当て
ノードを自動的にどのAZに割り当てるか決める。
手動でも設定可能
IAMロール設定
DynamoDBにアクセスする権利をクラスタに付与する。
Readonly, ReadWriteテーブル指定など細かい権限を指定できる。
暗号化
メモリ保持時や転送時の暗号化設定を有効化できる。
パラメータグループ
新規作成か設定する
メンテナンスウィンドウ
クラスタのメンテナンスをする時間をせっていできる。
Aurora
Auroraの概要
マルチAZで分散されたクラスター構成により、高速・高性能なリレーショナルデータベース
Amazonがクラウド時代に適したリレーショナルDBを一から考えて構築された新RDB
その特徴はNoSQL型の分散高速処理とRDBとしてのデータ操作性を両立させたこと
MySQLと2.5～5倍の性能を商用データベースの10分の1の価格で提供する高性能・低コストDB
特徴
高い並列処理によるストレージアクセスによってクエリを高速処理することが可能
Auroraは大量の書き込みや読み込みを同時に扱うことができる
データベースの集約やスループット向上が見込まれる
ただし、すべてが5倍高速というわけではなく、適用すべき領域を見つけて利用する
MySQL5.6互換やPostgreSQL互換を選択可能
耐障害性／自己回復性
3つのAZに2つのコピーを設置可能で合計6つのコピーを保持
過去のデータがそのままS3に継続的バックアップ
リストアも差分適用がなく高速
どのタイミングでも安定したリストア時間を実現
99.99％の高可用性・高耐久性
スケーラビリティ
10GBから最大64TBを提供するSSDデータプレーンを利用してシームレスに拡張可能
Auto-Scalingなどのクラウド独自のスケーラブルが可能
最大15のリードレプリカを利用した高速読み込みが可能
ユースケース
大規模なクエリ処理が発生するRDB環境などはAuroraへの移行を検討する。
書込み量が多くでトランザクション量が多い
クエリ並行度が高い、データサイズが大きいケースで効果を発揮する
コネクション数やテーブル数が多いデータベース処理
運用の容易さを活用する
スケーラビリティの高さやデータ容量が無制限に拡張できる
レプリケーションなどの性能の高さ
構成
1つのDBインスタンスと1つのDBクラスタボリュームで構成
3つのAZにコピーされたクラスタを単一と認識
Aurora Write(マスター)とAurora Reader(リードレプリカ, 最大15個)でDBクラスタを構成する。
Write, Readそれぞれのエンドポイントを介してEC2などからアクセスする。
フェイルオーバー
Readerをtier番号が大きい順、サイズが大きいサイズのReaderにフェイルオーバーを実施する。
マイグレーション
MySQLやPostgresSQLのスナップショットからAuroraへマイグレーション可能
MySQLは5.6, 5.7, 8.0.23のバージョンと互換性がある
マルチマスタ構成
Writerを複数別AZにスケーラブルに構築可能
どのノード、AZが落ちてもダウンタイムがゼロとなる
AuroraグローバルDB
他リージョンに設置する高性能なリードレプリカ作成が可能
ストレージレベルでレプリケーションを実施し、低レイテンシーでセカンダリリージョンとレプリケーションが可能
作成
使用可能なインスタンスクラス
tおよびrから選択
設置場所
VPCおよびサブネットを選択
セキュリティグループの設定
カスタムエンドポイント
エンドポイントを増やすことが可能。
増やすメリットは？
DBクラスタを他のAWSアカウントと共有
?
プロキシの作成
lambdaと連携する場合はプロキシを作成する
こちらだとコネクションが増えないというが、なぜだろう？
AutoScalingポリシー
RDSはストレージしかスケーリングできない。
AuroraはEC2インスタンスのようにAutoScalingすることができる。
具体的には、リードレプリカを増加させたりすることができる。
スナップショット
S3に保存され、ユーザーが指定したS3に保存することも可能。
クローン
クラスタ構成自体を複製することが可能。
実際の接続
mysqlコマンドがインストール済みのEC2インスタンスからエンドポイントに接続する。
Auroraサーバレス
ワークロードが予測困難な場合に使用
Auroraのオンデマンド自動スケーリングを実施
lambdaなどと連携して必要に応じて起動する。
普通のAurora(プロビジョンド)との違い
インスタンスサイズを指定できない。
代わりにフリートを設定してACUをMIN,MAXを設定する。
スケールがタイムアウトした場合や、アイドル状態の挙動も設定が必要。
DATA APIを有効にすると接続を管理せずに、Auroraサーバレスに対してSQLクエリを実行できる。
Auroraサーバレスのメリット
実働時間の変動が激しいケースでコストが安くなる。
スケーリングや可用性面でAuroraには劣る。
Redshift
Redshift概要
DWHを構成する、またはデータレイク分析をするサービス
ペタバイト以上まで拡張可能
1TBあたり年間1,000USD以下で利用可能。
自動ワークロード管理で、自動テーブルメンテナンスなどができるフルマネージド型
PostgresSQL互換の列指向データモデル
クラスタ構成が可能だが、単一AZでマルチAZ構成は不可。
高性能なra3インスタンスを使う
AQUAによる分散キャッシュによる高速動作が可能
データレイクの分析
S3にデータをため込む
S3をデータレイクとし、Redshift Spectrumで分析
インスタンスタイプ
RA3またはDC2インスタンスを選択
RA3インスタンスは1ノードあたり$3.836USD/hourだが、DC2は$0.314USD/hour
RA3は最低2ノード必要
1TB未満のデータセットでは、DC2ノードの使用を推奨
構成
リーダーノード
クエリのエンドポイント
SQLの生成、実行
コンピュートノード
高速SSDによるキャッシュ
クエリの並列実行
最大３２個まで適用可能
ストレージはRedshift管理用S3が勝手に構成
特徴
列指向
データ圧縮
ブロック単位でデータを格納し、ディスクIOを効率化
ソート
ブロックに対してメタデータを付与してそれを用いて検索する
リーダーノードのメモリにメタデータが格納されている
データ分散
マテリアライズドビュー
SQLのViewのような機能
頻繁に実行するパターンを結合・フィルタ・集計・射影などを使って高速化
運用の自動化
CloudWatchとの連動
自動バックアップ
スケジューリングやスナップショットが可能
自動メンテナンス
パッチ適用は自動で実施
時間を指定できる
スケジューリング機能
クラスターサイズの変更設定
一時停止と再開時間を設定
機械学習によるクエリの効率化
テーブルメンテナンスの自動化
テーブル分散スタイルの自動最適化
統計情報を使ってデータを再編成する
自動ワークロード管理
複数クエリの実行をワークロードで管理する際に機械学習でクエリ実行の優先順位を決めて自動化
ショートアクセラレーション
クエリの実行時間を予測し、実行時間が短いクエリを優先して実行
WLM(work load management)キューを削減可能
設定のレコメンデーション
パフォーマンスを分析し最適化やコスト削減についてレコメンデーションする
ワークロード管理(WLM)
ワークロードに応じてキューを設定し、スロットでCPUやメモリを割り当てる。
スロットを増やすと並列度が向上するが割り当てメモリは減少する。
説明がよくわからんよ？
クエリエディタ
マネコンでクエリを実行できる。
スケーリング
ノードを最大32個まで追加できる。ノードタイプの変更も可能
クラスターを追加することも可能
クラスタは自動的に数秒で追加でき、高速なパフォーマンスを維持
追加クラスタ数は1～10
Redshift Spectrum
S3に対して直接データ解析を可能。
ユーザー管理のS3バケットを指定して、解析することができる。
データをS3にため込む際にデータレイクとして使っていることが前提の機能
AthenaやS3クエリとの相違点はこの部分。
コンピュートノードの先にクエリエンジンが存在するような構成
データ連携(To Redshift)
S3
最も頻繁に使われるデータ連携先
S3からデータを取得してRedshiftで解析することも可能
S3内部のデータ解析を直接実行することも可能
Kinesis
Kinesis data Firehose を利用してストリーミングデータの格納先として Redshift を指定可能
これを解析に利用することが可能
RDS
RDS との直接接続はない
AWS Data Pipeline や DMSを利用してデータ移行を実施可能
DynamoDB
DynamoDB から Redshift にデータコピーを実行可能
Amazon EMR
EMR から Redshift にデータコピーを実行可能
データ連携(From Redshift)
QuickSight
Redshift に接続して、データの可視化を実施可能
S3
UNLOAD コマンドを実行することで、 Redshift から S3 へとデータを抽出することが可能
Amazon Machine Learning
RedShift を機械学習の学習データとして設定して利用可能
RDS
直接に連携はできないが、 PostgreSQL の機能を利用してデータを RedShift から RDS と連携可能
関連機能
QuickSight
データ可視化するBIツール
AWS Glue
ETLを行うマネージド型サービス
Athena, Redshift, EMRにloadする
AWS Lake Formation
データレイクの構成をベストプラクティスの中から構成を素早く実現することができる
Amazon EMR
Spark, Hive, Prestoなどのビッグデータフレームワークを使用して大量データを処理・分析する。
リザーブドノード
オンデマンドではなく、リザーブドで購入することで安価にすることができる。
実際の作成
設定
ノードのタイプの選択
クラスターのIAMロール設定
VPC、サブネットグループ、セキュリティグループなど
拡張されたVPCルーティング
パブリックアクセス設定
暗号化
メンテナンスウィンドウ
CloudWatchによるモニタリング
バックアップ設定
ElastiCache
概要
分散インメモリキャッシュサービスの構築・管理および助リングを実施できる。
特徴
キャッシュクラスタを数クリックで起動
フルマネージド型でモニタリング、自動障害検出、復旧、拡張、パッチ適用、バックアップに対応し高可用性を実現
広く利用されている2種類のエンジンmemcached, redisから選択可能
Redis
より高機能。
高速に値をRead/Writeできるインメモリキャッシュ型DB
シングルスレッドで動作するインメモリキャッシュDBで全てのデータ操作は排他的
スナップショット機能がある
データを永続化できる
以下が必要な場合
複雑なデータ型
リードレプリカ
pub/sub
フェイルオーバー
キーストアの永続性
バックアップと復元
複数のデータベース
Memcached
よりシンプル。一時的なデータ置き場として使う。
高速に値をRead/Writeできるインモリキャッシュ型DB
マルチスレッドで動作するインメモリキャッシュDB
スナップショット機能がない
データを永続化できない
フェイルオーバーや復元ができない。
以下が必要な場合
シンプルなデータ型を使う
複数コアまたはスレッドをもつ大きなノードを動かす必要がある
需要に応じたスケールアウト・イン機能
オブジェクトをキャッシュする必要がある
ElastiCache with Redis
Luaスクリプト
位置情報クエリ
pub/subモデル
チャットアプリなどのメッセージ処理、イベント処理
ユースケース
用途
セッション管理
IOT 処理とストリーム分析
メタデータ蓄積
ソーシャルメディアのデータ処理／分析
Pub/Sub 処理
DB キャッシュ処理
構成
アクセス頻度のtら会データをキャッシュに配置する。
通常のDBと組み合わせる
具体例
ユーザーのマッチング処理
レコメンデーションの結果処理
画像データの高速表示
ゲームイベント終了時のランキング表示
Last updated