I vår teste av Nikita med PostgreSQL, så er alle UUID-er i databasen av datatype varchar(36), mens det er raskere og mer kompakt å bruke PostgreSQL-typen UUID i stedet. Hva er årsaken til at varchar(36) brukes i dag?
Jeg mistenker dette kan byttes med følgende kodeendring, som ennå ikke er testet:
diff --git a/src/main/java/app/domain/noark5/SystemIdEntity.java b/src/main/java/app/domain/noark5/SystemIdEntity.java index 666f3fa0a..7a3ef4951 100644 --- a/src/main/java/app/domain/noark5/SystemIdEntity.java +++ b/src/main/java/app/domain/noark5/SystemIdEntity.java @@ -25,7 +25,6 @@ import static app.utils.constants.N5ResourceMappings.SYSTEM_ID_ENG; import static jakarta.persistence.CascadeType.REMOVE; import static jakarta.persistence.DiscriminatorType.STRING; import static jakarta.persistence.InheritanceType.JOINED; -import static java.sql.Types.VARCHAR; import static org.hibernate.annotations.UuidGenerator.Style.TIME;
@@ -50,7 +49,6 @@ public class SystemIdEntity @Id @GeneratedValue(generator = "uuid-gen") @Column(name = SYSTEM_ID_ENG, updatable = false, nullable = false) - @JdbcTypeCode(VARCHAR) @UuidGenerator(style = TIME) private UUID systemId;
Grunnen VARCHAR brukes er fra MySQL der datatype UUID ikke vises som feks:
7f000101-9570-13a1-8195-70e41beb001d
en endring å tvinge det til varchar type gjorde at det ble mer menneskelig lesbar. Dette "varchar" er ikke noe som er viktig å ivareta. Dersom jeg har det behovet i undervisning så kan jeg ha en lokal skript med en patch som fikser det ved behov.
Som du nevnte på #nikita at det ikke skal være basert på tid så tar jeg også bort
@UuidGenerator(style = TIME)
Aktuelle verdier her er: AUTO, RANDOM og TIME. Dersom en verdi ikke er satt så blir det satt til RANDOM, men jeg mistenker at det kan være lurt å tvinge RANDOM slik at det ikke skjer en endring senere der default endres.
Jeg håper å endre dette innen onsdag.
Thomas
________________________________ Fra: Petter Reinholdtsen pere@hungry.com Sendt: mandag 10. mars 2025 14:25 Til: nikita-noark@nuug.no nikita-noark@nuug.no Emne: Hvorfor VARCHAR(36) og ikke UUID som SQL-type?
I vår teste av Nikita med PostgreSQL, så er alle UUID-er i databasen av datatype varchar(36), mens det er raskere og mer kompakt å bruke PostgreSQL-typen UUID i stedet. Hva er årsaken til at varchar(36) brukes i dag?
Jeg mistenker dette kan byttes med følgende kodeendring, som ennå ikke er testet:
diff --git a/src/main/java/app/domain/noark5/SystemIdEntity.java b/src/main/java/app/domain/noark5/SystemIdEntity.java index 666f3fa0a..7a3ef4951 100644 --- a/src/main/java/app/domain/noark5/SystemIdEntity.java +++ b/src/main/java/app/domain/noark5/SystemIdEntity.java @@ -25,7 +25,6 @@ import static app.utils.constants.N5ResourceMappings.SYSTEM_ID_ENG; import static jakarta.persistence.CascadeType.REMOVE; import static jakarta.persistence.DiscriminatorType.STRING; import static jakarta.persistence.InheritanceType.JOINED; -import static java.sql.Types.VARCHAR; import static org.hibernate.annotations.UuidGenerator.Style.TIME;
@@ -50,7 +49,6 @@ public class SystemIdEntity @Id @GeneratedValue(generator = "uuid-gen") @Column(name = SYSTEM_ID_ENG, updatable = false, nullable = false) - @JdbcTypeCode(VARCHAR) @UuidGenerator(style = TIME) private UUID systemId;
-- Vennlig hilsen Petter Reinholdtsen _______________________________________________ nikita-noark mailing list -- nikita-noark@nuug.no To unsubscribe send an email to nikita-noark-leave@nuug.no
En annen ting verdt å merke seg. Mine lokale test på å konvertere nikita til en nativ image med graalvm ga et stort utsalg på ytelse, så det kan være greit å ha i bakhodet at vi kan kanskje få ting til å gå enda raskere.
Men ytelses forbedringen på UUID-typen er jo voldsom stort! Jeg gleder meg til å teste det lokalt.
Thomas ________________________________ Fra: Thomas John Sødring tsodring@oslomet.no Sendt: mandag 10. mars 2025 15:48 Til: Petter Reinholdtsen pere@hungry.com; nikita-noark@nuug.no nikita-noark@nuug.no Emne: Sv: Hvorfor VARCHAR(36) og ikke UUID som SQL-type?
Grunnen VARCHAR brukes er fra MySQL der datatype UUID ikke vises som feks:
7f000101-9570-13a1-8195-70e41beb001d
en endring å tvinge det til varchar type gjorde at det ble mer menneskelig lesbar. Dette "varchar" er ikke noe som er viktig å ivareta. Dersom jeg har det behovet i undervisning så kan jeg ha en lokal skript med en patch som fikser det ved behov.
Som du nevnte på #nikita at det ikke skal være basert på tid så tar jeg også bort
@UuidGenerator(style = TIME)
Aktuelle verdier her er: AUTO, RANDOM og TIME. Dersom en verdi ikke er satt så blir det satt til RANDOM, men jeg mistenker at det kan være lurt å tvinge RANDOM slik at det ikke skjer en endring senere der default endres.
Jeg håper å endre dette innen onsdag.
Thomas
________________________________ Fra: Petter Reinholdtsen pere@hungry.com Sendt: mandag 10. mars 2025 14:25 Til: nikita-noark@nuug.no nikita-noark@nuug.no Emne: Hvorfor VARCHAR(36) og ikke UUID som SQL-type?
I vår teste av Nikita med PostgreSQL, så er alle UUID-er i databasen av datatype varchar(36), mens det er raskere og mer kompakt å bruke PostgreSQL-typen UUID i stedet. Hva er årsaken til at varchar(36) brukes i dag?
Jeg mistenker dette kan byttes med følgende kodeendring, som ennå ikke er testet:
diff --git a/src/main/java/app/domain/noark5/SystemIdEntity.java b/src/main/java/app/domain/noark5/SystemIdEntity.java index 666f3fa0a..7a3ef4951 100644 --- a/src/main/java/app/domain/noark5/SystemIdEntity.java +++ b/src/main/java/app/domain/noark5/SystemIdEntity.java @@ -25,7 +25,6 @@ import static app.utils.constants.N5ResourceMappings.SYSTEM_ID_ENG; import static jakarta.persistence.CascadeType.REMOVE; import static jakarta.persistence.DiscriminatorType.STRING; import static jakarta.persistence.InheritanceType.JOINED; -import static java.sql.Types.VARCHAR; import static org.hibernate.annotations.UuidGenerator.Style.TIME;
@@ -50,7 +49,6 @@ public class SystemIdEntity @Id @GeneratedValue(generator = "uuid-gen") @Column(name = SYSTEM_ID_ENG, updatable = false, nullable = false) - @JdbcTypeCode(VARCHAR) @UuidGenerator(style = TIME) private UUID systemId;
-- Vennlig hilsen Petter Reinholdtsen _______________________________________________ nikita-noark mailing list -- nikita-noark@nuug.no To unsubscribe send an email to nikita-noark-leave@nuug.no
[Thomas John Sødring]
Som du nevnte på #nikita at det ikke skal være basert på tid så tar jeg også bort
@UuidGenerator(style = TIME)
Du misforstår. Jeg luftet mine fordommer og tvilsomme antagelser på #nikita, ikke noe krav om at det ikke skulle være som i dag. Jeg trodde at Nikita genererte UUID versjon 4 (aka basert på tilfeldige tall), mens da jeg leste koden så jeg at det virker som den var basert på tid i stedet. Begge deler er helt i orden Hvis den var basert på tilfeldige tall, så fikk vi et råd i dag om at vi burde vurdere UUID versjon 7 (fra RFC 9562), men den oppdaget jeg var utenfor rekkevidde med dagens N5TG-spesifikasjon (har bedt om at det endres i <URL: https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues/32... >).
Aktuelle verdier her er: AUTO, RANDOM og TIME. Dersom en verdi ikke er satt så blir det satt til RANDOM, men jeg mistenker at det kan være lurt å tvinge RANDOM slik at det ikke skjer en endring senere der default endres.
Det kan godt hende at tidsbasert UUID (v1) er bedre for ytelsen ved skriving enn helt tilfeldig UUID (v4/v7), så jeg ville avventet å bytte til vi vet mer om effekten av et slikt bytte. Det vi diskuterte med kollegaer med PostgreSQL-peiling i dat var relativ skalerbarhert av UUID versjon 4 versus 7 og det sier intet om forholdet til UUID versjon 1.
En annen ting verdt å merke seg. Mine lokale test på å konvertere nikita til en nativ image med graalvm ga et stort utsalg på ytelse, så det kan være greit å ha i bakhodet at vi kan kanskje få ting til å gå enda raskere.
Ja, ytelsesforbedring er bakgrunnen for forslaget. Datamengden som må sjekkes blir betydelig mindre med UUID vs. varchar(36) i UTF-8-form. Det er antagelig enda mer å hente på utvalgte indekser, men vi kommer tilbake til dette når vi har testet mer. :)