Quando useresti un ID stringa lungo anziché un intero semplice? [chiuso]


54

Vorrei usare Youtube come esempio: usano gli ID sotto forma di PEckzwggd78.

Perché non usano numeri interi semplici?

Oppure imgur.com: usano anche ID come 9b6tMZSimmagini e gallerie. Numeri non sequenziali.

  • Perché non usano numeri interi (in particolare quelli sequenziali)?

  • In quali casi è una saggia decisione utilizzare tali ID stringa anziché numeri interi?


47
Cosa ti fa credere che gli ID non siano solo semplici numeri interi? Conosco molti servizi web che usano numeri interi nel DB ma li visualizzano in alcune codifiche base64, quindi gli URL sembrano più belli. È interessante notare che gli ID di YouTube quasi mappano a numeri interi a 64 bit.
Josef,

2
@rwong Ma la domanda dei PO è perché non usano ID numerici e la risposta potrebbe essere: usano ID numerici, li visualizzano solo in base64 anziché in base10 o base2. Non lo so per certo, però, quindi sto chiedendo a OP cosa specificamente li induce a pensare che gli ID non siano semplici numeri a 64 bit in base64.
Josef,


3
Non è lo stesso di questo .
the_lotus,

Risposte:


101

Youtube non può utilizzare gli ID sequenziali per due motivi:

  1. I suoi database sono quasi certamente distribuiti, rendendo complicata la numerazione sequenziale.

  2. Ha un'opzione di privacy "Video non in elenco": quelli che non vengono visualizzati nei risultati di ricerca, ma sono disponibili se si conosce l'ID.

Pertanto, gli ID video dovrebbero essere ragionevolmente casuali e imprevedibili. Il fatto che l'ID sia rappresentato solo da cifre o da una combinazione di lettere e cifre è irrilevante: esiste una mappatura banale da una rappresentazione all'altra.


11
Gli ID numerici non devono essere sequenziali
Sopel,

28
@Sopel Penso che il punto di IMil sia che Youtube deve generare ID che sono scarsi. In altre parole, se si stima che sarà sempre necessario conservare gli 2^40oggetti, in alcune architetture ci sono motivi legittimi per scegliere uno spazio di 2^80o 2^120bit. Esempi di motivi sono: ridurre la collisione senza verificare tecnicamente la collisione; usando la scarsità di chiavi come parte della creazione di segreti difficili da trovare (il "video non
elencato

13
@Sopel la domanda era "Perché non usano numeri interi (in particolare quelli sequenziali)?" Spiego che: 1) gli ID sequenziali non sono desiderati; 2) interi e stringhe sono fondamentalmente la stessa cosa
Imil

3
La clausola "quindi" non segue logicamente ma i due punti numerati sono corretti. Come esempio del perché la casualità non è una conseguenza necessaria: la numerazione sequenziale con lacune uniformi funzionerà per fornire ID univoci in più database indipendenti in modo tale che i risultati possano essere combinati in un datawarehouse - questa è una forma di sharding. Cioè, supponiamo che tu preveda non più di 10000 database regionali (forse ne hai solo 10 in questo momento, quindi 10000 è sufficiente). Quindi ogni db può avere una colonna identità contando per 10000 con le ultime 4 cifre univoche, non ci saranno collisioni in unione.
davidbak,

2
@davidbak il requisito di casualità segue da (2). L'unicità può infatti essere ottenuta assegnando intervalli non sovrapposti a diverse istanze di database, ma ciò renderebbe prevedibili gli ID.
IMil

75
  • Sul modulo degli ID: Stanno usando Base64 (utilizzando i caratteri a- z, A- Z, 0- 9, -e _). Ciò consente loro di avere 6 bit di informazioni per carattere. YouTube utilizza ID video di 11 caratteri, il che significa che possono generare 2 6 * 11 o più di 7 * 10 19 ID. Come diceva Tom Scott , "è sufficiente per ogni singolo umano sul pianeta Terra per caricare un video ogni minuto per circa 18.000 anni". Base64 è anche facile da lavorare, perché 64 è una potenza di 2, il che significa che ogni carattere rappresenta un numero esatto di bit. Usiamo esadecimali (base 16) per lo stesso motivo.

  • Sulla natura non sequenziale degli ID: significa che non è necessario un contatore sincronizzato tra tutti i server che assegnano gli ID ai video. Possono semplicemente generare un numero casuale, verificare se è già in uso e andare da lì. Potrebbero persino assegnare a ciascun server un blocco di ID da cui scegliere ed eliminare il controllo di duplicazione. Non so se lo stanno facendo, ma potrebbero.

  • Un altro motivo per gli ID non sequenziali è che è ciò che fa funzionare i video "non elencati". Questi sono video che non verranno visualizzati nei risultati di ricerca o come suggerimenti, ma che sono accessibili se hai il link. Se stai utilizzando il conteggio sequenziale, puoi semplicemente andare a un video, aumentare l'ID di uno e l'idea dei video non elencati è ora rotta.

  • Gli ID non sequenziali aiutano anche a nascondere informazioni ai concorrenti, come la quantità totale di video o il numero di video caricati per periodo di tempo.

Consiglio vivamente il video di Tom Scott . Le sue informazioni sono quasi sempre sia interessanti che accurate.


6
Ricordiamo inoltre che 11 caratteri di una codifica base64 memorizzano 66 bit di informazioni, il che significa che possono facilmente mappare un intero a 64 bit in tale stringa. Vale a dire internamente, potrebbero comunque utilizzare un int a 64 bit (ma non è necessario farlo).
Bernhard Hiller,

1
Per fare un confronto, la rappresentazione decimale convenzionale potrebbe richiedere fino a 20 caratteri, "sprecando" fino a 9 caratteri rispetto a Base64.
dan04,

Il video di Tom Scott lo spiega perfettamente.
AGB,

13
  • I numeri interi non si adattano bene, un numero intero "normale" a 32 bit senza segno raggiungerà al massimo poco più di 4 miliardi.

  • Potrebbero non voler che tu sappia quanti elementi hanno in linea o tenere traccia del tasso che stanno crescendo.

  • Le lettere possono contenere più informazioni delle cifre, sono necessarie meno lettere per esprimere lo stesso "numero". Per un grande database indicizzatore questo potrebbe sommarsi.


7
1) si può usare int 64
Rakori il

4
2) perché? ........... sono comunque tutti pubblici. quelli che non sono pubblici - non sono accessibili. questo è tutto
Rakori,

3
3) puoi elaborare? esprimere quali informazioni?
Rakori,

2
Per 1: lo stesso vale per int32 e int64. Mentre int64 è potenzialmente molto più grande, potrebbe non essere abbastanza grande.
Nepho,

3
Nel database è necessario memorizzare un numero come numero. Quindi un int a 32 bit richiederebbe 32 bit. Il testo avrebbe una densità minore (la quantità di testo più povero dipende dalla codifica)
Taemyr,

8

1) Perché alcuni siti Web utilizzano le lettere nei loro ID? Sono stringhe?

Non sappiamo se quei siti web memorizzano gli ID nel loro database come stringhe. I numeri e le stringhe sono davvero gli stessi per i computer. Una stringa è solo un numero, appena mostrato con una base diversa. 'A' = 0x41 = 65 = 0b1000001, per il computer è lo stesso. Ma se lo visualizzi, più grande è la base, più corta è la rappresentazione e più brevi gli URL sono più facili da leggere e condividere per gli umani. Siti come YouTube e Imgur utilizzano la base 62 (lettere maiuscole e minuscole, più cifre) o più grandi (aggiungi un trattino o altri caratteri URL validi), che è relativamente breve per numeri grandi. Cosa preferiresti usare youtu.be/23489234892348234933o youtu.be/B9k6KMrv8vh?

2) Perché vengono utilizzati ID non sequenziali?

La risposta di IMil lo spiega bene:

Youtube non può utilizzare gli ID sequenziali per due motivi:

  • I suoi database sono quasi certamente distribuiti, rendendo complicata la numerazione sequenziale.

  • Ha un'opzione di privacy "Video non in elenco": quelli che non vengono visualizzati nei risultati di ricerca, ma sono disponibili se si conosce l'ID.

Ciò spiega anche perché gli ID sono così grandi: (YouTube non ospita 23.489.234.892.348.234.933 video diversi, ovviamente)

  • Quando si generano ID, è un problema se si genera accidentalmente lo stesso ID due volte, quindi è necessario un grande spazio ID per evitare il problema del compleanno

  • Le persone possono semplicemente indovinare l'URL dei video non elencati se la possibilità di utilizzare un determinato ID valido per un video non è molto, molto piccola.


3
> "YouTube non ospita 23.489.234.892.348.234.933 video diversi, ovviamente" Non sono così sicuro se questo è ovvio o no;)
unperson325680

People can just guess the URL of unlisted videos if the chance of any given valid ID being used for a video isn't very, very small.- come fai a sapere se un video non in elenco non è accessibile a tutti tranne che al suo autore? anche se qualcun altro ha indovinato il suo documento d'identità
Rakori,


2
@progo intendo se ogni singola persona al mondo ha caricato in media 3,3 miliardi di video su YouTube ...;)
Jasmijn,

5

perché non solo numeri interi, in particolare quelli sequenziali? E quando, in quali casi è saggia la decisione di tale ID stringa anziché numeri interi?

  • Migliore spazio UTF-8: quando trasformi un numero in una stringa ottieni al massimo 10 combinazioni per carattere (0-9), ma quando consenti qualsiasi carattere alfanumerico ottieni 62 combinazioni per carattere (az, AZ, 0-9 ), quindi utilizzando stringhe alfanumeriche è possibile produrre URL più brevi rispetto a se si utilizzano stringhe numeriche. Questo è importante per i siti in cui gli utenti condividono URL - come Youtube e Imgur.
  • Gli interi sequenziali sono più difficili da produrre. Per produrre un numero intero crescente sequenziale devi avere un singolo thread per produrre i numeri o coordinare molti host in un sistema distribuito e quando esegui un'applicazione ad alto volume come Youtube o Imgur che non si ridimensiona bene come una stringa generata casualmente (per non dire che si stanno generando in modo casuale)

A parte questo, non è necessariamente il caso che la rappresentazione interna sia una stringa. Molto probabilmente potrebbero codificare un identificatore numerico come stringa alfanumerica per l'URL più breve.


1
2) nel caso di un ID stringa, ma è necessario verificare che sia già stato generato un ID stringa prima di inserire un nuovo record in un db. qual è la differenza con un ID int allora?
Rakori,

@Rakorin Anche quando si utilizza qualcosa di semplice come UUIDv4, la possibilità di collison è minima. Usa abbastanza casualità e la possibilità è abbastanza inesistente, quindi la duplicità non ha bisogno di essere validata.
Andy,

1
@davidpacker e in cosa differisce dalla generazione di un numero intero più lungo?
Sopel,

@Sopel Come ha sottolineato Samuel, gli interi occuperebbero più spazio, cioè sarebbero più lunghi, delle stringhe. Altrimenti, non c'è davvero alcuna differenza.
Andy,

1
@davidpacker solo se stampato
Sopel,

2

Come hai sottolineato che sarebbe stato facile da usare un ID univoco universale usando solo numeri, perché sotto il cofano tutto è solo 0ed 1e si potrebbe espandere il numero a più di precisione che va fino a 128 bit o più.

Penso che il motivo principale sia che, supponendo un intervallo fisso arbitrario come uint32(solo per fare un esempio), se usi anche le lettere puoi avere un ID più breve in totale.

Immagino che sia un motivo estetico per l'URL. Invece di avere 4,129,873,773con le lettere è molto più breve Fu837t(solo inventato da me). Un utente potrebbe persino essere in grado di ricordare l'URL per averlo consegnato a un amico. Le piattaforme come Youtube di solito hanno UUID più lunghi di 32 bit perché esaurirebbero rapidamente lo spazio.


3
Questa penso sia la risposta. L'uso delle stringhe non è né più efficiente né più facile da mantenere univoco. Il motivo è che è più facile rappresentare come url
Sopel,

se un utente è in grado di ricordare Fu837t, ma non riesce a ricordare 2390?
Rakori,

4
@Rakori: Fu837t si confronta con 2223955238, quindi sì. Il 2390 verrebbe codificato come "Vg", quindi: anche sì.
Mooing Duck il

@MooingDuck, no. Come fai a sapere qual è l'algoritmo per generare quell'ID stringa?
Rakori,

3
@Rakori non è un algoritmo, è una codifica. Esistono algoritmi per trasferire numeri tra diverse codifiche, ma quale viene utilizzato non importa finché la codifica è ben definita. La codifica Url sicura base64 è ben nota e standardizzata .
Josef,

2

È auspicabile un breve URL poiché semplifica il collegamento e la condivisione (ad esempio è possibile condividere un collegamento in un SMS, è più veloce da digitare e così via). Servizi come Youtube o Imgurl vogliono che tu condivida gli URL in modo casuale, quindi questa è una considerazione importante.

L'uso di ID alfanumerici anziché numerici significa che sono necessari meno caratteri per esprimere un ID della stessa dimensione in bit. Ad esempio 6 cifre ti danno un milione di ID univoci ma 6 caratteri alfanumerici (usando il set base64) ti danno 68 miliardi di identificatori univoci.

Per quanto ne sappiamo, gli identificatori alfanumerici potrebbero essere numeri sequenziali, codificati in un formato alfanumerico come base64. Ma spesso i servizi commerciali evitano i codici sequenziali per impedire alle persone di indovinare gli ID ed evitare di divulgare informazioni commerciali come la quantità di clienti.


1

Esistono diversi motivi per cui dovresti utilizzare ID non numerici, ma anche capire che non tutti i valori con caratteri alfabetici sono in realtà stringhe. YouTube ha la reputazione di un numero incredibile di video, nell'ordine di 300 ore di video caricati ogni minuto ( rif ). Gli interi univoci che rappresentano quei video possono diventare piuttosto lunghi, quindi l'uso di qualcosa come i numeri con codifica URL Base64 ( ref ).

Tipi di rappresentazioni identificative:

  • Numeri interi semplici: (12345, 981027489382493)
  • Numero intero base 16: 123456789abcdef - noto anche come esadecimale
  • Numero intero base 64: 9b6tMZS
  • Stringhe leggibili: 12032017-Leggi-il-mio-fantastico-articolo-01

Tutti hanno i loro punti di forza e di debolezza. Più caratteri unici puoi utilizzare per i tuoi identificatori, meno caratteri devi rappresentare per un numero. I numeri di Base 64 sono un ottimo compromesso perché esiste una variante stabilita che funziona per gli URL e comprime il numero di caratteri necessari per rappresentare un numero da 6 a 8 (ovvero 3/4 della dimensione).

Le stringhe leggibili funzionano per i blog perché possono aumentare la ricerca, ed è molto più semplice generare titoli univoci quando il numero di record è ridotto.


1

Hash dei contenuti

La parola "hash" non si trova nelle risposte esistenti, belle, quindi eccoci qui:

Spesso, i dati possono essere identificati dal suo hash di contenuto anziché da un ID artificiale indipendente. Ciò è particolarmente evidente in software come gito file system come ZFS in cui questa particolare proprietà dell'uso degli hash del contenuto non solo rende le cose più facili (ad esempio la deduplicazione), ma ha anche altre belle proprietà come la banale memorizzazione nella cache, una cronologia sicura, il rilevamento del bit rot eccetera.

Gli hash di solito vengono come numeri esadecimali (o uno spazio di lettere ancora più grande), quindi è per questo che non vedi ID interi. Semplicemente non ci sono numeri interi (in quei casi).

Gli hash sono buoni se i tuoi oggetti dati sono immutabili (come in ZFS o git); sarebbero fantastici per archiviare immagini, ad esempio, su CDN di grandi dimensioni. Non so se questi ID particolari siano effettivamente hash, ma avrebbe sicuramente senso (e come ha commentato Michael Kjörling, gli ID brevi probabilmente non sono hash per ovvie ragioni - come confronto, git usa valori SHA-1 che sono 20 byte o 40 cifre esadecimali).


1
Almeno gli ID video di Youtube sono troppo brevi per essere hash. Si applica il paradosso del compleanno; in breve, in media, con uno spazio hash di n bit, inizierai a vedere le collisioni dopo aver visto 2 ^ (n / 2) BLOB di input. Con ~ 60-70 bit nell'ID, sono 30-35 bit di unicità o qualche miliardo di voci. Sono abbastanza sicuro che ospitano più video di quello ormai. E, naturalmente, la maggior parte degli hash sono numeri interi bene; che non sono normalmente stampati in formato decimale non ha alcuna influenza sul fatto che siano numeri interi. Certo, gli stessi dati potrebbero probabilmente essere interpretati come dati binari a virgola mobile ...
un CVn

3
@ MichaelKjörling: Beh, gli ID video di YouTube sono troppo brevi per essere hash crittografici , ma ci sono molte funzioni hash che hanno 64 bit di output o meno - CRC-16/32/64, Java hashCode(), ecc. Naturalmente, più breve è il hash, più sono probabili le collisioni casuali.
dan04,

Se avessi voluto che le persone ricordassero l'URL, non avresti reso significativo il caso. E dover dire "in alto" o "in basso" davanti a ogni lettera è molto meno efficiente del semplice dire numeri.
Lenne,

0

Ok, uno dei motivi è che i caratteri vengono inviati come caratteri e non come numeri interi. Ciò è dovuto al modo in cui funziona HTTP Get.

Quando dici "perché non usare un numero intero?" Bene, l'intero viene quindi tagliato e ogni cifra viene inviata come carattere e si finisce comunque con una stringa di caratteri. Quindi perché non usare tutte le opzioni per un personaggio?

C'è anche il fattore umano:

Prendi imgur per esempio: https://imgur.com/ ***** / s6UqP

s6UqP,

L'intervallo per ogni carattere è: dalla A alla Z maiuscola, dalla A alla Z maiuscola e da 0 a 9 = 26+ 26+ 10 = 62 opzioni per ogni posizione nella stringa. Con cinque posizioni sono 916132832 combinazioni possibili. Se dovessi usare solo numeri, avresti bisogno di 9 cifre.

Le persone possono contenere circa 7 oggetti in memoria, 9 cifre sono troppe, 5 caratteri sono fattibili.

Numero magico 7


Ricorda Gfycat: usano tre parole, due aggettivi e un nome animale. Perché ci sono molte possibilità ( 1502 adattivi e 1751 animali ) hanno più di 3 miliardi di combinazioni usando solo tre oggetti.
Gustavo Rodrigues,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.