ここ一ヶ月くらい以前の[[HeteroTSDB]]論文を全面的に書き直している。 実装も前職にしかないので、実験のやり直しのために、OSSで[[Xtsdb]][Xtsdb](https://github.com/yuuki/xtsdb)というソフトウェアを書きはじめた。しがらなみがないこともあって、前職で開発したときとは実装を大きく変えている。以下は今日の変更内容。 - [[Redis]]に書き込む処理をworkerプール(MemWriter)に委譲とし、MemWriterの各goruitineはbufferd channelにエンキューされるタスクを実行するようにした。4台構成で366516.538701 datapoints/sec になり速くなった。MemWriterの個数が5000とかにするとスループットはでるけど、xtsdb-ingesterがメモリを50%ぐらい食うのがよくない。ingesterのメモリ保存効率を見直す。 - 系列を保存するのにRedis Streamを暫定的に使っていたが、Redisのバリューとなる文字列を単純なbytes arrayに見立ててAPPENDで追記をしていく方式に変更した。メモリ使用量が大きいかつ系列内で最後に書いたタイムスタップよりも古いタイムスタンプの値を書き込めない制約があるためだ。メモリ使用量はだいたい2/3ぐらいになった。 - Redisから[[Cassandra]]へのクエリ発行時にタイムアウトするのでリトライをいれたり、タイムアウト値を見直したりした。 肝心の論文のストーリーがまだ固まっていない。既存の[[KairosDB]]や[[OpenTSDB]]との差異をどこに置くか。Xtsdbは性能では勝っているが単にRedisの実装が速いから速いですというだけだと、提案手法の良さにならない。少なくとも原理的になぜメモリベースKVSが速くなり得るのか、原理を踏まえて提案手法ではどう原理をいかせているのかを考えないといけない。 RedisのようなメモリベースのKVSが、CassandraやHBaseのようなディスクベースのKVSに対して、単にメモリだから速いのかという話をしがちだった。LSMツリーベースのKVSであれば、メモリ上のmemtableとディスク上のSSTableは別のデータ構造であり、書き込みパスはディスク上のログ書き込みとmemtableへの書き込みだけなので、Redisとかわらない。 ふと、[[S3 A Scalable In memory Skip List Index for Key Value Store]] の論文を読むと、memtableのインデックス構造として利用されている[[Skip Lists]]について、メモリ上ではより優れた性能をもつインデックス構造が提案されている。にもかかわらず、SSTableへのフラッシュ時の効率が悪く、ディスクベースKVS向きではないという話が書かれている。そこを改善した提案手法が、実験結果ではメモリ上での挿入効率が高いことも示されている。 メモリベースKVSが高速なのは、メモリ最適化されたインデックス構造を利用しやすいからという方向性でよさそうだ。ただフラッシュ時の効率がなぜよくなっているのかを言わないといけない。 フラッシュ時の移動効率を確認したいのだけど、Xtsdbの実験ではデータをCassandraへコピーできていはいてもRedis上のコピー元のデータをなぜか消しきれていない...