J'aimerais utiliser Youtube comme exemple: ils utilisent des identifiants sous forme de PEckzwggd78.

Pourquoi n'utilisent-ils pas de simples entiers?

Ou imgur.com - ils utilisent également des identifiants tels que 9b6tMZSdes images et des galeries. Pas d'entiers séquentiels.

• Pourquoi n'utilisent-ils pas des entiers (en particulier séquentiels)?

• Dans quels cas est-il judicieux d'utiliser de tels ID de chaîne plutôt que des entiers?

Youtube ne peut pas utiliser les identifiants séquentiels pour deux raisons:

1. Ses bases de données sont presque certainement distribuées, ce qui complique la numérotation séquentielle.

2. Il possède une option de confidentialité "Vidéos non répertoriées": celles qui n'apparaissent pas dans les résultats de la recherche, mais sont disponibles si vous connaissez l'identifiant.

Par conséquent, les identifiants vidéo doivent être raisonnablement aléatoires et imprévisibles. Que l'identifiant soit représenté uniquement par des chiffres, ou par une combinaison de lettres et de chiffres, est sans importance: il existe un mappage trivial d'une représentation à une autre.

• Sur la forme des ID: Ils utilisent base64 ( en utilisant les caractères a- z, A- Z, 0- 9, -et _). Cela leur permet d’avoir 6 bits d’information par caractère. YouTube utilise des identifiants vidéo à 11 caractères, ce qui signifie qu'ils peuvent générer 2 ^{6 * 11} ou plus de 7 * 10 ¹⁹ identifiants. Comme le dit Tom Scott , cela suffit "à chaque homme sur la planète Terre pour télécharger une vidéo toutes les minutes pendant environ 18 000 ans". Base64 est également facile à utiliser, car 64 correspond à une puissance de 2, ce qui signifie que chaque caractère représente un nombre exact de bits. Nous utilisons hexadécimal (base 16) pour la même raison.

• Sur la nature non séquentielle des identifiants: cela signifie qu'ils n'ont pas besoin d'un compteur synchronisé entre tous les serveurs qui attribuent des identifiants aux vidéos. Ils peuvent simplement générer un nombre aléatoire, vérifier s’il est déjà utilisé et partir de là. Ils pourraient même assigner à chaque serveur un bloc d'identifiants parmi lesquels choisir et éliminer la vérification des doublons. Je ne sais pas s'ils le font, mais ils le pourraient.

• Une autre raison des identifiants non séquentiels est que c'est ce qui permet aux vidéos "non répertoriées" de fonctionner. Ce sont des vidéos qui n'apparaissent pas dans les résultats de recherche ou sous forme de suggestions, mais qui sont accessibles si vous avez le lien. Si vous utilisez le comptage séquentiel, vous pouvez simplement visionner une vidéo, augmenter l'identifiant de un, et l'idée de vidéos non répertoriées est désormais dépassée.

• Les identifiants non séquentiels aident également à masquer les informations des concurrents, telles que le nombre total de vidéos ou le nombre de vidéos téléchargées par période.

Je peux fortement recommander la vidéo de Tom Scott . Ses informations sont presque toujours intéressantes et précises.

• Les entiers ne s’échelonnent pas aussi bien, un entier «normal» non signé de 32 bits atteindra un peu plus de 4 milliards.

• Ils ne voudront peut-être pas que vous sachiez combien d’articles ils ont en ligne ou ne suivent pas leur taux de croissance.

• Les lettres peuvent contenir plus d'informations que les chiffres, vous avez besoin de moins de lettres pour exprimer le même "nombre". Pour une grande base de données d'indexation, cela pourrait s'additionner.

1) Pourquoi certains sites Web utilisent-ils des lettres dans leurs identifiants? Sont-ils des ficelles?

Nous ne savons pas si ces sites Web stockent des identifiants dans leur base de données sous forme de chaînes. Les chiffres et les chaînes sont vraiment les mêmes pour les ordinateurs. Une chaîne est juste un nombre, juste montré avec une base différente. 'A' = 0x41 = 65 = 0b1000001, à l'ordinateur c'est tout pareil. Mais si vous l'affichez, plus la base est large, plus la représentation est courte et les URL plus courtes sont plus faciles à lire et à partager pour les humains. Des sites tels que YouTube et Imgur utilisent la base 62 (lettres, majuscules et minuscules, ainsi que les chiffres) ou supérieure (ajoutez un tiret ou un autre caractère URL valide), ce qui est relativement court pour les gros chiffres. Que préféreriez-vous utiliser, youtu.be/23489234892348234933ou youtu.be/B9k6KMrv8vh?

2) Pourquoi utilise-t-on des identifiants non séquentiels?

La réponse de IMil l' explique bien:

Youtube ne peut pas utiliser les identifiants séquentiels pour deux raisons:

• Ses bases de données sont presque certainement distribuées, ce qui complique la numérotation séquentielle.

• Il possède une option de confidentialité "Vidéos non répertoriées": celles qui n'apparaissent pas dans les résultats de la recherche, mais sont disponibles si vous connaissez l'identifiant.

Celles-ci expliquent également pourquoi les identifiants sont si volumineux: (YouTube ne contient évidemment pas 23 489 234 892 348 234 933 vidéos différentes)

• Lorsque vous générez des identifiants, vous rencontrez un problème si vous générez accidentellement le même identifiant deux fois. Vous avez donc besoin d'un grand espace d'identification pour éviter le problème de l'anniversaire.

• Les gens peuvent simplement deviner l'URL des vidéos non répertoriées si la probabilité qu'un identifiant valide soit utilisé pour une vidéo n'est pas très très petite.

pourquoi ne pas simplement des entiers, en particulier séquentiels? Et quand, dans quels cas est-il judicieux de choisir un tel ID de chaîne plutôt que des entiers?

• Meilleur espace UTF-8 - lorsque vous transformez un nombre en chaîne, vous obtenez au maximum 10 combinaisons par caractère (0 à 9), mais lorsque vous autorisez des caractères alphanumériques, vous obtenez 62 combinaisons par caractère (az, AZ, 0-9). ), donc en utilisant des chaînes alphanumériques, vous pouvez produire des URL plus courtes que si vous utilisiez des chaînes numériques. Ceci est important pour les sites où les utilisateurs partagent des URL - comme Youtube et Imgur.
• Les entiers séquentiels sont plus difficiles à produire. Pour produire un entier croissant séquentiel, vous devez obligatoirement qu'un seul thread produise les nombres, ou coordonne plusieurs hôtes dans un système distribué, et lorsque vous exécutez une application à volume élevé, telle que Youtube ou Imgur, qui ne s'échelonne pas aussi bien qu'une chaîne générée aléatoirement. ( pour ne pas dire qu'ils sont générer de manière aléatoire)

En aparté, ce n'est pas nécessairement le cas que la représentation interne est une chaîne. Ils pourraient très probablement coder un identifiant numérique sous forme de chaîne alphanumérique pour l'URL la plus courte.

Comme vous l' avez fait remarquer qu'il serait facile d'utiliser un identifiant unique universel tout en utilisant des nombres , car sous le capot , tout est juste 0et 1vous pouvez augmenter le nombre de plus de précision allant jusqu'à 128 bits ou plus.

Je pense que la raison principale en est que, en supposant une plage fixe arbitraire comme uint32(par exemple), si vous utilisez également des lettres, vous pouvez avoir un identifiant total plus court.

J'imagine que c'est une raison esthétique pour l'URL. Au lieu d'avoir 4,129,873,773avec des lettres c'est beaucoup plus court Fu837t(juste fictif composé par moi). Un utilisateur peut même être capable de se souvenir de l'URL pour le donner à un ami. Les plates-formes comme Youtube ont généralement des UUID plus longs que 32 bits, car elles manqueraient rapidement d'espace.

Une URL courte est souhaitable car elle facilite la liaison et le partage (par exemple, vous pouvez partager un lien dans un SMS, il est plus rapide de taper, etc.). Des services tels que Youtube ou Imgurl souhaitent que vous partagiez les URL de manière informelle. C’est donc une considération importante.

L'utilisation d'identifiants alphanumériques plutôt que numériques signifie que vous avez besoin de moins de caractères pour exprimer un identifiant de la même taille en bits. Par exemple, 6 chiffres vous donnent un million d'identifiants uniques, mais 6 caractères alphanumériques (en utilisant le jeu base64) vous donnent 68 milliards d' identifiants uniques.

Pour autant que nous sachions, les identifiants alphanumériques pourraient être des nombres séquentiels, juste encodés dans un format alphanumérique comme base64. Mais souvent, les services commerciaux évitent les codes séquentiels pour empêcher les utilisateurs de deviner leurs identifiants et pour éviter de divulguer des informations commerciales telles que le nombre de clients.

Il existe plusieurs raisons pour lesquelles vous utiliseriez des identifiants non numériques, mais comprenez également que toutes les valeurs avec des caractères alphabétiques ne sont pas vraiment des chaînes. YouTube a la réputation d'un nombre incroyable de vidéos, de l'ordre de 300 heures de vidéos téléchargées chaque minute ( réf .). Les entiers uniques représentant ces vidéos peuvent être assez longs, utilisez donc quelque chose comme les nombres encodés en URL Base64 ( ref ).

Types de représentations d'identifiant:

• Entiers simples: (12345, 981027489382493)
• Entiers en base 16: 123456789abcdef - aussi appelé hex
• Entiers base 64: 9b6tMZS
• Chaînes lisibles: 12032017-Read-my-awesome-article-01

Ils ont tous leurs forces et leurs faiblesses. Plus vous pouvez utiliser de caractères uniques pour vos identifiants, moins vous avez besoin de caractères pour représenter un nombre. Les chiffres en base 64 sont un très bon compromis car il existe une variante établie qui fonctionne pour les URL et compresse le nombre de caractères nécessaires pour représenter un nombre compris entre 6 et 8 (c'est-à-dire 3 / 4ème de la taille).

Les chaînes lisibles fonctionnent pour les blogs car elles peuvent améliorer la facilité de recherche et il est beaucoup plus facile de générer des titres uniques lorsque le nombre d'enregistrements est faible.

Contenu hashes

Le mot "hash" ne se trouve pas dans l'existant, gentil, répond, alors on y va:

Souvent, les données peuvent être identifiées par leur contenu hash au lieu d'un identifiant artificiel indépendant. Cela est particulièrement évident dans les logiciels gitou les systèmes de fichiers tels que ZFS où cette propriété particulière d’utiliser le hachage de contenu facilite les choses (par exemple, la déduplication), mais offre également d’autres propriétés intéressantes comme la mise en cache triviale, un historique sécurisé, la détection du etc.

Les hachages sont généralement des nombres hexadécimaux (ou un espace de lettre encore plus grand), c'est pourquoi vous ne voyez pas les ID entiers. Il suffit sont pas de nombres entiers (dans ces cas).

Les hachages sont bons si vos objets de données sont immuables (comme dans ZFS ou git); ils seraient bien de stocker des images, par exemple, sur de grands CDN. Je ne sais pas si ces identifiants sont en fait des hachages, mais cela aurait du sens (et comme Michael Kjörling l'a commenté, les identifiants courts ne sont probablement pas des hachages pour des raisons évidentes - à titre de comparaison, git utilise des valeurs SHA-1 de 20 octets ou 40 chiffres hexadécimaux).

Ok, une des raisons est que les caractères sont envoyés comme des caractères et non comme des entiers de toute façon. Cela est dû à la façon dont fonctionne un HTTP Get.

Quand vous dites, "pourquoi ne pas utiliser un entier?" Eh bien, le nombre entier est haché et chaque chiffre est envoyé sous forme de caractère et vous vous retrouvez avec une chaîne de caractères de toute façon. Alors pourquoi ne pas utiliser toutes les options pour un personnage?

Il y a aussi le facteur humain:

Prenez imgur par exemple: https://imgur.com/ ***** / s6UqP

s6UqP,

La plage de chaque caractère est la suivante: a à z majuscule, a à z sous-capital et 0 à 9 = 26+ 26+ 10 = 62 options pour chaque position de la chaîne. Avec cinq positions, 916132832 combinaisons possibles. Si vous n'utilisiez que des chiffres, vous auriez besoin de 9 chiffres.

Les gens peuvent contenir environ 7 objets en mémoire, 9 chiffres, c'est trop, 5 caractères sont réalisables.

Numéro magique 7