Bigtable es un servicio de base de datos NoSQL de valores clave y columnas anchas totalmente administrado para grandes cargas de trabajo analíticas y operativas como parte de la cartera de Google Cloud .
El desarrollo de Bigtable comenzó en 2004. [1] Ahora lo utilizan varias aplicaciones de Google, como Google Analytics , [2] indexación web, [3] MapReduce , que a menudo se utiliza para generar y modificar datos almacenados en Bigtable, [4] Google Maps , [5] búsqueda de Google Books , "Mi historial de búsqueda", Google Earth , Blogger.com , alojamiento de Google Code , YouTube , [6] y Gmail . [7] Las razones de Google para desarrollar su propia base de datos incluyen escalabilidad y un mejor control de las características de rendimiento. [8]
Google F1 se creó utilizando Spanner para reemplazar una implementación basada en MySQL . [9]
Apache HBase y Cassandra son algunos de los proyectos de código abierto más conocidos que se inspiraron en Bigtable.
El 6 de mayo de 2015, se puso a disposición una versión pública de Bigtable como parte de Google Cloud con el nombre Cloud Bigtable. [2]
A partir de enero de 2022, Bigtable administra más de 10 exabytes de datos y atiende más de 5 mil millones de solicitudes por segundo. [10] El 27 de enero de 2022, Google anunció una serie de actualizaciones para Bigtable, incluida la escalabilidad automatizada. [11]
Bigtable es uno de los ejemplos prototípicos de un almacén de columnas anchas . Asigna dos valores de cadena arbitrarios (clave de fila y clave de columna) y marca de tiempo (de ahí el mapeo tridimensional) a una matriz de bytes arbitraria asociada. No es una base de datos relacional y se puede definir mejor como un mapa ordenado multidimensional, distribuido y disperso. [3] : 1 Está construido sobre Colossus ( sistema de archivos de Google ), Chubby Lock Service , SSTable (almacenamiento estructurado en registros como LevelDB ) y algunas otras tecnologías de Google . Bigtable está diseñado para escalar en el rango de petabytes en "cientos o miles de máquinas, y para facilitar la adición de más máquinas [al] sistema y comenzar automáticamente a aprovechar esos recursos sin ninguna reconfiguración". [12] Por ejemplo, la copia de Google de la web se puede almacenar en una bigtable donde la clave de fila es una URL de dominio invertido , y las columnas describen varias propiedades de una página web, con una columna en particular que contiene la página en sí. La columna de página puede tener varias versiones con marca de tiempo que describen diferentes copias de la página web con marca de tiempo según el momento en que se obtuvieron. Cada celda de una tabla grande puede tener cero o más versiones con marca de tiempo de los datos. Otra función de la marca de tiempo es permitir tanto el control de versiones como la recolección de basura de datos vencidos.
Las tablas se dividen en varias tabletas : los segmentos de la tabla se dividen en ciertas claves de fila para que cada tableta tenga un tamaño de unos pocos cientos de megabytes o unos pocos gigabytes. Una tabla grande es algo así como un grupo de trabajadores de mapreduce en el que miles a cientos de miles de fragmentos de tabletas pueden ser atendidos por cientos a miles de servidores BigTable. Cuando el tamaño de la tabla amenaza con crecer más allá de un límite especificado, las tabletas pueden comprimirse utilizando el algoritmo BMDiff [13] [14] y el algoritmo de compresión Zippy [15] conocido públicamente y de código abierto como Snappy , [16] que es una variación menos óptima en términos de espacio de LZ77 pero más eficiente en términos de tiempo de cómputo. Las ubicaciones en el GFS de las tabletas se registran como entradas de base de datos en múltiples tabletas especiales, que se denominan tabletas "META1". Las tabletas META1 se encuentran consultando la tableta "META0", que normalmente reside en un servidor propio, ya que los clientes suelen consultarle la ubicación de la tableta "META1", que tiene la respuesta a la pregunta de dónde se encuentran los datos reales. Al igual que el servidor maestro de GFS, el servidor META0 no suele ser un cuello de botella , ya que el tiempo de procesador y el ancho de banda necesarios para descubrir y transmitir las ubicaciones de META1 son mínimos y los clientes almacenan en caché las ubicaciones de forma agresiva para minimizar las consultas.
Primero, una descripción general. Bigtable ha estado en desarrollo desde principios de 2004 y ha estado en uso activo durante aproximadamente ocho meses (aproximadamente febrero de 2005)..
Actualmente hay alrededor de 100 celdas para servicios como Imprimir, Historial de búsqueda, Mapas y Orkut..
Su nueva solución para las miniaturas es utilizar Bigtable de Google, que proporciona un alto rendimiento para una gran cantidad de filas, tolerancia a fallos, almacenamiento en caché, etc. Este es un buen (¿y raro?) ejemplo de sinergia real en una adquisición..
Hemos trasladado un conjunto de aplicaciones grande y crítico de MySQL a F1
{{citation}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace ).