Witam,
Zauwazylem, ze sporo tabel w postgreswej bazie danych ma spore luki w ID. Sa to skoki o 20, 50 czy 200 rekordow. Np. w malej tabelce jest 30 rekorod i zaraz przeskok na ID=50. Kilka rekordow i znowu wyskoczylo z 68 na 200. I ta sama tendencje widze w kilku tabelach. Nie ma zbyt opcji, zeby to bylo przez back-end kod. Na loclahost wszystki jest ok. Jakies pomysly o co moze chodzic? Czy moze to byc zwiazane z cloud i moze scaling up?
A przypadkiem nie masz PK zdefiniowanego jako SERIAL? Wówczas scenariusz, prowadzący do powstawania luk, mógłby być następujący:
Inne możliwość:
CACHE
A poza tym, po co się przejmować dziurami w PK?
poniatowski napisał(a):
Nie ma zbyt opcji, zeby to bylo przez back-end kod.
A używasz hibernate lub innego ORM? Kiedyś słyszałem że ORMy same nadają ID żeby były szybsze. Rezerwując właśnie po 50 sztuk. Ale to słyszałem 10 lat temu i może być już nieprawda. Albo nigdy nie była to prawda
A używasz hibernate lub innego ORM? Kiedyś słyszałem że ORMy same nadają ID żeby były szybsze. Rezerwując właśnie po 50 sztuk. Ale to słyszałem 10 lat temu i może być już nieprawda. Albo nigdy nie była to prawda
Brak ORM.
A jakie to ma znaczenie ?
jesli robi ci to jakiś problem, tzn że źle myslisz o zagadnieniu / bazach danych
Id (primary key) nie musi być ciałgły, i nie należy jakichkolwiek algorytmów na tej podstawie przygotować (np ilośc fv w miesiącu, nazbyt często widziane)
HiLo algorithm, coś w ten deseń
poniatowski napisał(a):
Nie ma zbyt opcji, zeby to bylo przez back-end kod.
Dlaczego? To skąd się te rekordy i idiki biorą? Ręcznie jest wstawiacie i macie na ścianie ostatni wolny ID zakreślany długopisem?
Generalnie przeskoki w IDkach to zupełna normalka w każdym sensowniejszym algorytmie generowania ID przez backend.
jarekr000000 napisał(a):
poniatowski napisał(a):
Nie ma zbyt opcji, zeby to bylo przez back-end kod.
Dlaczego? To skąd się te rekordy i idiki biorą? Ręcznie jest wstawiacie i macie na ścianie ostatni wolny ID zakreślany długopisem?
Generalnie przeskoki w IDkach to zupełna normalka w każdym sensowniejszym algorytmie generowania ID przez backend.
SERIAL w postgresie ustawia ID. Male luki byly by ok. Tylko ciekaw jestem jak to jest mozliwe, ze te luki zazwyczaj sa o 33 rekordy. Dziwnie tak jakos. Inaczej bym pewnie nawet na to nie zwrocil uwagi.
masz Postgresowe logi? moze tam coś znajdziesz
Sekwencje nie są transakcyjne, każda wycofana transakcja która pobrała sekwencję będzie powodować dziury. Kolejny powód to parametr cache dla sekwencji - różne zdarzenia mogą prowadzić do usunięcia wygenerowanych sekwencji z cache i ponownego ich wygenerowania.
Wydaje mi sie, ze to moze byc przez server crash https://stackoverflow.com/questions/66456952/what-does-log-cnt-mean-in-the-postgres-sequence/66458412#66458412 Tak to musi byc to. Tylko jak zalezc ten WAL plik konfiguracyjny?
poniatowski napisał(a):
Wydaje mi sie, ze to moze byc przez server crash https://stackoverflow.com/questions/66456952/what-does-log-cnt-mean-in-the-postgres-sequence/66458412#66458412 Tak to musi byc to. Tylko jak zalezc ten WAL plik konfiguracyjny?
Z tego co widzę, to wartość 32 jest zaszyta na sztywno:
https://github.com/postgres/postgres/blob/master/src/backend/commands/sequence.c#L723
https://github.com/postgres/postgres/blob/master/src/backend/commands/sequence.c#L733
Baza nie powinna ulegać awariom ;-) Jeśli jest to przyczyna luki w sekwencjach, oznaczałoby to, że postgres wykonuje częste "point-in-time-recovery" (przywraca spójności danych do konkretnegu punktu w czasie, używając logów transakcyjnych). Czy zaobserwowałeś tyle awarii silnika bazodanowego ile luk w sekwencjach?
Jak masz regularne crashe to nie doktoryzuj sie nad kluczami, ale upij się ze szczęścia, że w ogóle do tej pory serwerowi udawało się wstawać.
yarel napisał(a):
poniatowski napisał(a):
Wydaje mi sie, ze to moze byc przez server crash https://stackoverflow.com/questions/66456952/what-does-log-cnt-mean-in-the-postgres-sequence/66458412#66458412 Tak to musi byc to. Tylko jak zalezc ten WAL plik konfiguracyjny?
Z tego co widzę, to wartość 32 jest zaszyta na sztywno:
https://github.com/postgres/postgres/blob/master/src/backend/commands/sequence.c#L723
https://github.com/postgres/postgres/blob/master/src/backend/commands/sequence.c#L733Baza nie powinna ulegać awariom ;-) Jeśli jest to przyczyna luki w sekwencjach, oznaczałoby to, że postgres wykonuje częste "point-in-time-recovery" (przywraca spójności danych do konkretnegu punktu w czasie, używając logów transakcyjnych). Czy zaobserwowałeś tyle awarii silnika bazodanowego ile luk w sekwencjach?
Dokladnie. Teraz staram sie zrozumiec skad tyle awarii, bo raczej na to by wskazywalo. Jedyne co na razie znalazlem to jakies zapytanie, ktore bardzo dlugo sie kreci 10-20sec, ale to tez nie powinno zabic serwera, chyba?
@poniatowski: a to jeszcze z ciekawości... nie masz tam przypadkiem jakiegoś kubernetasa uwikłanego ? ;-)
yarel napisał(a):
@poniatowski: a to jeszcze z ciekawości... nie masz tam przypadkiem jakiegoś kubernetasa uwikłanego ? ;-)
Nie ma kubernate.
A swoją drogą jakie to ma znaczenie? Czy jest luka czy nie jest. Źle Ci z tym?