つまり、これは、Linkedinの腸に実装された、NoSQLデータベースとして知られるキーバリューストレージの非常に興味深い実装です。 つまり、キーと値を指定すると、メモリにすばやく格納/提供され、ディスクに保存されます。 原理的に興味深いのは、これではなく、クラスタリングの実装、優れた速度、Javaのプロジェクトでよく使用されるためです。 原則として、Habréでこのデータベースの詳細なレビューはなく、何かできることがあります。 しかし今のところ、私が直面しなければならなかったレーキについてお話ししたいと思います。
そして、運用中に1つの問題に直面しました。つまり、ヴォルデモートへの大量のトラフィックで、そのベースは恐ろしい力で膨らみ始めました-文字通り1時間あたり数十ギガバイト-開発者はそこにそれほど多くのデータがないことを保証しましたが。 掘らなければならなかった。
「掘り下げ」の結果、次のことが明らかになりました。VoldemortはいわゆるBDB JE- Berkeley DB Java Editionをデフォルトで使用し、このJEは通常のBerkeley DBとはまったく異なることが判明しました。 書き込みのみ-つまり、ジャーナル化されたFSと同じ原理に基づいて-あらゆる操作-記録、更新、削除-データはディスク上のファイルに書き込まれ、それ自体は削除されないことが判明しました。 その後、特別なクリーナープロセスが実行され、古いデータをクリーニングします-データベース内のファイルの一般的な使用率をチェックし、 bdb.cleaner.min未満の場合、使用率（デフォルトでは50％）が各ファイルのチェックを開始し、 bdb.cleaner.min未満の場合。 file.utilization percent（デフォルトでは5％）ファイルが削除され、そこからのデータが新しいファイルに転送されます。
いいね これらのパラメーターをいじる必要があるようですが、50％のリサイクルがあるとは思えません-多くのデータがディスクに保存されています。
確認-
# java -jar /usr/local/voldemort/lib/je-4.0.92.jar DbSpace -h /usr/local/voldemort/data/bdb -u
File Size (KB) % Used
-------- --------- ------
00000000 61439 78
00000001 61439 75
00000002 61439 73
00000003 61439 74
...
000013f6 61415 1
000013fd 61392 2
000013fe 61411 3
00001400 61432 2
00001401 61439 1
...
0000186e 61413 100
0000186f 61376 100
00001870 16875 95
TOTALS 112583251 7
# java -jar /usr/local/voldemort/lib/je-4.0.92.jar DbSpace -h /usr/local/voldemort/data/bdb -u
File Size (KB) % Used
-------- --------- ------
00000000 61439 78
00000001 61439 75
00000002 61439 73
00000003 61439 74
...
000013f6 61415 1
000013fd 61392 2
000013fe 61411 3
00001400 61432 2
00001401 61439 1
...
0000186e 61413 100
0000186f 61376 100
00001870 16875 95
TOTALS 112583251 7
おっと。 動作しません。クリーニングを意味します。 クリーニングのためのスレッド数を増やしようとしています-bdb.cleaner.threads （デフォルトは1）で遊んでいます- 役に立ちません。 Googleの結果、BDB JE専用のフォーラムのスレッドに出くわしました（BDB JEを何らかの方法で使用している場合、非常に便利なフォーラムであることがわかります）。
スレッド（残念ながら、今は見つかりません）は、BDBキャッシュのサイズがクリーニングに大きく影響することを明確に示しています。 つまり、キャッシュが小さい場合、多くのキーではすべてがキャッシュに収まることが望ましいため、クリーニングが開始されないこともあります。そうしないと、クリーニングパフォーマンスが大幅に低下します。 目的のキャッシュサイズは、次のコマンドを使用して推定できます-
# java -jar /usr/local/voldemort/lib/je-4.0.92.jar DbCacheSize -records 1000000 -key 100 -data 300
Inputs: records=1000000 keySize=100 dataSize=300 nodeMax=128 density=80% overhead=10%
Cache Size Btree Size Description
-------------- -------------- -----------
177,752,177 159,976,960 Minimum, internal nodes only
208,665,600 187,799,040 Maximum, internal nodes only
586,641,066 527,976,960 Minimum, internal nodes and leaf nodes
617,554,488 555,799,040 Maximum, internal nodes and leaf nodes
Btree levels: 3
（ keyとdataはキーとデータの平均サイズで、 recordsはレコード数です）。
つまり、データについては、100万件のレコードごとに約200 MBのキャッシュが必要です。100万件を超えるレコードがありました。 :(
合計-適切なキャッシュ（ bdb.cache.size ）を設定すると、データベースの使用率が1日あたりそれぞれ7％から望ましい50％に増加し、データベースのサイズがさまざまに低下しました。
道徳-直接ではなく間接的に使用されている場合でも、使用されている技術を研究します。