Solución:
Mesa grande
Un sistema de almacenamiento distribuido para datos estructurados
Bigtable es un sistema de almacenamiento distribuido (creado por Google) para administrar datos estructurados que está diseñado para escalar a un tamaño muy grande: petabytes de datos en miles de servidores básicos.
Muchos proyectos de Google almacenan datos en Bigtable, incluida la indexación web, Google Earth y Google Finance. Estas aplicaciones imponen demandas muy diferentes a Bigtable, tanto en términos de tamaño de los datos (desde URL hasta páginas web e imágenes satelitales) como requisitos de latencia (desde el procesamiento masivo de backend hasta el servicio de datos en tiempo real).
A pesar de estas variadas demandas, Bigtable ha proporcionado con éxito una solución flexible y de alto rendimiento para todos estos productos de Google.
Algunas caracteristicas
- DBMS rápido y de gran escala
- un mapa ordenado multidimensional, disperso y distribuido, que comparte características de bases de datos orientadas tanto a filas como a columnas.
- diseñado para escalar en el rango de petabytes
- funciona en cientos o miles de máquinas
- es fácil agregar más máquinas al sistema y comenzar automáticamente a aprovechar esos recursos sin ninguna reconfiguración
- cada tabla tiene varias dimensiones (una de las cuales es un campo para el tiempo, lo que permite el control de versiones)
- Las tablas están optimizadas para GFS (Google File System) al dividirse en varias tabletas: los segmentos de la tabla se dividen a lo largo de una fila elegida de modo que la tableta tenga un tamaño de ~ 200 megabytes.
Arquitectura
BigTable no es una base de datos relacional. No admite combinaciones ni admite consultas de tipo SQL enriquecidas. Cada tabla es un mapa disperso multidimensional. Las tablas constan de filas y columnas, y cada celda tiene una marca de tiempo. Puede haber varias versiones de una celda con diferentes marcas de tiempo. La marca de tiempo permite operaciones como “seleccionar ‘n’ versiones de esta página web” o “eliminar celdas que sean más antiguas que una fecha / hora específica”.
Para administrar las tablas enormes, Bigtable divide las tablas en los límites de las filas y las guarda como tabletas. Una tableta tiene alrededor de 200 MB y cada máquina ahorra alrededor de 100 tabletas. Esta configuración permite que las tabletas de una sola mesa se distribuyan entre muchos servidores. También permite un equilibrio de carga detallado. Si una mesa recibe muchas consultas, puede deshacerse de otras tabletas o mover la mesa ocupada a otra máquina que no esté tan ocupada. Además, si una máquina deja de funcionar, una tableta puede estar distribuida en muchos otros servidores, por lo que el impacto en el rendimiento de cualquier máquina determinada es mínimo.
Las tablas se almacenan como SSTables inmutables y una cola de registros (un registro por máquina). Cuando una máquina se queda sin memoria del sistema, comprime algunas tabletas utilizando técnicas de compresión propietarias de Google (BMDiff y Zippy). Las compactaciones menores involucran solo unas pocas tabletas, mientras que las compactaciones mayores involucran todo el sistema de tablas y recuperan espacio en el disco duro.
Las ubicaciones de las tabletas Bigtable se almacenan en celdas. La búsqueda de cualquier tableta en particular se realiza mediante un sistema de tres niveles. Los clientes obtienen un punto para una tabla META0, de la cual solo hay una. La tabla META0 realiza un seguimiento de muchas tabletas META1 que contienen las ubicaciones de las tabletas que se buscan. Tanto META0 como META1 hacen un uso intensivo de la búsqueda previa y el almacenamiento en caché para minimizar los cuellos de botella en el sistema.
Implementación
BigTable se basa en Sistema de archivos de Google (GFS), que se utiliza como almacén de respaldo para archivos de registro y datos. GFS proporciona almacenamiento confiable para SSTables, un formato de archivo propiedad de Google que se utiliza para conservar los datos de la tabla.
Otro servicio del que BigTable hace un uso intensivo es Regordete, un servicio de bloqueo distribuido confiable y de alta disponibilidad. Chubby permite a los clientes tomar un candado, posiblemente asociándolo con algunos metadatos, que puede renovar enviando mensajes de mantener vivo a Chubby. Los bloqueos se almacenan en una estructura de nombres jerárquica similar a un sistema de archivos.
Hay tres primarios tipos de servidor de interés en el sistema Bigtable:
- Servidores maestros: asigna tabletas a servidores de tabletas, realiza un seguimiento de dónde se encuentran las tabletas y redistribuye las tareas según sea necesario.
- Servidores de tableta: manejan solicitudes de lectura / escritura para tabletas y tabletas divididas cuando exceden los límites de tamaño (generalmente 100 MB – 200 MB). Si un servidor de tableta falla, entonces 100 servidores de tableta cada uno recogen 1 tableta nueva y el sistema se recupera.
- Servidores de bloqueo: instancias del servicio de bloqueo distribuido de Chubby. Muchas acciones dentro de BigTable requieren la adquisición de bloqueos, incluida la apertura de tabletas para escribir, garantizar que no haya más de un maestro activo a la vez y la verificación del control de acceso.
Ejemplo del trabajo de investigación de Google:
Un segmento de una tabla de ejemplo que almacena páginas web. El nombre de la fila es un
URL invertida. La familia de columnas de contenido contiene el contenido de la página, y la familia de columnas de anclaje contiene el
texto de cualquier ancla que hacen referencia a la página. Tanto Sports Illustrated como MY-look hacen referencia a la página de inicio de CNN, por lo que la fila contiene columnas denominadas
anchor:cnnsi.comy
anchor:my.look.ca. Cada celda de anclaje tiene una versión; la columna de contenido tiene tres versiones, en marcas de tiempo
t3,t5, yt6.
API
Las operaciones típicas de BigTable son la creación y eliminación de tablas y familias de columnas, la escritura de datos y la eliminación de columnas de una fila. BigTable proporciona estas funciones a los desarrolladores de aplicaciones en una API. Las transacciones se admiten en el nivel de fila, pero no en varias claves de fila.
Aquí está el enlace al PDF del trabajo de investigación.
Y aquí puede encontrar un video que muestra a Jeff Dean de Google en una conferencia en la Universidad de Washington, discutiendo el sistema de almacenamiento de contenido Bigtable utilizado en el backend de Google.
Es algo que han construido ellos mismos, se llama Bigtable.
http://en.wikipedia.org/wiki/BigTable
Hay un documento de Google sobre la base de datos:
http://research.google.com/archive/bigtable.html
Spanner es el sistema de administración de bases de datos relacionales (RDBMS) distribuido globalmente de Google, el sucesor de BigTable. Google afirma que no es un sistema relacional puro porque cada tabla debe tener una clave principal.
Aquí está el enlace del artículo.
Spanner es la base de datos escalable, de múltiples versiones, distribuida globalmente y replicada sincrónicamente de Google. Es el primer sistema que distribuye datos a escala global y admite transacciones distribuidas con coherencia externa. Este documento describe cómo está estructurado Spanner, su conjunto de características, el fundamento que subyace a varias decisiones de diseño y una API de tiempo novedosa que expone la incertidumbre del reloj. Esta API y su implementación son fundamentales para admitir la coherencia externa y una variedad de funciones potentes: lecturas sin bloqueo en el pasado, transacciones de solo lectura sin bloqueo y cambios de esquema atómico en todo Spanner.
Otra base de datos inventada por Google es Megastore. Aquí está el resumen:
Megastore es un sistema de almacenamiento desarrollado para cumplir con los requisitos de los servicios interactivos en línea actuales. Megastore combina la escalabilidad de un almacén de datos NoSQL con la conveniencia de un RDBMS tradicional de una manera novedosa y proporciona tanto garantías de coherencia sólidas como alta disponibilidad. Proporcionamos semántica ACID completamente serializable dentro de particiones de datos de grano fino. Esta partición nos permite replicar de forma sincrónica cada escritura en una red de área amplia con una latencia razonable y admitir una conmutación por error sin problemas entre centros de datos. Este artículo describe la semántica y el algoritmo de replicación de Megastore. También describe nuestra experiencia en el apoyo a una amplia gama de servicios de producción de Google creados con Megastore.