時間ディメンションに一意の制約を作成する必要はありません。これは機能します:
CREATE TABLE event (
id serial,
ts timestamp with time zone NOT NULL,
details varchar(255) NOT NULL
);
SELECT create_hypertable('event', 'ts');
id
の主キーに注意してください 削除されます。
TimescaleDBでは、一意の制約または主キーに時間ディメンションが含まれている必要があります。これは、宣言型パーティショニング<におけるPostgreSQLの制限に似ています。 / a> パーティションキーを一意性制約に含めるには:
TimescaleDBは、各チャンクに個別に一意性を適用します。チャンク間で一意性を維持すると、取り込みパフォーマンスに劇的な影響を与える可能性があります。
最も一般的なアプローチ 主キーの問題を修正するには、複合キーを作成し、質問で提案されている時間ディメンションを含めることです。時間ディメンションのインデックスが必要ない場合(時間のみのクエリは予期されない)、時間ディメンションのインデックスを回避できます。
CREATE TABLE event_hyper (
id serial,
ts timestamp with time zone NOT NULL,
details varchar(255) NOT NULL,
PRIMARY KEY (id, ts)
);
SELECT create_hypertable('event_hyper', 'ts', create_default_indexes => FALSE);
時間ディメンションとして整数列を使用することもできます。このような列に時間ディメンションプロパティがあることが重要です。値は時間の経過とともに増加します。これは挿入のパフォーマンスにとって重要であり、クエリは時間範囲を選択します。これは大規模なデータベースでのクエリのパフォーマンスにとって重要です。一般的なケースは、UNIXエポックを保存する場合です。
id
以降 event_hyper
で SERIALであり、時間とともに増加します。ただし、クエリで範囲が選択されるとは思えません。完全を期すために、SQLは次のようになります。
CREATE TABLE event_hyper (
id serial PRIMARY KEY,
ts timestamp with time zone NOT NULL,
details varchar(255) NOT NULL
);
SELECT create_hypertable('event_hyper', 'id', chunk_time_interval => 1000000);