1
LSMツリーは多くの非SQLエンジンでうまく使用されていますが、そのデータはハッシュテーブルとは違うキーでソートされています。たとえば、時系列データベース（TSDB）は、エンジンとしてレベルdbを使用するのに適しています。従来のRDBMSと多くのテーブルシステムはどうでしたか？データエンジンのようなLSMツリーも同様に適していますか？LevelDBのようなLSMツリーをRDBMSのストレージエンジンとして使用
A
答えて
1
場合がございます。 leveldbの強みを活用する方法（すなわち、高速シーケンシャルリーディング）でインデックスを設計する場合、うまくいくかもしれません。
実際、私はleveldb（linqdb）の上に小さなリレーショナルデータベースを構築していますが、インデックスはキー値として格納された列の値だけでソートされています。私の知見は、このような構造のクエリは、sqliteのインデックス付きカラム（約40％遅い）ほど高速ではありませんが、大きなマージンでパフォーマンスが優れています。
もちろん、クエリの速度には多くの要素がありますが、LSMは基本的なデータ構造であり、書き込みに最も適しています。
実際にhere
追加情報、我々はテーブルシステムを構築しますが、読み取りまたは一括書き込みは、典型的なユースケースかもしれしようとしています。現在、メモリ内ハッシュインデックスを使用していますが、これは範囲クエリとソートクエリをサポートしていません。私はLSMを見ています。なぜなら、それほど多くのメモリを必要とせず、そのキーが順番に格納されているからです。 –
@bugs king LSMはディスク（マージソートで書かれた大量のデータ）に最適ですので、メモリインデックス – ren
に最適なものがあるかどうかはわかりません。実際にはlsm-treeベースのmysqlが開発中ですmyrocksと呼ばれていますが、パフォーマンスと待ち時間の洞察力に関するリソースがあまりにも限られています。 –