データベース技術実践入門
https://gyazo.com/cb597902e1147f64de5ad98e6addb6a3
2012
2021年に読むには古い
第1章 データベースがないと何が困るのか
本書の対象読者
データベースの必要性がわからないという方
データベース技術の知識を整理したい方や，全体像をおさえたい方
1-2 データベースがないと何が困るのか
大量データの中から必要なものを高速に返せない
大量データはメモリ内だけでは扱えない
障害が起きたときの迅速な復旧が難しい
並列性の制御が難しい
データの整合性を保証することが難しい
第2章 インデックスで高速アクセスを実現する
2-1 「キーと値のペア」を管理したい
全件検索は大量データに向かない
目的の位置まで一瞬でたどり付ける方法を考える
インデックス構造を導入する
hash indexを使えば$ O(1)で探索できる
ハッシュインデックスは万能ではない
2-2 インデックスのデファクト「B+Treeインデックス」
B+Treeインデックスとは
探索の計算量
二分木$ O(\rm{log}_2N)
層が深くなるのでアクセス回数が多い
多分木$ O(\rm{log}_mN)
アクセス数が減らせる
2-3 RDBMSではどのように最適化を実現しているのか
一意性の保証
マルチカラムインデックス
インデックスだけを読む検索
「インデックスを読む→データを読む」が基本
データアクセスなしで処理できるクエリがある
例：価格にindexがあり、「価格<10000円の件数」が知りたいとき
2-4 更新コスト削減のための取り組み
ディスクへのまとめ書き
並列更新性能を高める
第3章 テーブル設計とリレーション
3-1 データモデリング技術の重要性
3-2 例題を使って考えてみよう
データ項目と関連性の意識
オーソドックスにテーブルを作ってみよう
3-3 ポイント①「テーブル関連」を導入する
参照整合性制約
3-4 ポイント②テーブル設計の妥当性を検証する
連番の列を導入する
1:N関連を2個導入する
主キーの値がよく変わる
レコード数が多くなる
コピペだらけ
マルチインデックスで、片方だけで一意に定まる
正規形はどこまで理解しておくべきか
経験が物を言う
第4章 SQL文の特徴とその使いこなし方
4-1 テーブルを操作する
テーブルを作成する
データベース製品間の互換性確保は難しい
一度作ったテーブルは簡単に変えられない
INSERT／SELECT／UPDATE／DELETEによるデータ操作
ジョイン
分散データベース環境とジョインの相性
サーバが別れているので
大規模になることを想定したアプリは巨大になりそうなテーブルとジョインしないようにアプリケーションを設計する
4-2 SQL文の実行効率を意識する
適切なインデックスが使われていることの確認
クエリ分析ツール
管理系コマンド
4-3 SQLの長所と短所
SQLは習得が容易
SQLは奥が深い
機能面
第5章 可用性とデータの複製
5-1 データベースはどういうときに落ちるのか
典型的な障害シナリオ
ソフトウェア障害
OS障害
ハードウェア障害
操作ミス
ディスク冗長化によってデータ消失を防ぐ
RAID
サーバの冗長化によってダウンタイムを減らす
5-2 レプリケーション
片方向レプリケーション
片方向／非同期
片方向／準同期
片方向／同期
双方向レプリケーション
双方向レプリケーションは技術的に難しい
障害からの復旧方法
人為的ミスへの対処
バックアップを戻した後どうすればよいのか
故意に遅延させたレプリケーション
第6章 トランザクションと整合性・耐障害性
6-1 トランザクションの大切さを理解する
中途半端な状態を防ぐ
SQL文レベルでのロールバック
耐障害性を確保する
REDOログの役割
二重書き込みのコスト
6-2 ロック機構による排他制御
ロックの範囲
ロックの期間
6-3 レプリケーションとトランザクション
「アトミックなレプリケーション」の重要性
ユーザはアトミックなレプリケーションにどう対処しているのか
第7章 ストレージ技術の変遷とデータベースへの影響
7-1 ハードウェアの性能改善の歴史
HDDによる処理の限界
メモリ価格の下落による64ビット環境の充実
メモリ上での処理の実行
64ビット時代のメモリ搭載量
シングルスレッド処理のパフォーマンス問題
SATA SSDによるパフォーマンス改善
PCI-Express SSDの効果
PCI-Expressとは
PCI-Express SSDの効率的な使い方
7-2 データベース改善の歴史
CPUスケーラビリティの改善
ディスクI/O並列性の改善
バックグラウンド処理の分割／並列化
7-3 今後のデータベースに求められるもの
ネットワークやCPUの利用効率がより重要になる
性能以外の重要性が高まる
第8章 データベース運用技術の勘どころ
8-1 データベース運用の苦労を知ろう
8-2 問題を予防する
よく知っている技術を使う
実績のある技術を使う
新しい技術のほうが不具合が多い
1年後にはまた新しい技術が登場する
アーキテクチャを複雑にしない
8-3 問題の認知
監視すべき項目
レスポンスタイム
CPU使用率
同時接続数とストール
秒間のSQL文実行回数
接続可否およびデータベース内部の状態
ハードウェア障害
空き領域
8-4 問題の解決
性能問題への対処
アプリケーションの修正
Webサーバの増設
キャッシュサーバの増設
スレーブサーバの増設
よりスペックの高いサーバへの移行・サーバの分割
「突然死」への対処
定型的な障害
非定型的な障害
第9章 MySQLに学ぶデータベース管理
9-1 MySQL導入のポイント
MySQLのインストールと基本設定
MySQLのダウンロード
①専用ユーザの作成
②データディレクトリの決定
③mysqlデータベースの作成
⑤MySQLの起動／接続／停止
ストレージエンジン
InnoDBストレージエンジン
ファイル構成
9-2 MySQL運用に必要なファイルの基礎知識
ログファイルの種類
エラーログファイル
スロークエリログファイル
一般ログファイル
バイナリログファイル
my.cnfの設定項目
basedir／datadir
port／socket
default-storage-engine
log-bin
slow-query-log
long-query-time
max_connections
innodb_buffer_pool_size
innodb_flush_method
innodb_data_file_path
innodb_autoextend_increment
innodb_log_file_size
9-3 MySQLバックアップの基礎
何のために何をバックアップするのか
バックアップの種類
コールドバックアップとオンラインバックアップ
論理バックアップと物理バックアップ
リカバリの方法
9-4 MySQLによるバックアップ／リカバリ
コールドバックアップの手順
バイナリログによるポイントインタイムリカバリ
バイナリログの有効化
バイナリログによるリカバリ
バイナリログのフォーマット
バイナリログの配置場所
mysqldumpによるオンラインバックアップ
ロックをかけないバックアップ
バイナリログの削除
LVMスナップショット機能によるオンラインバックアップ
第10章 MySQLのソースコードを追ってみよう
10-1 ソースコードを知ることに意味はあるのか
障害が起きたときに原因を突き止めることができる
自分でバグフィックスができる
自分に必要な機能を実装できる
MySQLのソースコードを入手する
10-2 ソースコードの構造を見てみよう
sql
include
mysys
storage
strings
mysql-test
client
10-3 ソースコードを解析してみよう
静的解析のアプローチ
動的解析アプローチとMySQLのビルド方法
configure
cmake
makeおよびmake install
デバッグ起動
動的解析をしてみよう
10-4 MySQLの設計思想を知ろう
プラグイン化を強力に推し進めている
外部ライブラリには極力依存しない
デバッグ用の機能
エンディアンフリー
関数ポインタ，サブクラスを多用し汎用性を上げる
プラグイン開発とは何か
MySQLのプラグイン開発の流れ
本体の開発も当然ながら可能
10-5 ソースハッキングのケーススタディ
バグの原因を突き止める
MySQLのクラッシュバグ
パッチの作成
原因究明の考え方
スタックトレースを取るシェルスクリプト
スタックトレースの分析
問題個所のソースコード
待たされているsql_parse.ccのソースコード
ソースコード上の変更個所を特定する
どの条件を満たしたらヒープソートを行うのかを決める
ヒープソート処理を実装する
EXPLAINの結果出力を制御する
テストケースを作成する
パッチの実行例
10-6 MySQLの開発コミュニティ
バグレポート
WorkLogで新機能を登録
パッチの投稿／レビュー／議論
パッチのレビュー
第11章 データベース技術の現在と未来
11-1 データベース技術のトレンド
データモデリングとSQL
オンラインでの定義変更
トリガーを使って変更履歴を記録し，あとでまとめて反映
レプリケーション構成を活用
スキーマレスのデータベース
11-2 大量データを高速に扱う技術
インデックス性能の劣化要因
レンジパーティショニング
B+Tree以外のインデックス
高速なSSDの利用
トランザクション
整合性のあるレプリケーションを実現
一貫性のあるバックアップを保証
11-3 分析系処理と列指向データベース
分析系の処理は何が難しいのか
DWH型のテーブル設計やSQL文を知ろう
DWH型のテーブル
DWH型のSQL文
レコード数およびデータサイズが大きい
従来型RDBMSにおける課題
処理対象ではない列にもアクセスが行われる
インデックス設計がきわめて難しい
範囲検索で大量のレコードにマッチする
列指向データベースとは何か
列指向データベースのメリット
必要な列だけがアクセスされるのでI/O効率が高い
圧縮効率が良い
ロード処理が高速
列指向データベースのデメリット
主キー検索などの狭い範囲の処理が遅い
製品としての成熟度が低い
11-4 NoSQLデータベース
インメモリの処理が生み出した新たな課題
SQLデータベースの課題
NoSQLとは何か
テーブル／ファイルを開きっぱなしにする
一般的なNoSQLの欠点
トランザクションをサポートしていない
「スキーマ」がない
主キー以外のインデックスを使えない
NoSQLの用途
キャッシュ
セッションデータ
RDBMSとNoSQLのハイブリッド構成
MySQL Cluster（NDB）
myCached/HandlerSocket
分散データベース
11-5 その他のトピック
Write Onceのデータベース
Write Scaling
マルチマスタ構成
自動Shard編成
第12章 ビッグデータ時代のデータベース設計
12-1 Webサービスのためのデータベース概論
データベースの選定基準
ソーシャルゲームの主な特徴
ユーザ数が基本的に多く一気に増えることもある
主な情報はすべてサーバ側で持つ
ユーザIDをキーにした処理が多い
構造化されたデータ項目が多い
永続的に必要とされるデータと期間限定のデータがある
可用性や整合性に関する要求が意外と高い
大規模Webサービス向けのデータベースに求められる機能
オンライン（無停止）でのスキーマ変更
水平分散（Sharding）の容易さ
安定性
単一障害点の除去
2ヵ所以上のデータセンター
単体性能の高さ
局所的な超高速化
規模が違えば選定基準も変わる
12-2 Mobageにおけるデータベースの活用事例
大規模サービスとデータベース
クラウドとリアルサーバ
トラフィック増加／減少への対応
性能改善
性能分析
運用体制の整備
DeNAおよび子会社での経験
データベースの製品選定
性能が高いこと
時系列／履歴系データの扱いに長けていること
トランザクション／耐障害機能が充実していること
良質のドキュメント／品質／普及度を満たしている
12-3 Webサービスとデータモデリング
データモデリングの重要性を知ろう
データの分類
マスタ系のテーブル
トランザクション系のテーブル
テーブル関連
1対多関係
派生関係
階層関係
「階層型部品表」タイプ
12-4 データ量増加対策と高速化手法
テーブルサイズと負荷対策
INSERT主体のテーブル
INSERTの性能指標
時系列処理の高速化アプローチ
DELETEのチューニング
データの保持期間を確認する
データ削除のやり方によっても成果は変わる
スレーブ遅延を防ぐには
UPDATE主体のテーブル
負荷傾向をモニタリングする
12-5 MySQLにおける性能改善テクニック
クエリを改善する
遅いクエリを洗い出す
ソートの実行効率に注意する
実行頻度の多いクエリを洗い出す
遅いトランザクションを改善する
MySlowTranCaptureによる遅いトランザクションの洗い出し
ロック競合への配慮
タイムアウト設定
ロックを長時間かけない
異なるサーバ間でのデッドロックに注意する