Escolhendo o ajuste certo - Persistência imediata ou eventual?
Com o surgimento dos bancos de dados NoSql, a "persistência eventual" é uma opção disponível para acelerar as leituras e gravações no banco de dados. A persistência, também conhecida popularmente como durabilidade em disco, há muito tempo é reconhecida e valorizada como uma das características desejáveis de um sistema de banco de dados compatível com ACID (Atomicidade, Consistência, Isolamento e Durabilidade).
Quando ouvi falar de persistência eventual pela primeira vez, isso abalou minha forte mentalidade de banco de dados relacional, em que a durabilidade é como uma crença religiosa.
Com o passar do tempo, percebi que nem todos os aplicativos precisam de persistência imediata, especialmente quando a compensação é desempenho e custo, porque as leituras e gravações no disco são lentas. As vantagens da persistência eventual às vezes superam em muito a persistência imediata.
É hora de exorcizar o medo da persistência eventual dos usuários do banco de dados!
Imediato e Eventual
persistência - Então, o que é o
diferença?
Em termos simples, a persistência eventual significa que toda vez que você grava dados no banco de dados, parece que a linha foi gravada com êxito no disco porque a gravação é reconhecida pelo sistema de banco de dados. O host que aciona essa gravação recebe uma confirmação de volta do banco de dados informando que a gravação foi bem-sucedida; no entanto, por trás dos panos, o banco de dados, na verdade, não gravou os dados no disco, mas os gravou em uma camada intermediária, como a memória ou um cache do sistema de arquivos. A gravação real no disco é enfileirada e ocorre de forma assíncrona.
Persistência imediata significa que a gravação no disco é síncrona e a gravação é reconhecida somente depois que os dados são gravados no disco.
Alguns segundos depois que isso é mencionado aos 3NFers (meu nome para usuários de bancos de dados relacionais), a reunião termina rapidamente ou as soluções de banco de dados que fornecem persistência eventual são descartadas como soluções inviáveis. O reconhecimento das gravações depois que elas são persistidas no disco tem sido a única maneira.
Este blog examina se determinadas cargas de trabalho podem funcionar com uma gravação adiada no disco em favor do desempenho e do custo SE a gravação inicial for em uma camada à prova de falhas confiável e totalmente redundante com várias camadas de opções de alta disponibilidade.
Fatores a serem considerados quando
Escolhendo a persistência correta
opção
Acho que, em muitos cenários, é possível evitar a persistência eventual em favor do desempenho e do custo. Vamos examinar isso.
Antes de me aprofundar mais no assunto, deixe-me afirmar categoricamente que a durabilidade é um ótimo recurso, mas ao custo do desempenho e de um CAPEX/OPEX mais alto. CAPEX/OPEX mais alto porque será necessário investir em armazenamento mais rápido para oferecer melhor desempenho. Se você conseguir sobreviver porque tem outros recursos de redundância incorporados ao seu produto e o desempenho for um fator de grande importância, será necessário considerar a persistência eventual como uma possível solução
Vamos voltar ao básico por um segundo e examinar o que um usuário de aplicativo realmente deseja de sua interação com um banco de dados
- Gravar dados rapidamente
- Leia os dados que escrevi todas as vezes com respostas consistentes
- Nunca perder o que escrevi. O que isso realmente significa é minimizar a perda de dados. Observe que eu uso a palavra minimizar porque há vários cenários em que até mesmo a garantia "rígida" dos bancos de dados RDBMS pode ir por água abaixo.
Os bancos de dados RDBMS existem há muito, muito tempo. Eles certamente minimizaram e resolveram esses erros. Isso faz muito sentido para cargas de trabalho muito sensíveis que podem resultar em oportunidades perdidas devido a resultados inconsistentes. O que quero dizer é que essa é uma solução do tipo tudo ou nada. Para aplicativos que realmente não precisam desse tipo de durabilidade, a compensação em relação ao desempenho se mostra cara.
E se a sua solução de banco de dados permitir que você grave dados rapidamente, leia de forma consistente o que leu, nunca perca o que escreveu, forneça isolamento de transações sem sacrificar a velocidade e o desempenho por uma fração do custo do que você tem atualmente? Isso teria repercussão em você? Acredito que sim.
E se sua solução de banco de dados for
- Centrado na memória, o que lhe permite gravar dados muito rapidamente.
- Mantém seus dados na memória, o que lhe permite ler da memória muito rapidamente, essencialmente permitindo que você de forma consistente ler o que você escreveu.
- Possui recursos de HA integrados que permite você tem cópias de dados em uma implementação com reconhecimento de rack e de data center, de modo que, se um nó cair antes que uma gravação possa ser persistida no disco, você sempre poderá contar com outros nós ou outro cluster para compensar a folga.
As vantagens dessa arquitetura são
- Os aplicativos que podem tolerar alguns casos muito, muito raros de queda de dados ainda podem funcionar porque há vários níveis de redundância incorporados.
- A velocidade e o desempenho não são sacrificados.
- O custo da solução é baixo.
Podemos garantir que nunca haverá
perda de dados em um sistema, seja ele
sistemas relacionais ou NoSQL?
Na verdade, a resposta é não, porque você só pode minimizar o número de erros, não eliminá-los completamente. Embora muitos argumentem que a gravação em disco é a maneira mais segura de proteger os dados, por ter vindo desse mundo, já vi e consertei vários cenários em que os dados foram perdidos devido a unidades defeituosas, corrupção de dados, trabalhos de ETL com falha etc. As soluções existentes não oferecem necessariamente uma garantia 100% de que seus dados estão seguros. A questão é que temos que considerar as várias dimensões envolvidas e as compensações que temos que fazer.
Se você optar pela persistência eventual, é imperativo garantir
1) Recursos integrados de alta disponibilidade entre clusters para compensar a perda de dados causada pela impossibilidade de persistir os dados.
2) Várias camadas de redundância por meio de recursos de HA entre clusters ou replicação para data centers alternativos
3) Processos robustos de controle de qualidade que podem detectar e reparar rapidamente dados errôneos ou perdidos?
4) Desempenho, velocidade e custo são fundamentais para sua empresa?
O Couchbase Server oferece a você a funcionalidade tradicional de durabilidade com os recursos de aumento e aumento de escala por meio de um botão, com desempenho incrível por uma fração do custo das soluções de banco de dados tradicionais.
Conclusão
A durabilidade é desejável, mas, dependendo dos requisitos de latência, do perfil do aplicativo e das despesas em que se está disposto a incorrer, poderíamos nos dar bem com a persistência eventual. Se sua solução de banco de dados tiver os seguintes recursos
- Possui redundância integrada e vários níveis de recursos de alta disponibilidade que minimizam a perda de dados
- Pode proporcionar um desempenho incrível
- Por uma fração do custo da solução que você tem atualmente
Então, a persistência eventual é uma solução mais do que viável.
A chance de um aplicativo sofrer perda de dados em um sistema totalmente durável é quase a mesma que teria em um sistema eventualmente persistente com a sobrecarga adicional de custo, desempenho e escalabilidade. Nesse caso, a durabilidade não é superestimada?
_____________________________________________________________________________________
Este artigo foi escrito por Sandhya Krishnamurthy, engenheira de soluções sênior da Couchbaseum dos principais fornecedores de bancos de dados NoSql.
Entre em contato com o autor em sandhya.krishnamurthy@couchbase.com
- Fale conosco nos fóruns
- Siga-nos https://twitter.com/couchbasedev e https://twitter.com/couchbase
Visite os sites abaixo para saber mais sobre os produtos Couchbase, para fazer downloads gratuitos de produtos e treinamento gratuito
http://www.couchbase.com/nosql-databases/downloads/
http://training.couchbase.com/online
