Nos complace compartir que después de agregar ANSI SQL, índices secundarios, esquema en estrella y capacidades de visualización a la base de datos operativa de Cloudera, presentaremos el soporte de transacciones distribuidas en los próximos meses.
¿Qué es ÁCIDO?
El modelo ACID de diseño de bases de datos es uno de los conceptos más importantes en las bases de datos. ACID significa atomicidad, consistencia, aislamiento y durabilidad. Durante mucho tiempo, se requirió el cumplimiento estricto de estas cuatro propiedades para una base de datos comercialmente exitosa. Sin embargo, este modelo creaba problemas cuando se trataba de escalar más allá de una base de datos de un servidor. Para adaptarse a esta limitación, los clientes ampliaron el hardware en el que se implementaron las bases de datos.
Las bases de datos NoSQL aflojaron una o más de estas 4 propiedades para lograr mejoras drásticas en la escalabilidad:Cloudera Operational Database (con tecnología Apache HBase) fue una de esas bases de datos. Hicimos concesiones en atomicidad; específicamente, Cloudera proporcionó atomicidad de una sola fila. Para compensar, admitimos tablas muy anchas (con potencialmente millones de columnas). Esto permitió a los clientes desnormalizar sus esquemas en estrella y representarlos como filas individuales para realizar confirmaciones atómicas en una sola fila de lo que solía representarse como varias tablas.
Desde el nacimiento de HBase, hemos estado trabajando para crear capacidades que reduzcan la brecha de características con los RDBM tradicionales, manteniendo los beneficios de la escalabilidad, la coherencia, la durabilidad y el aislamiento de NoSQL.
A principios de este año, brindamos soporte para ANSI SQL, índices secundarios, esquema en estrella y vistas además de Apache HBase, lo que brinda una interfaz y capacidades que son familiares para todos los desarrolladores de aplicaciones que alguna vez crearon una aplicación que usa MySQL o PostGres.
Ahora estamos a punto de ofrecer la capacidad de realizar confirmaciones atómicas en datos que cruzan filas y tablas en todo el clúster.
¿Qué es una transacción atómica?
Una transacción comprende un conjunto de operaciones en una base de datos que se administran atómicamente, por lo que todas las operaciones deben completarse por completo (comprometerse) o no tener ningún efecto (abortar).
Actualmente, solo admitimos transacciones atómicas de una sola fila. Esto significa que cuando los desarrolladores buscan adoptar la base de datos operativa de Cloudera, deben pensar de manera diferente sobre su esquema.
Ahora estamos introduciendo la capacidad de tener transacciones complejas que abarcan varias filas y tablas, lo que significa que los desarrolladores pueden implementar el esquema en estrella tradicional o aprovechar las columnas anchas o ambos, según sus necesidades. Esta flexibilidad, combinada con el enfoque de esquema evolutivo de Cloudera Operational Database, permite a los desarrolladores aprovechar una base de datos escalable moderna mientras llevan adelante su conjunto de habilidades existente.
Una cosa importante a tener en cuenta es que el soporte de transacciones en Cloudera Operational Database está "libre de bloqueos" y proporciona garantías de aislamiento de instantáneas. Las bases de datos tradicionales implementan un "bloqueo" a todos los datos asociados con una transacción para que otros clientes que accedan a los datos no los cambien antes de que se confirmen en la base de datos. Sin embargo, esto podría resultar en condiciones de carrera que terminarían con dependencias circulares y se colgarían. Los bloqueos también fueron la causa de un rendimiento dramáticamente bajo por parte de una aplicación, ya que las aplicaciones se esperaron unas a otras para poder obtener un bloqueo y continuar.
Nuestro enfoque permite que la primera transacción que se completa avance y las otras que intentaban realizar cambios en el mismo conjunto de datos tendrán que volver a intentarlo. Esto evita cualquier ralentización de todo el ecosistema de aplicaciones que se ejecutan simultáneamente en la base de datos. En otras palabras, nuestro enfoque permite la escalabilidad lineal al mismo tiempo que brinda la atomicidad que las bases de datos transaccionales tradicionales pueden brindar.
Resultados preliminares de rendimiento
Nuestra capacidad de soporte de transacciones se encuentra actualmente en versión beta y se está sometiendo a pruebas de rendimiento exhaustivas.
Las pruebas actuales incluyen el punto de referencia TPC-C estándar de la industria utilizando la aplicación OLTP Bench. El punto de referencia TPC-C simula una serie de compras realizadas simultáneamente en varios almacenes. El esquema utilizado en TPC-C se representa en el siguiente diagrama entidad-relación:
Los números en los bloques de entidad representan la cardinalidad de las tablas (número de filas). Estos números están factorizados por W, el número de almacenes, para ilustrar la escala de la base de datos. Los números al lado de las flechas de relación representan la cardinalidad de las relaciones (el número promedio de hijos por padre). El símbolo + representa la pequeña variación numérica de la población de la base de datos.
La colocación de un pedido requiere que se ejecuten las siguientes 10 consultas como una sola transacción atómica:
1.SELECT c_discount, c_last, C_credit FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ? 2. SELECT w_tax FROM warehouse WHERE w_id = ? 3. SELECT d_next_o_id, D_tax FROM district WHERE d_w_id = ? AND d_id = ? 4. UPSERT INTO district (d_next_o_id, d_w_id, d_id) SELECT d_next_o_id + 1, d_w_id, D_id FROM district WHERE d_w_id = ? AND d_id = ? 5. UPSERT INTO new_order (no_o_id, no_d_id, no_w_id) VALUES (?,?,?) 6. UPSERT INTO order (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES (?,?,?,?, ?,?,?) Repeat following queries for each item selected for order. 7. SELECT i_price, i_name, i_data FROM item WHERE i_id = ? 8. SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? 9. UPSERT INTO stock (s_quantity, s_ytd, s_order_cnt, s_remote_cnt, s_i_id, s_w_id) SELECT ?, s_ytd + ?, s_order_cnt + 1, s_remote_cnt + ?, s_i_id, s_w_id FROM stock WHERE s_i_id = ? AND s_w_id = ? 10. INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)
Una transacción de pago requiere que las 6 consultas siguientes se ejecuten como una sola transacción atómica:
1. UPSERT INTO warehouse (w_ytd, w_id) SELECT w_ytd + ?, w_id FROM warehouse WHERE w_id =? 2. SELECT w_street_1, w_street_2, w_city, w_state, w_zip, w_name FROM warehouse WHERE w_id = ? 3. UPSERT INTO district (d_ytd, d_w_id, d_id) SELECT d_ytd + ?, d_w_id, d_id FROM district WHERE d_w_id = ? AND d_id = ? 4. SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name FROM district WHERE d_w_id = ? AND d_id = ? 6. UPSERT INTO customer (c_balance, c_ytd_payment, c_payment_cnt, c_w_id, c_d_id, c_id) SELECT ?, ?, ?, c_w_id, c_d_id, c_id FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ? 7. INSERT INTO history (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES (?,?,?,?,?,?,?,?)
Con servidores de 3 regiones ejecutándose en nodos Dell PowerEdge R440, pudimos lograr los siguientes resultados:
En este gráfico, el eje Y representa la cantidad de pedidos que se pueden procesar por completo (incluida la creación de nuevos pedidos, el pago, la entrega, etc.) por minuto y se expresa en el punto de referencia tpm-C. El eje X representa el número de entidades que ejecutan transacciones en paralelo.
Estos resultados preliminares indican que el sistema alcanza un rendimiento máximo de transacciones entre 150 y 300 transacciones y se requieren más pruebas para identificar ese pico.
A medida que esta capacidad madure, tanto el rendimiento de OpDB como nuestra capacidad para medir el rendimiento mejorarán.
Conclusión
La mayoría de las aplicaciones aprovechan las transacciones para respaldar la gran cantidad de necesidades que enfrentan las empresas. Sin embargo, cuando los RDBMS tradicionales no pueden escalar, los clientes se ven obligados a fragmentar manualmente la base de datos y administrar cada base de datos fragmentada como una base de datos independiente por sí misma.
Cuando esto se vuelva demasiado engorroso de administrar, los clientes deberían considerar migrar esa aplicación a la base de datos operativa de Cloudera. La compatibilidad con transacciones complejas combinada con la compatibilidad con ANSI SQL y la naturaleza escalable de Apache HBase proporciona una combinación que puede reducir significativamente la complejidad operativa de la gestión del crecimiento.
Si está cansado de administrar bases de datos fragmentadas y busca reducir el TCO de la base de datos, comuníquese con su equipo de cuenta de Cloudera para ver cómo podemos ayudarlo.
