「ベゾス・レター:アマゾンに学ぶ14ヵ条の成長原則」を読んだ
- 作者:スティーブ&カレン・アンダーソン
- 出版社/メーカー: すばる舎
- 発売日: 2019/11/18
- メディア: 単行本
目的、モチベーション
twitterで知った。ベゾスが発してる情報源である株主への手紙を読み解いて、成長原則を学ぶというコンセプトが面白そうだったので、読んだ。
全体の感想
Amazon系のビジネス書は、「ワンクリック ジェフ・ベゾス率いるAMAZONの隆盛」や「ジェフ・ベゾス 果てなき野望」など何冊か読んだことがあったり、ネットの記事を読んだりしてたので、めちゃくちゃ目新しいものがあったかというと微妙。頭の中は整理できたり、復習にはなったりした。
ややこしいが、本書の14ヵ条はAmazonが掲げる「Our Leadership Principles」という14項目からなる信条とは別物で、著者が約20年分の株主へのレターからベゾスやAmazonが重視している原則を見出したものなので注意。
メモ
前段として、Amazonにおけるリスクの話があった。
リスクは一般的には避けられるものだが、長期的に正しく進むためや、大きな革新やリターンを得るためには大胆に迅速に進める必要がある。
そのため、ある程度は失敗する前提で学びを得られれば良しとしてリスクを犯すべき。
14ヵ条は以下の通りで、企業文化として有名なものが多かった。
- 成長サイクル:実験
- 第1条 「いい失敗」を促す
- 第2条 大きなアイデアに賭ける
- 第3条 ダイナミックな発明や革新を実践する
- 成長サイクル:構築
- 第4条 顧客にこだわる
- 第5条 長期的な考え方を採用する
- 第6条 自分の「弾み車」 を理解する
- 成長サイクル:加速
- 成長サイクル:規模の拡大
- 第11条 企業文化を守る
- 第12条 高水準を重視する
- 第13条 重要な項目を計測し、計測項目を疑い、自分の直感を信じる
- 第14条 常に1日目だと信じる
特に印象に残ったのは、以下。
第4条 顧客にこだわる
ユーザ本位というのは、どのような会社でも同じようなことを掲げるが、Amazonでは顧客に「すごい」と言われるような極端なレベルまでこだわるというのを徹底している。
顧客の問題を解決するのではなく、問題を発生させずに完全に潰すのが仕事。
徹底している一例として挙げられて面白かったのは、オンデマンドの映画を購入した顧客が見た時間帯に、顧客が気づかないレベルでネットワークの状態が少しだけ悪かったことをシステムが検知し、Amazon側から自ら顧客に謝罪と返金の連絡を行った。
第7条 決定は迅速に行う
大きい組織でも迅速に意思決定を行うために、「後戻りできない」ものと「失敗しても辞めたり取り返しのつく」ものの2種類に分類している。
遅くなって手遅れになるよりも、情報不足で間違うことの方を良しとする。
第13条 重要な項目を計測し、計測項目を疑い、自分の直感を信じる
意思決定の際には数字をみて良し悪しの判断を勿論行っているが、スムーズにできる一方で、革新が起こりにくくもなるので数字は疑いもする。
- 作者:スティーブ&カレン・アンダーソン
- 出版社/メーカー: すばる舎
- 発売日: 2019/11/18
- メディア: 単行本
「絵で見てわかるシステムパフォーマンスの仕組み」を読んだ
目的、モチベーション
バックエンドのパフォーマンス改善において、指標となるCPUやメモリ等の基礎の理解を深め、実際の調査方法などが知りたかった。
全体の感想
表紙とタイトルから、図録みたいなものなのかと勝手に連想していたが、いい意味で裏切られた。普通にテキストによる説明がメインで、他の技術書よりもイメージをつかみやすいように絵がたくさんあったという印象。
アルゴリズムやデータ構造、アプリケーション、OS、インフラ、プロジェクトの進め方など、カバー範囲がとにかく広かった。
パフォーマンスのボトルネックの調査方法を知りたいのが目的の一つだったので、OSのコマンドの使い分けなどは特に良かった。
またパフォーマンステストの進め方は目的ではなかったが、私の経験で思ってるよりも時間がかかったり、再現が難しかったり今まであまりうまくいかなかったことが言語化されていて、整理もできて良かった。
少し個人的に残念なのは、2014年に出版された本のためDockerやコンテナ周りの話は触れられてなかった。
目次
概要
【第1章】パフォーマンスの基礎的な考え方
計算量やアルゴリズムの説明だった。知ってる内容だったので割愛。
【第2章】パフォーマンス分析の基本
2.2 必要なパフォーマンス情報とは
2.2.1 「はさみうち」の原則
前後の計測も行わないと、ただのスパイクなのか、何が原因なのかを確認できないので、必ず行うこと。
2.2.2 パフォーマンス情報の3種類
名前 | 特徴 |
---|---|
サマリ形式 | 一定期間の合計や平均の情報。概況を抑えるのには向いているが、変動を捉えるのには不向き。 |
イベント記録形式 | 個々のイベントを逐次記録された情報。詳細な調査には向くが、データ量や負荷が大きくなるので、本番で常に実行するには不向き。 |
スナップショット形式 | ある時点での状況の記録情報。定期的に取得することで、原因調査などが行える。 |
2.4 OSのコマンド
コマンド | 形式 | 計測点 | 補足 |
---|---|---|---|
sar | サマリ形式 | OSのカーネルからのOS情報 | CPU、I/O、メモリなどの概況がわかる。 |
vmstat | サマリ形式 | OSのカーネル情報からのOS情報 | 実行待ちの平均プロセス数、ブロックされているプロセス数などがわかる。 |
ps | スナップショット形式 | OSのカーネルで各プロセスの情報 | プロセスの状態、CPU時間などがわかる。負荷が高いので高頻度で取得するには向いてない。 |
netstat | サマリ形式/スナップショット形式 | ドライバレベル | ソケット、ルーティング、インターフェースごとの統計がわかる。 |
iostat | サマリ形式 | OSカーネル内部のブロックデバイスレベル | |
top | スナップショット形式 | OSレベル | OS全体の概況把握に最適。少々負荷が高い。 |
パケットダンプ(wireshark、tcpdumpなど) | イベント記録形式 | ドライバレベル | 負荷が大きく、パフォーマンスに影響が出る。 |
pstack | スナップショット形式 | OSから見たコールスタックの情報 | 何度か取得し、詰まってる処理を特定して、アプリケーションなどの問題を特定する。負荷は低い。 |
システムコール(straceなど) | イベント記録形式 | OSから見たプロセスのシステムコール情報 | 負荷が高い。 |
プロファイラ | サマリ形式 | OSから見たプロセスの各関数の処理時間 |
【第3章】実システムのパフォーマンス分析
用語の説明が多かったので、割愛。
【第4章】パフォーマンスチューニング
4.3 現場で用いられるテクニック
パフォーマンス改善と一口に言っても様々な方法があるが、一覧化されると整理できて良かった。
- ループの省略、キャッチボールの削減
- 局所最適に陥られないこと。例えば、DBで何度もINDEXを使った参照をするよりかは、1度のフルスキャンでデータを取得する。
- 参照頻度の高いデータはキーバリューストア化かハッシュ化する
- ハッシュのアクセスはO(1)
- 参照頻度の高いデータは使う場所の近くに置く
- CPUの内部レベルでも、CDNなどでも。
- 同期を非同期に変える
- 帯域制限
- LRU(Least Recent Used)方式
- 処理の分割またはロックの粒度の詳細化
- 不揮発なライトバックのキャッシュの採用
- マルチレイヤのキャッシュの採用
- ジャンボフレームと高速ネットワークの採用
- パケットあたりのデータ量を増やすことでパケット数を減らし、CPU使用量を減らす
- 負荷分散、ラウンドロビン
- アフィニティ、バインド、Stickyセッション
- キャッシュの特性を活かすために局所化する
- copy on write(COW)
- ジャーナル、ログ
- DBへの書き込みなどを一括で行い、パフォーマンスを改善する
- 圧縮
- 楽観的ロック
- カラムナデータベース(Columnar Database)
- サーバのパフォーマンス設定は初期値=最大値?
【第5章】パフォーマンステスト
この章では、パフォーマンステストの進め方が紹介されていた。
企画段階から、リリースしてから運用するまで、関係者とどのように進めるのかなど。
ややSIerっぽい内容ではあるが、環境構築や実際のテスト時の注意点は大変参考になった。
5.2 よくある失敗:9つのアンチパターン
5.2.1 期間内に終わらない!
本番環境でないと再現しない、再現するための環境構築に時間がかかる、特定の操作で問題発生などで、スケジュール通りに進まない。
5.2.2 パフォーマンスが出ない! パフォーマンス問題が解決できない!
原因究明には、あらゆるレイヤーの知識が求められるため、時間がかかる。
5.2.3 環境差異を考慮しないために問題が発生
インフラやサーバの設定が異なるなど。
5.2.4 負荷シナリオ設計に不備があるために問題が発生
- 一部の画面操作しか考慮していなかった
- 長時間滞在して多くの画面を遷移し、セッションに蓄積されて多くのメモリが使用された
5.2.5 バッファ/キャッシュの利用を考慮しないために問題が発生
特定のデータやパターンを集中的にテストしたために、キャッシュが乗った状態で十分に検証できてなかった。
5.2.6 シンクタイムを考慮しないために問題が発生
本番環境でユーザが複数の操作する際にテスト時よりも時間がかかり、HTTPのコネクション数やセッションの維持数に影響が出てしまう。
5.2.9 テストに時間がかかる
インフラの環境構築、計測や監視の設定、負荷生成シナリオスクリプト、本番同等のデータ作成、調査の時間など。
5.3 パフォーマンステストの種類
開発段階に応じて、できる種類のテストが異なる(インフラ、アプリケーションなどの単体しか行えないなど)。
また、知りたいパフォーマンスの種類によっても分類できる。
- 狭義のパフォーマンステスト: 要件が満たせるか
- 限界パフォーマンス: 上限の調査
- 縮退パフォーマンス: 一部のノードが落ちてしまったときのテスト
- 障害テスト: 障害が起こってしまった際のエラーの確認や対応の確認など
5.4 プロジェクト工程で考えるパフォーマンステスト
5.4.1 要件定義
「スループット」、「レスポンスタイム」、「ユーザ多重度」の3つは必ず設定すること。これらは互いに依存し合うため、一つ改善しても他が悪化する可能性があるため。
【第6章】仮想化環境におけるパフォーマンス
仮想化をすることによって、CPUの命令の変換やメモリのマッピングなどの処理が入るため、遅くなる。
また、元のOSのCPU数より多くのCPUを使用するとオーバーヘッドが生じるので、チューニングが必要になる。
【第7章】クラウド環境におけるパフォーマンス
ざっと読んだが、今回の目的とは関係ないので割愛。
次のアクション
詳解 システム・パフォーマンスを読む。
「[試して理解]Linuxのしくみ」を読んだ
[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識
- 作者: 武内覚
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/23
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
目的、モチベーション
バックエンドのパフォーマンス改善において、指標となるCPUやメモリ等の基礎の復習をしたかった。
全体の感想
サブタイトルにある通り、実験と図解を重視されており、理解しやすかった。
OS周りはとっつきにくく、今まで教科書的な本を読んだことがあったが、頭には入りにくかったりイメージしにくかったが、こちらの本は図がとにかく多いのが良かった。
あやふやだった点を整理することもでき、理解しやすく良書だったが、今回求めてたレベル感ではなかった。1,2年目のときに読みたかった。
OS周りの1冊目の入門書としてや、理解を整理したいときにオススメです。
気になったところ
第2章 ユーザモードで実現する機能
コマンド
コマンド | 説明 |
---|---|
strace | システムコールの呼び出しの詳細が見れる |
sar | CPU時間の割合の詳細が見れる |
第5章 メモリ管理
メモリに関する統計情報
統計情報の取得には、freeコマンドを用いる。
フェールド名 | 説明 |
---|---|
total | 全メモリの量 |
free | 見かけ上の空きメモリ(詳しくはavailable) |
buff/cache | バッファキャッシュ、及びページキャッシュが利用するメモリ。システムの空きメモリが減少してきたら、カーネルによって解放される。 |
available | 実質的な空きメモリ。freeフィールドの値に、空きメモリがたりなくなってきたら、解放できるカーネル内メモリ領域のサイズを足したもの。 |
仮想記憶
プロセスが物理アドレスを直接扱うと、プロセス間で干渉したり、連続したアドレスが取得できない場合に処理が煩雑になってしまう。
この問題に解決するために、仮想記憶を介して、仮想アドレスを扱う。仮想記憶はページテーブルと呼ばれる、仮想アドレスと物理アドレスのマップングした対応情報をカーネルが使うメモリ内保存される。
デマンドページング
メモリはプロセスが生成された際に割り当てられる。これだとメモリが無駄に割り当てられる可能性がある。
デマンドページングを用いれば、仮想アドレスは最初に割り当てて、物理メモリは実際に使用される際に割り当てることで、改善できる。
第7章 ファイルシステム
ファイルシステムの不整合
システムの電源が処理途中に落ちてしまったりして、ファイルシステムのデータに不整合が生じる可能性がある。
不整合を防ぐ代表的なものは、「ジャーナリング」と「コピーオンライト」の2つの方式がある。
ジャーナリング
この手法では、下記のように処理内容を別のメタデータで保存することで防ぐ。
- 処理に必要なアトミック処理の一覧を、いったんジャーナル領域に書き出す(この一覧をジャーナルログと呼ぶ)。
- ジャーナル領域の内容に基づいて、実際にファイルシステムの内容を更新する。
1つ目の処理の途中で終わった場合はメタデータを破棄し、2つ目の処理の途中で終わった場合は再実行することで、不整合を解消できる。
コピーオンライト
この手法では、更新されるデータを別の場所にすべて書き込んでからリンクを張り替えることで防ぐ。
処理の途中で終わった場合は、再起動時にデータを削除することで、不整合を解消できる。
第8章 ストレージデバイス
HDDの性質上、ハードウェアがレイテンシーのボトルネックになる。
そのため、シーケンシャルにデータを配置し、できるだけ多くのデータを一度に取得することで、パフォーマンスの向上が期待できる。
I/Oスケジューラ
ブロックデバイスへのアクセス要求を一定期間溜めて、下記のような加工を行ってから、デバイスドライバにI/O要求をすることで、I/O性能の向上を目指す。
- マージ: 複数の連続するセクタへのI/O要求を1つにまとめる。
- ソート: 複数の不連続なセクタへのI/O要求をセクタ番号順に並び替える。
次のアクション
低レイヤーの理解が欠かせないなと思ったので、そちらの本とかを調査しつつ、もう1冊入門レベルの本(絵で見てわかるシステムパフォーマンスの仕組み)を買ったので読む。 あとは、積読中の詳解 システム・パフォーマンスを読む。
[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識
- 作者: 武内覚
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/23
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
「Apache Kafka 分散メッセージングシステムの構築と活用」を読んだ
Apache Kafka 分散メッセージングシステムの構築と活用 (NEXT ONE)
- 作者: 株式会社NTTデータ,佐々木徹,岩崎正剛,猿田浩輔,都築正宜,吉田耕陽,下垣徹,土橋昌
- 出版社/メーカー: 翔泳社
- 発売日: 2018/10/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
目的、モチベーション
本業のプロダクトでKafkaを使っていて、理解を深めたいと思ったので読んだ。
読む前の状態としては、Kafkaは触れてるが大規模のデータを捌けるPub/Subメッセージを扱うログ型DBみたいなものぐらいのイメージだった。
全体の感想
生まれた歴史から、どのような仕組みで何を解決するものなのか、実際の例まで一通り網羅されていて、入門書として良かった。
実用例のパターンも何種類も紹介されていて、本番環境レベルではないがイメージを掴むには良かった。
インストール方法やコード例(Javaがほとんど)もあって、手も動かせる。
コードで動かさなかったが、半日ぐらいで読めた。
Kafkaは便利だと思っていたが、完全にメッセージを厳密に一度だけ処理するには、アプリケーション側でも冪等性を保つなどの工夫が必要で単純なものではないんだなと思った。
目次
- 目的、モチベーション
- 全体の感想
- 目次
- 概要
概要
印象に残ったところを記載してます。少し公式ドキュメントを読んで補足している箇所もあります。
第1部 導入Apache Kafka
1 Apache Kafkaの概要
1.3 Kafka誕生の背景
元々は、LinkedInの下記のような技術的課題からオープンソースとして生まれた。
- 高スループットでリアルタイムに処理したい
- 任意のタイミングでデータを読み出したい
- 各種プロダクトやシステムとの接続を用意にしたい
- メッセージをロストしたくない
1.4 Kafkaによる要求仕様の実現
下記の3要素からなる。
- Producer: メッセージの送信元
- Broker: メッセージの収集/配信役
- 挟むことで、ProducerとConsumerの接続先を一つにでき、増減などの構成変更に影響されないようにできる
- Consumer: メッセージの配信先
https://kafka.apache.org/images/producer_consumer.png
送達保証
Exactly Onceレベル(Consumerが処理を実行するのを一回にする)の送達保証をするために、トランザクションの概念を導入。
ProducerとBroker間では、BrokerがProducerにAckの返送に失敗した場合、ProducerがRetryしてBrokerがメッセージを受け取り、2度目以降は記録せずに排除することで実現する。
ConsumerとBroker間では、どこまでメッセージを受け取ったかのオフセットを管理されており、トランザクションでオフセットのコミットを行うことで実現する。オフセットコミットに失敗した場合、もう一度メッセージが処理されるため、Consumer側でも冪等性が必要。
2 Kafkaの基本
2.3 システム構成
Brokerは耐久性向上のために複数台で構成されており、ZooKeeperで分散処理の管理が行われている。
2.4 分散メッセージングのための仕組み
Partition: Topicに対する負荷を分散させるために、Partition単位で分割されている。負荷分散のために、Brokerクラスタ中に分散に配置される。
Messageの送受信
ProducerのMessage送信: メッセージがあるデータ量まで蓄積されたか、指定した時間毎に送ることでパフォーマンス向上できる。
ConsumerのMessage取得: 同様にまとめて送信することができる。
スループットの向上が期待できる一方で、レイテンシーが発生するのでトレードオフ。
Consumerのロールバック
ロールバックによって、メッセージのAt Least Once(最低でも一回は受信される)ことは保証できるが、Exactly Onceはアプリケーション側の対応が必要。
2.5 データの堅牢性を高めるレプリケーションの仕組み
ISR: In-Sync Replica, 最新の状態を保っているReplicaのこと。
最小のISR数を min.insync.replica
で指定できる。
High Watermark
レプリケーションが完了しているOffsetのことを指す。これより新しいOffsetのものはConsumerが取得できない。
ProducerのMessage到達保証レベルの調整
Messageが送信されたことを示すAckを、BrokerがProducerへ返す設定によって、性能と耐障害性に大きく影響する。
値 | 説明 |
---|---|
0 | BrokerのAckを待たない。Brokerに保存されたことは一切保証されず、リトライも行われない。 |
1 | Leaderのレプリカに書き込まれたらAckを返す。Followerのレプリカに書き込まれる前に、Leaderが落ちるとデータロストが発生する。 |
all | すべてのISRの数までレプリケーションされたらAckを返す。但し、万一レプリケーションされてないノードのみ生き残った場合、データロストが発生する。 |
上記の「書き込まれた」というのはディスクに書き込まれたタイミングではなく、あくまでもメモリに書き込まれたタイミング。
ディスクへの書き込みは、 log.flush.interval.ms
を指定する。
3 Kafkaのインストール
インストール方法が紹介されてました。
4 KafkaのJava APIを用いたアプリケーションの作成
Javaの標準ライブラリでの実装例が紹介されてました。
4.4 作成したProducerアプリケーションのポイント
Producerの送信処理は非同期で行われるため、アプリケーション側で send
メソッドでメッセージをする際にはキューに入れられただけで実際の送信は別で行われる。
第2部 実践Apache Kafka
5 Kafkaのユースケース
下記のような実例の概要が紹介されてました。
- データハブ
- ログ収集
- Webアクティビティ分析
- IoT
- イベントソーシング
5.3 データハブ
システムが成長していくと、複数のDBやログデータを収集して分析用のDBなどに加工して送りたくなるケースが出てくる。
それぞれを直接つないでしまうと、影響範囲が広くなる上に、必要となるフォーマットが異なる度に実装が必要となってしまう。
このサイロ化の解決手段の一つが、データハブアーキテクチャ。上流のシステムの接続をKafkaなどのハブを介することで、疎結合にすることができる。
6 Kafkaを用いたデータパイプライン構築時の前提知識
6.3 データパイプラインで扱うデータ
ストリーミング処理では、複数のアプリケーションが常時起動している状態で、改修などで発生するデータの変更等を行わなければならない。
Messageのデータ型は、異なる言語でも使えるフォーマット(JSON, Apache Avroなど)を用いた上で、互換性を保つべき。
しかし、どうしても互換性を担保できないケースも出てくるが、Schema Registryを用いれば解決できるケースもある。
Schema Registryでは、Apache Avro前提で、Producerの送信時にスキーマ情報を保存してConsumerがそのスキーマ情報をもとにデシリアライズする。
7 KafkaとKafka Connectによるデータハブ
8 ストリーム処理の基本
9 Structured Streamingによるストリーム処理
5章で紹介されていたものの、実装例を中心に紹介されてました。
10 Kafkaで構成するIoTデータハブ
10.2 IoTに求められるシステム特性とKafka
IoTでは、下記のような特徴からKafkaと相性が良い。
10.3 センサーデータ向けデータハブの設計
センサー側でデータを加工するのは難しいため、サーバ側で加工することになる。
ブローカーに保存する前に、加工すればデータ量を削ることができるが、生データの情報が失われ、保存後に加工するとその逆が発生するので、トレードオフ。
軽量なMQTTプロトコルを用いれば、メッセージングモデルによる非同期処理が効率的に行える。
11 さらにKafkaを使いこなすために
11.2 Consumer Group
Consumer Groupというグループを各Consumerに設定することで、複数のConsumerで分散処理を行える。
各Partitionにつき必ず1つのConsumerが対応付けられるように割り当てられる。
そのため、Consumerの数が多いと割り当てられないConsumerが発生する。逆にPartition数の方が多いと、複数のPartitionが割り当てられるConsumerが発生する。
割り当てのロジックは partition.assignment.strategy
で指定できる。
11.3 Offset Commit
enable.auto.commit
でOffset Commitの自動化を切り替えられる。
現時点(2019/10/14)の最新のバージョンでは、基本的にはtrueがデフォルトとなっている。
自動化するとアプリケーション側の制御が不要になる一方で、障害のタイミング次第で複数回処理されたり、一度も処理されないケースが発生するので要注意。
11.5 Partition数の考慮
Brokerの数に対して、Partition数が少ないと送受信の処理の重いLeaderがあるBrokerに負荷が集中してしまうため、要注意。
Apache Kafka 分散メッセージングシステムの構築と活用 (NEXT ONE)
- 作者: 株式会社NTTデータ,佐々木徹,岩崎正剛,猿田浩輔,都築正宜,吉田耕陽,下垣徹,土橋昌
- 出版社/メーカー: 翔泳社
- 発売日: 2018/10/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
「RDBMS解剖学」を読んだ
RDBMS解剖学 よくわかるリレーショナルデータベースの仕組み (DB Magazine Selection)
- 作者: 鈴木幸市,藤塚勤也
- 出版社/メーカー: 翔泳社
- 発売日: 2005/02/22
- メディア: 単行本(ソフトカバー)
- 購入: 11人 クリック: 88回
- この商品を含むブログ (26件) を見る
目的、モチベーション
- DBの処理の一連の流れを俯瞰して理解したい
- 特に、実行計画やトランザクション管理など
全体の感想
SQLを解析して、どのようなプランでデータを制御し、トランザクションや排他制御、マルチバージョンをどのように行うかなどを俯瞰的に解説されてました。
SQL周りは特に目新しい情報もあまりありませんでしたが、特にトランザクションの制御やログなどはなかなか基礎的なところから説明した書籍等があまりないので、重宝しました。
廃版になってしまってるので手に入れにくいですが、DBの中の基礎知識がない方にはオススメです。
目次
- 目的、モチベーション
- 全体の感想
- 目次
- 概要
- 第1部 はじめに
- Chapter 1 データベースの基礎とディスクアクセス
- 第2部 SQLの処理
- Chapter 2 SQLをどう料理するか(1) SQLの構文解析
- Chapter 3 SQLをどう料理するか(2) SQLから演算へ
- Chapter 4 カタログとインデックス
- Chapter 5 SQLの実行エンジン
- Chapter 6 物理プランの生成
- 第3部 システム化のサポート
- Chapter 7 トランザクションの基礎
- Chapter 8 トランザクション制御とMVCC
- Chapter 9 ログ機能によるパフォーマンスの向上
- Chapter 10 ログによる障害からの復旧
- 第4部 複数データベースをまとめる
- Chapter 11 クラスタリングによる性能向上
- Chapter 12 データベースのパーティショニング
- 次のアクション
概要
第1部 はじめに
全体の処理の種類や流れは以下の図のように整理できる。
Chapter 1 データベースの基礎とディスクアクセス
ディスクはメモリと比べて安価だが、数万とかのレベルで遅い。
第2部 SQLの処理
Chapter 2 SQLをどう料理するか(1) SQLの構文解析
構文を解析して、構文ツリーを作成する。
Chapter 3 SQLをどう料理するか(2) SQLから演算へ
論理プラン: SQLを操作手順に解釈して、代数の演算に変換し、どれが効率的に行えるか選択する
物理プラン: 論理プランをコンピュータ上の実行手順に書き換えたもの
Chapter 4 カタログとインデックス
カタログとは
- データベース情報
- テーブル情報
- ビュー情報
- カラム情報
- インデックス情報
- 制約情報
- データベースユーザ情報
- 統計情報(カラムの最大値、最小値、種類数など)
- ストアドプロシージャ/トリガー情報
- 性能情報
重要な用途は、「SQL構文解析の整合性チェック」と「最適プランの選択」。
Chapter 5 SQLの実行エンジン
テーブルスキャンやマージの種類が複数紹介されていた。
これらのアルゴリズムとカタログ情報から最適なプランを評価する。
Chapter 6 物理プランの生成
物理プランの最適化方式
有名なものは2種類ある。
ルールベース方式
事前に優先順位のルールを用意して、選択する。
テーブルの容量等が考慮されていないため、データの増減などの環境変化に対応できない。
コストベース方式
各統計情報から、「コスト」と呼ばれる最適化のための指標を算出して、最小なプランを選択する。
コストベース方式の例
第3部 システム化のサポート
Chapter 7 トランザクションの基礎
トランザクションをどのように保証するか
追記型では、古い値と新しい値を保持して、COMMITやROLLBACKの時点でどちらかを無効にする。
そのため、更新時には対象データの容量だけ余分にストレージが必要になる。
同時実行制御~複数のトランザクションが同時に実行される場合~
パフォーマンスを出すには平行して処理する必要がある。
一方でトランザクションが干渉しあうと、次のような問題が発生するので制御する必要がある。
- 更新の消失
- ダーティーリード
- 非再現リード
Chapter 8 トランザクション制御とMVCC
インデックスなどの内部ロック
Bツリーの場合はルートノードからリーフノードを探索するため、二相ロックに従うと一連のノードをロックしなければならない。
そのため、ツリープロトコルで実装されることが多い。
- あるノードのロックを獲得
- ロックを獲得しているノードの子ノードのロックだけ獲得できる
- 個別のノードのロックはいつでも解放できる(ほかのトランザクションがロックできるようになる)
- いったんロックを解放したら、このノードのロックは獲得できない
タイムスタンプを使った同時実行制御
ロック以外の方法の一つとしては、タイムスタンプをそれぞれのトランザクションに発行して、その順番を使って強制的に実行を制御することができる。
タイムスタンプの順番に従ってない場合はabortする。abortが連鎖することもあり、あまりよろしくない。
マルチバージョン同時実行制御
マルチバージョン同時実行制御(MVCC)は、タイムスタンプをベースとしている。
タイムスタンプでは、結果が正しくても実行順序に問題があると強制的にアボートされてよろしくない。
この問題に対して、古いデータを保持しておいて、トランザクションの一貫性を担保する。
データの書き込み中にも、古いデータを返すことで並列で処理を行える。
Chapter 9 ログ機能によるパフォーマンスの向上
データ更新処理の仕組み
ログファイルに書き込んだらcommitされる。
この時点では、データファイルにはまだ保存されていない。
ログ機能の構成と役割
パフォーマンス改善と、バックアップの2つの側面がある。
性能上の課題
ログの書き込みは、シーケンシャルなので、都度データファイルに書き込むよりもパフォーマンスがよい。
ディスクへの書き出しの性格の違い
バイナリログと実データのディスクを分離すると、ディスクヘッドのオーバヘッドが減り、パフォーマンス改善につながる。
複数のトランザクションを1度に書き込める可能性がある。
Chapter 10 ログによる障害からの復旧
データファイルへの書き込み記録であるチェックポイントをもとに、復旧時にREDOなどを行う
第4部 複数データベースをまとめる
Chapter 11 クラスタリングによる性能向上
Chapter 12 データベースのパーティショニング
パーティションを行うことで、各ノードでの全データアクセスのデータ量が減るので、パフォーマンスが上がる。
一方で、どのようにパーティションを行うか、どのレイヤーで制御するかなどの複雑性が上がるので、キャパシティプランニングが非常に重要。
また、パーティション間のデータを結合する際には余計にコストがかかる場合もあるので、設計も重要。
次のアクション
RDBMS解剖学 よくわかるリレーショナルデータベースの仕組み (DB Magazine Selection)
- 作者: 鈴木幸市,藤塚勤也
- 出版社/メーカー: 翔泳社
- 発売日: 2005/02/22
- メディア: 単行本(ソフトカバー)
- 購入: 11人 クリック: 88回
- この商品を含むブログ (26件) を見る