2

最近、私は新しいプロジェクトの観点から Cassandra を調査しており、このコミュニティとその wiki からも多くのことを学びました。しかし、圧縮を使用したレコードの削除管理と非常によく似ているように見えますが、物理ディスク領域の管理に関して Cassandra で更新がどのように管理されているかについては何も見つかりませんでした。

それぞれ 5 つの列の値を持つ 100 のレコードがあるとします。そのため、すべての変更がディスクにフラッシュされると、すべてのレコードが隣接して書き込まれ、削除操作が行われると、最初にメモリ テーブルでマークされ、構成で設定された時間の後に物理レコードが削除されます。いっぱいになったとき。そして、圧縮プロセスはスペースを要求します。

ここで問題となるのは、一方がスキーマレスであるため、最初は固定数の列がないことですが、もう一方は圧縮プロセスが行われるときに..読み取りプロセスを高速化するために、従来の RDBMS のようにレコードをディスクに隣接して配置しますか? RDBMSに関しては、列のデータ型の宣言ごとに固定量のスペースを割り当てる必要があるため、簡単です。

しかし、Cassandra は、読み取りを高速化するために、圧縮プロセス (更新と削除の両方) でディスク上のレコードを正確に配置する方法を教えてください。

圧縮に関連するもう 1 つの質問は、削除クエリはなく、既存のレコードを可変長データで更新する更新クエリがある場合、または新しい列をまとめて挿入する更新クエリがある場合、圧縮によって既存のデータ行の間でディスク上のスペースがどのように利用可能になるかということです。 ?

4

1 に答える 1

3

行と列は、SSTable にソートされた順序で格納されます。これにより、シーケンシャル ディスク IO のみを使用して、複数の SSTable を圧縮して、新しい (並べ替えられた) SSTable を出力できます。この新しいSSTableは、ディスク上の新しいファイルと空き領域に出力されます。このプロセスは、列の行数には依存せず、並べ替えられた順序で格納されているだけです。そうです、すべてのSSTable（フォーム圧縮の結果であっても）で、行と列がディスク上でソートされた順序で配置されます。

さらに、質問で示唆しているように、更新は挿入と違いはありません。ディスク上の値を上書きするのではなく、Memtable にバッファリングされてから、新しい SSTable にフラッシュされます。最終的に新しいSSTableが元の値を含むSSTableで圧縮されると、新しい値が古い値を消滅させます。つまり、古い値は圧縮から出力されません。タイムスタンプは、どの値が最新であるかを判断するために使用されます。

削除は同じ方法で処理され、効果的に「反価値」または墓石が挿入されます。このプロセスの制限は、かなりのスペース オーバーヘッドが必要になる可能性があることです。削除は事実上「遅延」であるため、スペースはしばらくたってから解放されます。また、コンパクションの出力は入力と同じサイズになる可能性がありますが、新しいSSTableが完了するまで古いSSTableを削除できないため、ディスク使用率を50%に削減できます。

上記のシステムでは、更新時に新しい値が古い値に上書きされるのではなく、新しい SSTable に書き込まれるため、既存のキーの新しい値は、事前に決められた長さまでパディングすることなく、既存のキーとは異なるサイズにすることができます。 .

于 2011-08-30T18:49:28.973 に答える