Temos o prazer de compartilhar que, depois de adicionar ANSI SQL, índices secundários, esquema em estrela e recursos de visualização ao Banco de Dados Operacional da Cloudera, apresentaremos o suporte a transações distribuídas nos próximos meses.
O que é ÁCIDO?
O modelo ACID de design de banco de dados é um dos conceitos mais importantes em bancos de dados. ACID significa atomicidade, consistência, isolamento e durabilidade. Por muito tempo, a adesão estrita a essas quatro propriedades foi necessária para um banco de dados comercialmente bem-sucedido. No entanto, esse modelo criou problemas quando se tratava de dimensionar além de um banco de dados de um servidor. Para acomodar essa limitação, os clientes aumentaram o hardware no qual os bancos de dados foram implantados.
Os bancos de dados NoSQL afrouxaram uma ou mais dessas 4 propriedades para obter melhorias dramáticas na escalabilidade - o Cloudera Operational Database (Powered by Apache HBase) foi um desses bancos de dados. Fizemos trade-offs na atomicidade - especificamente, Cloudera forneceu atomicidade de linha única. Para compensar, oferecemos suporte a tabelas muito amplas (com potencialmente milhões de colunas). Isso permitiu que os clientes desnormalizassem seus esquemas em estrela e os representassem como linhas únicas para fazer confirmações atômicas em uma única linha do que costumava ser representado como várias tabelas.
Desde o nascimento do HBase, trabalhamos para criar recursos que reduzam a lacuna de recursos com RDBMs tradicionais, mantendo os benefícios da escalabilidade, consistência, durabilidade e isolamento do NoSQL.
No início deste ano, fornecemos suporte para ANSI SQL, índices secundários, esquema em estrela e visualizações no Apache HBase, trazendo uma interface e recursos que são familiares a todos os desenvolvedores de aplicativos que já criaram um aplicativo que usa MySQL ou PostGres.
Agora estamos prestes a fornecer a capacidade de fazer commits atômicos para dados que cruzam linhas e tabelas no cluster.
O que é uma transação atômica?
Uma transação compreende um conjunto de operações em um banco de dados que são gerenciados atomicamente, portanto, todas as operações devem ser totalmente concluídas (confirmadas) ou não ter efeito (anuladas).
Atualmente, oferecemos suporte apenas a transações atômicas de linha única. Isso significa que, quando os desenvolvedores procuram adotar o Banco de Dados Operacional da Cloudera, eles precisam pensar de maneira diferente sobre seu esquema.
Agora estamos introduzindo a capacidade de ter transações complexas que abrangem várias linhas e tabelas, o que significa que os desenvolvedores podem implementar o esquema em estrela tradicional ou tirar proveito de colunas largas ou ambos, dependendo de suas necessidades. Essa flexibilidade combinada com a abordagem de esquema evolutivo do Cloudera Operational Database permite que os desenvolvedores aproveitem um banco de dados de escalabilidade horizontal moderno enquanto levam adiante seu conjunto de habilidades existente.
Uma coisa importante a ser observada é que o suporte a transações no Cloudera Operational Database é “livre de bloqueios” e fornece garantias de isolamento de instantâneos. Os bancos de dados tradicionais implementam um “bloqueio” para todos os dados associados a uma transação para que outros clientes que acessam os dados não os alterem antes de serem confirmados no banco de dados. No entanto, isso pode resultar em condições de corrida que acabariam com dependências circulares e travariam. Os bloqueios também eram a causa do desempenho dramaticamente ruim por parte de um aplicativo, pois os aplicativos esperavam uns pelos outros para que pudessem obter um bloqueio e prosseguir.
Nossa abordagem permite que a primeira transação concluída avance e as outras que estavam tentando fazer alterações no mesmo conjunto de dados terão que tentar novamente. Isso evita qualquer lentidão em todo o ecossistema de aplicativos executados simultaneamente no banco de dados. Em outras palavras, nossa abordagem permite escalabilidade linear enquanto fornece a atomicidade que os bancos de dados transacionais tradicionais são capazes de fornecer.
Resultados de desempenho preliminares
Nosso recurso de suporte a transações está atualmente em beta e passando por extensos testes de desempenho.
Os testes atuais incluem o benchmark TPC-C padrão da indústria usando o aplicativo OLTP Bench. O benchmark TPC-C simula várias compras realizadas simultaneamente em vários armazéns. O esquema usado no TPC-C é representado no seguinte diagrama entidade-relacionamento:
Os números nos blocos de entidade representam a cardinalidade das tabelas (número de linhas). Esses números são fatorados por W, o número de depósitos, para ilustrar o dimensionamento do banco de dados. Os números próximos às setas de relacionamento representam a cardinalidade dos relacionamentos (o número médio de filhos por pai). + símbolo representa a pequena variação numérica da população do banco de dados.
Uma colocação de pedido requer que as 10 consultas a seguir sejam executadas como uma única transação 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 (?,?,?,?,?,?,?,?,?)
Uma transação de pagamento requer que as 6 consultas a seguir sejam executadas como uma única transação 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 (?,?,?,?,?,?,?,?)
Com servidores de 3 regiões em execução em nós Dell PowerEdge R440, conseguimos obter os seguintes resultados:
Neste gráfico, o eixo Y representa o número de pedidos que podem ser totalmente processados (incluindo criação de novos pedidos, pagamento, entrega etc.) por minuto e é expresso no benchmark tpm-C. O eixo X representa o número de entidades executando transações em paralelo.
Esses resultados preliminares indicam que o sistema atinge um pico de transferência de transações em algum lugar entre 150 e 300 transatores e testes adicionais são necessários para identificar esse pico.
À medida que essa capacidade amadurece, a taxa de transferência do OpDB e nossa capacidade de medir a taxa de transferência melhorarão.
Conclusão
A maioria dos aplicativos aproveita as transações para dar suporte às inúmeras necessidades que as empresas enfrentam. No entanto, quando os RDBMSs tradicionais não podem ser dimensionados, os clientes são forçados a fragmentar manualmente o banco de dados e gerenciar cada banco de dados fragmentado como um banco de dados independente por conta própria.
Quando isso se tornar muito complicado de gerenciar, os clientes devem considerar a migração desse aplicativo para o Banco de Dados Operacional da Cloudera. O suporte a transações complexas combinado com o suporte ANSI SQL e a natureza de expansão do Apache HBase fornecem uma combinação que pode reduzir significativamente a complexidade operacional do gerenciamento do crescimento.
Se você está cansado de gerenciar bancos de dados fragmentados e deseja reduzir o TCO do banco de dados, entre em contato com sua equipe de contas Cloudera para ver como podemos ajudar.
