Webエンジニアのための データベース技術 実践入門

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)


第1章 データベースがないと何が困るのか

1-1 技術者として求められるスキルセット

データベース技術の重要性
本書の対象読者
データベースの必要性がわからないという方
データベース技術の知識を整理したい方や,全体像をおさえたい方
1-2 データベースがないと何が困るのか

大量データの中から必要なものを高速に返せない
大量データはメモリ内だけでは扱えない
障害が起きたときの迅速な復旧が難しい
並列性の制御が難しい
データの整合性を保証することが難しい
1-3 本書では何を扱っていくのか

第2章 インデックスで高速アクセスを実現する

2-1 「キーと値のペア」を管理したい

全件検索は大量データに向かない
目的の位置まで一瞬でたどり付ける方法を考える
インデックス構造を導入する
ハッシュインデックス
ハッシュインデックスは万能ではない
2-2 インデックスのデファクト「B+Treeインデックス」

B+Treeインデックスとは
多分木と二分木
B+TreeとB-Tree
2-3 RDBMSではどのように最適化を実現しているのか

一意性の保証
マルチカラムインデックス
インデックスだけを読む検索
インデックスマージ
2-4 更新コスト削減のための取り組み

ディスクへのまとめ書き
並列更新性能を高める
第3章 テーブル設計とリレーション

3-1 データモデリング技術の重要性

3-2 例題を使って考えてみよう

データ項目と関連性の意識
オーソドックスにテーブルを作ってみよう
3-3 ポイント①「テーブル関連」を導入する

参照整合性制約
3-4 ポイント②テーブル設計の妥当性を検証する

連番の列を導入する
1:N関連を2個導入する
主キーの値がよく変わる
レコード数が多くなる
3-5 正規化理論の基本をおさえよう

第1正規形
第2正規形
第3正規形
正規形はどこまで理解しておくべきか
第4章 SQL文の特徴とその使いこなし方

4-1 テーブルを操作する

テーブルを作成する
データベース製品間の互換性確保は難しい
一度作ったテーブルは簡単に変えられない
INSERT/SELECT/UPDATE/DELETEによるデータ操作
INSERT文
SELECT文
UPDATE文
DELETE文
ジョイン
分散データベース環境とジョインの相性
4-2 SQL文の実行効率を意識する

適切なインデックスが使われていることの確認
EXPLAIN
クエリ分析ツール
管理系コマンド
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データベースの作成
④設定ファイルmy.cnfの作成
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 ソースハッキングのケーススタディ

[ケース1]コアファイルから問題個所を特定する
バグの原因を突き止める
MySQLのクラッシュバグ
パッチの作成
[ケース2]スタックトレースから問題個所を特定する
原因究明の考え方
スタックトレースを取るシェルスクリプト
スタックトレースの分析
問題個所のソースコード
待たされているsql_parse.ccのソースコード
[ケース3]新機能を追加してみる
ソースコード上の変更個所を特定する
どの条件を満たしたらヒープソートを行うのかを決める
ヒープソート処理を実装する
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による遅いトランザクションの洗い出し
ロック競合への配慮
タイムアウト設定
ロックを長時間かけない
異なるサーバ間でのデッドロックに注意する




昨日は遊びすぎたので、今日は読書三昧。

いわゆる効率的なクエリとかデータベース設定をステップアップ方式で学ぶ本ではない。
今のデータベース技術を広く、浅く解説した本。

データベースはMySQLくらいしか使ったことがない自分でも、スイスイ読めた。

とにかく例がわかりやすい。
ドラクエにおけるジョブチェンジを可能にする、効率てきなDBの作り方とか。


面白くてすいすい読めた。


レベルの高い人は、ガンガンハックして先進的な技術を取り入れても良いと思うけれど、自分みたいなレベルの高くない人は、十分に枯れたMySQLとかが良いのかな。と

あと、やっぱりクラウドサービスは便利だな。
学生起業家とかが使うのもわかる。

自作サーバーっていうのは、色々と自分好みのチューニングできて面白いかもしれないけれど、大概のウェブサービスならクラウドに任せるってので十分だなぁ。