-
Notifications
You must be signed in to change notification settings - Fork 14
FAQ
A: "塊"という意味。内容としては単なるIDとデータの組なので、"オブジェクト"という命名でも良かったのが、"オブジェクトストレージ"という用語は関連する他のライブラリで使用されているためそれとは区別したかった。またCannyLSが扱うIDやデータにはいろいろと制約も多いので、若干一般的ではない単語を使って目立たせたかったという面もあり"lump"という用語が採用された。
A: Overviewに記載されている目標を達成可能そうな既存ライブラリを見つけられなかったため(ベンチマーク結果も参考となる)。
A: CannyLSは「極力無駄や余計な層を排して、性能や予測可能性を追求する」といった設計思想を持っているため、それ自体が(いくつか例外はあるが)極力プリミティブな機能だけに提供するように努めている。そのため、現状のCannyLSのAPIを用いて上位層(利用側)で実現可能な機能に関しては、今後も取り込むことはないものと想定される。
A: CannyLSはインデックス情報を全てメモリに載せる構造になっているため、少しでもキーサイズを節約したかったので固定長とした(参考: In Memory Lump Index、Memory Usage)。例えば64bit環境で単純に可変長キー(e.g., Vec<u8>)を採用した場合には「キーのメモリアドレス」と「キーの長さ」を表現するためだけに128bitが必要となってしまう（それに加えてキー自体の長さ分領域が必要）。ただし 128bit という具体的な長さには「自分達の用途ではそれで十分であった」以外の理由はないため、将来的には、ストレージインスタンス毎に任意のキー幅を選択可能なように拡張するかもしれない。
CannyLSの達成目標の一つに「安定した読み書きレイテンシの提供」といったものがある。仮にサイズに上限を設けなかったとしたら、他例えば1GBのデータを含んだlumpがPUTされると、それを単にディスクに書き出すだけで(典型的には)数秒～十数秒の間、他の操作要求の実行がブロックされてしまうことになる。こういったケースが発生してしまうことを避けたいために、lumpのデータサイズに比較的小さな上限を設けている（CannyLSが内部的に、こういった巨大なデータを分割することも可能ではあるが、そういった処理は必要であれば利用側ででも実施可能ではあるのでサポートしていない）。また、CannyLSでは、保存されている全lumpの格納位置の情報を、全てメモリ上に保持している関係上、各lumpのデータ格納位置を極力コンパクトに表現可能にして消費メモリを節約したかった、というのも理由の一つである（参考: Memory Usage、Data Region Allocator）。
A: いずれ全体的に英語にしたいと思っているので、まずは見出しだけを英語にしている。
A: 開発当初はtokioが存在していなかったのと、その安定版がリリースされる前に、fibersが十分に使えるものになってしまったから、という点が大きい。CannyLSをfibers以外に対応させるのはそこまでは難しくないので、もし需要があればいつか対応するかもしれない。
A: ワークアラウンドとしては、一つのHDD内に複数個のlusfファイルを作成することで対応可能。実はストレージが使用するブロックのサイズを大きくすることで、原理上は容量上限を増やすことも可能なので、将来的には(もし要望があれば)単一のファイルのままで512TB制限を緩和するような修正が行われる可能性もある。
A: もともと想定していた用途が「ロングテールの動画」や「ユーザ生放送のタイムシフト」の保存および配信であったため。いわゆるWARMストレージ用途。アーカイブ目的のコールドストレージとは異なり、通常の視聴要求を処理する必要があるが、その際にレイテンシが大きいと視聴開始やシーク時に時間が掛かることになり、視聴体験が低下してしまうため、レイテンシを重視している。またniconicoでの構成では、CannyLSの上に冗長化層が存在し、そこではErasureCodingというアルゴリズムを用いて、保存対象のデータを複数個のフラグメント群に分割している(各フラグメントが一つのlumpに対応)。取得の際には、それらのフラグメント群からオリジナルデータを復元する必要があるが、その際のレイテンシは、CannyLSからのGETに一番時間を要したフラグメントによって決定されてしまうので、レイテンシのバラつきが少ないことも重要な要因となる。
A: 用途として「キャッシュヒット率の高いHOTストレージ」や「アーカイブ目的で書き込みが主なCOLDストレージ」ではなく「読み書きが満遍なく発生するようなWARMストレージ」を想定しているため。加えてストレージ容量としては巨大なもの(e.g., 数百TB以上)を想定しているおり、これに対して満遍ない読み書き要求が発生した場合には、メモリキャッシュを提供したとしてもそれにヒットすることはほぼなくオーバーヘッドが増えるだけであるため、キャッシュはヒットしないものと諦めて、完全にランダムアクセスワークロードを見越した設計および実装を採用することとした。また仮にCannyLSをHOTストレージ用に使う機会があったとしても、上位層(CannyLSの利用側)の方がアプリケーションの特性を良く把握しているはずなので、（CannyLSは素の性能の向上に注力し）必要であればそちらでキャッシュ層を設けた方がシステム全体での効率は向上する可能性が高いのではないかと考えている。