web-dev-qa-db-ja.com

C-StoreのTupleMoverがLWMより古い行のみを考慮するのはなぜですか？

Michael StonebrakerによるC-StoreペーパーのTupleMoverセクション（リンク： http://db.csail.mit.edu/projects/cstore/vldb.pdf ）には、次のように説明されています。

MOP（マージアウトプロセス）は、LWM（最低水準点;タイムスタンプの順序/エポック値）またはそれ以前の挿入時刻を持つ、選択したWSセグメント内のすべてのレコードを検索します[...]レコードの最新の挿入時刻RS 'はセグメントの新しいt_lastmoveになり、常にLWM以下になります。 [...]したがって、LWMはHWM（最高水準点）を「追跡」し、履歴アクセスを必要とするユーザーのニーズとWSスペースの制約を仲介するためにそれらの間のデルタが選択されます。

WS（書き込み最適化ストレージ）からRS（読み取り最適化ストレージ）にレコードを移動するときに、タプルムーバーがLWMより古いレコードのみを考慮するのはなぜですか？ これは、LWMの後にシステムに挿入されたすべての行がWSにのみ存在することを意味しませんか？システムでは、LWMが小さい、つまり、古い履歴クエリがサポートされているシステムでは、これは、レコードの多くがWSのみにあり、読み取り最適化ストレージによって提供されるすべての最適化を見逃すことを意味する場合があります。

私は何かが足りないのですか？

verticacolumnstore
3
Joydip Datta

参照されている論文が10年前のものであることを考えると、Verticaにはより自動化されたエポックアドバンスメカニズムがあるため、 Vertica分析データベース：7年後のCストア を確認することをお勧めします。

参考までに、現在使用されている頭字語は次のとおりです。

  • WOS-書き込み最適化ストア
  • ROS-最適化されたストアを読む
  • AHM-古代史マーカー（最低水準点）
  • LGE-ラストグッドエポック

VerticaでのEpochの動作の概要：

WS（書き込み最適化ストレージ）からRS（読み取り最適化ストレージ）にレコードを移動するときに、タプルムーバーがLWMより古いレコードのみを考慮するのはなぜですか？

Verticaは、バックグラウンドプロセスとしてエポックを自動的に進めます。以下の例では、データがコミットされると、そのデータは現在のエポックに属します。

-- Get the current Epoch
dbadmin=> SELECT CURRENT_Epoch FROM system;
 CURRENT_Epoch
---------------
           238
(1 row)

-- Insert a row into the table without committing (WOS)
dbadmin=> INSERT INTO tbl (a) VALUES (1);
 OUTPUT
--------
      1
(1 row)

-- Get the Epoch for the row
dbadmin=> SELECT a, Epoch FROM tbl;
 a | Epoch
---+-------
 1 |
(1 row)

-- Commit the insert
dbadmin=> COMMIT;
COMMIT

-- Get the Epoch for the row
dbadmin=> SELECT a, Epoch FROM tbl;
 a | Epoch
---+-------
 1 |   238
(1 row)

これは、LWMの後にシステムに挿入されたすべての行がWSにのみ存在することを意味しませんか？

そうではありません。 WOSは、データがROSに移動されるまで、単なる一時的な保管場所です。エポックは、トランザクションを管理するための単なる方法です。

5
Kermit