Gran sistema de almacenamiento de datos estructurados distribuidos en tablas

Bigtable es un sistema distribuido de almacenamiento de datos estructurados diseñado para manejar cantidades masivas de datos: normalmente petabytes de datos distribuidos en miles de servidores comunes. Muchos proyectos de Google utilizan Bigtable para almacenar datos, incluida la indexación web, Google Earth y Google Finance. Estas aplicaciones tienen requisitos muy diferentes para Bigtable, tanto en términos de volumen de datos (desde URL hasta páginas web e imágenes satelitales) y capacidad de respuesta (desde el procesamiento por lotes de back-end hasta el servicio de datos en tiempo real).

Bigtable logra los siguientes objetivos: amplia aplicabilidad, escalabilidad, alto rendimiento y alta disponibilidad. Bigtable es un mapa ordenado multidimensional escaso, distribuido y duradero.

Figura 1: Fragmento de tabla que almacena una página web de muestra. El nombre de la línea es una URL inversa. La familia de columnas de contenido almacena el contenido de la página web, mientras que la familia de columnas de anclaje almacena el texto del enlace de anclaje que hace referencia a la página web (nota para Alex: si no conoce el anclaje de HTML, búsquelo). Sports Illustrater y la página de inicio de MY-look hacen referencia a la página de inicio de CNN, por lo que esta fila contiene columnas denominadas "anchor:cnnsi.com" y "anchor:MY.look.ca". Cada enlace de anclaje tiene solo una versión (nota para Alex: preste atención a la versión de la columna de identificación de marca de tiempo, t9 y t8 identifican respectivamente las versiones de los dos enlaces de anclaje, la columna de contenido tiene tres versiones, identificadas por las marcas de tiempo t3); t5 y t6 respectivamente.

Líneas

Bigtable organiza los datos en orden lexicográfico de claves de fila. Cada fila de la tabla se puede dividir dinámicamente. Cada partición se denomina "losa", que es la unidad más pequeña para la distribución de datos y el ajuste del equilibrio de carga.

Ancestor

Webtable tiene un idioma de familia de columnas que se utiliza para almacenar el idioma en el que están escritas las páginas web.

Solo utilizamos una clave de columna en la familia de columnas de idioma para almacenar el ID del identificador de idioma de cada página web. Otra familia de columnas útil en Webtable es el ancla; cada clave de columna de esta familia de columnas representa un enlace de ancla, como se muestra en la Figura 1. El calificador de una familia de columnas de anclaje es el nombre del sitio web que hace referencia a esta página; el elemento de datos en cada columna de la familia de columnas de anclaje almacena el texto del enlace. El control de acceso, las estadísticas de uso de disco y memoria se realizan a nivel de familia de columnas.

Impresión de marcas de tiempo

Las diferentes versiones de datos se indexan mediante marcas de tiempo. El tipo de marca de tiempo de Bigtable es un entero de 64 bits.

Bigtable puede asignar valores a marcas de tiempo para representar el tiempo en "tiempo real" con una precisión de milisegundos; los programas de usuario también pueden asignar valores a marcas de tiempo. Si una aplicación necesita evitar conflictos entre versiones de datos, debe generar sus propias marcas de tiempo únicas. En los elementos de datos, las diferentes versiones de los datos se ordenan en orden inverso según la marca de tiempo, es decir, los datos más recientes aparecen primero. Para aliviar la carga de administración de múltiples versiones de datos, proporcionamos dos parámetros de configuración para cada familia de columnas a través de los cuales Bigtable puede recolectar automáticamente basura de versiones de datos obsoletas. Los usuarios pueden especificar guardar solo las últimas n versiones de datos, o solo guardar versiones de datos "suficientemente nuevas" (por ejemplo, guardar solo los datos escritos en los últimos 7 días).

Otras funciones admitidas por Bigtable

1. Bigtable admite el procesamiento de transacciones de una sola fila. Con esta función, los usuarios pueden realizar operaciones atómicas de lectura, actualización y escritura en los datos almacenados bajo la línea clave.

2.Bigtable permite utilizar elementos de datos como contadores de números enteros.

3.Bigtable permite a los usuarios ejecutar scripts en el espacio de direcciones del servidor.

4.Bigtable se puede utilizar con MapReduce, un marco de computación paralela a gran escala desarrollado por Google. Desarrollamos algunas clases contenedoras. Al utilizar estas clases contenedoras, Bigtable se puede utilizar como entrada y salida del marco MapReduce.

Bigtable se basa en varias tecnologías de Google.

Utilice GFS para almacenar archivos de registro y datos; almacene datos en el formato de archivo STable; utilice Chubby para administrar metadatos:

Bigtable se basa en varios otros componentes básicos de Google. BigTable utiliza el sistema de archivos distribuido (GFS) de Google para almacenar archivos de registro y archivos de datos. Los clústeres de BigTable normalmente se ejecutan en un grupo de máquinas compartidas, y las máquinas del grupo también ejecutarán una variedad de otras aplicaciones distribuidas. Los procesos de BigTable suelen compartir máquinas con otros procesos de aplicaciones. BigTable se basa en el sistema de administración de clústeres para programar tareas, administrar recursos en las máquinas, manejar fallas de las máquinas y monitorear el estado de las máquinas.

Los archivos utilizados para almacenar datos en BigTable están en formato SSTable de Google. SSTable es una estructura de mapa persistente, ordenada e inmutable, y Map es una estructura de datos de mapeo de valor clave. Los valores de clave y valor son cadenas de bytes arbitrarias. Internamente, una STable es una secuencia de bloques de datos (normalmente cada bloque tiene un tamaño de 64 KB, configurable). . SSTable utiliza un índice de bloque (generalmente almacenado al final de SSTable) para ubicar bloques de datos cuando se abre STable y el índice se carga en la memoria; Cada búsqueda se puede completar mediante una búsqueda en el disco: primero, use el método de búsqueda binaria para encontrar la ubicación del bloque de datos en el índice en la memoria y luego lea el bloque de datos correspondiente del disco duro. También puede optar por mantener toda la tabla en la memoria para no tener que acceder al disco duro.

BigTable también se basa en Chubby, un componente de servicio de bloqueo distribuido serializado y de alta disponibilidad. Chubby tiene cinco réplicas activas, atendidas por una sola réplica principal. La réplica es consistente con el algoritmo de Paxos. Chubby proporciona un espacio de nombres (incluidos algunos directorios y archivos), y cada directorio y archivo es un candado. Los clientes de Chubby deben permanecer hablando por teléfono con Chubby. Si la sesión del cliente expira, se pierden todos los bloqueos.

Bigtable consta de tres componentes principales: bibliotecas vinculadas a programas cliente, un servidor maestro y múltiples servidores de tabletas.

Bigtable dividirá la tabla y el tamaño de la misma permanecerá en el rango de 100-200 MB. Una vez fuera del alcance, se dividirá en trozos más pequeños o se fusionará en trozos más grandes. Cada servidor de mosaicos es responsable de una cierta cantidad de mosaicos, maneja solicitudes para leer y escribir sus mosaicos y divide o fusiona mosaicos. Los servidores de chip se pueden agregar y quitar en cualquier momento según la carga. Aquí, el servidor del chip en realidad no almacena datos, sino que es equivalente a un proxy que conecta Bigtable y GFS. Algunas operaciones de datos en el cliente acceden indirectamente a GFS a través del proxy del servidor del chip. El servidor maestro es responsable de asignar mosaicos a los servidores de mosaicos, monitorear la adición y eliminación de servidores de mosaicos, equilibrar la carga en los servidores de mosaicos y manejar la creación de tablas y familias de columnas. Tenga en cuenta que el servidor maestro no almacena ningún segmento, no proporciona ningún servicio de datos y no proporciona información de posicionamiento de los segmentos.

Cuando el cliente necesita leer y escribir datos, contacta directamente con el servidor del chip. Dado que los clientes no necesitan obtener información de ubicación de los sectores del servidor maestro, la mayoría de los clientes nunca necesitan acceder al servidor maestro, que generalmente tiene una carga más liviana.

El servidor maestro es principalmente responsable de las siguientes tareas: asignar tabletas a servidores de tabletas, detectar servidores de tabletas recién agregados o caducados, equilibrar la carga de los servidores de tabletas y enviar spam a archivos guardados en GFS Collect. Además, maneja operaciones de modificación relacionadas con esquemas, como la creación de familias de tablas y familias de columnas.

Utilizamos una estructura de tres capas similar a un árbol B+ para almacenar la información de ubicación de la tableta.

La primera capa es el archivo almacenado en Chubby, que contiene la información de ubicación de la losa raíz. Este archivo Pangdun pertenece al servicio Pangdun. Una vez que Chubby no está disponible, significa que la ubicación de la placa raíz se pierde y todo Bigtable no está disponible.

El segundo nivel es el monumento raíz. El segmento raíz es en realidad el primer segmento de la tabla de metadatos y contiene las ubicaciones de los otros segmentos de la tabla de metadatos. El monumento a la raíz es especial para mantener constante la profundidad del árbol, el monumento a la raíz nunca se divide.

La tercera capa son otros sectores de metadatos, que junto con el sector raíz forman una tabla de metadatos completa. Cada metadato contiene información de ubicación para muchos fragmentos de usuario.

Los datos cortados finalmente se escriben en GFS. La forma física de los cortes en GFS son varios archivos SSTable. La siguiente figura muestra la situación básica de las operaciones de lectura y escritura.

La relación entre BigTable y GFS

El clúster incluye un servidor principal y un servidor de chip. El servidor principal es responsable de distribuir chips al servidor de chips, y el servidor de chips solo es responsable de servicios de datos específicos. Pero no crea que el servidor del chip realmente almacena datos (excepto los datos memtables en la memoria). Solo GFS conoce la verdadera ubicación de los datos. El servidor principal asigna el chip al servidor del chip, lo que significa que el servidor del chip obtiene todos los nombres de archivos SSTable del chip. El servidor del chip puede saber en qué archivo SSTable se encuentran los datos requeridos a través de algunos mecanismos de indexación y luego leer los datos. del archivo SSTable de GFS. Estos datos pueden distribuirse en varios servidores de fragmentos.

Diagrama de estructura de tabla grande simplificado;

El diagrama de estructura toma como ejemplo la tabla Webtable, que almacena varias páginas web de NetEase, Baidu y Douban. Cuando queremos encontrar el contenido de Baidu Tieba de ayer, podemos buscar en la tabla web (com. Baidu Tieba, contenido:, ayer).

Suponiendo que el cliente no tiene caché, Bigtable accede al servidor de corte de la tableta raíz, con la esperanza de obtener la información de ubicación del segmento al que pertenece la página web. Utilice metadatos. webtable.com.baidu.tieba como clave de fila buscada en la losa raíz y ubica la última mayor que ella, que son los metadatos. webtable.com.baidu.www, por lo que se determina que se requiere el fragmento A de la tabla de metadatos. Acceda al servidor de películas de la película A, continúe buscando Webtable.com.baidu.tieba para ubicar Webtable.com.baidu.www y determine la película B que requiere la tabla Webtable. Acceda al servidor de chip del chip B para obtener datos.

Lo que hay que tener en cuenta aquí es que cada segmento en realidad se compone de varios archivos SSTable y memtables, y estos SSTables y memtables están ordenados. Esto da como resultado que al buscar la pieza B, puede ser necesario buscar en todas las STables y memtables. Además, el cliente no debe obtener directamente el nombre del archivo SSTable de la tabla de metadatos, sino que solo debe obtener la información de la pieza. pertenece al servidor de piezas y lo pasa a través del servidor de piezas como acceso del Agente SSTable.