CockroachDB: La guía definitiva

Capítulo 1. Introducción a CockroachDB

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

CockroachDB es un sistema de base de datos SQL distribuido, transaccional, relacional y nativo de la nube. ¡Eso sí que es un trabalenguas! Pero en pocas palabras, CockroachDB aprovecha tanto los puntos fuertes de la generación anterior de sistemas de bases de datos relacionales -fuerte consistencia, la potencia de SQL y el modelo de datos relacional- como los puntos fuertes de los principios modernos de la nube distribuida. El resultado es un sistema de base de datos ampliamente compatible con otras bases de datos transaccionales basadas en SQL, pero que ofrece una escalabilidad y disponibilidad mucho mayores.

En este capítulo, repasaremos la historia de los sistemas de gestión de bases de datos (SGBD) y descubriremos cómo CockroachDB aprovecha los avances tecnológicos de las últimas décadas para cumplir sus ambiciosos objetivos.

Breve historia de las bases de datos

El almacenamiento y el procesamiento de datos son las "aplicaciones asesinas" de la civilización humana. El lenguaje verbal nos proporcionó una enorme ventaja a la hora de cooperar como comunidad. Sin embargo, sólo cuando desarrollamos el almacenamiento de datos -por ejemplo, el lenguaje escrito- cada generación pudo aprovechar las lecciones de las generaciones precedentes.

Los registros escritos más antiguos -que datan de hace casi 10.000 años- son los registros contables agrícolas. Estos registros cuneiformes, grabados en tablillas de arcilla(Figura 1-1), tienen la misma finalidad que las bases de datos que soportan los sistemas contables modernos.

Las tecnologías de almacenamiento de la información progresaron lentamente durante miles de años. El uso de soportes de papel baratos, portátiles y razonablemente duraderos, organizados en bibliotecas y armarios, representó las buenas prácticas durante casi un milenio.

Figura 1-1. Tablilla cuneiforme hacia el año 3000 a.C. (Fuente: Wikipedia)

La aparición del procesamiento digital de datos ha supuesto una auténtica revolución de la información. En el transcurso de una sola vida humana, los sistemas de información digital han dado lugar a un crecimiento exponencial del volumen y la velocidad de almacenamiento de la información. Hoy en día, la mayor parte de la información humana se almacena en formatos digitales, gran parte de ella en sistemas de bases de datos.

Bases de datos prerrelacionales

Los primeros ordenadores digitales tenían una capacidad de almacenamiento insignificante y se utilizaban principalmente para el cálculo: por ejemplo, para generar tablas balísticas, descifrar códigos y realizar cálculos científicos. Sin embargo, con la generalización de las cintas y discos magnéticos en los años 50, cada vez fue más posible utilizar los ordenadores para almacenar y procesar volúmenes de información que serían difíciles de manejar por otros medios.

Las primeras aplicaciones utilizaban simples archivos planos para almacenar datos. Pero pronto se hizo evidente que la complejidad de tratar de forma fiable y eficaz grandes cantidades de datos requería plataformas de software especializadas y dedicadas, y éstas se convirtieron en los primeros sistemas de datos.

Los primeros sistemas de bases de datos se ejecutaban en ordenadores centrales monolíticos, que también eran responsables del código de las aplicaciones. Las aplicaciones estaban estrechamente acopladas a los sistemas de bases de datos y procesaban los datos directamente mediante directivas de lenguaje procedimental. En la década de 1970, dos modelos de sistemas de bases de datos se disputaban el dominio: el modelo de red y el modelo jerárquico. Estos modelos estaban representados por las principales bases de datos de la época, IMS (Sistema de Gestión de la Información) e IDMS (Sistema Integrado de Gestión de Bases de Datos).

Estos sistemas suponían un gran avance respecto a sus predecesores, pero tenían importantes inconvenientes. Las consultas debían anticiparse a la implementación, y sólo se admitía el procesamiento de registros a la vez. Hasta el informe más sencillo requería recursos de programación para su implementación, y todos los departamentos de TI sufrían un enorme retraso en las solicitudes de informes.

El modelo relacional

Probablemente nadie haya tenido más influencia en sobre la tecnología de las bases de datos que Edgar Codd (piense lo que piense Larry Ellison). Codd era un "matemático programador" -lo que hoy llamaríamos un científico de datos- que había trabajado en IBM de forma intermitente desde 1949. En 1970, Codd escribió su artículo fundamental, "Un modelo relacional de datos para grandes bancos de datos compartidos". En él exponía lo que Codd consideraba problemas fundamentales en el diseño de los sistemas de bases de datos existentes:

• Los sistemas de bases de datos existentes fusionaban las representaciones físicas y lógicas de los datos de un modo que a menudo complicaba las peticiones de datos y creaba dificultades para satisfacer peticiones que no se habían previsto durante el diseño de la base de datos.

• No existía una norma formal para la representación de datos. Como matemático, Codd estaba familiarizado con los modelos teóricos de representación de datos y creía que estos principios debían aplicarse a los sistemas de bases de datos.

• Los sistemas de bases de datos existentes eran demasiado difíciles de utilizar. Sólo los programadores podían recuperar datos de estos sistemas, y el proceso de recuperación de datos era innecesariamente complejo. Codd pensaba que tenía que haber un método de fácil acceso para recuperar datos.

El modelo relacional de Codd describía un medio de representar lógicamente los datos que era independiente del mecanismo de almacenamiento subyacente. Requería un lenguaje de consulta que pudiera utilizarse para responder a cualquier pregunta que pudieran satisfacer los datos.

El modelo relacional define los componentes fundamentales de una base de datos relacional:

• Las tuplas son un conjunto de valores de atributos. Los atributos se denominan valores escalares (unidimensionales). Una tupla puede considerarse como un "registro" o "fila" individual.

• Una relación es una colección de tuplas distintas de la misma forma. Una relación representa un conjunto de datos bidimensional con un número fijo de atributos y un número arbitrario de tuplas. Una tabla de una base de datos es un ejemplo de relación.

• Las restricciones refuerzan la coherencia y definen las relaciones entre tuplas.

• Se definen varias operaciones, como como uniones, proyecciones y uniones. Las operaciones sobre relaciones siempre devuelven relaciones. Por ejemplo, cuando unes dos relaciones, el resultado es a su vez una relación.

• Una clave consiste en uno o más atributos que pueden utilizarse para identificar una tupla. Puede haber más de una clave, y una clave puede constar de varios atributos.

Además, el modelo relacional define una serie de "formas normales" que representan niveles decrecientes de redundancia en el modelo. Una relación está en tercera forma normal si todos los datos de cada tupla dependen de la clave primaria completa de esa tupla y de ningún otro atributo. Generalmente recordamos esto con el adagio: "La clave, toda la clave y nada más que la clave (así que ayúdame, Codd)".

La tercera forma normal representa generalmente el punto de partida para la construcción de un modelo de datos eficiente y eficaz. Volveremos sobre la tercera forma normal en el Capítulo 5. La Figura 1-2 ilustra datos en tercera forma normal.

Figura 1-2. Datos representados en una estructura relacional de "tercera forma normal".

Aplicación del modelo relacional

El modelo relacional sirvió de base para las estructuras familiares presentes en todas las bases de datos relacionales actuales. Las tuplas se representan como filas y las relaciones como tablas.

Una tabla es una relación a la que se ha dotado de almacenamiento físico. El almacenamiento subyacente puede adoptar distintas formas. Además de la representación física de los datos, se introdujeron esquemas de indexación y agrupación para facilitar el tratamiento eficaz de los datos y aplicar restricciones.

Los índices y el almacenamiento agrupado no formaban parte del modelo relacional, pero se incorporaron a las bases de datos relacionales para mejorar de forma transparente el rendimiento de las consultas sin cambiar los tipos de consultas que podían realizarse. Así, la representación lógica de los datos tal y como se presentaban a la aplicación era independiente del modelo físico subyacente.

De hecho, en algunas implementaciones relacionales, una tabla puede estar implementada por múltiples estructuras indexadas, permitiendo diferentes rutas de acceso a los datos.

Transacciones

Una transacción es una unidad lógica de trabajo que debe tener éxito o fracasar como una unidad. Las transacciones son anteriores al modelo relacional, pero en los sistemas prerrelacionales, las transacciones solían ser responsabilidad de la capa de aplicación. En el modelo relacional de Codd, la base de datos asumió la responsabilidad formal del procesamiento transaccional.¹ En la formulación de Codd, un sistema relacional proporcionaría soporte explícito para iniciar una transacción y confirmarla o cancelarla.

El uso de transacciones para mantener la coherencia en los datos de la aplicación también se utilizaba internamente para mantener la coherencia entre las distintas estructuras físicas que representaban las tablas. Por ejemplo, cuando una tabla se representa en varios índices, todos esos índices deben mantenerse sincronizados de forma transaccional.

El modelo relacional de Codd no definía todos los aspectos delcomportamiento transaccionalque se hicieron comunes a la mayoría de los sistemas de bases de datos relacionales. En 1981, Jim Gray articuló los principios básicos del procesamiento de transacciones que seguimos utilizando hoy en día. Estos principios se conocieron posteriormente en comotransacciones ACID -atómicas, consistentes, aisladas y duraderas-.

En palabras de Gray: "Una transacción es una transformación de estado que tiene las propiedades de atomicidad (todo o nada), durabilidad (los efectos sobreviven a los fallos) y consistencia (una transformación correcta)". El principio de aislamientode -añadidoen una revisión posterior- exigía que una transacción no pudiera ver los efectos de otrastransacciones en curso.

El aislamiento perfecto entre transacciones -aislamiento serializable- crea algunas restricciones en el procesamiento concurrente de datos. Muchas bases de datos adoptaron niveles inferiores de aislamiento o permitieron a las aplicaciones elegir entre varios niveles de aislamiento. Estas implicaciones se tratarán con más detalle en el Capítulo 2.

El lenguaje SQL

Codd especificó que un sistema relacional debía soportar un "sublenguaje de base de datos" para navegar y modificar datos relacionales. Propuso el lenguaje Alpha en 1971, que influyó en el lenguaje QUEL diseñado por los creadores de Ingres -un primer sistema de base de datos relacional desarrollado en la Universidad de California, que influyó en la base de datos de código abierto PostgreSQL.

Mientras tanto, los investigadores de IBM estaban desarrollando System R, un prototipo de SGBD basado en el modelo relacional de Codd. En desarrollaron el lenguaje SEQUEL como sublenguaje de datos para el proyecto. Con el tiempo, SEQUEL pasó a llamarse SQL y se adoptó en las bases de datos comerciales de IBM, incluida IBM DB2.

Oracle eligió SQL como el lenguaje de consulta para su pionero sistema de gestión de bases de datos relacionales (SGBDR) Oracle, y a finales de los años 70, SQL se había impuesto a QUEL como lenguaje de consulta relacional y se convirtió en lenguaje estándar ANSI (Instituto Nacional de Normalización Estadounidense) en 1986.

SQL necesita muy poca presentación. Hoy en día, es uno de los lenguajes informáticos más utilizados del mundo. Dedicaremos el Capítulo 4 a la implementación de SQL en CockroachDB. Sin embargo, merece la pena señalar que la relativa facilidad de uso que proporcionó SQL amplió drásticamente el público de usuarios de bases de datos. Ya no era necesario ser un programador de bases de datos muy experimentado para recuperar datos de una base de datos: SQL podía enseñarse a usuarios ocasionales de bases de datos, como analistas y estadísticos. Es justo decir que SQL puso las bases de datos al alcance de los usuarios empresariales.

La hegemonía de los RDBMS

La combinación del modelo relacional, el lenguaje SQL y las transacciones ACID se convirtió en el modelo dominante para los nuevos sistemas de bases de datos desde principios de los 80 hasta principios de los 2000. Estos sistemas pasaron a conocerse genéricamente como RDBMS.

El RDBMS surgió más o menos al mismo tiempo que un cambio sísmico de paradigma en las arquitecturas de las aplicaciones. El mundo de las aplicaciones mainframe estaba dando paso al modelo cliente/servidor. En el modelo cliente/servidor, el código de la aplicación se ejecutaba en microordenadores (PC), mientras que la base de datos se ejecutaba en un miniordenador, cada vez más con el sistema operativo Unix. Durante la migración a cliente/servidor, las bases de datos prerrelacionales basadas en mainframe se abandonaron en gran medida en favor de la nueva generación de RDBMS.

A finales del siglo XX, el RDBMS reinaba supremo. Las principales bases de datos comerciales de la época -Oracle, Sybase, SQL Server, Informix y DB2- competían en rendimiento, funcionalidad o precio, pero todas eran prácticamente idénticas en su adopción del modelo relacional, SQL y las transacciones ACID. A medida que crecía la popularidad del software de código abierto, los sistemas de gestión de bases de datos relacionales de código abierto, como MySQL y PostgreSQL, ganaron una importante y una tracción cada vez mayor.

Entra en Internet

A principios del siglo XXI se produjo un cambio aún más importante en las arquitecturas de las aplicaciones: . Ese cambio fue, por supuesto, Internet. Al principio, las aplicaciones de Internet se ejecutaban en una pila de software similar a la de una aplicación cliente/servidor. Un único gran servidor albergaba la base de datos de la aplicación, mientras que el código de la aplicación se ejecutaba en un servidor de "nivel intermedio" y los usuarios finales interactuaban con la aplicación a través de navegadores web.

En los primeros tiempos de Internet, esta arquitectura era suficiente, aunque a menudo a duras penas. Los servidores de bases de datos monolíticos eran a menudo un cuello de botella para el rendimiento, y aunque se implementaban habitualmente bases de datos en espera, el fallo de una base de datos era una de las causas más comunes de fallo de la aplicación.

A medida que la web crecía, las limitaciones del RDBMS centralizado se hicieron insostenibles. La emergente red social "web 2.0" y los sitios de comercio electrónico tenían dos características cada vez más difíciles de soportar:

• Estos sistemas tenían una escala global o casi global. Los usuarios de varios continentes necesitaban acceder simultáneamente a la aplicación.

• Cualquier nivel de tiempo de inactividad era indeseable. El antiguo modelo de "actualizaciones de fin de semana" ya no era aceptable. No había ninguna ventana de mantenimiento que no supusiera una interrupción significativa del negocio.

Todas las partes estaban de acuerdo en que el sistema monolítico de base de datos única tendría que ceder si se querían satisfacer las demandas de la nueva generación de aplicaciones de Internet. Se reconoció que un obstáculo muy importante y potencialmente inamovible se interponía en el camino: El teorema CAP -o de Brewer-afirma que sólo se pueden tener como máximo dos de las tres características deseables en un sistema distribuido (ilustrado en la Figura 1-3):

Coherencia

Todos los usuarios ven la misma vista del estado de la base de datos.

Disponibilidad

La base de datos sigue disponible a menos que fallen todos los elementos del sistema distribuido.

Tolerancia de partición

El sistema funciona en un entorno en el que una partición de la red puede dividir en dos el sistema distribuido, o si dos nodos de la red no pueden comunicarse. Un sistema tolerante a la partición seguirá funcionando a pesar de que la red deje caer (o retrase) un número arbitrario de mensajes entre nodos.

Figura 1-3. El teorema CAP afirma que un sistema no puede soportar las tres propiedades de consistencia, disponibilidad y tolerancia a la partición

Por ejemplo, considera el caso de un sistema global de comercio electrónico con usuarios en Norteamérica y Europa. Si falla la red entre los dos continentes (una partición de red), debes elegir uno de los siguientes resultados:

• Los usuarios de Europa y Norteamérica pueden ver versiones diferentes de la base de datos: sacrificando la coherencia.

• Una de las dos regiones tiene que apagarse (o pasar a ser de sólo lectura): sacrificando ladisponibilidad.

Los RDBMS en clúster en ese momento sacrificarían generalmente la disponibilidad. Por ejemplo, en la base de datos en clúster Real Application Clusters (RAC) de Oracle, una partición de red entre nodos provocaría la parada de todos los nodos de una de las particiones.

Sin embargo, los pioneros de Internet, como Amazon, creían que la disponibilidad era más importante que la consistencia estricta. Amazon desarrolló un sistema de base de datos -Dynamo-que implementaba la "consistencia eventual". En el caso de una partición, todas las zonas seguirían teniendo acceso al sistema, pero cuando se resolviera la partición, las incoherencias se reconciliarían -posiblemente perdiendo datos en el proceso.

El movimiento NoSQL

Entre 2008 y 2010, surgieron docenas de nuevos sistemas de bases de datos , todos los cuales abandonaron los tres pilares del RDBMS: el modelo de datos relacional, el lenguaje SQL y las transacciones ACID. Algunos de estos nuevos sistemas -Cassandra, Riak, Project Voldemort y HBase, por ejemplo- estaban directamente influidos por tecnologías no relacionales desarrolladas en Amazon y Google.

Muchos de estos sistemas eran esencialmente "sin esquema", es decir, no admitían o incluso no exigían ninguna estructura específica para los datos que almacenaban. En concreto, en las bases de datos clave-valor, una clave arbitraria proporciona acceso programático a un "valor" estructurado arbitrario. La base de datos no sabe nada de lo que contiene este valor. Desde el punto de vista de la base de datos, el valor es sólo un conjunto de bits no estructurados. Otros sistemas no relacionales representaban los datos en formatos semi-tabulares o como documentos JSON (JavaScript Object Notation). Sin embargo, ninguna de estas nuevas bases de datos aplicaba los principios del modelo relacional.

Estos sistemas se denominaron inicialmente sistemas de bases de datos no relacionales distribuidas (DNRDBMS), pero -como no incluían el lenguaje SQL- rápidamente se conocieron con el término mucho más pegadizo de bases de datos "NoSQL".

NoSQL siempre fue un término cuestionable. Definía lo que la clase de sistemas descartaba, en lugar de sus características distintivas únicas. Sin embargo, "NoSQL" se mantuvo, y en la década siguiente, bases de datos NoSQL como Cassandra, DynamoDB y MongoDB se establecieron como un segmento distinto e importante del panorama de las bases de datos.

La aparición del SQL distribuido

Los retos de implementar transacciones distribuidas en a escala web, más que ninguna otra cosa, provocaron el cisma de los sistemas modernos de gestión de bases de datos. Con el auge de las aplicaciones globales con requisitos de tiempo de actividad extremadamente altos, se hizo impensable sacrificar la disponibilidad por una consistencia perfecta. Casi al unísono, las principales empresas de la web 2.0, como Amazon, Google y Facebook, introdujeron nuevos servicios de bases de datos que sólo eran "eventual" o "débilmente" consistentes, pero global y altamente disponibles, y la comunidad de código abierto respondió con bases de datos basadas en estos principios.

Sin embargo, las bases de datos NoSQL tenían sus propias y graves limitaciones. El lenguaje SQL era ampliamente conocido y constituía la base de casi todas las herramientas de inteligencia empresarial. Las bases de datos NoSQL se dieron cuenta de que tenían que ofrecer cierta compatibilidad con SQL, por lo que muchas añadieron algún dialecto similar a SQL, lo que llevó a la redefinición de NoSQL como "no sólo SQL". En muchos casos, estas implementaciones de SQL eran sólo de consulta y estaban pensadas únicamente para soportar funciones de inteligencia empresarial. En otros casos, un lenguaje similar a SQL admitía el procesamiento transaccional, pero sólo proporcionaba el subconjunto más limitado de funciones SQL.

Sin embargo, los problemas causados por una consistencia debilitada eran más difíciles de ignorar. La coherencia y la corrección de los datos suelen ser innegociables para las aplicaciones de misión crítica. Mientras que en algunas circunstancias -las redes sociales, por ejemplo- puede ser aceptable que distintos usuarios vean puntos de vista ligeramente diferentes del mismo tema, en otros contextos -como la logística- cualquier incoherencia es inaceptable. Las bases de datos no relacionales avanzadas adoptaron la coherencia sintonizable y sofisticados algoritmos de resolución de conflictos para mitigar la incoherencia de los datos. Sin embargo, cualquier base de datos que abandone la coherencia estricta debe aceptar escenarios en los que los datos pueden perderse o corromperse durante la reconciliación de particiones de la red o portransacciones que compiten en el tiempo de forma ambigua.

Google fue pionero en muchas de las tecnologías que hay detrás de importantes sistemas NoSQL de código abierto. Por ejemplo, las tecnologías Google File System y MapReduce condujeron directamente a Apache Hadoop, y Google Bigtable condujo a Apache HBase. Como tal, Google era muy consciente de las limitaciones de estos nuevos almacenes de datos.

El proyecto Spanner se inició en como un intento de construir una base de datos distribuida, similar al actual sistema Bigtable de Google, que pudiera soportar tanto una fuerte consistencia como una alta disponibilidad.

Spanner se beneficiaba de la red altamente redundante de Google, que reducía la probabilidad de problemas de disponibilidad basados en la red, pero la característica realmente novedosa de Spanner era su sistema TrueTime. TrueTime modela explícitamente la incertidumbre de la medición del tiempo en un sistema distribuido, de modo que pueda incorporarse al protocolo de transacciones. Las bases de datos distribuidas se esfuerzan mucho por devolver información coherente de las réplicas mantenidas en todo el sistema. Los bloqueos son el principal mecanismo para evitar que se cree información incoherente en la base de datos, mientras que las instantáneas son el principal mecanismo para devolver información coherente. Las consultas no ven los cambios en los datos que se producen mientras se ejecutan, porque leen de una "instantánea" coherente de los datos. Mantener instantáneas en bases de datos distribuidas puede ser complicado: normalmente, se requiere una gran cantidad de comunicación entre nodos para llegar a un acuerdo sobre el orden de las transacciones y las consultas. La información del reloj proporcionada por TrueTime permite utilizar instantáneas con una comunicación mínima entre nodos.

Google Spanner optimiza aún más el mecanismo de instantáneas utilizando receptores GPS y relojes atómicos instalados en cada centro de datos. El GPS proporciona una marca de tiempo validada externamente, mientras que el reloj atómico proporciona tiempo de alta resolución entre las "fijaciones" del GPS. El resultado es que todos los servidores Spanner del mundo tienen casi la misma hora de reloj. Esto permite a Spanner ordenar las transacciones y consultas con precisión, sin requerir una excesiva comunicación entre nodos ni retrasos debidos a una excesiva incertidumbre del reloj.

Nota

Spanner depende en gran medida de la red redundante de Google y del hardware especializado del servidor. Spanner no puede funcionar independientemente de la red de Google.

La versión inicial de Spanner llevó los límites del teorema CAP tan lejos como permitía la tecnología. Representaba un sistema de base de datos distribuido en el que se garantizaba la coherencia, se maximizaba la disponibilidad y se evitaban las particiones de red en la medida de lo posible. Con el tiempo, Google añadió funciones relacionales al modelo de datos de Spanner, así como compatibilidad con el lenguaje SQL. En 2017, Spanner había evolucionado hasta convertirse en una base de datos distribuida compatible con los tres pilares del RDBMS: el lenguaje SQL, el modelo de datos relacional y las transacciones ACID.

El advenimiento de CockroachDB

Con Spanner, Google demostró persuasivamente la utilidad de una base de datos distribuida altamente consistente. Sin embargo, Spanner estaba estrechamente vinculada a Google Cloud Platform (GCP) y, al menos al principio, no estaba disponible públicamente.

Había una necesidad evidente de que las tecnologías desarrolladas por Spanner estuvieran más disponibles. En 2015, un trío de antiguos alumnos de Google -Spencer Kimball, Peter Mattis y Ben Darnell- fundaron Cockroach Labs con la intención de crear una base de datos de código abierto, geoescalable y compatible con ACID.

Spencer, Peter y Ben eligieron el nombre "CockroachDB" en honor a la humilde cucaracha, que, según cuentan, es tan resistente que sobreviviría incluso a una guerra nuclear(Figura 1-4).

Figura 1-4. El logotipo original de CockroachDB

Objetivos de diseño de CockroachDB

CockroachDB se diseñó para soportar los siguientes atributos:

Escalabilidad

La arquitectura distribuida de CockroachDB permite que un clúster escale sin problemas a medida que aumenta o disminuye la carga de trabajo. Se pueden añadir nodos a un clúster sin ningún reequilibrio manual, y el rendimiento se escalará de forma predecible a medida que aumente el número de nodos.

Alta disponibilidad

Un clúster CockroachDB no tiene ningún punto único de fallo. CockroachDB puede seguir funcionando si falla un nodo, zona o región sin comprometer la disponibilidad.

Coherencia

CockroachDB proporciona el más alto nivel práctico de aislamiento y consistencia transaccional. Las transacciones funcionan independientemente unas de otras y, una vez confirmadas, se garantiza que sean duraderas y visibles para todas las sesiones.

Rendimiento

La arquitectura de CockroachDB está diseñada para soportar cargas de trabajo transaccionales de baja latencia y alto rendimiento en . Se ha hecho todo lo posible por adoptar las buenas prácticas de bases de datos en lo que respecta a indexación, almacenamiento en caché y otras estrategias de optimización de bases de datos.

Geo-partición

CockroachDB permite que los datos se ubiquen físicamente en localidades específicas para mejorar el rendimiento de las aplicaciones "localizadas" y respetarlos requisitos de soberanía de datos.

Compatibilidad

CockroachDB implementa SQL estándar ANSI y es compatible con PostgreSQL mediante el protocolo wire. Esto significa que la mayoría de los controladores y marcos de bases de datos que funcionan con PostgreSQL también funcionarán con CockroachDB. Muchas aplicaciones PostgreSQL pueden portarse a CockroachDB sin necesidad de cambios significativos en la codificación.

Portabilidad

CockroachDB se ofrece como un servicio de base de datos totalmente gestionado, que en muchos casos es el modo de implementación más fácil y rentable. Pero también es capaz de ejecutarse en prácticamente cualquier plataforma que puedas imaginar, desde el portátil de un desarrollador hasta una implementación masiva en la nube. La arquitectura de CockroachDB está muy bien alineada con las opciones de implementación en contenedores y, en particular, con Kubernetes. CockroachDB proporciona un operador de Kubernetes que elimina gran parte de la complejidad que conlleva una implementación de Kubernetes.

Puede que estés pensando: "¡Esta cosa puede hacerlo todo!". Sin embargo, merece la pena señalar que CockroachDB no pretendía ser todo para todo el mundo. En concreto:

CockroachDB prioriza la coherencia sobre la disponibilidad

Hemos visto antes cómo el teorema CAP establece que tienes que elegir entre consistencia o disponibilidad cuando te enfrentas a una partición de la red. A diferencia de las bases de datos "eventualmente" consistentes, como DynamoDB o Cassandra, CockroachDB garantiza la consistencia a toda costa. Esto significa que hay circunstancias en las que un nodo CockroachDB se negará a atender peticiones si se queda aislado de sus pares. Un nodo Cassandra en circunstancias similares podría aceptar una solicitud aunque exista la posibilidad de que los datos de la solicitud tengan que ser descartados posteriormente.

La arquitectura CockroachDB prioriza las cargas de trabajo transaccionales

CockroachDB incluye las construcciones SQL para emitir agregaciones y las funciones de "ventanas" analíticas de SQL 2003, y CockroachDB es ciertamente capaz de integrarse con herramientas populares de inteligencia empresarial como Tableau. No hay ninguna razón específica por la que CockroachDB no pueda utilizarse para aplicaciones analíticas. Sin embargo, las características únicas de CockroachDB están más orientadas a las cargas de trabajo transaccionales. Para cargas de trabajo exclusivamente analíticas que no requieran transacciones, otras plataformas de bases de datos podrían ofrecer un mejor rendimiento.

Es importante recordar que, aunque CockroachDB se inspiró en Spanner, no es en absoluto un "clon de Spanner". El equipo de CockroachDB ha aprovechado muchos de los conceptos del equipo de Spanner, pero se ha desviado de Spanner en varios aspectos importantes.

En primer lugar, Spanner se diseñó para funcionar con un hardware muy específico. Los nodos de Spanner tienen acceso a un reloj atómico y a un dispositivo GPS, lo que permite unas marcas de tiempo increíblemente precisas. CockroachDB está diseñado para funcionar bien en hardware básico y dentro de entornos en contenedores (como Kubernetes) y, por tanto, no puede depender de la sincronización del reloj atómico. Como veremos en el Capítulo 2, CockroachDB sí depende de una sincronización de reloj decente entre nodos, pero es mucho más tolerante a la desviación del reloj que Spanner. Como resultado, CockroachDB puede ejecutarse en cualquier lugar, incluido cualquier proveedor de nube o centro de datos local (y un clúster de CockroachDB puede incluso abarcar varios entornos de nube).

En segundo lugar, aunque el motor de almacenamiento distribuido de CockroachDB está inspirado en Spanner, el motor SQL y las API están diseñados para ser compatibles con PostgreSQL. PostgreSQL es uno de los RDBMS más implantados en la actualidad y está respaldado por un amplio ecosistema de controladores y marcos de trabajo. El "protocolo cableado" de CockroachDB es totalmente compatible con PostgreSQL, lo que significa que cualquier controlador que funcione con PostgreSQL funcionará con CockroachDB. En la capa del lenguaje SQL, siempre habrá diferencias entre PostgreSQL y CockroachDB debido a las diferencias en los modelos de almacenamiento y transacción subyacentes. Sin embargo, la sintaxis SQL más utilizada es compartida entre las dos bases de datos.

En tercer lugar, CockroachDB ha evolucionado para satisfacer las necesidades de su comunidad y ha introducido muchas funciones nunca previstas por el proyecto Spanner. Hoy en día, CockroachDB es una próspera plataforma de bases de datos cuya conexión con Spanner sólo tiene interés histórico.

Lanzamientos de CockroachDB

La primera versión de producción de CockroachDB apareció en mayo de 2017. Esta versión introdujo las capacidades básicas de las bases de datos SQL transaccionales distribuidas, aunque con algunas limitaciones de rendimiento y escala. La versión 2.0 -lanzada en 2018- incluía nuevas funciones de partición para implementaciones distribuidas geográficamente, compatibilidad con datos JSON y mejoras masivas en el rendimiento.

En 2019, ¡CockroachDB saltó valientemente de la versión 2 a la 19! Esto no se debió a las 17 versiones fallidas entre la 2 y la 19, sino que refleja un cambio en la estrategia de numeración para asociar cada versión con su año de lanzamiento en lugar de designar las versiones como "mayores" o "menores".

Entre los lanzamientos anteriores destacan:

• La versión 19.1 (abril de 2019) introdujo funciones de seguridad como el cifrado en reposo y la integración con LDAP (protocolo ligero de acceso a directorios), la función de captura de datos de cambios descrita en el capítulo 7 y optimizaciones multirregión.

• La versión 19.2 (noviembre de 2019) introdujo el protocolo de transacciones Parallel Commits y otras mejoras de rendimiento.

• La versión 20.1 (mayo de 2020) introdujo muchas funciones SQL, como ALTER PRIMARY KEY , SELECT FOR UPDATE , transacciones anidadas y tablas temporales.

• La versión 20.2 (noviembre de 2020) añadió compatibilidad con tipos de datos espaciales, nuevas páginas de detalles de las transacciones en la consola de la BD, y puso a disposición de forma gratuita las funcionalidades distribuidas BACKUP y RESTORE.

• La versión 21.1 (mayo de 2021) simplificó el uso de la funcionalidad multirregión y amplió las opciones de configuración del registro.

• La versión 21.2 (noviembre de 2021) introdujo lecturas de estancamiento limitado y numerosas mejoras de estabilidad y rendimiento, incluido un sistema de control de admisión para evitar la sobrecarga del clúster

CockroachDB en acción

CockroachDB ha ganado una fuerte y creciente tracción en un mercado de bases de datos abarrotado. Los usuarios que se han visto limitados por la escalabilidad de las bases de datos relacionales tradicionales, como PostgreSQL y MySQL, se sienten atraídos por la mayor escalabilidad de CockroachDB. Los que han estado utilizando soluciones NoSQL distribuidas como Cassandra se sienten atraídos por la mayor coherencia transaccional y compatibilidad SQL que ofrece CockroachDB. Y los que se están transformando hacia arquitecturas modernas en contenedores y nativas de la nube aprecian la preparación de la plataforma para la nube y los contenedores.

En la actualidad, CockroachDB puede presumir de una adopción significativa a escala en múltiples sectores. Veamos algunos de estos casos prácticos.²

CockroachDB en DevSisters

DevSisters es una empresa de desarrollo de juegos con sede en Corea del Sur, responsable de juegos como Cookie Run, el juego para teléfonos móviles de : Kingdom. Al principio, DevSisters utilizaba Couchbase para su capa de persistencia, pero se encontró con problemas relacionados con la integridad transaccional y la escalabilidad. Al buscar una nueva solución de base de datos, los requisitos de DevSister incluían escalabilidad, coherencia transaccional y soporte para un rendimiento muy alto.

DevSisters consideró Amazon Aurora y DynamoDB, así como CockroachDB, pero al final eligió CockroachDB. Sungyoon Jeong, del equipo de DevOps, afirma: "Habría sido imposible escalar este juego en MySQL o Aurora. Experimentamos más de seis veces el tamaño de la carga de trabajo que habíamos previsto, y CockroachDB fue capaz de escalar con nosotros durante todo este viaje."

CucarachaDB en DoorDash

DoorDash es una plataforma de comercio local que conecta a los consumidores con sus negocios favoritos en Estados Unidos, Canadá, Australia, Japón y Alemania. En la actualidad, DoorDash ha creado más de 160 clústeres CockroachDB para sus desarrolladores para diversas cargas de trabajo internas, de cara al cliente y de análisis de backend.

Al equipo de DoorDash le gusta que CockroachDB escale horizontalmente, hable SQL y sea compatible con Postgres, y que gestione lecturas y escrituras pesadas sin afectar al rendimiento. La arquitectura resistente de CockroachDB y los cambios de esquema en tiempo real también son una gran ventaja para el equipo. "DoorDash ha podido utilizar CockroachDB para migrar y escalar numerosas cargas de trabajo sin tener que reescribir las aplicaciones, sólo con pequeños cambios de índice o esquema", dice Sean Chittenden, jefe de ingeniería del equipo de Infraestructura Central de DoorDash.

CucarachaDB en Bose

Bose es una empresa líder mundial en tecnología de consumo especialmente conocida como proveedor de equipos de audio de alta fidelidad.

La base de clientes de Bose se extiende por todo el mundo, y Bose pretende ofrecer a esos clientes las mejores soluciones de asistencia basadas en la nube.

Bose ha adoptado una arquitectura de software moderna, basada en microservicios. La columna vertebral de la plataforma Bose es Kubernetes, que permite a las aplicaciones acceder a servicios de bajo nivel -computación en contenedores- y a servicios de nivel superior como Elasticsearch, Kafka y Redis. CockroachDB se convirtió en la base de la plataforma de bases de datos de esta plataforma de microservicios en contenedores.

Aparte de la resistencia y escalabilidad de CockroachDB, la capacidad de CockroachDB para alojarse en un entorno Kubernetes fue decisiva.

Al ejecutar CockroachDB en un entorno Kubernetes, Bose ha empoderado a los desarrolladores proporcionándoles una capacidad de autoservicio de base de datos bajo demanda. Los desarrolladores pueden poner en marcha clusters de CockroachDB para desarrollo o pruebas de forma sencilla y rápida dentro de un entorno Kubernetes. En producción, CockroachDB ejecutándose con Kubernetes proporciona escalabilidad, redundancia y alta disponibilidad.

Resumen

En este capítulo, hemos situado CockroachDB en un contexto histórico y presentado los objetivos y capacidades de la base de datos CockroachDB.

Los RDBMS que surgieron en las décadas de 1970 y 1980 fueron un triunfo de la ingeniería de software que impulsó las aplicaciones de software desde el cliente/servidor hasta los inicios de Internet. Pero las demandas de aplicaciones de Internet escalables globalmente y siempre disponibles eran incompatibles con las arquitecturas RDBMS monolíticas y estrictamente consistentes de la época. En consecuencia, en torno a 2010 surgieron diversos sistemas NoSQL distribuidos y "eventualmente consistentes" para satisfacer las necesidades de una nueva generación de aplicaciones internas.

Aunque estas soluciones NoSQL tienen sus ventajas, suponen un paso atrás para muchas o la mayoría de las aplicaciones. La incapacidad de garantizar la corrección de los datos y la pérdida del lenguaje SQL, muy familiar y productivo, supuso una regresión en muchos aspectos. CockroachDB se diseñó como una base de datos transaccional basada en SQL altamente consistente y disponible que ofrece un mejor compromiso entre disponibilidad y consistencia, priorizando la consistencia por encima de todo, pero proporcionando una disponibilidad muy alta.

CockroachDB es una base de datos SQL de alta disponibilidad y coherencia transaccional, compatible con los marcos de desarrollo existentes y con los modelos de implementación en contenedores y las arquitecturas en la nube, cada vez más importantes. CockroachDB se ha desplegado a escala en una amplia gama de verticales y circunstancias.

En el próximo capítulo, examinaremos la arquitectura de CockroachDB y veremos exactamente cómo consigue sus ambiciosos objetivos de diseño.

¹ De la "Regla 5" de las 12 reglas de Codd, publicadas a principios de los 80.

² Cockroach Labs mantiene una lista creciente de casos prácticos de CockroachDB.