SCC0219 - Introdução ao Desenvolvimento Web (2025)

Group Discussion: NoSQL

Integrantes:
- Davi Gabriel Domingues (15447497) -> Administrador;

- Giovanna Nascimento Noventa (15637210);

- Luis Asuncion Velasquez (16796593);

- Pedro Martins Oliveira (13696213).

Link pros slides: 

https://docs.google.com/presentation/d/1NjtKKMWWv90Wqz-0JFO0QSQQ4XlAcVSLaS0FS2znlWo/edit?usp=sharing

1) DB Name

CouchDB

2) Main DB features

Lema: Relaxe

• Armazena os dados em formato JSON - documentos.

• Investe em confiabilidade, ou seja, se esforça para lidar com os erros de maneira a não impactar o banco e ainda permitir que o usuário o utilize.

• Permite funcionamento offline, ao guardar o dado localmente até que seja possível enviar para o servidor.

• ACID - seguindo o lema deles de lidar com erros de forma confiável e eficiente.

• Para evitar espaço desperdiçado ele usa uma técnica de compactação que pega as informações pouco usadas, armazena todas em um único arquivo novo e depois deleta os arquivos antigos.

• Informação pode ser visualizada de múltiplas maneiras após ser requisitada

• Realiza a validação de usuários para verificar quem pode ou não ler ou escrever determinada informação.

• Como permite o uso offline, lida com conflitos ao armazenar ambas as informações e lidar com elas de um jeito parecido com o GIT.

• Feito com Erlang (linguagem de programação garbage-collector)

• NoSQL

3) Does it implement CA, CP or AP? Why?

O Couchdb é um sistema AP. Prioriza Disponibilidade (A) e Tolerância a Partições (P). 

Explicação:

• Alta Disponibilidade: O CouchDB continua aceitando gravações mesmo que partes do sistema estejam indisponíveis ou desconectadas.

• Tolerância a Partições: Ele é projetado para funcionar corretamente mesmo em caso de falha de rede ou comunicação entre nós do cluster.

• Consistência: O CouchDB adota consistência eventual: conflitos são permitidos e resolvidos depois. Ele não mantém a consistência forte assim que a partição ocorre.

Assim, CouchDB pertence ao tipo AP, escolhendo disponibilidade e tolerância a falhas de rede. Esse modelo é ideal para cenários com replicação, aplicações móveis e sistemas distribuídos. O CouchDB armazena múltiplas versões de documentos em caso de conflito, permitindo sincronização posterior e resolução personalizada.

4) DB Advantages

• Facilidade de replicação: administração embutida com a aplicação web Futon (origem ligada a ser um banco de dados voltado para a internet, já que armazena objetos de larga escala)

• Uso de MVCC (Controle de concorrência de multiversão): evitando a necessidade de travar o arquivo do banco de dados durante a sua gravação, independentemente das cargas atuais do banco de dados, o CouchDB pode ser executado em velocidade máxima e sem restrições para seus usuários. Uma vez que os documentos possuem controle de versão e são anexados em tempo real, as solicitações de leitura do banco de dados sempre verão capturas instantâneas atualizadas do banco de dados, não importa quem acessou o primeiro documento.

• Uso da checagem posterior: se nenhum dado novo foi averiguado/constatado pelo banco, então será fornecido os dados salvos anteriormente

• Uso da função MapReduce: transforma um documento em um único valor, que é retornado na forma de índice -> uso de views para estruturar o armazenamento de dados, estruturadas em funções JS (as views permitem filtrar documentos para encontrar informações relevantes para um processo específico do banco de dados. Essas informações podem ser mapeadas de acordo com suas preferências e extraídas em uma ordem específica).

• Replicação incremental: permite que apenas as mudanças feitas desde a última replicação sejam copiadas entre bancos de dados, em vez de todos os dados, garantindo consistência para sistemas offline-first e distribuídos. O CouchDB rastreia todas as alterações de documentos usando um log de alterações (changes feed). Quando se replicam dados entre dois bancos, o log é verificado para identificar o que mudou desde a última replicação. Isso garante sincronização distribuída.

• Escalabilidade: design adaptável para o particionamento dos bancos de dados e para o ajuste da escala dos dados em múltiplos nós (infraestrutura multicloud) -> maior desempenho -> suporte a particionamento e replicação horizontais (cria uma solução de fácil gerenciamento, para balancear cargas de leitura e de gravação durante a implementação do banco de dados).

• Open source: aberto ao público desde 2010, tem uma comunidade desenvolvedora bastante ativa, o que auxilia bastante para o mantimento do desempenho e da consistência do CouchDB

• Armazenamento eficiente de documentos: Uso em larga escala de JSON, juntamente com os anexos binários associados, como imagens. Não há limite para o tamanho do texto ou o número de elementos de cada documento. Quando replicados, os dados podem ser acessados ​​e atualizados em clusters de servidores distribuídos globalmente.

Consequência notória: boa tolerância contra falhas/inconsistências

Citação IBM: “Como você tem mais controle sobre o software, também tem mais flexibilidade para adaptá-lo às necessidades específicas do seu negócio. Seja para um armazenamento de documentos de uso geral, para permitir a sincronização eficiente de dados ou para adotar uma mentalidade de "prioridade ao offline", o CouchDB oferece às empresas a flexibilidade necessária para criar infra estruturas duráveis, confiáveis ​​e escaláveis.”

5) DB Disadvantages

• Ausência de transações: Não possui suporte a transações atômicas, o que dificulta a garantia de integridade de dados em operações complexas, como updates. Transações atômicas são um conjunto de operações que são tratadas como uma única unidade de trabalho, como um bloco indivisível, desse modo, ou todas elas são executadas ou nenhuma delas é. A grande problemática de não se ter suporte a esse tipo de transações, está na falta de garantia de consistência dos dados e processos realizados. Desse modo, poderíamos ter uma operação que foi feita pela metade e interrompida, nesse caso, não conseguiríamos garantir que a parte executada não será perdida e, muito menos, que permanecerá consistente. A presença de um suporte a esse tipo de transação se mostra essencial para que esses processos trabalhem de maneira indivisível, como um átomo, e sejam processados ao mesmo tempo e de maneira consistente. (É um dos princípios ACID)

• Consultas complexas: Apesar de se mostrar eficiente para grandes volumes de dados, ele pode não ser tão apropriado quando bancos de dados relacionais quando tratamos de consultas complexas que envolvem junções ou agregações. Como ele não possui suporte a joins ou agregações nativas, isso pode exigir que elas sejam feitas manualmente pelas aplicações, o que pode gerar mais consumo do sistema e, consequentemente, redução de performance e sobrecarga. 

• Segurança: Apesar de possuir algumas features de segurança, elas podem não ser tão confiáveis como as vistas em outros bancos de dados. Assim, é necessário que o usuário adicione uma camada adicional de segurança manualmente. 

• Falta de ferramentas de visualização nativa: O CouchDB não oferece interfaces gráficas robustas para visualização ou manipulação de dados por padrão. Apesar da existência do Fauxton, que é a interface administrativa do CouchDB, ele se atém a operações mais básicas. Dessa forma, os usuários precisam recorrer a ferramentas de terceiros ou desenvolver suas próprias soluções para explorar os dados de forma visual, o que adiciona complexidade e esforço ao processo de uso e manutenção do banco.

• Consumo de Disco e Memória: Cada documento tem seu histórico de revisão armazenado, sendo assim, mesmo que um documento tenha sido alterado, sua versão anterior estará armazenada. Com o tempo, um número grande de revisões poderá estar guardado e, consequentemente, teríamos um aumento no uso do disco. Além disso, o CouchDB mantém partes dos dados e índices carregados na memória RAM, o que é muito comum para alta performance. Porém, em um banco complexo e grande, podemos ter eventuais problemas nessa estrutura de hardware, especialmente em sistemas com pouca capacidade de memória. 

6) Application Niches

Algumas empresas que usam:

• Oi 

• IBM

• Santander

Há diversos nichos os quais o CouchDB se enquadra, porém, alguns deles são:

 A) Aplicações móveis

• Permite uso do aplicativo sem internet, sincronizando os dados posteriormente.

• Ideal para apps de campo, vendas externas, inspeções, e regiões com infraestrutura precária.

B) Ambientes distribuídos com conectividade intermitente

• Opera com base na replicação de bancos locais em vários nós sincronizando com servidor central.

• Aplicável em redes de lojas, escritórios remotos e centros de saúde desconectados.

C) Sistemas de CRM descentralizados (CRM = Gestão do Relacionamento com o Cliente)

• Dados de clientes acessíveis e passíveis de atualização, mesmo offline.

• Sincronização posterior com resolução de conflitos automatizável.

D)  Plataformas de colaboração com edição distribuída

• Ideal para apps com vários editores simultâneos (documentos, tarefas).

• Gerencia conflitos com MVCC e merge de alterações.