【データベース】メモリの種類（「データキャッシュ」と「ログバッファ」など）

ほとんどの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