Czy jeśli używa się UUID, to ID w postaci longa/inteagera generowanego przez bazę danych jest już niepotrzebne?
Java 
Hibernate - Rejestracja:około 7 lat
- Ostatnio:2 minuty
- Postów:858
4
Jeśli chodzi o czystość: nie ma sensu, lepiej mieć jeden id niż dwa oznaczające to samo.
Jeśli chodzi o wydajność to może mieć to sens, gdy nie używasz kolumny uuid jako klucz czy jako indeks. Przez swoją losowość UUID słabo współgra z b-tree, są nawet rozszerzenia, które to minimalizują https://github.com/tvondra/sequential-uuids jak i nowe formaty UUID https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-01.html
robertos7778
Ale to jest jakaś specyfika PostgreSQL, z tego co czytam w opisie tego rozszerzenia. Sekwencyjnie generowane ID tworzy drzewo przeważone w lewo, co nie zawsze jest zaletą. Dużo zależy od sposobu korzystania z tego indeksu. Jeśli kolejne odczyty dotyczą sąsiednich wartości kluczy, wtedy lepsze są ID narastające. Tak samo gdy chcemy odczytywać ostatnio utworzone dane, czyli bierzemy je z prawej strony drzewa. Ale przy dużej liczbie odczytów po losowych ID przez wiele procesów równocześnie, właśnie rozproszenie kluczy po indeksie pozwoli uniknąć problemu "hot blocków".
- Rejestracja:około 3 lata
- Ostatnio:ponad rok
- Postów:2310
2
Sampeteq napisał(a):
Czy jeśli używa się UUID, to ID w postaci longa/inteagera generowanego przez bazę danych jest już niepotrzebne?
A z jakich motywacji myslisz o tym UUID ?
Argumenty ZA Uuid / Guid widzę ze 2-3, wiele więcej za Id
a) UUid jest generowany przez libkę do perzystencji (Hibernate), i jest określony jeszcze przed zapisem. Wprawdze jak po ludzku się buduje powiazania obiektów Hibertane, nie jest to potrzebne, ale z rzadka się przyda (hardkorzy kodujacy obiekt obcy jako int zamiast referencji, taka "optymalziacja" która zabija sens używania hibernate)
b) jest taki schemat włamu / nadużycia apki webowej, która ujawnia id, np http:alamakota/invoices?id=17 przez wbicie nastepnej liczby uzyskuje wgląd w fakturę, w która by wglądu nie miał - jeśli tam w URL jest Uuuid, włam jest niemal niemożliwy
c) bardzo wyrafinowane i niszowe zagadnienia serializacji / transferu rekordów do innej bazy
Wiecej argumentów za uuid nie przypominam sobie
tabela z id, mozna na to liczyć, gdy się nie poda order by przy odczycie, jest zwykle w miare "estetycznie" posortowana
wydajność itd... wiele przemawia za id
slsy napisał(a):
Jeśli chodzi o czystość: nie ma sensu, lepiej mieć jeden id niż dwa oznaczające to samo.
Ma sens miec dwa w przypadku b)
Podstawowy argument za UUID to skalowalność/replikacje multi master.
Prawda
UUID może podać (ale nie musi) klient nie związany z aplikacją. Zawsze to jakiś ficzer
- Rejestracja:ponad 6 lat
- Ostatnio:około 21 godzin
- Lokalizacja:Silesia/Marki
- Postów:5505
0
slsy napisał(a):
Przez swoją losowość UUID słabo współgra z b-tree
A jeśli ma się UUIDa rosnącego w czasie? Pamiętam że w Cassandze był taki algorytm generowania UUIDa że górna część to był czas a dolna część to był IPik komputera (czy jakoś tak). Dzięki temu UUID był zawsze rosnący
UPDATE chyba UUID - Version 1
edytowany 2x, ostatnio: KamilAdam
Poczytaj link, który wrzuciłem https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-01.html
@KamilAdam: Pytanie czy to nadal uuid, czy Olx uuid, ten jest na wyższym stopniu rozwoju bo ma kolejność ;)
- Rejestracja:prawie 5 lat
- Ostatnio:około 3 godziny
- Postów:613
- Rejestracja:ponad 7 lat
- Ostatnio:dzień
- Postów:3277
1
@robertos7778: Ten indeks musi być zmaterializowany do jakiejś fizycznej formy na dysku. Dopisanie czegoś na końcu indeksu jest tańsze niż dopisanie czegoś w środku. Jeszcze większy problem będziesz mieć jeżeli założysz indeks klastrowy na kluczu głównym, bo będzie konieczna nie tylko przebudowa indeksu, ale i danych.
- Rejestracja:prawie 5 lat
- Ostatnio:4 miesiące
- Postów:24
0
Nie lubię ID generowanego przez bazę, ponieważ oznacza to, że moja encja w początkowym etapie jest jakby niekompletna - brakuje jej ID. W Javie to jeszcze przejdzie, bo wszystko może być nullem (chociaż muszę się pilnować, żeby użyć instancji zwróconej z repozytorium) i nawet nie zauważę, ale np. w Kotlinie oznacza to, że wszędzie muszę się uganiać z typem nullowalnym. Repozytorium nie musi też zwracać zapisanej encji, mam "kontrolę" nad generowaniem ID w testach (przydało się, chociaż pewnie dało się lepiej to zrobić).
edytowany 1x, ostatnio: mythflame
- Rejestracja:około 6 lat
- Ostatnio:7 miesięcy
- Postów:216
0
@piotrpo:
To już są szczegóły implementacyjne, która każda baza może realizować inaczej. Przecież dopisanie "w środku" nie oznacza, że trzeba rozpychać indeks i przepisywać jego fragmenty. Można dodać kolejny "blok" indeksu z N liśćmi, a jego adres dopisać do węzła drzewa powyżej, który i tak musi znać lokalizację swoich węzłów (liści)-dzieci. Minus indeksu zapisywanego w sposób losowy to operacja range-scan na takim indeksie, no ale nie po to się go tworzy w taki sposób, żeby sąsiednie klucze leżały obok siebie.
Jeśli często sięgamy do sąsiednich kluczy lub skanujemy ich zakresy to lepsze są klucze generowane po kolei.
Ale jeśli mamy dużo odczytów po kluczu unikalnym lub prawie-unikalnym i mamy równocześnie wiele sesji to robiących, to klucze losowo trafiające w strukturę drzewa pozwolą na rozłożenie obciążenia pod kątem I/O. Oczywiście zakładając, że warstwa fizyczna posiada wiele urządzeń, które równocześnie mogą być odczytywane. Jak pod spodem będzie jeden dysk, to będzie gorzej.
edytowany 1x, ostatnio: robertos7778