Executando verificação de segurança...
19

Quando o NoSQL não é o vilão

Super Disclaimer

Toda ferramenta tem seu ponto ideal de uso e hoje não estou vindo criticar o modelo relacional e endeusar o modelo NoSQL. Mas sim compartilhar um artigo interessante que eu estava lendo sobre sincronização entre dispositivos usando um banco de dados NOSQL chamado PouchDB

História:

Desde 2020 eu venho acompanhando um canal no youtube chamado Dev as Life que pertence a um Japones chamado Takuya Matsuyama.

Este Japonês tem o seu próprio Saas com modelo de assinatura paga chamado Inkdrop que aliás ele está mantendo novamente sozinho.

E apesar de ter assistido esse canal muitas vezes inclusive me incentivando a deixar meu preconceito com Javascript para trás e tentar aprender um pouco sobre a linguagem, eu nunca havia lido seus posts no medium. Quando vi pela primeira vez foi como abrir a caixa de pandora.

O determinado post

Dentro do medium, eu estava lendo sobre "como eu deixei de ter meta financeira para meu SaaS" quando ele bateu 1000 assinantes (para quem não sabe, ele cobra o mínimo de 10 dólares por mês), "Como eu fiz o electron ficar 1000ms mais rápido" ... e outras coisas assim, até chegar ao post que me surpreendeu How i Develop an app that runs and syncs on both desktop and mobile platforms alone.

Ok, ele exagerou um pouco porque usou um monte de ferramenta open-source para fazer isso. Mas o ponto em questão que me surpreendeu foi o uso do PouchDB que é um NoSQL que eu nunca vi, nem senti o cheiro. Diferente de MariaDB, MySQL, Postgres, MongoDB, MemCached até o falecido Redis que são nomes que você vê como um gato pingado em código alheio por ai.

Mas veja o que ele diz sobre o pouchDB no determinado post, já vou mandar traduzido para facilitar a leitura.

Apache CouchDB é um banco de dados orientado a documentos (NoSQL) que possui API JSON baseada em HTTP e oferece suporte à sincronização multimestre. Possui uma GUI baseada na web chamada Fauxton que permite gerenciar bancos de dados e documentos facilmente. PouchDB é um banco de dados JavaScript inspirado no CouchDB, que pode ser sincronizado com ele. Primeiro, criei a versão desktop e não me importei com plataformas móveis porque presumi que o PouchDB funciona tão bem em dispositivos móveis porque está escrito em JavaScript e parece já haver algumas opções . Se não funcionar, eu poderia construir meu próprio módulo de banco de dados cliente, pois o CouchDB é RESTful.

O motivo pelo qual escolhi o CouchDB em vez de outro PaaS (Platform-as-a-Service) que oferece suporte à sincronização de dados entre dispositivos como o Firebase é porque eu precisava de suporte flexível de indexação do lado do cliente. Há 3 anos, quando comecei este projeto, o firestore ainda não era tão flexível para realizar isso. O PouchDB parecia promissor, pois suporta MapReduce do lado do cliente para construir índices e possui um módulo de pesquisa de texto completo . Além disso, existe um DBaaS para CouchDB chamado Cloudant , que pode dimensionar elasticamente a taxa de transferência e o armazenamento de forma independente. Como não tenho vontade de operar servidores, comecei a usar o Cloudant logo no início. Atualmente estou operando o CouchDB no AWS EC2 porque descobri que a carga do servidor é basicamente estável e não tão pesada como os serviços BtoC do que eu esperava e o Cloudant era muito lento e desconfortável para gerenciar no IBM Cloud.

No geral, estou feliz com o CouchDB e o PouchDB até agora.

Interessante, não é? eu achei ainda mais porque o Inkdrop tem a filosofia de Offline things first. Ou seja, ele não necessita que você fique 100% conectado para fazer suas coisas.

Você pode editar algo do celular offline, outro no notebook, outro num mac, outro num linux ... e a partir do momento que se conecta a internet, todos os dispositivos se sincronizam e os dados são compartilhados entre eles.

Vendo o github do pouchDB

Após ler este post, eu fui procurar o PouchDB no github e quando encontrei, procurei pontos que possam ser interessantes arquiteturalmente no código então vamos dar uma olhada e antes que perguntem sim, o PouchDB possui muitos testes 🏆

1º O pouchDB é uma coleção de vários node-packages que interagem ou não entre si. O que torna muito enxuto quando você quer fazer algo simples e não precisa da estrutura completa.

2º O pouchDB possui suporte a replicação, md5 e merge mas isso não foi tão interessante quanto a forma que se escreve com o pouchDB

PouchDB Example:

Tirado diretamente no Site Oficial, este é como você utilizaria o PouchDB na sua aplicação:

var db = new PouchDB('dbname');

db.put({
  _id: '[email protected]',
  name: 'David',
  age: 69
});

db.changes().on('change', function() {
  console.log('Ch-Ch-Changes');
});

db.replicate.to('http://example.com/mydb');

Se isso te lembra o prisma, fique tranquilo me lembra também

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

async function main() {
  const user = await prisma.user.create({
    data: {
      name: 'Alice',
      email: '[email protected]',
    },
  })
  console.log(user)
}

main()
  .then(async () => {
    await prisma.$disconnect()
  })
  .catch(async (e) => {
    console.error(e)
    await prisma.$disconnect()
    process.exit(1)
  }) 

Se colocar um do lado do outro, nem parece ter diferença.

Concluindo

Vou deixar o post que me fez pesquisar mais sobre o PouchDB aqui em baixo.

Espero ter atiçado um pouco mais sua curiosidade sobre o assunto. Obrigado por ler até aqui

Carregando publicação patrocinada...
3

Achei muito interessante esse post. Eu ainda não sou muito erudito em banco de dados, só usei o IDB do javaScript, e ele é bem limitado, apesar de ser simples de implementar.

Descobrir alternativas é sempre bom, e certamente marcarei o PouchDB em minha mente para estudar no futuro.

Infelizmente parece que o post causou discórdia nos comentários sobre o uso de NoSQL e SQL... Ao meu ver, cada um tem seus papéis. NoSQL tem suas vantagens assim como SQL. O ideal é dominar os dois mundos, afinal, quanto mais ferramentas melhor.

2

Sim, eles leram o post de cabo a rabo mas os links que davam o contexto em questão foi completamente pulado.

Inclusive alguns hackings que o Takuya precisou fazer no PouchDB para que o mesmo atuasse bem em Mobile e Desktop.


Como por exemplo, criar um adaptador sqlite3 (relacional) para pouchDB (NoSQL) de forma que a indexação de arquivos fosse mais rápida.

Post: Hacking PouchDB

Ou usando a feature do Sqlite3 para fazer full text search localmente.

O grande ponto de usar PouchDB foi ele ser um banco de dados "de arquivos" que serviu muito bem para um "app de anotação em markdown" que precisava sincronizar "entre muitos dispositivos" de forma multimestre.

Se ambos tivessem lido o link corretamente poderia ter visto que o Takuya não usou o modelo nosql sozinho e precisou usar algumas features que o modelo relacional era capaz de prover e vice-versa.

2
2

Pode ajudar entender:

Alguns precisam de uma atualização porque foram escritos há tempos, mas a base permanece a mesma, não mudou nada fundamental. Não existem produtos milagrosos e quem conhece a computação não cai em contos da carochinha.

NoSQL cai bem onde qualquer porcaria cairia de tão simples que é o problema a ser resolvido ou em casos muito fora do normal. Especialmente no modelo de documento um bom produto relacional é melhor opção em cenários mais comuns, para mais detalhes deve ler todos os links com atenção. NoSQL tem usos bem úteis e uma necessidade real, mas o grosso da adoação atual é por modinha e não por necessidade, em geral é escolhido por falta de fundamentos, até mesmo científicos e preferência por crenças que o marketing incute nas mentes mais fracas, e claro, vão negativar este comentário.

Obrigado pela postagem.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

3

NoSQL cai bem onde qualquer porcaria cairia de tão simples que é o problema a ser resolvido ou em casos muito fora do normal.

Acho que não é tão simples. O primeiro "NoSQL" que eu conheço foi MUMPS (tinha alguma coisa da IBM na época mas não recordo o nome). Ok, não está no TIOBE nem no PYPL mas ainda tem sistemas legados, versões novas gratuitas e comerciais (se tem versão comercial é porque alguém ainda usa). Mas vejamos um caso "simples":

VistA

Veterans Health Information Systems and Technology Architecture (VISTA)

  • Sistema integrado usado nos EEUU para assistência médica para veteranos.

  • É composto por 180 aplicações (clinicas, financeiras e administrativas)

  • Próximo de 9 milhões de clientes (veteranos) e 180.000 usuários (médicos)

Em 2018 eles tentaram "modernizar" o sistema. Após atrasos e outros problemas (inclusive relatos de mortes prematuras) voltaram ao original.

"NoSQL" vs Relacional

MGateway Ltd

We're a UK-based software development company. Since 1993, we've been developing tools, interfaces and frameworks for both the front-end and back-end of the Web Technology stack.

We also specialise in software tools, interfaces and frameworks to allow the ultra high-performance Global Storage databases (eg InterSystems IRIS and the Open Source YottaDB database) to operate at the back-end Web Applications.

A empresa disponibilizou um benchmark YottaDB vs Redis. Rodei localmente para ver os resultados e achei, no mínimo, interessantes (aproximadamente 4x mais rápido na escrita e 6x mais rápido na leitura).

Só um último link From Healthcare to Mapping the Milky Way: 5 Things You Didn’t Know About Epic’s Tech.

Conclusão

Banco de dados não relacionais não são novidade (M é de 1966) e podem ser utilizados, virtualmente, em qualquer aplicação. É necessário o conhecimento de M mas o YottaDB, por exemplo, permite a utilização de M, C, Go, JavaScipt, Lua,Perl, PHP, Python e Rust.

2

Preciso! :claps: :claps: :claps: :claps:
O pessoal adora repetir esses mantras criados ao redor de NoSQL.
'use NoSQL' is the new 'use Microservices'.

1

É até o contrário, já tem mais de 10 anos que mandam usar NoSQL em tudo, e microsserviços pouco mais de 5 anos que realmente pegou moda. No SQL eu até não acho um crime, porque é o que eu falei, usam onde qualquer coisa serve na maioria das vezes, e onde vai além só a produtividade costuma ser prejudicada no longo prazo. Microsserviços causa uma quantidade enorme de problemas. Por sorte a maioria das pessoas que diem fazer microsserviços entendem tão pouco o que é, que fazem uma arquitetura monotítica com vários executáveis e não causa problema :D Esse é o nível da ignorância e arrogância. Só querem estar na moda, não há decisão técnica, até por falta do fundamento.