失敗から学ぶRDBの正しい歩き方

DB

2020-04-04 22:26:52

失敗から学ぶRDBの正しい歩き方

  • 第1章 データベースの迷宮
  • 第2章 失われた事実
  • 第3章 やり過ぎたJOIN
  • 第4章 効かないINDEX
  • 第5章 フラグの闇
  • 第6章 ソートの依存
  • 第7章 隠された状態
  • 第8章 JSONの甘い罠
  • 第9章 強過ぎる制約
  • 第10章 転んだ後のバックアップ
  • 第11章 見られないエラーログ
  • 第12章 監視されないデータベース
  • 第13章 知らないロック
  • 第14章 ロックの功罪
  • 第15章 簡単過ぎる不整合
  • 第16章 キャッシュ中毒
  • 第17章 複雑なクエリ
  • 第18章 ノーチェンジ・コンフィグ
  • 第19章 塩漬けのバージョン
  • 第20章 フレームワーク依存症

第1章 データベースの迷宮

  • N/A

第2章 失われた事実

  • N/A

第3章 やり過ぎたJOIN

p.32

  • JOINのアルゴリズムの種類
    • Nested Loop Join(NLJ)
      • 内部表の結合キーの列に利用できるINDEXがあると、ループ数を省略できるため、外部表が小さいほど高速
      • 内部表の結合キーが一意のときは内部表対象レコードを絞り込むことができるため、より高速
      • 1レコードずつ確定するため、確定したレコードはレスポンスとして返すことができる
    • Hash Join
      • 外部表が大きいまたは内部表の対象件数が多いとき、結合条件のお索引がなく、テーブルフルスキャンが必要なときはNLJより有利
      • Hash表を作成さえすれば結合は非常に高速である一方、Hash表の作成と保存ができるだけの十分なメモリが必要
    • Sort Merge Join
      • ソートに用いる索引が作成されていると高速化できる
      • Hash Joinと同様に表の大部分を結合する場合に有効
      • Hash Joinと異なり、等値結合だけではなく不等式を使った結合にも利用できる
      • INDEXが活用できる場合は、Hash Joinより速い場合もある

p.38

  • 多すぎるJOIN
    • JOINは必要最低限
    • INDEXは適切に活用
    • Joinするテーブルは小さくしてからJoinする
    • 複雑すぎる場合はviewに逃げる

第4章 効かないINDEX

p.45

  • 設定したINDEXが効かない(使われない)ケース
    • 検索結果が多い、全体の件数が少ない
      • INDEX利用条件
        • 検索結果がテーブル全体の20%未満
        • 検索対象のテーブルが十分に大きい
    • 条件にその列を使っていない
    • カーディナリティの低い列に対する検索
      • カーディナリティ
        • 列に格納されるデータの値にどのくらいの種類があるか
    • あいまいな検索
      • LIKE検索は前方一致のみINDEX利用可能
    • 統計情報と実際のテーブルで乖離がある場合

第5章 フラグの闇

  • N/A

第6章 ソートの依存

  • N/A

第7章 隠された状態

  • N/A

第8章 JSONの甘い罠

p.109

  • なんでもJSONの危険性
    • ORMが使えない
      • JSONデータ型をサポートしているケースは少ない
    • データの整合性が保てない
      • 必須属性の指定が難しい
      • データの中身を指定できない
      • 参照整合性制約を強制できない

p.115

  • JSONデータ型の採用を検討するときの注意点(該当する場合は採用を避けたい)
    • 正規化することはできないか
    • JSONに対して頻繁に更新を行いたいか
    • 検索条件としてJOIN内の属性が固定できない場合

第9章 強過ぎる制約

  • N/A

第10章 転んだ後のバックアップ

p.132

  • 3つのバックアップ
    • 論理バックアップ
      • SQLやCSVとして、DBそのものを再構成できるように取得。実体はテキスト。
      • 手軽に取得できるが、ファイルサイズが大きくなりやすく、バックアップとリストアともに時間が長くなりがち
    • 物理バックアップ
      • データベースの物理ファイルをまるごと取得
      • 最小限のサイズで取得でき、バックアップとリストアともに時間が短く済むが、論理バックアップと違い移植性が低いことが多い
    • PITR
      • 特定の日時の状態にデータをリストアできる形で取得
      • ログとバックアップファイル両方が必要なため、バックアップのサイズは大きくなりがち。論理バックアップや物理バックアップと比べてリストアが難しい。

p.135

  • 3つのバックアップにおける3つの指針
    • RPO
      • いつ時点のデータを復旧するか(目標復旧時点)
    • RTO
      • どれくらいの時間で復旧できる(目標復旧時間)
    • RLO
      • どこまで復旧するか(目標復旧レベル)

p.136

  • 稼働率とバックアップ設計の指標
    • 稼働率90%(年間停止時間36.5日)
      • バックアップとリストアで十分
    • 99%(3.65日)
      • オンプレミス環境なら予備マシンが必要
      • 大規模データならリストア所要時間を把握しておく必要がある
    • 99.9%(8.7時間)
      • 法定停電への対応や24時間365日サポートなど、システム外の仕組み作りも必要
    • 99.99%(52分)
      • バックアップからのリストアだけでは難しい
      • コールドスタンバイなどが必要
    • 99.999%(5分)
      • 遅延レプリケーションなどの専用システムが必要
    • 99.9999%(32秒)
      • 無停止サーバーなどが必要になってくる
      • コストが非常に高くなる

第11章 見られないエラーログ

  • N/A

第12章 監視されないデータベース

  • N/A

第13章 知らないロック

  • N/A

第14章 ロックの功罪

  • N/A

第15章 簡単過ぎる不整合

  • N/A

    第16章 キャッシュ中毒

    p.214

  • キャッシュの種類
    • クエリキャッシュ
      • RDBS側で前回のSQL実行結果を保存
    • アプリケーションキャッシュ
      • サーバーサイドキャッシュともいう
    • その他のキャッシュ
      • CDN、HTTPアクセラレータ「Varnish」を利用したHTTPレイヤのキャッシュ、ブラウザやローカルストレージを利用したキャッシュなどがある

第17章 複雑なクエリ

p.233

  • SQLの構文評価順序
    • FROM,ON,JOIN,WHERE,GROUP BY,HAVING,SELECT,DISTING,ORDER BY,LIMIT

第18章 ノーチェンジ・コンフィグ

  • N/A

第19章 塩漬けのバージョン

  • N/A

第20章 フレームワーク依存症

  • N/A

About the author

Image

bmf san @bmf_san
A web developer in Japan.