Quand utiliseriez-vous un long ID de chaîne au lieu d'un simple entier? [fermé]

54

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?

database database-design web-services Rakori
la source
47
Qu'est-ce qui vous fait croire que les identifiants ne sont pas de simples entiers? Je connais beaucoup de services Web qui utilisent des entiers dans la base de données, mais les affichent dans un encodage base64 afin que les URL soient plus jolies. Fait intéressant, les identifiants youtube correspondent presque à des entiers 64 bits.
Josef
2
@ rwong Mais la question des OP est de savoir pourquoi ils n'utilisent pas d'identifiants numériques et la réponse pourrait être: ils utilisent des identifiants numériques, ils les affichent simplement en base64 au lieu de base10 ou base2. Je ne le sais pas avec certitude, alors je demande à OP ce qui leur fait penser que les ID ne sont pas de simples entiers 64 bits en base64.
Josef
9
youtube.com/watch?v=gocwRvLhDf8
Roger Lipscombe
3
N'est-ce pas la même chose que ça ?
the_lotus
3
Duplication possible de Pourquoi certains sites Web importants utilisent-ils des chaînes alphanumériques pour les identifiants de ressources plutôt que pour les nombres?
Brad Werth

Réponses:

101

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.

IMil
la source
11
Les identifiants numériques ne doivent pas être séquentiels
Sopel
28
@Sopel Je pense que le point sur IMil est que Youtube doit générer des identifiants clairsemés. En d'autres termes, si l'on estime que vous n'aurez jamais besoin que de stocker des 2^40éléments, certaines architectures ont des raisons légitimes de choisir un espace 2^80ou des 2^120bits. Des exemples de raisons sont: réduire la collision sans vérifier techniquement la collision; utilisation de la rareté des clés dans le cadre de la fabrication de secrets difficiles à trouver (la "vidéo non répertoriée"), etc.
dimanche
13
@Sopel, la question était "Pourquoi n'utilisent-ils pas des entiers (en particulier séquentiels)?" J'explique que: 1) les identifiants séquentiels sont indésirables; 2) les entiers et les chaînes sont fondamentalement la même chose
IMil
3
La clause "conséquent" ne suit pas logiquement, mais les deux points numérotés sont corrects. Comme exemple de la raison pour laquelle le caractère aléatoire n’est pas une conséquence nécessaire: une numérotation séquentielle avec des espaces uniformes permettra de fournir des identifiants uniques dans plusieurs bases de données indépendantes, de sorte que les résultats puissent être combinés dans un entrepôt de données - il s’agit d’une forme de partage. En d’autres termes, supposons que vous ne prévoyez pas plus de 10 000 bases de données régionales (vous n’en avez peut-être que 10, donc 10000 est suffisant). Ensuite, chaque base de données peut avoir une colonne d’identité comptant pour 10 000 avec 4 chiffres uniques, il n’y aura pas de collision à la fusion.
davidbak
2
@davidbak l'exigence de caractère aléatoire découle de (2). L'unicité peut en effet être obtenue en affectant des plages ne se chevauchant pas à différentes instances de base de données, mais cela laisserait les ID prévisibles.
IMil
75

  • 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 19 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.

rchard2scout
la source
6
Signalons également que les 11 caractères d’un codage en base64 stockent 66 bits d’information, ce qui signifie qu’ils peuvent facilement mapper un entier de 64 bits dans une telle chaîne. C'est-à-dire en interne, ils pourraient utiliser un int de 64 bits de toute façon (mais ne doivent pas le faire).
Bernhard Hiller
1
À des fins de comparaison, la représentation décimale conventionnelle peut nécessiter jusqu'à 20 caractères, ce qui «gaspille» jusqu'à 9 caractères par rapport à Base64.
dan04
La vidéo de Tom Scott explique cela parfaitement.
AGB
13

  • 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.

Martin Maat
la source
7
1) on peut utiliser int 64
Rakori
4
2) pourquoi ........... ils sont tous publics de toute façon. ceux qui ne sont pas publics - ne sont pas accessibles. c'est tout
Rakori
3
3) pouvez-vous élaborer? exprimer quelle information?
Rakori
2
Pour 1: il en va de même pour int32 et int64. Bien que int64 soit potentiellement beaucoup plus grand, il pourrait ne pas être assez grand.
Népho
3
Dans la base de données, vous stockez un nombre sous forme de nombre. Donc, un int de 32 bits prendrait 32 bits. Le texte aurait moins de densité (le nombre de textes plus pauvres dépendrait de l'encodage)
Taemyr
8

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.

Jasmijn
la source
3
> "YouTube n'abrite pas 23 489 234 892 348 234 933 vidéos différentes, évidemment" Je ne suis pas sûr de savoir si cela est évident ou non;)
unperson325680 Le
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.- comment savoir si une vidéo non répertoriée n'est pas accessible à tout le monde, sauf à son auteur? même si quelqu'un d'autre a deviné sa carte d'identité
Rakori
1
@Rakori parce que c'est comme ça que Youtube fonctionne.
Josef
2
@progo Je veux dire si chaque personne dans le monde a téléchargé 3,3 milliards de vidéos sur YouTube en moyenne ...;)
Jasmijn
5

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.

Samuel
la source
1
2) dans le cas d'un identifiant de chaîne, mais vous devrez vérifier qu'un identifiant de chaîne a déjà été généré avant d'insérer un nouvel enregistrement dans une base de données. Quelle est la différence avec un ID int alors?
Rakori
@Rakorin Même en utilisant quelque chose d'aussi simple que UUIDv4, les chances de collision sont minimes. Utilisez assez d’aléatoire et le hasard est quasi inexistant, de sorte que la duplicité n’a pas vraiment besoin d’être validée.
Andy
1
@davidpacker et en quoi est-ce différent de générer un entier plus long?
Sopel
@Sopel Comme Samuel l'a souligné, les entiers prendraient plus de place, c'est-à-dire seraient plus longs, que les chaînes. Sinon, il n'y a vraiment pas de différence.
Andy
1
@davidpacker uniquement après avoir été imprimé
Sopel
2

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.

Ewald B.
la source
3
Je pense que ceci est la réponse. L'utilisation de chaînes n'est ni plus efficace ni plus facile à maintenir l'unicité. La raison en est qu'il est plus facile à représenter sous forme d'URL
Sopel
si un utilisateur est capable de se souvenir de Fu837t, mais ne peut-il pas se souvenir de 2390?
Rakori
4
@Rakori: Fu837t serait comparable à 2223955238, alors oui. Le 2390 serait codé comme "Vg", donc: aussi oui.
Mooing Duck
@MooingDuck, non. Comment savez-vous quel est l'algorithme pour générer cet ID de chaîne?
Rakori
3
@Rakori ce n'est pas un algorithme, c'est un encodage. Il existe des algorithmes pour transférer des nombres entre différents codages, mais celui qui est utilisé importe peu tant que le codage est bien défini. Le codage base64 en url safe est bien connu et normalisé .
Josef
2

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.

JacquesB
la source
1

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.

Berin Loritsch
la source
1

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).

AnoE
la source
1
Au moins, les identifiants vidéo Youtube sont trop courts pour être des hachages. Le paradoxe de l'anniversaire s'applique; bref, en moyenne, avec un espace de hachage de n bits, vous commencerez à voir des collisions après avoir vu 2 blobs d’entrée (n / 2). Avec environ 60 à 70 bits dans l'ID, vous obtenez 30 à 35 bits d'unicité, soit quelques milliards d'entrées. Je suis sûr qu'ils hébergent plus de vidéos que ça maintenant. Et, bien sûr, la plupart des hachages sont des entiers parfaits; qu'ils ne sont pas normalement imprimés sous forme décimale n'a pas d'incidence sur le fait qu'ils soient entiers ou non. Certes, les mêmes données pourraient probablement être interprétées comme des données binaires à virgule flottante ...
un CVn
3
@ MichaelKjörling: Eh bien, les identifiants de vidéo YouTube sont trop courts pour être des hachages cryptographiques , mais il existe de nombreuses fonctions de hachage offrant une sortie de 64 bits ou moins - CRC-16/32/64, Java hashCode(), etc. hash, les collisions aléatoires les plus probables sont.
dan04
Si vous vouliez que les gens se souviennent de l'URL, vous ne l'auriez pas rendue significative. Et avoir à dire "haut" ou "bas" devant chaque lettre est beaucoup moins efficace que simplement dire des chiffres.
Lenne
0

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

Pieter B
la source
Il se souvient de Gfycat: ils utilisent trois mots, deux adjectifs et un nom d'animal. Comme il existe de nombreuses possibilités ( 1502 adjetives et 1751 animaux ), ils ont plus de 3 milliards de combinaisons utilisant seulement trois objets.
Gustavo Rodrigues