喪中のハガキ印刷がうまくいかない

滑ってるのか何なのか分からないけど、上トレイから給紙ができない。印刷するハガキ用紙が厚手(0.28mm)なのがあまり良くない気がするので、官製はがきの標準の厚さ(0.23mm)と同じくらいの薄さのを買ってみよう。Amazonで買おうと思ったら、EP-806Aに対応しているかどうか分からなかったのでやめた。

merge対象が一つだけになる時

最初、A, Bの2つのリストがmerge対象となるが、途中でどちらかのリストの要素が無くなりこれ以上取得できない場合、scan_onlyに移行してmerge対象のリストは1つだけになる。

できれば対象が1つになった時点で別のクラスに移行したい。が、別のクラスに移行するとクライアント側で保持しているActorRefを切り替える必要があって面倒。
取り敢えず対象が1つになった場合の状態を持つようにしてみようかな。

merge

大まかな流れ

  • N < 1でkvlistに対象が残っている場合は、fromがあれば通知してreceive待ち
  • A, Bの各kvlistをkeyを比較しながらwriteしていく
  • 片方のkvlistが残ったらscan_onlyに移行
  • scan_onlyでkvlistに要素が無くなったらterminate

mergeからスタートするとN=0で始まるので、すぐにreceive待ちになると思うんだけど、誰がstepメッセージを投げるか？

handle_cast

https://github.com/krestenkrab/hanoidb/blob/master/src/hanoidb_merger.erl#L202

なんでhanoidb_writer:handle_castを外部モジュールから直接呼び出しているんだろう。
同期的な挙動にしたかったのかな。メッセージングで処理するのが面倒だったのかな。
よく見るとhanodb_mergerはhanoidb_writerのPIDを取得していないので、hanoidb_mergerと同じプロセス内でhanoidb_writerの処理を動かすデザインなのか。

しかし困った。handle_castとかhandle_callはメッセージングで呼ばれる前提にしていて、直接呼び出せるようにしてない…。
元実装と違ってしまうけど、ここは同期メッセージを使うようにするかー。

In-Memory DB

サーバをrebootした時にメモリにロードしなければならないことを考えると、DBを分散化して1ノードあたりのデータ容量を下げるようにしていくべきなのかも。もしくは大きい1ノードを切ってパーティショニングし、パーティション単位で並列にロードするとか。

Early MaterializationとLate Materialization

https://www.cse.iitb.ac.in/~venkateshek/column_vs_row.pdf
Verticaの資料を漁っていたら、Early MaterializationとLate Materializationという言葉が出てきたので調べてみた。タプルの値をいつ実体化するか、ということらしい。上記資料のP.25-26の説明が分かりやすかった。

と思ったんだけど、Verticaの資料に戻ってみたら、より分かりやすい例がP.35-44にあった。
http://www.slideshare.net/SamchuLi/vertica-62970578