Per prima cosa, vedi il Teorema CAP . È simile al vecchio aforisma di "Fast, Good, Cheap: Pick 2."
In theoretical computer science, the CAP theorem, also known as Brewer's theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:
- Consistency (all nodes see the same data at the same time)
- Availability (a guarantee that every request receives a response about whether it succeeded or failed)
- Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures)
Interi
Il mantenimento di un numero serializzato richiede coerenza ... un posto che è il custode dei numeri. Nei sistemi di grandi dimensioni questo può diventare un collo di bottiglia , un singolo punto di errore o entrambi. Nei sistemi distribuiti, è normale iniziare a rilassare questo vincolo (Consistenza) a favore degli altri due.
Esistono strategie per mantenere identità numeriche serializzate in sistemi distribuiti, come algoritmo HI-LO oi suoi derivati, ma è ancora molto possibile saltare grandi quantità di numeri in caso di errori del nodo.
UUID
Un altro metodo comune è utilizzare un UUID , un identificatore generato a caso (che è il doppio delle dimensioni di Int64), che ha una probabilità piuttosto alta (ma non al 100%) di essere unica da qualsiasi altro UUID generato. In pratica è solo un numero casuale molto grande. Questo è utile per le operazioni client, perché il client può generarlo con una buona possibilità di univocità e successivamente utilizzarlo per identificare o tenere traccia delle cose. Ma le collisioni (lo stesso ID generato) sono possibili (specialmente se il client ha un RNG terribile ) e deve ancora essere affrontato.
Il mio sospetto è che gli identificatori di youtube siano una variante più breve di un uuid che viene poi convertito in una variazione di base64 senza punteggiatura. Perché la punteggiatura uccide la possibilità di essere utilizzato nei collegamenti. Quindi, è un numero molto grande (casuale o serializzato) che è stato convertito in testo in modo che sia più breve.
stringhe
Un formato identificativo piuttosto popolare è "entity- #" o "system-entity- #" se si dispone di un numero di sistemi interoperativi. Il # è generato in modo consistente dal sistema proprietario (ancora distribuito nel senso che esistono più sistemi, microservizi, qualsiasi cosa) o con una variazione HI-LO. E per scopi di visualizzazione, è piuttosto semplice rimuovere il prefisso e utilizzare solo la parte numerica.
Scelta
Quanto sopra non è ovviamente un elenco completo e alla fine sono tutti solo numeri binari su disco. Le ragioni per usare l'una o l'altra sono i compromessi architettonici più favorevoli al tuo sistema. Gli UUID hanno le proprietà architettoniche più convenienti per i sistemi distribuiti, ma sono negativi con il fattore umano (l'utente può ricordare e digitare 102875, ma non B9FE6378-E76C-40D5-883B-72FE376952A4, un UUID appena creato).
Se c'è qualche ambiguità in ciò che viene identificato, né UUID né numeri sono particolarmente utili ma le stringhe sono fantastiche lì. Almeno numeri serializzati possono darti un'idea di scala che può suggerire ciò che viene referenziato.
Ci sono, ovviamente, problemi di sicurezza con un identificatore di stringa come ho detto, perché può dare ai potenziali attaccanti informazioni sul tuo sistema.
Ho persino visto un post sul blog eliminare gli identificatori numerici a causa dell'impressione che dà quando a un utente vengono assegnate risorse con un numero limitato (ad esempio, Account # 5) ... Non che io ritenga che ciò abbia un merito. Dopo tutto, è sempre possibile iniziare la sequenza numerica a 6 cifre se la fiducia dell'utente è un problema aziendale valido. Modifica: l'analisi dell'andamento potrebbe essere un problema di sicurezza con l'incremento degli ID.