Het is niet nodig om een unieke beperking op de tijddimensie te creëren. Dit werkt:
CREATE TABLE event (
id serial,
ts timestamp with time zone NOT NULL,
details varchar(255) NOT NULL
);
SELECT create_hypertable('event', 'ts');
Merk op dat de primaire sleutel op id
is verwijderd.
TimescaleDB vereist dat elke unieke beperking of primaire sleutel de tijddimensie bevat. Dit is vergelijkbaar met de beperking van PostgreSQL in declaratieve partitionering partitiesleutel opnemen in unieke beperking:
TimescaleDB dwingt ook uniekheid in elk afzonderlijk stuk af. Het behouden van de uniciteit van de verschillende chunks kan de opnameprestaties dramatisch beïnvloeden.
De meest gebruikelijke aanpak om het probleem met de primaire sleutel op te lossen, moet u een samengestelde sleutel maken en de tijdsdimensie opnemen zoals voorgesteld in de vraag. Als de index op de tijddimensie niet nodig is (er worden geen zoekopdrachten alleen op tijd verwacht), dan kan de index op tijddimensie worden vermeden:
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);
Het is ook mogelijk om een integerkolom als tijddimensie te gebruiken. Het is belangrijk dat een dergelijke kolom tijddimensie-eigenschappen heeft:de waarde neemt in de loop van de tijd toe, wat belangrijk is voor de invoegprestaties, en query's zullen een tijdsbereik selecteren dat van cruciaal belang is voor de queryprestaties in een grote database. Het gebruikelijke geval is voor het opslaan van Unix-tijdperk.
Sinds id
in event_hyper
SERIEEL is, zal het met de tijd toenemen. Ik betwijfel echter of de query's het bereik erop zullen selecteren. Voor de volledigheid zal SQL zijn:
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);