Especulemos, la mayoría del software de google fue escrito en 1998 - 2000. Se programó en C y C++ para correr bajo Linux. En Julio del 2000, la demanda de Google era de un billon de páginas web. Para Noviembre del 2000 era 3 billones. A esta proporción de crecimiento, habría ahora 3.5 billones, aunque la cuenta no ha cambiado en su home page desde Noviembre. Si se busca por la palabra "y" se contarán cerca de 3.6 billones . No está claro que role tienen los otros lenguajes, pero aún sin contarlos se aproximan a casi 4 billones (al menos en Inglés). Parece que se están quedando sin IDs disponibles de páginas web.

Si se usa un número ID que identifique a cada nueva página en la web, hay un problema una vez que se llega a 4,294,967,296 números. Números mas grandes requieren de más procesamiento y diferente código. Nuestras especulaciones hacen 3 asunciones:

1. Google usa funciones estándares del lenguaje C en la programación de su centro.

2. Cuando los primeros programas de Google fueron desarrollados 4 o 5 años atrás, un único ID fue requerido para todas las páginas web

3. Parece razonable y eficiente usar un entero largo sin signo en ANSI C. En Linux, estas variables son 4 bytes, y tienen un máximo de 4.2 billones antes que se concierta en cero.

Cuando los programas centros fueron desarrollados para Google muchos años atrás, era razonable asumir que el límite de 4.2 billones no era un problema potencial.

Es también posible que el freshboot , que empezó a trabajar en Agosto del 2001, fue asignado a su propio bloque de ID no usado del fondo de 4.2 billones. Esto sugiere una cierta cantidad de ineficiencia en el uso de números disponibles. De hecho, freshboot se comporta como si solo pudiera sostener cierto número de páginas, en cuyo punto desecha la página más vieja y sobreescribe con una nueva página de diferente sitios. Esta peculiaridad podría ser otro síntoma de la limitada contidad de números disponibles.

Por lo tanto, no es un juego de niños agregar otro byte y hacer que en lugar de 4 bytes sea un entero de 5 bytes. Usar un byte extra, básicamente significa que usar un caracter sin signo como multiplicador de 4.2 billones y agregar eso al entero para obtener el resultado final. Si el entero es A, y el multliplicador es B, el nuevo entero será A + (B * 4.2 billones).

Para algo tan básico como el ID de la página, esto implica una reparación masiva en el software de Google. Entretanto, se tendrán 15,000 cajas de Linux que actualizar. Cada caja de Linux en Google ejecuta un juego estándar de software, así que puede ser intercambiable con otras cajas una vez que el dato sea duplicado. La actualización se tendía que hacer en fases, de otra manera todo Google dejará de funcionar por un tiempo. El bajo perfirmance es tolerable, dadas las circunstancias, pero dejar de funcionar significaría una pérdida inmediate en el mercado.

En junio del año pasado os hablábamos sobre la teoría de los 4 bytes, la cual afirmaba que Google había llegado al máximo de su capacidad, puesto que en su momento se programó con el lenguage C ó C++, cometiéndose algunos errores.

La teoría defiende que Google otorga a cada documento un número (un ID), pero que este número solamente puede tomar como valor máximo 4.294.967.296, que es 2 elevado a 32 (32 bites = 4 bytes). El error que se cometió fue asignar a este ID el tipo unsigned long (que solamente puede tomar valores entre 0 y 4.294.967.296).

El hecho es que, desde febrero de este año, el número de documentos que Google asegura indexar es de 4.285.199.774, y esta cifra no ha aumentado en todo este tiempo. Una cifra bastante parecida a la de la teoría de los 4 bytes.

REFERENCIA

Anónimo. [en línea]. [Citado 26-11-2004]. Disponible en http://www.aclantis.com/article7487.html