回答編集履歴
2
微修正、微加筆
test
CHANGED
|
@@ -4,15 +4,15 @@
|
|
|
4
4
|
|
|
5
5
|
# 1
|
|
6
6
|
|
|
7
|
-
SQLでもNoSQLでも、多くの実装で、更新があるたびに更新データをディスク上のログ領域に書き出し、続いてメモリ上のキャッシュを更新する仕組みがあります。サーバがクラッシュするなどしてキャッシュが失われても、再起動時にログを順番に読み取っていけば、キャッシュの内容をクラッシュ直前の状態に復旧することができます。このように、メモリ上のキャッシュの更新に先立ってディスクに更新データを書き出しておき、クラッシュリカバリに役立てる仕組みを、先行書き込みログ (WAL) などと呼びます (
|
|
7
|
+
SQLでもNoSQLでも、多くの実装で、更新があるたびに更新データをディスク上のログ領域に書き出し、続いてメモリ上のキャッシュを更新する仕組みがあります。サーバがクラッシュするなどしてキャッシュが失われても、再起動時にログを順番に読み取っていけば、キャッシュの内容をクラッシュ直前の状態に復旧することができます。このように、メモリ上のキャッシュの更新に先立ってディスクに更新データを書き出しておき、クラッシュリカバリに役立てる仕組みを、先行書き込みログ (WAL) などと呼びます (呼び方は実装によって違います)。
|
|
8
8
|
|
|
9
|
-
データベース中のインデクスやテーブル (に相当するもの) へのアクセスは、可能な限りメモリ上のキャッシュにアクセスすることで行います。これにより、直近に更新されたデータの参照・更新はメモリアクセスだけで行えます。キャッシュにないデータは、ディスクからメモリに読み込まれます。
|
|
9
|
+
データベース中のインデクスやテーブル (に相当するもの) へのアクセスは、可能な限りメモリ上のキャッシュにアクセスすることで行います。これにより、直近に更新されたデータの参照・更新はメモリアクセスだけで行えます。キャッシュにないデータは、ディスク上のデータベースストアからメモリに読み込まれます。
|
|
10
10
|
|
|
11
11
|
一方、キャッシュサイズは無限に大きくはできませんから、キャッシュが一定のサイズに達したら、累積された更新をディスク上のデータベースストアに書き出します。このとき、書き出された更新の分のWALは削除することができます。
|
|
12
12
|
|
|
13
|
-
以上のことは、SQLでもNoSQLでも同じようなものです。つまり、LSM-treeとWALは関係ありません。たしかに、質問者さんも懸念されている通り、WAL
|
|
13
|
+
以上のことは、SQLでもNoSQLでも同じようなものです。つまり、LSM-treeとWALは関係ありません。たしかに、質問者さんも懸念されている通り、更新の度にWALのためのディスクへの書き込みが発生してしまいますが、クラッシュリカバリを実現するためにはやむを得ないことです。
|
|
14
14
|
|
|
15
|
-
ただ、以上の説明でお
|
|
15
|
+
ただ、以上の説明でお気づきかもしれませんが、WALがなくてもデータベースは動作します。WALの保存を停止することで、クラッシュリカバリを諦める代わりにパフォーマンス向上をめざした運用をする場合はあります。また、WALに相当する機能を最初から持たない実装もあります。
|
|
16
16
|
|
|
17
17
|
# 2
|
|
18
18
|
|
|
@@ -22,9 +22,9 @@
|
|
|
22
22
|
|
|
23
23
|
LSM-treeアルゴリズムは、このようなディスクデバイスの特性に合わせて、なるべくランダムアクセスを減らすようなアルゴリズムとして考案されたもののようです。次のような特徴があります。
|
|
24
24
|
|
|
25
|
-
- 単一のデータベースストアに更新を書き
|
|
25
|
+
- 単一のデータベースストアに更新を書き出すのではなく、小さなストアファイルに分けて書き出す。これにより、書き込みのほとんどは単なるシーケンシャルライトになる。
|
|
26
26
|
- データベースストアからの読み出しは、ほぼストアファイルの数だけのシーケンシャルリードで完了する。
|
|
27
|
-
- ストアファイルが増えてきたら、小さなストアファイルをまとめてより大きなストアファイルにする操作 (コンパクション) を行う。これは[マージソート](https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%82%B8%E3%82%BD%E3%83%BC%E3%83%88)と同様のアルゴリズムで
|
|
27
|
+
- ストアファイルが増えてきたら、小さなストアファイルをまとめてより大きなストアファイルにする操作 (コンパクション) を行う。これは[マージソート](https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%82%B8%E3%82%BD%E3%83%BC%E3%83%88)と同様のアルゴリズムでB木などより高速にできる。
|
|
28
28
|
|
|
29
29
|
詳しくは、次のウィキペディア (英語版) の記事の参考文献などを参照して下さい。LSM-treeやそうでない実装のベンチマーク比較も見つかります。
|
|
30
30
|
|
1
加筆: WALをやめる運用
test
CHANGED
|
@@ -11,6 +11,8 @@
|
|
|
11
11
|
一方、キャッシュサイズは無限に大きくはできませんから、キャッシュが一定のサイズに達したら、累積された更新をディスク上のデータベースストアに書き出します。このとき、書き出された更新の分のWALは削除することができます。
|
|
12
12
|
|
|
13
13
|
以上のことは、SQLでもNoSQLでも同じようなものです。つまり、LSM-treeとWALは関係ありません。たしかに、質問者さんも懸念されている通り、WALを実現するためには更新の度にディスクへの書き込みが発生してしまいますが、クラッシュリカバリを実現するためにはやむを得ないことです。
|
|
14
|
+
|
|
15
|
+
ただ、以上の説明でお分かりと思いますが、WALがなくてもデータベースは動作します。WALの保存を停止することで、クラッシュリカバリを諦める代わりにパフォーマンス向上をめざした運用をする場合はあります。
|
|
14
16
|
|
|
15
17
|
# 2
|
|
16
18
|
|