EBt の DB はこんな感じの複雑さです

EBt は実は結構な規模のデータを扱います。

データが少ないとあんまり気になりませんが、大量のデータを扱う場合、ちゃんとしたデータベースが必要になります。というか、DB無しで管理できるデータのサイズにはおのずと限界があります。
というわけで、EBt は結構な規模のデータベースが背後で動いています。
一応、世の中色々なDBがあります。それを使うという選択肢も検討しましたが、EBt に組み込む必要があるし、そもそもRDBは EBt のデータにいまいち馴染まない。
というわけで、色々考えた結果、あきらめて自分で DB を作ることにしました。はい、自分で DB 作りましたよ。もちろん、RDB で世の中に出ているものほど多機能ではありませんが、EBt 用として必要十分な DB です。

なんで RDB 使わないの？

うん、一番の問題は ID なんですよ。世の中にある DB の ID がいまいち用途に合わなくってね。
他にも、DB はオブジェクト指向のDBでないと困るし、不定長のデータを扱えないと困る。他にも色々あって、ね。
というわけで、腹をくくって DB 作りましたよ、ええ。

どんなDB?

まぁ、不定長のオブジェクトが保存できるDBですね。んで、それをツリーの形で管理するみたいなもんです。2分木ではなく n 分木だったりするし、色々と複雑な構造です。
で、ツリー構造なので、偏りが起きたりするので、定期的にメンテナンスする必要があります。そのための機能がありますが、常時動かす必要もないので手動で動かすようになっています。
一応、安定稼働はしています。不安があるだろうとは思いますが…

IDも変な奴です

IDも変な実装にしていて、int だけじゃなくって適当な uniq 値だったりとか、文字列とか、そんなもんで ID 作れます。
なにせ、相互に通信できない環境でユニークなIDを生成する必要があるので。完璧は無理ですが、一応まずそんな事は起きない作りになっています。
更に、ID と ID を組み合わせて別の ID 作ったりとか、ほんとにおまえ ID か? って奴です。こんな ID は変人が作るようなもんです。
なんというか、そういうIDでないとどーにもデータ管理が複雑で。まぁ、変な要求があるからこそ自前でDBを作らないといけないわけです。

まぁ、というわけで。

実は EBt って内部的には色々複雑なのです。
好きで作っているので自業自得なのですが、正直このDBはしんどかった。
一応、DBの動作に関連するパラメタはいくつかあるので、今後気になったらその辺のパラメタをいじることになります。
また、データのブロックをメモリ上に展開する処理がちょいと重いので、その辺が気にならないようにちょっとずつ非同期処理を入れていますが、まだまだやることは多いですね。

次回は

うん、ちょっとネタが尽きた。
日曜日だから、趣味のネタでも書くかな？