Los gigantes de internet como Google, Amazon, Yahoo o Facebook necesitan mover de forma fiable, rpida y energticamente eficiente

volmenes de informacin impensables hace unos aos y, con la tecnologa proporcionada hasta la fecha, no era posible de realizar. Si miramos hacia atrs, la fiabilidad estaba condicionada a que un sperordenador o un pequeo grupo de estos no fallasen al procesar programas preconcebidamente imperfectos. Por esta razn, los esfuerzos de los ingenieros estaban centrados en el hardware intentando obtener lo mximo de cada mquina. Pero ahora, estas empresas tienen miles, decenas de miles o incluso centenares de miles de ordenadores trabajando al unsono para mantener vivo el flujo de datos continuo al que se ven sometidos. No es de extraar entonces que, con tal cantidad de servidores operando, sea inevitable que siempre fallar alguno. En cuanto a la rapidez, ya no nos vale con tener sper-ordenadores con los mejores procesadores, pues por mucho que nos empeemos en el procesador, los cuellos de botella estn en los propios datos y en la entrada y salida de estos de las mquinas.

Por ltimo, el consumo de energa, con la moderna preocupacin de los recursos energticos, es, probablemente el principal problema cuando se habla de esos miles de ordenadores trabajando conjuntamente. Google dispone de su propia fuente de energa solar, que proporciona una bonita instantnea area de sus DataCenters con tejados construidos bajo paneles solares. Y no es de extraar, cuando esta empresa cuenta con, seguramente, el mayor centro de datos del mundo. Ms de medio milln de servidores que obliga al gigante a encargar sus componentes a medida para eliminar elementos intiles para el procesado de sus datos. Incluso utiliza su propia patente de unidad de alimentacin de bajo consumo. Con todo esto, para poder llevar a buen puerto esta macro arquitectura de servidores, debemos olvidarnos del propio hardware y centrarnos en las aplicaciones, en que sea el software el que d la solucin. Las bases de datos sern las encargadas de ello.

Qu es BigTable
BigTable es un mapa multidimensional ordenado, disperso, distribuido y persistente. Esta es la definicin que da el propio Google sobre BigTable. Por el momento no vamos a entrar en ella y lo haremos ms adelante. Inicialmente hablaremos ms a grandes rasgos sobre lo que es BigTable. Google cre BigTable porque los sistemas de bases de datos tradicionales no tenan ni tienen, la capacidad de crear sistemas lo suficientemente grandes.

Adems, estos sistemas de bases de datos relacionales, como SQL Server, Oracle o MySQL fueron pensados y diseados para que se ejecutasen en un solo servidor con mucha potencia. Por ello, no encajaran en las estructuras distribuidas den miles de servidores. BigTable est pensado para ser una base de datos en la que se almacene la informacin perteneciente a todos los productos de Google, En la actualidad es usada, entre otros, por el propio buscador, Google Maps, Google Earth, Google Finance, Blogger, etc. De esta manera, la cantidad de informacin almacenada es enorme y del orden de Petabytes. Cada tabla en BigTable, est dividida en tablets que tienen un tamao mximo de 200MB. Si llegasen a superar este tamao, seran automticamente divididas y comprimidas usando un sistema de compresin propio de Google para luego ser enviadas a nuevos servidores dentro de la red. Aunque tiene algn parecido con los sistemas tradicionales relacionales de bases de datos, rompe alguna de sus principales premisas. Un ejemplo es la organizacin de las propias tablas. Estas se dividen en conjuntos de columnas y stos en otras columnas. Es posible aadir columnas en cualquier momento y no es posible borrar las filas. El historial es vital para Google, y por ello no podemos eliminar nada en BigTable, ni siquiera sobreescribirlo. Para reemplazar una fila, lo que debemos es insertar una nueva que la sustituya, contradiga o actualice en base a una lnea temporal. Existen 3 claves primarias que se utilizan para la localizacin de los datos: la propia fila (similar a un identificador de fila), la columna (que lleva un nombre dentro del conjunto de columnas inicial y anteriormente citado) y un timestamp (marca de tiempo) que diferencia dos filas iguales en el tiempo. De esta forma, tenemos un historial completo y podemos acceder a filas borradas simplemente referenciando el timestamp. Las celdas contienen un nico tipo de datos: cadenas de caracteres. As de simple. Esto lo veremos ms adelante cuando divulguemos un poco en como se organiza por dentro la informacin. Por razones de rendimiento la informacin se suele almacenar de forma binaria, es decir, como volcados de la memoria que los contenan. Algunos datos interesantes en cuanto al volumen de datos que nos da Google estn enfocados a pequeas herramientas como Google Analytics o Google Earth. En agosto de 2006, Google Analytics tena ocupados 220 TB de informacin distribuidos en 90 mil millones de celdas y Google Earth ocupaba 70 TB distribuidos en 17 mil millones de celdas. Desgraciadamente BigTable es propietario y completamente privado y secreto de Google por lo que no podemos emplearlo ni hacer pruebas sobre l. Existen

alternativas libres creadas a partir de la informacin arquitectural y tecnolgica proporcionada por Google como pueden ser Hadoop e Hypertable.

De GFS a BigTable
No debemos entender BigTable sin saber lo que subyace en su base. Google File System (GFS), es un sistema de ficheros distribuido, creado por Google para satisfacer la creciente demanda en las necesidades de la empresa en el procesamiento de datos. Garantiza el rendimiento, la escalabilidad y la disponibilidad en todo momento. Es el cimiento que sustenta y hace posible BigTable. El principal objetivo de GFS es el poder almacenar ficheros de gran tamao de forma segura y que soportase una gran carga de trabajo. Al ser un sistema distribuido los datos que componen cada fichero no estn guardados en un mismo disco duro, ni siquiera en un solo servidor, sino que utiliza toda la red de ordenadores necesaria para llevar su cometido lo suficientemente eficiente como se haya pensado. Adems, por cada trozo de un fichero se hacen 3 copias que irn a parar a 3 mquinas diferentes. Existen dos tipos de servidores. Los servidores Master y los Chunkservers. Los servidores Master almacenan dnde estn los trozos (chunks), es decir, la situacin fsica o real que componen los ficheros, as como la jerarqua de ficheros y directorios. Para que estos servidores no se saturen, los clientes que acceden a ellos almacenan temporalmente los datos necesarios para el acceso posterior a los mismos trozos de archivo y as no tener que volver a lanzar la misma peticin sobre el servidor. Los Chunkservers almacenan los trozos propiamente dichos. Tpicamente, cada trozo ocupa 100MB en adelante, siendo frecuente encontrarse con ficheros de varios GB que son manejados de manera asombrosamente eficiente. Esta red de servidores es capaz de almacenar y administrar varios millones de estos trozos. Los ficheros en GFS tienen una peculiaridad y es que no se pueden sobreescribir, solo es posible aadir datos al final del fichero y aadir una marca de tiempo (timestamp) para seguir el flujo de cambios. A su vez, existen dos tipos se servidores Chunkserver: los primarios y los secundarios. Aqu es donde se encuentran las 3 copias de cada trozo que se mencionaba antes. Por un lado, el servidor primario almacena la copia principal y otros dos servidores secundarios, almacenan otra copia cada uno de ellos. De esta manera, el proceso de escritura en un fichero (trozo) es el que se ilustra en la Figura 2. El cliente inicia la transaccin

pidiendo la informacin de localizacin al servidor Master y este le contesta con los datos solicitados. Acto seguido, el cliente pasa los nuevos datos a los tres servidores Chunkserver y le informa al servidor primario de la intencin de aadir los datos. El servidor primario ordena a los secundarios que almacenen los datos que tienen en el bus de entrada y que informen de sus acciones. Una vez realizado todo este proceso, el servidor primario da la confirmacin al cliente que inici todo el trabajo. GFS no forma parte del sistema operativo, sino que se accede a travs de libreras, por lo que lo convierte en portable.

Entendiendo BigTable
Recordemos la definicin que Google da de BigTable: BigTable es un mapa multidimensional ordenado, disperso, distribuido y persistente. Pasemos a analizar esta interesante definicin desglosando cada trmino. El primero de ellos, que corresponde con la base de BigTable, es mapa. Un mapa, o un array asociativo es una estructura de datos muy simple presente en la mayora de los lenguajes de programacin modernos. Est compuesto por un conjunto de tuplas (o filas) indexadas por una clave, en muchos casos, de texto. Un ejemplo de declaracin y acceso a un mapa sera el siguiente: $map = array( key = texto: valor) (declaracin) $map[texto] valor (acceso) A estos mapas, que son utilizados de manera muy habitual, se les pueden aadir dimensiones y aqu pueden empezar los problemas o la complejidad. Se puede asimilar al concepto de los vectores del lgebra Lineal. Estos vectores pueden tener mltiples dimensiones. Y no solo 1, 2 o 3, sino que la dimensin puede ir

ms all y, en nuestra mente, existen problemas para imaginarse dimensiones superiores a 3. En el caso de los mapas pasa algo parecido. La computacin actual es totalmente capaz de representar ms de 3 dimensiones pero la representacin o el entendimiento de las mismas sigue siendo igual de complicada. Siguiendo con el ejemplo anterior, para 1 dimensin podemos usar el mapa tal cual lo hemos definido. Por ejemplo, para dimensin 1: $map = {clave_1 : gato, clave_2 : perro, clave_3 : caballo} La dimensin 2 puede asimilarse a una matriz o tabla. De esta forma el mapa quedara de la siguiente manera: $map = { animales : { gato, perro, caballo }, plantas : { helecho, margarita } } Por analoga obtenemos la dimensin 3, y podemos pensar en un cubo. A partir de aqu entra la dificultad de representacin de ms dimensiones por lo que queda para las computadoras. Una vez visto esto, pasamos a la siguiente de las definiciones que aporta Google: multidimensional. Es decir, BigTable va a estar utilizando las representaciones anteriores. Para las cuatro subdefiniciones siguientes tenemos:

Ordenado: cada una de las filas del mapa, y solo ellas, van a estar ordenadas por un criterio: la clave. Disperso: se puede entender como poco denso. Distribuido: tal y como ya se ha visto en GFS, los ficheros no se guardan en un solo servidor sino que estos se parten y se distribuyen por la red de servidores disponible. De esta manera, para un mapa concreto, podemos tener la mitad del mismo en un servidor y la otra mitad en otro.

Persistente: simplemente significa que queda guardado en unidades no voltiles (discos) y que no desaparecen con cortes de luz o cuando se desactivan las mquinas. Como ya se ha comentado, el mapa es indexado por 3 valores: una clave de fila, una clave de columna y un timestamp. Adems, los valores de las celdas son del tipo texto. Para entender mejor la estructura interna, utilizaremos un ejemplo que se ir construyendo paso a paso hasta llegar a cmo es almacenada informacin til para el motor de bsqueda de Google. El motor de bsqueda debe indexar todos los sitios webs y guardar el contenido de los mismos, tanto url como el HTML que contienen y otros datos como pas, direccin IP, etc. El mapa encargado de almacenar estos datos es conocida como Webtable. A partir de este momento usaremos el tmino tabla para referirnos al mapa de menor dimensin (el ms genrico). Para empezar, cada tabla est compuesta por varias filas o tuplas que corresponden con cada URL encontrada por los robots indexadores de Google. De esta forma, la clave de fila sern las URL. Por motivos de eficiencia y para mantener ordenados los niveles de dominio (.com es un dominio de primer nivel, .com.es es un dominio de segundo nivel, etc.) las claves se guardan al revs de como es en realidad la URL. Por ejemplo, com.google.www o com.cosasquecontar.www seran las claves para buscar la informacin referente a www.google.com y www.cosasquecontar.com respectivamente. En cada una de estas filas habr contenido, denominado familias de columnas. Hasta este punto la tabla (mapa) quedara as: com.cosasquecontar.www = { // clave de fila // familia de columnas } com.google.www : { // clave de fila // familia de columnas } Tal y como ya se ha explicado, el BigTable es multidimensional, por lo que, cada familia de columnas puede tener varios valores, cada uno indexado con otra clave propia: la clave de columna. Ahora toca decidir qu informacin nos resulta interesante guardar de cada pgina. Por ejemplo, es interesante conocer a dnde enlazan las pginas por lo que un dato puede ser el cdigo HTML que contiene enlaces (<a href=http>texto_enlace</a>). Podemos aadir la primera columna a la familia de columnas. Esta columna sera la clave en el concepto de clave valor de los mapas. Eliminamos uno de los mapas para simplificar. Quedara algo as:

com.cosasquecontar.www = { // clave de fila links : // clave del mapa com.cosasquecontar.www <a href=http://twitter.com/roviyo>Twitter</a> <a href=http://kayros-design.blogspot.com/>Blog</a> } Ahora damos otro paso y es que, siendo como es multidimensional, cada columna puede tener su propia familia de columnas aadiendo nuevos mapas dentro de los mapas ya creados. De esta manera podramos agrupar los links de antes atendiendo a dnde enlazan o podramos clasificarlos entre internos (enlazan la propia pgina desde la que se escriben) o externos (enlazan otras pginas distintas). Con todo ello, lo nico que estamos haciendo es transformar links en un nuevo mapa (submapa del mapa com.cosasquecontar.www). Quedara algo as: com.cosasquecontar.www = { // clave de fila links : { // nuevo mapa links com.twitter : // primera clave del mapa links <a href=http://twitter.com/roviyo>Twitter</a>, com.blogspot : // segunda clave del mapa links <a href=http://kayros-design.blogspot.com/>Blog</a> } } Recapitulando. Tenemos nuestra tabla Webtable. En ella tenemos un mapa principal (la URL de la web) y una familia de columnas de primera nivel que tiene una nica columna (links) que a la vez es otro mapa. Dentro de esta columa, definimos una nueva familia de columnas, en este caso con dos columnas (com.twitter y com.blogspot). Para simplificarlo y hacerlo ms entendible, las claves del mapa link son nuestras columnas y el conjunto de columnas forma la familia. Una vez aqu, aadimos una segunda columna a nuestra primera familia de columnas para poder guardar ms informacin de la web. Lo transformamos directamente en un mapa para evitar repeticiones en la explicacin. Quedara as: com.cosasquecontar.www = { // clave de fila . . . content : { clave : valor, }

} En content se guardar el pripio HTML de la pgina y nos va a servir para introducir el ltimo contepto principal de BigTable: los timestamp. Como ya se ha comentado, en BigTable (en realidad es en GFS) no permite borrar datos, sino aadir nuevos. De esta manera podremos localizar la ltima versin aadida a nuestras tablas y as mostar informacin actual en el motor de bsqueda. Estas sern nuestras claves de la columna content. Aadiendo los timestamp como clave, nuestra tabla queda as: com.cosasquecontar.www = { // clave de fila . . . content : { // mapa content 12345544433 : // primera clave del mapa content <html> . . . . . . . // version del 20/03/2011 1234554590 : // segunda clave del mapa content <html> . . . . . . . // version del 21/03/2011 } } Cada nmero (12345544433, 12345545590) son los timestamps (generados gracias a funciones de fecha) que hacen posible tener almacenado el historial del contenido de las pginas web. Una vez construdo el ejemplo completo solo queda saber como acceder a alguno de los datos de la tabla. Esto es tan sencillo como lo siguiente: $Webtable[com.cosasquecontar.www][content][12345545590] Y obtendremos el cdigo HTML que tena la web www.cosasquecontar.com a fecha 21/03/2011. Para que queden claro los conceptos se aade el esquema siguiente:

Vas: BigTable Google, GFS Google, Linux-Magazine

En el caso de Google, nos encontramos con MapReduce, sistema que le permite manejar datos de todo tipo en un complejo proceso dividido en otros ms pequeos distribuidos entre una ingente cantidad de ordenadores. MapReduce se basa en 2 pasos fundamentales: 1.-Mapeado: en ste una computadora principal evala una peticin y la divide en subproblemas que asigna a otros ordenadores, y as sucesivamente. Luego se graba la informacin y se mantiene en los discos duros de los ordenadores finales en vez de centralizarlos. 2.-Reduccin: aqu, otros ordenadores operarios cogen la informacin de los anteriores y la ordenan en un formato que permita resolver la peticin. Al final obtenemos un conjunto de datos sobre tus datos que se ha generado especficamente para responder a una peticin.

Google est desarrollando y refinando continuamente nuevas tecnologas de bsqueda.