出典について
この記事はInfluxDB BlogのPaul Dix氏によるThe new InfluxDB storage engine: a Time Structured Merge Tree(2015/10/7)を翻訳したものです。
1年以上にわたって、我々の時系列データのユースケースに合わせたストレージエンジンを作るかもしれない、とお話ししてきました。本日、新しいストレージエンジンの最初のバージョンが、ナイトリービルドからテスト用に利用できるようになったことをお知らせします。我々は時間構造のマージツリー(Time Structured Merge Tree)、あるいは略してTSMと呼んでいます。
我々のテストでは、0.9.4と比べて最大45倍のディスク容量に対する改善がみられ、10,000,000,000 (100億)のデータポイント(10万以上のシリーズに、5000ポイントずつバッチ書込みを実施)を継続的に秒間30万ポイントを超える速度でEC2のc3.8xlargeインスタンス上に書込みを行いました。新しいエンジンは0.9.4に比べてクエリの性能を犠牲にすることなく、同じデータを最大98%節約して書込みます。
この投稿では、新しいエンジンについて少し説明し、詳細な記事やどのようにテストすれば良いかの手引きのありかをご紹介します。
列指向ストレージと制限のないフィールド
新しいストレージエンジンは、列指向フォーマットです。つまり複数のフィールドを持つことで、クエリパフォーマンスに負の影響を与えないことを意味します。このエンジンでは、メジャメントのフィールド数の制限を取り払いました。例えば、MySQLを計測対象とし、MySQLから収集した2, 3百のメトリックを独立したフィールドとすることができます。
エンジンは更新に対して最適化されていないとはいえ、新しい列指向のフォーマットでは単一フィールドを更新する際に、該当データポイントの他のフィールドを操作することなく更新可能となります。
圧縮
圧縮には、フィールドのデータ型およびタイムスタンプの精度に応じて、複数の圧縮技術を利用します。タイムスタンプの精度はナノ秒のスケールまで表示できるようになったため重要となります。タイムスタンプには差分符号化(デルタエンコーディング)を利用し、スケーリングと圧縮にはsimple8bか、ランレングス方式の符号化が利用され、またデルタが非常に大きい場合は圧縮なし、となります。デルタが小さいタイムスタンプに対しては通常の圧縮がベストです。例えば、ナノ秒のタイムスタンプが10ns(ナノ秒)間隔で分布している場合は、高圧縮率が実現できます。秒の精度のタイムスタンプのデータが10秒間隔で分布する場合にも、同レベルの圧縮となるでしょう。
floatに対してはFacebookのGorillaの論文で述べられているのと同じ差分符号化を利用し、booleanに対してはビットを、integerに対しては差分符号化を、stringに対してはSnappy圧縮を利用します。stringの圧縮には辞書式圧縮を追加することも検討しており、これは繰返しstringがデータがあらわれる場合にとても効果的な方式です。
タグのメタデータを含めたデータの総サイズは、データの形式に応じて、1ポイントあたり最低2バイトとなり、ランダムなデータについては容量が大きくなります。10秒間隔で取得された、シリーズ内の倍精度のfloatのランダムデータは、1ポイントあたり約3バイトとなりました。参考までに、GraphiteのWhisperストレージは1ポイントあたり12バイトです。実世界のデータは、もう少し良い圧縮率となるでしょう。なぜなら、値が繰り返されたり、デルタが小さくなることは良くあることだからです。
LSMツリーとの類似
新しいエンジンはLSMツリーと似ています(LevelDBやCassandraはこれをベースとしています)。先行書込みログを持っており、読取り専用のインデックスファイルがあり、時々コンパクションが行われ、インデックスファイルが結合されます。我々はこれを時間構造のマージツリー(Time Structured Merge Tree)と呼んでいます。インデックスのファイルは隣接する時間のブロックを持っており、コンパクションはこれを大きな時間のブロックにマージするからです。
インデックスファイルがコンパクションされたときに、データの圧縮がさらに行われます。シャードが書込みに対してひとたびコールドになると、圧縮率が最大化されるように出来る限り少ないファイルにコンパクションされるのです。
テストおよび追加の情報
我々は新しいストレージエンジンを早い段階でアナウンスしています。これは設計およびコードをコミュニティーでレビューし、テストしていただきたいからです。これは、現時点ではプロダクション用途ではありません。実際のところ、ナイトリービルドでデフォルトで有効化されていませんし、またナイトリービルドをインストールする度にデータを入れ直せるよう事前に計画しておく必要があるでしょう。新しいストレージエンジンを有効化し、テストを始める方法はこの手順を参照することができます。
我々は、どのようなストレージエンジンを以前に試し、なぜ駄目だったか、また新しい時間構造のマージツリーのエンジンについての全ての詳細を書き上げました。
皆さんにテストしていただき、どうだったかを教えていただきたいと思っています。我々は内部で物理マシン上および、様々なクラウドプロバイダ上で追加のテストをしています。もう少し本格的な用途に利用できるよう準備が出来たと感じたら、ここで再度周知するつもりです。0.9.5のリリースはこの新しいストレージエンジンと共にリリースし、このストレージエンジンに対してホットバックアップも可能にする予定です。0.9.5のリリースは「準備ができたら」となる予定です。つまり、追加のテストが終わり、新しいエンジンのバグを修正し終わった後、ということです。
最後に、新しいストレージエンジンの設計に関するいくつかの基本的な事項をホワイトボードに書いた動画をご紹介します。
※元記事に埋込の動画を参照のこと
