スライド 1

Size: px

Start display at page:

Download "スライド 1"

せとかそや
5 years ago
Views:

1 pgpool-ii によるオンメモリクエリキャッシュの実装 SRA OSS, Inc. 日本支社

2 pgpool-ii とは PostgreSQL 専用のミドルウェア OSS プロジェクト (BSD ライセンス ) proxy のようにアプリケーションと PostgreSQL の間に入って様々な機能を提供コネクションプーリング負荷分散自動フェイルオーバーレプリケーションクエリキャッシュ

3 導入事例 :JTB が発行する JTB 旅カードの Web サイトカード会員が利用するポータルサイトとポイント管理を行うバックヤード機能から構成従来クレジットカード会社で行っていたポイント管理を JTB に移管することで顧客のニーズを反映した情報提供を行う CRM の役割を果たす

4 今作っているものオンメモリクエリキャッシュ複数 pgpool-ii の連携機能外部プログラムに依存しない pgpool-ii 組み込みの HA 機能オンラインリカバリなどの制御

5 Web 環境におけるレイヤー別負荷の違い DB サーバ AP サーバ後ろのレイヤーほど負荷が高くボトルネックになりやすい

6 キャッシュを活用して負荷を軽減 DB サーバ AP サーバ AP サーバで結果をキャッシュして返す DB サーバで結果をキャッシュして返す

7 キャッシュの実装例 (1) アプリケーションサーバ /httpdサーバレベルでのキャッシュ実装 APC(Alternative PHP cache) PHPが動いているサーバ上の共有メモリにキャッシュを作る Apache2のコンテントキャッシュ mod_cache, mod_file_cache RailsやHibernateなどのORマッパーでのキャッシュ Squid や Varnish などのリバースプロキシを使う memcached などの KVS(Key Value Store) を使ったキャッシュ API やフレームワーク固有の方法でのキャッシュなのでそれぞれ使い方や特性が違う使用するフレームワークが変わると実装し直し

8 DBMS でのキャッシュキャッシュの実装例 (2) MySQL の実装が有名 DB2 にもある? DBMS へのアクセスがなくなるわけではないので DBMS がボトルネックになることもある MySQL のクエリキャッシュオンメモリキャッシュクエリ文字列が一致したらキャッシュヒット Prepared query には対応していないテーブルが更新されたら該当キャッシュは全クリアされる MySQL を再起動したらキャッシュの内容はなくなる

9 AP サーバのキャッシュと DB サーバのキャッシュの比較 AP サーバでキャッシュ DB サーバでキャッシュキャッシュの効果 DBサーバへの負荷アプリケーション透過性スケーラビリティ

10 実は pgpool-ii にもすでにクエリキャッシュがありますしかしいろいろ問題が... キャッシュストレージが DB なので遅い DB を更新しても自動ではキャッシュが更新されない拡張問い合わせに対応していないそこで新しく実装しなおすことにしました Google Summer of Code としてプロトタイプを実装現在バグ取り未実装部分の実装を行っています

11 pgpool-ii オンメモリクエリキャッシュの主な機能キャッシュストレージとして共有メモリか memcached を選択できるセッションユーザをまたがってキャッシュが再利用できる memcached を使う場合は pgpool-ii PostgreSQL を再起動した後にキャッシュを再利用することも可能テーブル別にキャッシュするしないを指定できるキャッシュの更新は自動的に行われる更新問い合わせが来たらキャッシュをクリア一定時間が過ぎたキャッシュを自動クリアすることも可能拡張問い合わせでもキャッシュが使える ( 実装中 )

12 pgpool-ii オンメモリクエリキャッシュの利用イメージ pgpool-ii DB サーバ AP サーバ pgpool-ii で結果をキャッシュして返す

13 AP サーバ DB サーバ pgpool-ii のキャッシュ機能の比較 AP サーバでキャッシュ DB サーバでキャッシュ pgpool-ii でキャッシュキャッシュの効果 DB サーバへの負荷アプリケーション透過性スケーラビリティ

14 pgpool-ii オンメモリクエリキャッシュの仕組み SELECT 共有メモリ OR memcached キャッシュにあるか? NO SQL パーサ YES キャッシュストレージ振り分けエンジンコミット時に SELECT 結果をキャッシュ PostgreSQL DB

15 キャッシュサーバのスケールアウト memcached サーバのキャッシュを共有できる DB サーバ AP サーバ pgpool-ii

16 工夫した点キャッシュのヒットの定義クエリ文字列 + データベース名 + テーブル名 + ユーザ名を MD5 ハッシュしたものをキーにして一致を判断しハッシュ値が一致したらキャッシュがヒットしたものと見なす直接 SQL 文を比較しないのは長大なSQL 文を保存する必要性を避けるためユーザ名がキーに含まれているのは参照権限がないテーブルのデータをキャッシュを経由して他のユーザが参照できないようにするため一方で参照しても良いキャッシュを参照できないデメリットがある MD5 ハッシュで管理してキーが衝突する心配はないのか? 管理するキーの数を 2^32( 約 42 億 ) とする 1 マイクロ秒 (1/1,000,000 秒 ) に 1 回キャッシュを登録しても衝突するまでの平均時間は太陽の寿命より長い ( たぶん ) 2^(128-32)/(1000*1000*60*60*24*365) = 2,512,308,552,583,217 年 = 2,512 兆年 = 2.5 京年

17 キャッシュ対象とならない SELECT Immutable でない関数への呼び出しを含む SELECT SELECT CURRENT_TIMESTAMP; SELECT INTO, SELECT FOR UPDATE, SELECT FOR SHARE SELECT の結果データが大きいもの (> memqcache_maxcache) 巨大なデータでキャッシュが使い尽くされてしまうのを防ぐため成功しなかった SELECT ロールバックされたトランザクション内の SELECT 結果 BEGIN; INSERT INTO t1 VALUES(1); SELECT * FROM t1; ROLLBACK; もし SELECT * FROM t1 の結果をキャッシュしてしまうと次の SELECT * FROM t1 で存在しないはずの 1 が返ってしまう一時テーブルを含んでいる SELECT セッションが終了するとテーブルが消えてしまうため Unlogged テーブルを含んでいる SELECT PostgreSQL クラッシュ後の再起動でデータが消えてしまうため

18 キャッシュ更新 / 無効化ポリシー (Invalidation) キャッシュ対象のテーブルが一部でも更新されたらそのテーブルを参照しているキャッシュをすべて自動的に削除する更新クエリ :INSERT/UPDATE/DELETE/TRUNCATE/COPY FROM そのためにキャッシュを登録する際に参照しているテーブルのOIDを調べファイルに登録しておく更新クエリが実行されたらそのファイルを調べて関連するキャッシュを削除するデータベースやテーブルが削除された場合も同様テーブル構造が変わるようなコマンド (ALTER TABLE) が実行された場合も同様更新が多い DB には向かない有効時間を過ぎたキャッシュは無効になる ( 無効にしない設定も可能 ) 手動でキャッシュを削除可能 ( 計画中 ) キャッシュストレージが memcached の場合はちょっと悩ましい pgpool-ii や PostgreSQL が再起動しても memcached が動いていれば前回のキャッシュを有効に使える?

19 制限事項 VIEW もキャッシュされるが VIEW が参照しているテーブルが更新されてもキャッシュは有効スキーマが異なっていても DB 名テーブル名が同じならば同じテーブルと見なされるトリガによって暗黙的に更新されるテーブルが認識できない外部キーが指定されていて ON DELETE CASCADE などで他のテーブルの行が暗黙的に更新されたことが認識できない DROP TABLE CASCADE で暗黙的に削除されたテーブルが認識できない TRUCATE TABLE CASCADE で暗黙的に内容が削除されたテーブルが認識できない

20 オンメモリクエリキャッシュの設定項目 memory_cache_enabled = false メモリキャッシュの有効 / 無効 memqcache_method = 'shmem' キャッシュストレージの選択 shmem( 共有メモリ ) or memcachedが選択可能 memcachedを選択した場合の設定項目 memqcache_memcached_host = 'localhost' memqcache_memcached_port=11211 memqcache_total_size= トータルキャッシュサイズ memqcache_expire=60 キャッシュの有効時間 memqcache_maxcache=1024 格納できる最大のSELECT 結果サイズ memqcache_cache_block_size= キャッシュブロックのサイズ ( 共有メモリのときのみ ) memqcache_oiddir = '/var/log/pgpool/oiddir' テーブルOIDを格納する領域

21 ベンチマーク! SELECT count(*) という PostgreSQL では全スキャンになる遅いクエリを約 100% のキャッシュヒット率でアクセスしたケース ( ベストケース ) SSDを使いしかもテーブルがキャッシュに乗った状態なので実環境ではもっと差が開く可能性があるハードウェアノート PC(dual core i5-2540m 2.60GHz Hyper threading 有効メモリ 8GB SSD(Intel 320 MLC) ソフトウェア pgpool-ii, PostgreSQL, memcached を同じマシンで動かしている PostgreSQL 9.1 shared_buffers = 32MB pgbench SQL: SELECT count(*) FROM pgbench_accounts; 1000 回実行 10 万件テーブルサイズ 13MB I/O ネックにならない

22 ベンチマーク結果 50,000 45,000 40,000 トランザクション / 秒 35,000 30,000 25,000 20,000 15, 倍の性能向上 10, 倍の性能向上 5,000 0 PostgreSQL 9.1 memcached shmem

23 まとめ各レイヤにおけるキャッシュソリューションを比較アプリケーションサーバでのキャッシュは効果が高いがアプリケーションの改造が必要になることが多い DBMS でのキャッシュはアプリケーションの改造が要らないメリットがあるまた DBMS の負担を軽減する更新の多い用途には向かないスケールアウトができない pgpool-ii のオンメモリキャッシュはアプリケーションの改造が不要 DBMS の負担を軽減しさらにスケールアウトすることができるただし更新の多い用途には向かない pgpool-ii のようなミドルウェアにおけるキャッシュは用途によって大きなメリットがある

24 今後の開発予定拡張問い合わせへの対応テーブル別に自動キャッシュバリデーションをするしないを指定できる 2012 年 5 月位にリリース予定

25 参考 URL pgpool-ii のホスティングサイト旧サイト pgfoundry から引っ越したので注意! tar ball のダウンロードができますソースリポジトリは git.postgresql.org でからリンクされています日本語と英語のメーリングリストがあります

Web 環境におけるレイヤー別負荷の 2 違い DB サーバ AP サーバ後ろのレイヤーほど負荷が高くボトルネックになりやすい

pgpool-ii 最新情報開発中のメモリキャッシュ機能について SRA OSS, Inc. 日本支社石井達夫 Web 環境におけるレイヤー別負荷の 2 違い DB サーバ AP サーバ後ろのレイヤーほど負荷が高くボトルネックになりやすい 3 キャッシュを活用して負荷を軽減 AP サーバ DB サーバ AP サーバで結果をキャッシュして返す DB サーバで結果をキャッシュして返す 4 キャッシュの実装例