Client (app-server) vs ID unici generati da DB

Question

Client (app-server) vs ID unici generati da DB

#1 da (1 voti)

1

Ho letto su l'approccio di instagram per generare identificatori univoci.

Oltre al contenuto rimanente mi piacerebbe capire i punti che stanno facendo come un cono di client-generato (per client voglio dire qui un app-server, non userland non attendibile), in particolare:

Generalmente richiede più spazio di archiviazione (96 bit o superiore) per garantire univocamente garanzie [ID generato dall'app generato da DB]

Come è il tempo corrente in millis + shardID + contatore modulo nello spazio a 64 bit (lungo / bigint) meglio di quanto generato dall'app qualcosa come millisimi di tempo corrente + 23 bit casuali (64 bit totali)? (Quindi l'app generata ha bisogno di almeno 96 bit)

database identity database-design

posta canni 11.11.2018 - 15:29

fonte

1 risposta

Leggi altre domande sui tag database identity database-design

Separazione tra richieste di siti Web regolari e richieste API Codice comune per la trasformazione di un'entità

score 1 · Accepted Answer

23 bit significa che si ottiene una collisione del 50% a circa 3000 Id per millisecondo. Quindi si confronta male con il loro approccio 1000 per shard per millisecondo.

Immagino che abbiano bisogno di ID per più di 25 foto al secondo che ricevono.

Detto questo, penso che siano andati per la soluzione sbagliata qui. un approccio GUID sarebbe di gran lunga superiore, i limiti di sorta e di dimensioni sono in gran parte artificiali e questa citazione si distingue come una bandiera rossa per me:

41 bits for time in milliseconds (gives us 41 years of IDs with a custom epoch)

41 anni! questo è più tempo di cui abbiamo bisogno giusto? chi è Gona preoccuparsi di quelle vecchie foto in 30 anni? nessuno giusto?

Perché stai hardcoding nel tuo bug del millennio?

Qual è il piano per quando quel giorno andrà in giro, quanto costerà e perché non lo stiamo facendo in primo luogo?