以前、ストレージからデータを読み込む処理が遅い為に、あるバッチの実行が完了するまでにかなりの時間を要することがありました。
データの読み込みは処理が進む中で何度も行われるので、最初に必要なデータを全部取ってきてHashMapに詰め、以降はストレージに読みに行かないようにして全体の処理が時間内に収まるようにしたのですが、今度は最初のデータ取得時にOutOfMemoryが出るようになりました。
処理時間は多少長くなっても良いので、HeapではなくDiskにデータを保持するようなMap実装を探したのですが見つからず、自分で書いてみました(結局前記の問題の対応としては使ってませんが)。
github.com/masayuki038/FileStoredMap
Features
- 各Entryをdiskに書くのでheapをほとんど消費しない
- 読み書きが遅い
- java.util.Mapを実装しているので、既存のMapの置き換えが簡単
- SerializableであればPOJOも保存可
- データはBSONフォーマットにシリアライズする
BSON
最初はシリアライズライブラリにMessagePackを使おうと思っていたのですが、シリアライズされたbyte列を、デシリアライズせずに直接読んで解釈できたら面白そうなので、より読みやすそうなBSONを使うことにしました。
Github Project Pages
heapの使い方や読み書きのスピードをOracle Berkeley DBと比較してみたのですが、その結果を載せる場所を探していたところ、Github Pagesとしてプロジェクトのページを作成することができるということなので、作ってみました。
masayuki038.github.com/FileStoredMap/
最初はjekllyで作ろうと考えたのですが、どうもGithubにアップした際に_config.ymlにて指定したBASE_PATHがうまく反映されず、解決の目処が立たなかったので、今回はGithubのサイトから利用できる「Automating GitHub Page Generator」を使いました。この機能の使い方は以下のページを参考にしました。
GitHub Pagesホスティングサービス（ほぼ）完全活用ガイド
もともとこのプロジェクトページを作りたくてGithub Pagesを見始めたのですが、関連記事を読んでいく中でOctopressを初めてしまい、rvm、bunldeを入れたりして、とんだyak shavingでした。
Bench
計測の仕方は適当なので、ベンチ結果は参考程度で。特にBDBのreadが重いところは気になっていて、時間を作って確認するつもりでいます。