勉強日記

チラ裏

理論から学ぶデータベース実践入門 ch12 Webアプリケーションのためのデータ構造 (1/2)

RDB 勉強メモ

gihyo.jp

まとめ

  • 性能を得るためにリレーショナルモデルから逸脱せざるをえない場合の対処法
  • キャッシュは実装に関わるデータ構造
    • 物理的な限界を打ち破るためのもの
      • 他には「金を積む」という方法もある
    • 論理データとは別に構造化されたデータを付け足す
      • 節度をもってデータモデルを維持しつつ、物理的な限界に立ち向かう
    • インデックスと通じる部分がある
      • RDBで利用可能なインデックスよりも複雑なデータ構造が必要なら役に立つ

キャッシュという考え方

  • コンピュータシステムにはさまざまなキャッシュがある

メリット/デメリット

  • メリット
    • コストの高い処理の回避
  • デメリット
    • 複雑性の増大
      • システムの開発・保守コスト増大

DBアプリケーションにおけるキャッシュ

  • 複雑さの増大と引き換えに、コストの高い処理をコストの低い処理でできるだけ代替
  • データに局所性があると効果大
    • 時間
    • 空間
  • データの構造を工夫することで処理の効率向上

キャッシュはあくまでもキャッシュ

  • 消えてもかまわない
  • 原本となる論理データとは明確に区別せよ

キャッシュとして使うための要件

  • 下記が明確であること
    • キャッシュへの問い合わせがキャッシュミスしたときの対処法
    • キャッシュミスしたときにDBへ問い合わせる方法
    • キャッシュミスしたときに新たにキャッシュへエントリを追加する方法
    • データが更新されたときにキャッシュと同期する方法
    • データがすべて消失したときに1回再構築する方法
    • キャッシュの整合性を確認する方法
  • 同期方法
    • トリガーで即時
    • バッチで定期
  • タイムラグをどれだけ許容できるか等勘案して決める

キャッシュすべきデータの種別

キャッシュすべきでない

  • トランザクション中に参照するデータ
    • 参照と更新が完全に同期していなければならない

キャッシュ可能

  • きわめて頻繁にアクセスする
  • アクセスに偏りがある
  • 長期にわたり変更される予定がない
  • 表示することが目的

キャッシュの実装方法

NoSQLをキャッシュとして使う

  • 下記のような性能特性のものを使う
    • オーバヘッドが少なくアクセスが極めて速い
      • e.g. KVS
    • RDBが苦手とする種類の検索が可能
    • 多数のサーバマシンを用いて分散処理ができる
  • MySQL + memcachedとか
  • 【補】AWS RDS + ElastiCacheとか

論理データはRDBで管理する

  • 異常の発生を抑えられる
  • 複数のDB製品を使用するため、複雑さは増大する

コラム: NoSQLでRDBは置き換えらるか？

  • No
  • よく言われる「スキーマレスであること」は良し悪し
    • 扱いやすい
    • データの重複や矛盾の問題からは逃れられない
      • むしろ守るすべがない
  • 相補的
    • RDBの不得意がNoSQLには得意
    • RDBの得意がNoSQLには不得意

テーブルをキャッシュとして使う

  • 何らかの加工を施してから別のテーブルに格納
    • 非正規化とか
  • 論理データと混同しないこと
  • メリデメ
    • 単一のDB製品だけで完結
    • 1つのDBサーバで管理すべきデータサイズが増えてしまう
    • 更新時オーバヘッド
  • 使いどころ
    • 更新よりも参照のほうが圧倒的に多い

集計テーブル

  • 「テーブルをキャッシュとして使う」例で代表的なもの
  • 非常に高コストな集約関数をキャッシュ
  • ランキングとか
    • 高コスト
    • わりに頻出要件
  • 論理データの更新にどう追従する
    • マテリアライズドビュー機能に委ねる
      • クエリ実行結果をキャッシュするビュー
      • DB製品がサポートしていればぜひ
    • トリガーで即時更新
    • バッチで定期更新

結合済みのデータ

  • データ件数が多い場合、1度のJOINも許容できないことがある
  • 結合済データのテーブルを作っておく
    • 論理データよりも大きくなるが「キャッシュ」であることに変わりはない
  • 論理データの更新にどう追従する
    • 更新・削除
      • FKのカスケード
    • 挿入
      • INSERTのトリガー
  • メリット
    • ディスクI/O削減
    • ソートとの相性が良い
    • NewSQLとの相性が良い

ディスクI/O削減

  • 結合解決時、それぞれのテーブルへのアクセスが生じる
    • バッファプールに一切キャッシュされていなければ、都度ディスクI/O生じる
  • 結合済ならばデータは1箇所
    • キャッシュミス時のI/O減る
      • ただしバッファプールのキャッシュヒット率自体が低下してしまう可能性がある
        • 大きなキャッシュデータを用いるため

ソートとの相性が良い

  • 2つのテーブルを結合してからソートする場合、実行計画によってはファイルソートになってしまうことがある
  • 結合済データに対してインデックスを作成しておけば、インデックスでソート解決できる

NewSQLとの相性が良い

  • NewSQL
    • RDBに対してKVSのためのインタフェースを提供するハイブリッド型製品
  • KVSでは等価比較によるデータ取得のみが可能
  • 結合済テーブルならNewSQLという選択肢が増える