Executando verificação de segurança...
Respondendo a "Fala pessoal! Tudo bem? Pô, essa ideia de salva..." dentro da publicação Vídeo tutorial: Como está sendo programado as TabCoins aqui no TabNews
1
FelipeBarso

Fala Galerinha Massa!

Acho que ficou pra aula 2 👨‍🏫 mostrar mais detalhes do cache implementado no Pagar.me pra gente ver melhor o tradeoff 🤓, mas algo importante para avaliar é a proporção de leituras/gravações de saldo em cada um dos dois sistemas.

Imagino que no Pagar.me o número de leituras de saldo seja um pouco maior que o de gravações, mas no TabNews o número de leituras vai ser ordens de grandeza maior do que o de gravações. Pelo menos foi o que considerei quando fiz essa sugestão na PR #462 que é bem alinhada com a sugestão do Rodrigo.

Para impedir inconsistências, poderia colocaria uma coluna a mais que seta o saldo acumulado como outdated quando outro saldo acumulado é calculado. Com isso, no início da transação, é feito o lock da linha que continha o saldo mais atual e, ao final da transação, ele é setado como outdated. Assim a escrita ocorreria de forma serial para cada usuário/conteúdo, sem risco de inconsistência.

->sequencebalance_typerecipient_idamountlast_balanceoutdated<-
...1user:tabcoinaa55true...
...2content:tabcoinbb11true...
...3user:tabcoinaa510false...
...4content:tabcoinbb12false...

O que acham dessa abordagem?

Carregando publicação patrocinada...
1
filipedeschamps

Sobre escrita/leitura no TabNews, não tinha parado para pensar. O que podemos especular talvez é o seguinte: sempre usaremos páginas estáticas (e mais para frente inclusive o retorno da API também deveria estar sob o efeito de cache). Mas em contra partida, cada tabcoin doada ou retirada (que seriam os "up votes" ou "down votes" de um conteúdo) irá gerar novas escritas no banco (novos lançamentos de balance_operations).

Mas independente disso, eu chutaria que por um bom tempo nada disso será gargalo, independente da estratégia adotada. Se isso for uma verdade, eu prefiro sempre utilizar a estratégia mais simples e bruta.

PS: o layout de tabelas que vocês estão usando está sensacional heim? Nota 10 😍 🤝

1
FelipeBarso
Autor
Autor

Penso que o número de leituras será muito maior do que o de escritas pelo seguinte...

Vamos partir de uma situação de cache ideal, onde nenhuma nova consulta ao banco de dados será necessária enquanto não houver nenhuma escrita.

Nesse caso, o quanto o número de leituras vai ser maior do que o de escritas irá depender somente do algoritmo utilizado para classificar a relevância dos conteúdos.

Dependendo desse algoritmo, uma única gravação (inclusão de novo conteúdo ou "curtida"), vai gerar a necessidade de reclassificar todo ou parte dos conteúdos, e para isso serão necessárias diversas leituras, não somente no conteúdo novo/alterado, mas em todos que serão reclassificados.

Só aí já serão várias leituras a mais do que escritas... Agora indo para a realidade, em que o cache demandará algumas revalidações, aumenta ainda mais o número de leituras com relação a escritas.

Resumindo... A depender do algoritmo de classificação e das estratégias de cache, teremos ordens de grandeza diferentes na razão entre leituras e gravações, mas, de qualquer forma, serão muito mais leituras.

PS: O Rodrigo caprichou mais na tabela, pois até centralizou o conteúdo... hahaha