[c]LevelDB C (1)

いままでLMDBを使っていたが、違うタイプのDBも検討したい。
候補として出てきたのは、以前も調べたLevelDB。
C++で書かれているが、Cのインターフェースもあるので、そちらを見ていこう。

---

なぜ検討しようかと思ったかというと、LMDBの特徴のいくつかが、いま作っているアプリと噛み合わなくなってきたからだ。

ここのサイトにまとまっていた。
A short guide to LMDB – Kolab Now

"Caveats"の最初に書かれているように、memory mappingされるようになっていて、それがサイズの上限になってしまうのだ。
そんなに大きいデータを扱うつもりがなかったので気にしていなかったのだけど、だんだん扱うサイズが大きくなってきて、とうとうエラーが発生するようになってしまったのだった。
64bitのLinuxで開発していたら気にならなかったのだけど、Raspberry Pi3に持っていくと1.5GBくらいまでしか指定できなかった。
environmentを複数に分ければ確保できるのかもしれないが、そこまでしてLMDBに合わせなくてもいいんじゃないのか・・・。

DBの内容は削除もしていくのだが、「The database file will never shrink」なので、アクションを起こさないと小さくなってくれない。
mdb_env_copy2()でMDB_CP_COMPACTを実行すれば減りそうだが、それをやるにはcopy2した後のenvに切り替えないといかんだろう。
その時間が致命的かどうかが、ちょっと見積もることができていない。

Transactionの範囲がDBではなく、environment単位というのも手痛かった。
1つのDBだけアクセスしたくても、それを含むenvironmentをロックすることになるのだ。
まあ、だからTransactionは手短にするよう書かれているのだろうがね。

それに関して解決できていないのが、mdb_txn_begin()だ。
複数のスレッドからアクセスすることがあるので、先にmdb_txn_begin()したスレッドが優先され、後から呼んだ方はmdb_txn_commit/abort()されるまでロックされるだろう、という想定でいた。
いたのだが、両方ロックされてしまうことがあったのだ。
mdb_txn_begin()前後にログを出しながらtidを見ていたのだが、2スレッド目がmdb_txn_begin()すると両方のログが止まってしまったから、そう判断している。
なんかAPIの使い方を間違えているような気はするのだけど、よくわかってない。

そんなこんなで、LMDBの問題ではなく特徴が生かせなくなっているので、別のDBも見てみようか、と考えたのだった。

---

もう1つ、LMDB本体とは直接関係ないのだけど、Windows 10の2018年春バージョン以降のWSLでLMDBがうまく動かないというのも後押ししている。
WSLのディスクキャッシュが変わったのが原因だろうということだったので、予想が当たってちょっとうれしいものの、VirtualBoxなどのLinux環境が必須になったのは面倒だ。
1台のWindows10だけ2018年秋バージョンにしてみたが、そっちでも変わらなかった。