PipelineDBのWindowsとスライスの比較

Question

PipelineDBとストリーム解析の新機能

私はこれらの2つのSQLコマンドを持っています。

CREATE CONTINUOUS VIEW timing_hashtags WITH (sw = '1 minutes') 
AS SELECT h, minute(arrival_timestamp) as minuteOfArrival, COUNT(*) as quantity 
FROM hashtag_stream GROUP BY h, minuteOfArrival; 

と

CREATE CONTINUOUS VIEW timing_hashtagsTTL WITH (ttl = '1 minute', ttl_column = 'minuteOfArrival') 
AS SELECT h, minute(arrival_timestamp) as minuteOfArrival, COUNT(*) as quantity 
FROM hashtag_stream GROUP BY h, minuteOfArrival; 

私は両方の連続ビューで次のクエリを実行すると、

SELECT * FROM timing_hastags order by minuteOfArrival desc; 

結果は、timing_hastagsとtiming_hastagsTTLの両方の連続ビューで同じです。

誰かが私に「TTL」と連続ビューの「SW」演算子の使用方法の違いを理解する助けてください。

ありがとうございます。

Answer 1

私はうまくいけば2間の区別を明確にするために、ここで各1を定義します：

TTL - これより古いすべての行がバックグラウンドで削除することができることを刈り取りへのヒント。したがって、TTL期限切れの行は、リーパーがそれらを取り除くことを諦めていない場合には、読み出し時に依然として見える可能性がある。

スライディングウィンドウ - 読み取り時にこのウィンドウ内のデータのみを考慮してください。指定したウィンドウの外部のデータは、読み取り時には表示されません。スライディングウィンドウはTTLを内部的に使用して古い行を期限切れにします。また、読み取り時にスライディングウィンドウ上で最終的な集約を行います。

誰かが私に「TTL」と連続ビューの「SW」オペレータの 用法の違いを理解する助けてください。

CREATE CONTINUOUS VIEW timing_hashtags WITH (sw = '1 minutes') 
    AS SELECT h, minute(arrival_timestamp) as minuteOfArrival, COUNT(*) as quantity 
FROM hashtag_stream GROUP BY h, minuteOfArrival; 

スライディングウィンドウのCVは、タイムスタンプ列が含まれるときはいつでも、それだけでなしスライディングウィンドウでTTLを使用するために、ほとんど常に良いでしょう。理由は、最後の1分間の最終的な集約は読み取り時に実行されるため、各行はすでに分レベルで集約されているため不要である可能性が高いからです。また、内部的には、SW CVは1分よりも細かく集約され（たとえば、毎分多くの行が存在する）、読み取り時にこれらの行を1分以上集約します。

このCV定義からminuteOfArrivalを削除すると、SWセマンティクスがより明確になる場合があります。 minuteOfArrivalがなくても、CVから読み取ったときの最後の分のデータしか表示されません。