Typ av databas ID

För att särskilja rader i databasen samt tillgå dem. Alla rader i databasen måste ha något som särskiljer dem.

Beslut

Använd UUIDv4. Analys

Är tidsbaserst och randomiserat. Klienten genererar själv sina id i alla fall.

---

Nedanstående ej aktuellt.

Använd BIGINT för ID för gruppering (GID) och SMALLINT för ID inom gruppen (IGID).

Användaren väljer själv GID. Det är ett nummer mellan 0 och 18.4 quintillioner. Garanterar unikhet. Jämförelse: det uppskattas finnas 7.5 quintillioner sandkorn på jorden. Klienten avslöjar inte för servern vem hen är som äger numret. Pga anonymitet-arkitekturen i systemet finns ingen traditionell autentifikation, så vem som helst som kan gissa numret (GID) kan tillgå datan från servern (nej, jag fixade det, men låt låtsas att så var fallet). Även om datan kan tillgås så kan enbart ägaren dekryptera den. OCH att från början gissa numret är i praktiken omöjligt. Det är över dubbelt så svårt som att hitta ett hemligt sandkorn på jorden. (Men kommer ha metod att förhindra skriv/radera data via enbart GID, "PermaNonce").

Påminnelse: vi är intresserade av att anonymisera data som fysiskt sparas på serverns hårddisk. Å andra sidan, I realtids-interaktion med server så ser servern användarens IP och kan tekniskt associera ip med användarnamn och GID, och klienten har ingen garanti för att det inte sker. Det är förväntat och inte fokus för åtgärderna här. Vad som är fokus är att: Om en angripare kommer över databasen kan de verken dekryptera databasen eller ens se vilka användare som har vilken krypterad data. Associationer mellan datablock och användare finns bara tillgänglig för användaren. I det fall en användare måste misstänka att servern associerar användarnamn med GID och sparar i hemlighet, så kan användarnamnet helt strykas och enbart GID användas för den som vill, I likhet med hur du i "Mullvad VPN" enbart behöver en id-sträng.

Använd antagligen sedan kompositnyckel (GID+IGID) för primär nyckel.

Resonemang

Bigint strategin

Medan jag försökte lösa ett problem med UUIDv4 (se nedan) insåg jag en ny strategi med BIGINT.

BIGINT är en ett nummerspann på 18.4 quintillioner. Hälften av UUID. Fortfarande tillräckligt för att undvika kollision.

Klient genererar ett sådant ID och hållet det hemligt för servern, men markerar alla sin data med det ID. Ingen traditionell autentifikation sker. Server ser bara att någon från ip nummer x skickar krypterad data markerat med det ID. Via min lösning ser servern aldrig vem id numret är bundet till.

UUIDv4 är långsammare därför försöker jag kompensera för det. Jag introducerade idén om ett gruppering ID (gid) för att hjälpa indexering och sökning. Med BIGINT kan jag ha unika sådana id för varje användare. Tanken var att ingen sådan gruppering skulle ske, för att anonymisers data, men här görs en kompromiss. En gruppering kommer ske, och därmed kommer servern kunna se att rader tillhör en viss användare, men kan inte veta vilken användare. Anonymitet är bevarad, med något mindre obfuskation av data. En värd kompromiss för effektivare databas, och med tanke på att datan ändå inte är så känslig.

Klienten sätter id nummer för sina egna rader inom sitt eget gruoperings-ID. Vilken datatyper ska vi ha för det? Vi kan pressa ner det till SMALLINT, 0 - 65,535. Det räcker, för klienten kan också återanvända id-nummer då inga komplicerade samband finns.

UUIDv4 strategin

Fråga .... UUID eller integer för ID i Databas...

UUID exempel 0acca9b1-0909-4de1-9dc1-4874306f394f, integer exempel 1029.

Säg att jag har 1 miljon rader i databasen (användares data-delar)

Sannolikheten för en kollision mellan UUID:er när man har en miljon lagrade UUID:er är mindre än att hitta samma atom i en hel galax, eller att slumpmässigt välja samma sekund två gånger i universums hela tidslinje. Denna jämförelse visar hur oerhört osannolika kollisioner mellan UUID:er är, vilket gör UUID:er extremt pålitliga för att generera unika identifierare i praktiska tillämpningar. (chatgpt)

Sannolikhet för att genereras samma numer två gånger: 1.88x10^-37

Eller

0.000000000000000000000000000000000000188

Fördel, uuid kan genereras på klientsidan. Nakdel, folk menar UUID är onödigt för enklare program, och motverkar indexering.

Att läsa UUID vs. Sequential ID as Primary Key | Baeldung

Benchmark UUID Benchmark War | Ardent Performance Computing

Kompromiss

UUIDv4:

Nakdel

• Något mer krävande för databasen. 30% långsammare för INSERT enligt artikeln ovan, 25-40% genomsnitt för alla (SELECT, etc). Pga. Svårare indexering, kräver mer minne. Färre rader per sida vid vanlig SELECT, ökar disk i/o.
• Tar mer plats. 128 bit, mot 64 för största integer typ.

Åtgärd

• Skapa ett anonymt gruppering-id (integer) för varje användare som data sparas med och som data-tabellen indexeras för. Sökning med uuid och gid gör att vi undviker problemet med att uuid är långsamt att söka över, eftersom gid avlastar.
• • nackdel är att server måste skapa gid.
• • nej server måste inte skapa gid. Klient väljer slumpmässigt ett BIGINT nummer, mellan 0 och 18.4 quintilioner. Klient garanteras då i praktiken ett unikt gid.

Fördel

• Klient kan generera id själv. Mycket välkommet. Underlättar i JavaScript.
• Icke sekventiell, försvårar/hindrar vissa attacker. IDOR/enum attack. Min specifika design med anonymisering av data vore känslig för det.
• Globalt id, därför futureproofing i någon mån.

Motiv

• Vi kan förvänta oss framtida utveckling av tekniker som gör UUID mer effektiva i databaser.
• UUID stödjer mina ambitioner om anonymisering av data.

UUIDv7:

Fördel

• Enbart 10-20% långsammare än integer.
• kan härleda tidpunkt från id.

Annat

Gid + rolling time window. Separate table. Thus no stamp on each block.