Las bases de datos han evolucionado considerablemente durante la última década, pero todavía hay mucho más que las bases de datos pueden hacer, según el cofundador y director de tecnología de Cockroach Labs, Peter Mattis, quien considera que las capacidades sin servidor y de varias nubes ocupan los primeros puestos de la lista, junto con mayor integración con el almacenamiento de objetos.
Como creador de CockroachDB, una base de datos relacional distribuida geográficamente, laboratorios de cucarachas está a la vanguardia del diseño de bases de datos escalables. Solo hay un puñado de bases de datos que pueden manejar transacciones ACID distribuidas globalmente. Google Cloud Spanner fue el primero, y ahora CockroachDB es una de varias bases de datos con clientes en producción.
Contabilizar con precisión las escrituras en una configuración de base de datos distribuida globalmente es un problema informático realmente difícil, y Cockroach ha investigado significativamente para resolverlo. La empresa está atrayendo a grandes empresas, incluidos bancos globales y Netflix, que necesitan esta solución.
Pero eso no significa que los desarrolladores de Cockroach no se estén durmiendo en los laureles en su sede de la ciudad de Nueva York. I+D “nunca se hará”, declaró enfáticamente Mattis en una entrevista con datanami sobre el futuro de las bases de datos, que es nuestro enfoque editorial para el mes de enero.
La gran característica nueva que Cockroach Labs entregó en los últimos seis meses fue el lanzamiento de una versión sin servidor de CockroachDB que se ejecuta en la nube. El desarrollo de CockroachDB Serverless requirió bastante trabajo de ingeniería para Mattis y su equipo, ya que la base de datos se diseñó inicialmente como una base de datos distribuida que se escalaba gradualmente agregando nodos. Con Kubernetes manejando la orquestación bajo las sábanas, los clientes ya no tienen que preocuparse por agregar más nodos a un clúster de CockroachDB.
“Uno de los principales desafíos que aún experimentamos en el mundo de las bases de datos es la planificación de la capacidad, tratando de proporcionar la cantidad correcta de recursos para su carga de trabajo, de modo que pueda manejar la explosión. Pero no desea aprovisionar en exceso porque eso es costoso”, cube Mattis. “Todo el mundo es muy consciente de los costos en este momento. No quieren gastar de más”.
En lugar de intentar pronosticar correctamente la carga de trabajo de la transacción por adelantado, el enfoque sin servidor permite a los clientes de CockroachDB agregar nodos a su clúster de base de datos en respuesta a la demanda, de manera casi instantánea. Toma segundos agregar más capacidad a una instancia sin servidor de CockroachDB, en comparación con decenas de minutos para agregar una nueva máquina digital a un clúster dedicado de CockroachDB, cube Mattis.
Peter Mattis es cofundador y director de tecnología de Cockroach Labs.
Con la llegada de la tecnología sin servidor, la industria está comenzando a cambiar su forma de pensar acerca de las bases de datos multiusuario, cube el CTO.
“Esta concept de que, en lugar de tener su base de datos dimensionada perfectamente para el {hardware} subyacente y luego solo poder escalarla de manera incremental en función de agregar unidades frías y máquinas adicionales, en realidad es mejor tener un clúster de base de datos físico mucho más grande debajo, y luego cortar crear pequeñas bases de datos virtuales a partir de eso”, explica Mattis. “La ventaja de hacer esto es que está empaquetando un montón de cargas de trabajo en el mismo clúster y, suponiendo que tiene suficientes controles de aislamiento, que hemos integrado en… la capa de la base de datos, son efectivamente aislados. No están físicamente aislados, lo cual es bueno porque luego puede compartir los recursos físicos y, a menudo, ve que las cargas de trabajo tienen un comportamiento irregular. Si promedia un montón de cargas de trabajo juntas, se equilibra, por lo que en realidad obtiene una mejor utilización basic de los recursos al hacer esto y brinda una mejor experiencia”.
La integración de Kubernetes en las implementaciones de CockroachDB es una parte importante de esta oferta basic, y no es un ejercicio trivial diseñar un operador de Kubernetes que funcione con un sistema con estado, como CockroachDB (a diferencia de un sistema sin estado, que period el diseño authentic de K8S). punto). Pero la integración de Kubernetes fue solo una pequeña parte del trabajo basic en el desarrollo de una base de datos multiinquilino sin servidor, cube Mattis.
“No es ‘Oh, simplemente rociamos Kubernetes encima de esto’. Hay bastante más trabajo que eso”, cube. “Kubernetes es un componente allí, es un componente central, pero es como una décima parte del esfuerzo allí. El otro 90 % fue todo el trabajo duro dentro del núcleo de CockroachDB”.
Mattis hizo algunos comentarios sobre la reciente datanami historia sobre si la base de datos se está convirtiendo en un motor de consulta para almacenes de objetos. Hay algo de verdad en la tendencia, cube, pero también es una simplificación excesiva de lo que está sucediendo, particularmente para los sistemas OLTP en los que se enfoca Cockroach Labs.
“Hay algo ahí que es verdad y hay algo ahí que está mal interpretado”, cube. “Almacenamiento S3 BLOB: no quiero decir que se esté comiendo el mundo de la base de datos. Eso es demasiado fuerte. Pero hay ventajas significativas al separar realmente el cómputo para la base de datos y el almacenamiento para la base de datos”.
La parte que se perdió en la historia, cube Mattis, es que S3 no se está convirtiendo en la capa de almacenamiento principal para todos los datos. Están sucediendo muchas más cosas que simplemente ponerlo en S3. “Es la capa elementary del almacenamiento, pero por encima de eso, todavía tiene que organizar los datos en S3”, cube.
Gran parte de esa organización (para los sistemas OLAP de todos modos) se lleva a cabo en formatos de almacenamiento emergentes como Ladrillos de datos Delta Lake, Apache Iceberg y Apache Hudi, cube. “Y ese es definitivamente un componente central de la capa de almacenamiento”, cube. “Quiero enfatizar que la parte superior de S3 es significativa”.
Cockroach Labs en realidad tiene un proyecto para utilizar el almacenamiento S3 como backend. La empresa está haciendo esto por la misma razón por la que los reproductores OLAP utilizan S3: eficiencia.
“Si realmente puede llegar al punto en el que puede escalar el almacenamiento de forma independiente a través de la CPU, esto conduce a una mayor eficiencia”, cube Mattis. “No lo estamos haciendo necesariamente porque S3 resolvió todos estos problemas. Lo estamos haciendo solo desde ese ángulo de eficiencia y podemos escalarlo a la utilización de recursos en función de la carga de trabajo. ‘Oh, esta es una carga de trabajo con mucho almacenamiento. Está bien, más almacenamiento, menos CPU’, en un issue de forma que no puede obtener en una sola VM”.
El almacenamiento de S3 no debe considerarse como algo separado de la base de datos, sino como parte de la base de datos, cube. Eso no es para facilitarles las cosas a los creadores de bases de datos, cube Mattis. De hecho, hay problemas informáticos difíciles de resolver mediante la integración de S3 en la base de datos. Pero dado que se pueden obtener eficiencias, es algo en lo que está trabajando Cockroach Labs.
“Copo de nieve es así, ¿verdad? él cube. “S3 es la parte de back-end, pero están creando un código de almacenamiento de datos importante además de ese back-end de S3. Y lo mismo ocurrirá con Cockroach Labs si esto llega a buen término. Es más un proyecto de investigación en este momento, pero uno que estamos investigando de manera significativa”.
Otra área de investigación activa para los intrépidos cucarachas es el soporte para entornos de múltiples nubes. Esta es una solicitud que los usuarios de CockroachDB están haciendo cada vez con más frecuencia, cube Mattis.
“Cockroach Cloud funciona en GCP y AWS en este momento. Vamos a agregar soporte para Azure”, cube. “Y luego de eso, agregaremos soporte para bases de datos de múltiples nubes, una sola base de datos lógica que abarcará tres proveedores de nube diferentes”.
Las bases de datos multinube están en nuestro futuro (deepadesigns/Shutterstock)
Los grandes bancos están siendo empujados por los reguladores hacia el ámbito de múltiples nubes, cube Mattis. Si un proveedor de la nube deja de funcionar y se lleva consigo los servicios bancarios de uno de los bancos más grandes del mundo, eso puede tener un impacto potencialmente devastador a corto plazo para la economía, por lo que los reguladores europeos, en explicit, están dispuestos a obligar a los bancos a hacer algo al respecto.
“De hecho, están obligados a deshacerse de ese riesgo sistémico”, cube Mattis. “Quieren tener clústeres y que toda la plataforma de servicios financieros pueda ejecutarse y distribuirse en varias nubes”.
A nivel conceptual, admitir una sola imagen de base de datos en tres proveedores de nube diferentes es relativamente sencillo, cube Mattis. Kubernetes estará involucrado, cube. Pero el mayor desafío será la integración a nivel de crimson. Los cargos punitivos de salida de datos, cube, también supondrán un desafío para leer y escribir datos en una sola base de datos que abarque varias nubes.
En un desarrollo relacionado, la compañía también está trabajando para diseñar un clúster de espera en caliente para los clientes.
“Aunque CockroachDB es un sistema altamente confiable y resistente que se repara solo con fallas de nodos o regiones, tenemos clientes que dicen, incluso con eso, tenemos cargas de trabajo que son tan críticas para la misión que queremos tener un clúster de espera en caliente”, Mattis cube. “Así que, en realidad, la replicación en este clúster de espera en caliente es una funcionalidad en la que hemos estado trabajando durante un tiempo y vamos a ver una vista previa este año”.
Mattis es bastante optimista sobre las perspectivas de Cockroach Labs. La compañía está compitiendo y ganando acuerdos contra competidores más grandes, cube, y disfruta de dos años más que las nuevas empresas más pequeñas en términos de soporte de transacciones ACID distribuidas geográficamente.
“Estamos siendo utilizados en cargas de trabajo de misión crítica que, si se reducen, es importante: millones de dólares por hora de tiempo de inactividad e impactos significativos en estos clientes”, cube. “Así que es el mundo actual, probado en batalla donde creo que tenemos una ventaja significativa en este momento”.
Artículos relacionados:
Cassandra obtendrá transacciones ACID a través del nuevo protocolo de consenso de Accord
Cockroach Labs es el unicornio de datos más reciente
