ほとんどのDBが以下3つを持っています。
- データキャッシュ
- ログキャッシュ
- ワーキングメモリ
共通の特徴
- ユーザーが用途に応じてサイズを変更することができる。
データキャッシュ
SELECT系(検索系)に関係します。ディスクにあるデータを一時的にキャッシュする領域です。運よくこれからSELECTするデータがこのメモリに載っていたら高速なレスポンスが可能です。
Oracle11 | PostgreSQL9.3 | MySQL5.7 | |
---|---|---|---|
名称 | データベースバッファキャッシュ | 共有バッファ | バッファプール |
パラメータ | DB_CACHE_SIZE | shared_buffers | innodb_buffer_pool_size |
初期値 | 4MB * CPU数 * グラニュルサイズ | 128MB | 128MB |
確認コマンド | SELECT value FROM v$parameter WHERE name='db_cache_size'; | show shared_buffers; | SHOW VALIABLES LIKE 'innodb_buffer_pool_size' |
備考 | SGA内部に保持される。 | - | - |
ログバッファ
更新系(INSERT、DELETE、UPDATE、MERGE)に関係します。DBMSは更新系のSQLを受け取った時は即座にディスクを書き換えているのではなく、一旦ここに蓄積した上でまとめて書き込んでいます。(なので、SQL文の実行と、ストレージへの更新タイミングにズレが発生する非同期処理になります。)
なぜわざわざこんな仕組みなの?
こんなことをしていては非同期になってしまいますし、データ整合性を担保取れなくなるような気がします。
理由としてはディスク書き込みよりメモリ書き込みの方が高速に終わるのでユーザーを待たせなくても良くなるためです。
Oracle11 | PostgreSQL9.3 | MySQL5.7 | |
---|---|---|---|
名称 | REDOログバッファ | トランザクションログバッファ | ログバッファ |
パラメータ | LOG_BUFFER | wal_buffers | innodb_log_buffer_size |
初期値 | 512KB または 128KB * CPUカウントのどちらか大きい方 | 64KB | 8MB |
確認コマンド | SELECT value FROM v$parameter WHERE name='log_buffer'; | show wal_buffers; | SHOW VALIABLES LIKE 'innodb_log_buffer_size' |
備考 | SGA内部に保持される。 | - | InnoDBエンジン使用時のみ有効 |
なぜ「データキャッシュ」に比べて、「ログバッファ」のサイズは小さいか?
基本的にデータベースは検索をメインの処理として想定しているミドルウェアのためです。検索系と更新系では想定処理件数にだいぶ差があるので、可能な限り検索系のメモリの容量を増やした方が得策だと考えられているのです。
検索
数百万件や数千万件というオーダーになることも珍しくないです。
更新
1トランザクションあたり、1〜数万件程度です。
ただ例外もある。
ただ、想定しているシステムが例えばバッチ処理がメインだったとしたら更新処理がメインになるので「データキャッシュ」よりも「ログバッファ」のメモリ量を増やすようなチューニングをした方が良いことは言うまでもないです。
ワーキングメモリ
SQLでソートやハッシュが必要になった時に使用される領域です。この領域が不足した場合は多くのDBMSでディスクが使われることになります。(OSでいうところの「スワップ」)
Oracle11 | PostgreSQL9.3 | MySQL5.7 | |
---|---|---|---|
名称 | PGA(Program Global Area) | ワークバッファ | ソートバッファ |
パラメータ | PGA_AGGREGATE_TARGET | work_mem | sort_buffer_size |
初期値 | 10MB または SGAサイズの大きい方のどちらか | 8MB | 256KB |
Javaアプリケーションみたいに「Out of Memory」という選択肢をとることはないです。DBMSの思想としてどんなに遅くても良いので処理を継続させるというものになっているためです。
この記事へのコメントはありません。