MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ | mond
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ
PostgreSQLのメモリ管理 | Everyday Deadlock
この記事は PostgreSQL Advent Calendar 2012 の13日目の記事です。 昔からデータベースエンジン関係の研究をしているうちの研究室 では、「PostgreSQLを使う」というとPostgreSQLのコードをいじってTPCベンチマークを走らせることを指すので、未だにSQLとか書けなくて困ることが多いのですが、幸か不幸かPostgreSQLのソースコードはそこそこ読めるようになりました。 そんなわけで、PostgreSQLのソースコードの中でも、今回のAdvent Calendarのネタとしてメモリ管理の部分について紹介します。 これからPostgreSQLのコードを読んでみたいという人にとっては、コードのどの部分を読んでも必要となる知識なので、割と役に立つとおもいます。 【宣伝】大晦日にデータベースの同人誌をコミケで売ります 本題に入る前にいきなり宣伝で恐縮ですが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
