Jak utworzyć Hypertable TimescaleDB z partycjonowaniem czasu na nieunikalnym znaczniku czasu?

Nie ma potrzeby tworzenia unikalnego ograniczenia w wymiarze czasowym. To działa:

CREATE TABLE event (
  id serial,
  ts timestamp with time zone NOT NULL,
  details varchar(255) NOT NULL
);
SELECT create_hypertable('event', 'ts');

Zwróć uwagę, że klucz podstawowy w id zostanie usunięty.

TimescaleDB wymaga, aby każde ograniczenie unikatowe lub klucz podstawowy zawierały wymiar czasu. Jest to podobne do ograniczenia PostgreSQL w partycjonowaniu deklaratywnym aby dołączyć klucz partycji do ograniczenia unikatowego:

TimescaleDB wymusza również unikatowość każdego fragmentu indywidualnie. Utrzymanie unikalności w różnych porcjach może dramatycznie wpłynąć na wydajność pobierania.

Najczęstsze podejście Aby rozwiązać problem z kluczem podstawowym, należy utworzyć klucz złożony i uwzględnić wymiar czasu, jak zaproponowano w pytaniu. Jeśli indeks w wymiarze czasu nie jest potrzebny (nie oczekuje się zapytań tylko w czasie), można uniknąć indeksu w wymiarze czasu:

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);

Możliwe jest również użycie kolumny liczb całkowitych jako wymiaru czasu. Ważne jest, aby taka kolumna miała właściwości wymiaru czasu:wartość rośnie w czasie, co jest ważne dla wydajności wstawiania, a zapytania będą wybierać zakres czasu, który jest krytyczny dla wydajności zapytań w dużej bazie danych. Typowy przypadek służy do przechowywania epoki uniksowej.

Od id w event_hyper jest SERIAL, z czasem będzie wzrastać. Wątpię jednak, aby zapytania wyselekcjonowały na nim zakres. Dla kompletności SQL będzie:

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);