DEV Community: Anderson Silva

Eventual consistência em sistemas de banco de dados distribuídos

Anderson Silva — Sat, 06 Apr 2024 22:49:55 +0000

Nos dias atuais, as empresas de médio/grande porte estão cada vez mais utilizando sistemas distribuídos para garantir que suas aplicações suportem um número crescente de usuários, o que consequentemente resulta em um aumento no número de requisições por segundo. Embora haja diversos aspectos a serem considerados em relação às aplicações distribuídas, gostaria de focar especificamente na questão da consistência em sistemas de banco de dados distribuídos escaláveis.

Existem várias estratégias viáveis para escalar um banco de dados relacional. Uma delas é aumentar os recursos de hardware, como adicionar mais memória, CPU e armazenamento, o que é conhecido como escalonamento vertical (scaling up). Outra estratégia para melhorar a capacidade de processamento em consultas é adicionar réplicas de leitura (read-replicas). Embora essas estratégias sejam amplamente utilizadas, elas também apresentam desafios que podem variar dependendo da aplicação.

Read-Replicas

Na imagem abaixo, podemos observar uma arquitetura básica para a distribuição dos bancos de dados nessa organização, utilizando read-replicas. Você configura um ou mais nós que atuarão como read-replicas, além de um banco de dados principal. O banco de dados principal é conhecido como Primary, enquanto as read-replicas são chamadas de Secondary. Essa terminologia pode variar e também pode ser encontrada como master-slave.

O funcionamento básico consiste em permitir operações de escrita apenas no banco de dados Primary, sendo que todas essas alterações são então replicadas nos bancos secundários. Qualquer operação de leitura, por sua vez, é processada pelas réplicas secundárias. Essa abordagem torna a aplicação mais tolerante a falhas. Entretanto, o tempo de resposta do servidor para o cliente pode ser afetado, dependendo de como essas réplicas estão sendo atualizadas, o que pode ser prejudicial em determinados contextos. É neste ponto que entra em cena a consistência eventual.

O que significa consistência eventual?

Primeiramente, devemos entender o que é consistência. Isso se refere a uma consulta de banco de dados que retorna os mesmos dados sempre que o mesmo pedido é feito.

Na consistência eventual, os resultados são menos consistentes inicialmente, porém são fornecidos muito mais rapidamente, com baixa latência. Os resultados iniciais de consultas de dados com consistência eventual podem não refletir as atualizações mais recentes, pois leva tempo para que as atualizações alcancem réplicas em todo o cluster de banco de dados.

Além disso, existe o conceito de consistência forte, onde significa que os dados mais recentes são retornados. No entanto, devido a métodos internos de consistência, isso pode resultar em maior latência ou atraso.

Vamos analisar o cenário abaixo e entender como ocorre essa consistência eventual dos dados em nosso contidiano.

O usuário adiciona um valor X em uma conta pelo aplicativo. Esse valor é então persistido no banco de dados principal (Primary). Após essa operação, o processo de replicação ocorre rapidamente na réplica 1 (Secondary 1), porém há uma latência maior na réplica 2 (Secondary 2). Quando o usuário verifica o saldo, a consulta pode ser direcionada tanto para a réplica 1 quanto para a réplica 2. No caso mencionado, a consulta foi direcionada para a réplica 2, onde o saldo ainda não havia sido atualizado. Como resultado, o usuário ficou insatisfeito e teve que verificar novamente o saldo para visualizar a atualização correta.

Conclusão

A consistência eventual oferece uma abordagem que prioriza a escalabilidade e a baixa latência, permitindo que as atualizações de dados sejam propagadas de forma assíncrona. No entanto, isso pode resultar em situações onde os dados podem não estar imediatamente consistentes em todas as réplicas, o que requer estratégias adequadas para lidar com essa eventual inconsistência.

Por outro lado, a consistência forte garante que os dados sejam atualizados de forma síncrona em todas as réplicas, garantindo uma visão consistente do estado do sistema. No entanto, isso pode acarretar em maior latência e sobrecarga devido à necessidade de sincronização imediata entre os nós do sistema.

Em última análise, a escolha entre consistência eventual e consistência forte depende das necessidades específicas da aplicação e das prioridades em termos de desempenho, escalabilidade e tolerância a falhas. É crucial entender os requisitos do sistema e as características do ambiente para implementar a estratégia de consistência mais adequada.

Boas práticas em classname no CSS

Anderson Silva — Sun, 20 Feb 2022 22:22:58 +0000

Introdução

Creio que todo desenvolvedor seja back-end ou front-end tem aquele "receio" de mexer com o CSS. Faz uma estilização em uma parte específica da aplicação e os estilos adicionados acabam "vazando" para outros elementos. As classnames em CSS são altamente utilizadas para poder separar a estilização e também utilizada como seletor e muita das vezes não tomamos o cuidado necessário ao escolher nomes semâticos para nossas classes, que consequentemente podem ocorrer esse "vazamento" de estilos.

O modelo BEM

Este modelo BEM, vejo como sendo bem importante na separação de pequenas partes da aplicação em componentes. Sendo assim, quando pensamos em componentes, temos aquela ideia de algo que faz parte de um contexto específico e que pode ser dinâmico. Nesse modelo a letra B significa "Block", a letra E significa "Element" e por último temos a letra M que significa "Modifiers". Para ficar mais claro, vamos partir para o código e ver como isso se aplica na prática.

Aplicação demo

A aplicação que será utilizada contém apenas um textfield para simplificar. As tecnologias utilizadas são: React, Typescript e node-sass. Temos um simples componente de TextField. Analisando este componente, podemos perceber que ele já é um bloco, ou seja...

Link do post original: https://andersonnsilva.site/post/boas-praticas-na-nomeacao-de-classname-no-css

Incremental Static Regeneration (ISR) com Nextjs

Anderson Silva — Mon, 10 Jan 2022 11:34:17 +0000

Static-Site Generation

A ideia principal deste conceito é a geração de páginas estáticas durante o tempo de build. Essas páginas podem ser enviadas para uma CDN e disponibilizadas globalmente em poucos segundos. Como nem tudo são flores, temos um probleminha. Vamos imaginar um e-commerce com 10000 produtos e para cada produtos temos que gerar uma página estática. Se essas páginas são geradas no build da aplicação, vamos ter um atraso considerável até que todas as páginas estejam prontas. Sendo assim, quanto mais páginas eu tenho que gerar de forma estática maior será o tempo de build.

O problema com a geração de sites estáticos: como o tempo de construção aumentam linearmente com o número de páginas, você pode ficar preso por horas até que seu site seja construído.

Mesmo que cada página fosse gerada estaticamente em torno de 1 ms, ainda levaria horas para reconstruir todo o site. Para grandes aplicações da web, escolher a geração completa de sites estáticos não é o primeiro passo. As equipes em grande escala precisam de uma solução híbrida mais flexível e personalizada.

Veja o post completo neste link: https://andersonnsilva.site/post/incremental-static-regeneration-isr-com-nextjs

Como a SQL lida com valores NULL

Anderson Silva — Sat, 08 Jan 2022 11:11:07 +0000

Durante meus estudos direcionado para questões de projeto e implementação de banco de dados, encontrei algo bastante interessante e que seria legal compartilhar. A SQL tem diversas regras e abordagem para lidar com valores NULL e que se dividem da seguinte forma:

Valor desconhecido (existe, mas não é conhecido);

A data de nascimento de uma pessoa não é conhecida, e por isso é representada por NULL no banco de dados.

Valor não disponível (existe, mas é propositalmente retido);

Uma pessoa tem um telefone residencial, mas não deseja que ele seja listado, por isso ele é retido e representado como NULL no banco de dados.

Valor não aplicável (o atributo é indefinido para essa tupla);

Um atributo Conjuge seria NULL para uma pessoa que não fosse casada, pois ele não se aplica a essa pessoa.

Link do post original:
https://andersonnsilva.site/post/como-a-sql-lida-com-valores-null