Youtube no puede usar ID secuenciales por dos razones:

1. Es casi seguro que sus bases de datos están distribuidas, lo que complica la numeración secuencial.

2. Tiene una opción de privacidad "Videos no listados": aquellos que no aparecen en los resultados de búsqueda, pero están disponibles si conoce la ID.

Por lo tanto, las ID de video deben ser razonablemente aleatorias e impredecibles. Si la identificación está representada solo por dígitos, o por una combinación de letras y dígitos, es irrelevante: hay una asignación trivial de una representación a otra.

• En el formulario de las ID: Están usando Base64 (usando los caracteres a - z , A - Z , 0 - 9 , - , y _ ). Esto les permite tener 6 bits de información por personaje. YouTube utiliza ID de video de 11 caracteres, lo que significa que pueden generar 2 ID ^{6 * 11} , o más de 7 * 10 ¹⁹ . Como Tom Scott lo puso , eso es "suficiente para que cada humano en el planeta Tierra suba un video cada minuto para 18,000 años ". También es fácil trabajar con Base64, porque 64 es una potencia de 2, lo que significa que cada carácter representa un número exacto de bits. Usamos hexadecimal (base 16) por el mismo motivo.

• Sobre la naturaleza no secuencial de las ID: significa que no necesitan un contador sincronizado entre todos los servidores que asignan ID a los videos. Solo pueden generar un número aleatorio, verificar si ya está en uso y continuar desde allí. Incluso podrían asignar a cada servidor un bloque de ID para elegir y eliminar la comprobación de duplicación. No sé si lo están haciendo, pero podrían.

• Otra razón para las ID no secuenciales es que es lo que hace que funcionen los videos "no listados". Estos son videos que no se mostrarán en los resultados de búsqueda o como sugerencias, pero que son accesibles si tienes el enlace. Si está utilizando el conteo secuencial, solo puede ir a un video, aumentar la ID en uno y la idea de videos no listados ahora está rota.

• Las identificaciones no secuenciales también ayudan a ocultar la información de los competidores, como la cantidad total de videos o la cantidad de videos subidos por período de tiempo.

Puedo recomendar video de Tom Scott . Su información es casi siempre interesante y precisa.

• Los enteros no escalan bien, un entero sin signo "normal" de 32 bits tendrá un máximo de más de 4 mil millones.

• Es posible que no quieran que sepas cuántos artículos tienen en línea o hacer un seguimiento de la tasa de crecimiento.

• Las letras pueden contener más información que los dígitos, necesita menos letras para expresar el mismo "número". Para una base de datos de indexador grande esto podría sumar.

1) ¿Por qué algunos sitios web usan letras en sus identificaciones? ¿Son cadenas?

No sabemos si esos sitios web almacenan identificaciones en su base de datos como cadenas. Los números y las cadenas son realmente iguales a las computadoras. Una cadena es solo un número, solo se muestra con una base diferente. 'A' = 0x41 = 65 = 0b1000001 , para la computadora es todo lo mismo. Pero si lo muestra, cuanto más grande sea la base, más corta será la representación, y las URL más cortas serán más fáciles de leer y compartir para los humanos. Los sitios como YouTube e Imgur utilizan la base 62 (letras, mayúsculas y minúsculas, más dígitos) o más grandes (agregue un guión u otros caracteres de URL válidos), que es relativamente corto para números grandes. ¿Qué preferirías usar, youtu.be/23489234892348234933 o youtu.be/B9k6KMrv8vh ?

2) ¿Por qué se utilizan identificaciones no secuenciales?

La respuesta de IMil lo explica bien:

  

Youtube no puede usar ID secuenciales por dos razones:

     

• Es casi seguro que sus bases de datos están distribuidas, lo que complica la numeración secuencial.

  

• Tiene una opción de privacidad "Videos no listados": aquellos que no aparecen en los resultados de búsqueda, pero están disponibles si conoce la ID.

  

Estos también explican por qué los ID son tan grandes: (YouTube no alberga 23,489,234,892,348,234,933 videos diferentes, obviamente)

• Al generar ID, es un problema si accidentalmente genera la misma ID dos veces, por lo que necesita un gran espacio de ID para evitar el problema del cumpleaños

• La gente puede simplemente adivinar la URL de los videos no listados si la posibilidad de que se use un ID válido determinado para un video no es muy, muy pequeña.

  

¿por qué no solo los enteros, particularmente los secuenciales? ¿Y cuándo, en qué casos es una decisión acertada para tal ID de cadena en lugar de enteros?

• Mejor espacio UTF-8: cuando conviertes un número en una cadena, obtienes como máximo 10 combinaciones por carácter (0-9), pero cuando permites cualquier carácter alfa numérico, obtienes 62 combinaciones por carácter (az, AZ, 0-9), por lo tanto, al usar cadenas alfanuméricas, puede producir urls más cortas que si usara cadenas numéricas. Esto es importante para los sitios donde los usuarios comparten urls, como Youtube e Imgur.
• Los enteros secuenciales son más difíciles de producir. Para producir un entero creciente secuencial, debe tener un solo hilo para producir los números, o coordinar muchos hosts en un sistema distribuido, y cuando ejecuta una aplicación de alto volumen como Youtube o Imgur que no se escala tan bien como una cadena generada al azar (por no decir que se están generando al azar)

Además, no es necesariamente el caso de que la representación interna sea una cadena. Es muy probable que estén codificando un identificador numérico como una cadena alfanumérica para la url más corta.

Como ha señalado, sería fácil usar una ID única universal usando solo números porque bajo el capó todo es simplemente 0 y 1 y podría ampliar el número a más precisión hasta 128 poco o más.

Creo que la razón principal es que, asumiendo un rango fijo arbitrario como uint32 (solo por un ejemplo), si usa letras también puede tener una ID más corta en total.

Me imagino que es una razón estética para la URL. En lugar de tener 4,129,873,773 con letras, es mucho más corto Fu837t (solo ficticio hecho por mí). Un usuario podría incluso recordar la URL para dársela a un amigo. Las plataformas como Youtube generalmente tienen UUID más largos que 32 bits porque se quedarían sin espacio rápidamente.

Una URL corta es deseable ya que simplifica la vinculación y el uso compartido (por ejemplo, puede compartir un enlace en un SMS, es más rápido de escribir, etc.). Los servicios como Youtube o Imgurl quieren que compartas las URL de manera casual, por lo que esta es una consideración importante.

El uso de ID alfanuméricas en lugar de números significa que necesita menos caracteres para expresar una ID del mismo tamaño de bit. Por ejemplo, 6 dígitos le dan un millón de ID únicos, pero 6 caracteres alfanuméricos (usando el conjunto base64) le dan 68 mil millones de identificadores únicos.

Por lo que sabemos, los identificadores alfanuméricos podrían ser números secuenciales, simplemente codificados en un formato alfanumérico como base64. Pero a menudo los servicios comerciales evitan los códigos secuenciales para evitar que las personas adivinen identificaciones y para evitar revelar información comercial como la cantidad de clientes.

Hay varias razones por las que usaría identificadores no numéricos, pero también comprende que no todos los valores con caracteres alfabéticos son realmente cadenas. YouTube tiene la reputación de una increíble cantidad de videos, del orden de 300 horas de video subidos cada minuto ( ref ) . Los enteros únicos que representan esos videos pueden llegar a ser bastante largos, por lo que se usan números codificados como URL Base64 ( ref ).

Tipos de representaciones de identificadores:

• Enteros simples: (12345, 981027489382493)
• Base 16 enteros: 123456789abcdef - también conocido como Hex
• Base 64 enteros: 9b6tMZS
• Cadenas legibles: 12032017-Read-my-awesome-article-01

Todos ellos tienen sus fortalezas y debilidades. Mientras más caracteres únicos pueda usar para sus identificadores, menos caracteres necesitará para representar un número. Los números de la base 64 son un compromiso bastante bueno porque hay una variante establecida que funciona para las URL y comprime el número de caracteres necesarios para representar un número del 6 al 8 (es decir, 3/4 del tamaño).

Las cadenas legibles funcionan para los blogs porque pueden aumentar la capacidad de búsqueda y es mucho más fácil generar títulos únicos cuando el número de registros es pequeño.

Hash de contenido

La palabra "hash" no se encuentra en las respuestas existentes, agradable, así que aquí vamos:

A menudo, los datos se pueden identificar por su hash de contenido en lugar de una identificación artificial independiente. Esto es particularmente evidente en software como git o sistemas de archivos como ZFS, donde esta propiedad particular de usar hashes de contenido no solo facilita las cosas (por ejemplo, la eliminación de duplicaciones), sino que también tiene otras propiedades interesantes como el almacenamiento en caché trivial, un historial seguro. detectar la rotura de bits, etc.

Los hash usualmente vienen como números hexadecimales (o un espacio de letras aún más grande), por lo que no ves las ID de enteros. Simplemente hay no hay enteros (en esos casos).

Los hash son buenos si sus objetos de datos son inmutables (como en ZFS o git ); serían excelentes para almacenar imágenes, por ejemplo, en CDN grandes. No sé si esas ID particulares en realidad son hashes, pero sin duda tendría sentido (y como comentó Michael Kjörling, las ID cortas probablemente no sean hashes por razones obvias, como En comparación, git usa valores SHA-1 que son 20 bytes o 40 dígitos hexadecimales).