NoSQL: Teorema CAP, MongoDB, CouchDB
MongoDB 2.1
DB Name: MongoDB 2.1 [editar]
Google Docs | Apresentação (slides)
Students List: [editar]
- Beatriz Aparecida Diniz | 11925430
- Eduardo Vinicius Barbosa Rossi | 10716887
- Gabriel da Cunha Dertoni | 11795717 [Presenter]
- Gabriel Vicente Rodrigues | 11795377 [Presenter]
- João Antônio Misson Milhorim | 11834331 [Editor]
- João Victor Sene Araújo | 11796382
- Lourenço de Salles Roselino | 11796805 [Presenter]
- Lucas Ferreira de Almeida | 11262063
- Marco Antônio Ribeiro de Toledo | 11796419
- Melissa Motoki Nogueira | 5588687 [Editor]
- Natan Henrique Sanches | 11795680
- Pedro Augusto Ribeiro Gomes | 11819125 [Coordinator]
- Thiago H. Cardoso | 11796594
- Pedro Dias Batista | 10769809
Main DB Features: [editar]
- Document Model: dados são armazenados em documentos, que por sua vez são agrupados em coleções. Os documentos são autocontidos e podem ser tratados como objetos. Dessa forma, é possível focar somente nos dados que se necessita armazenar e processar, sem se preocupar com estruturas rígidas em tabelas. Documentos de uma mesma coleção não precisam ter os mesmos campos e isso é chamado de “esquema flexível”. É possível aplicar regras de validação para as coleções.
- Sharding: o processo de dividir uma grande quantidade de dados sobre várias instâncias (ou “shards”) distribuídas. Isso permite grande escalabilidade horizontal. Cada shard armazena apenas parte dos dados e atua como um banco de dados independente. Todas as operações de cliente são feitas através de processos chamados “mongos”. Esses processos direcionam a request para a shard correta e também permite um melhor balanceamento de carga.
- Replication: permite a utilização de diversos servidores com dados replicados para recuperação de dados e backup. Isso também permite melhor disponibilidade, confiabilidade e tolerância a falhas.
- Authentication: garante que somente usuários autorizados possam acessar o banco de dados. O MongoDB providencia uma série de mecanismos de autenticação para usuários acessarem o banco.
- Database Triggers: uma feature que permite executar código quando algum evento acontece no banco de dados. São formas boas de garantir consistência de dados e fazer processamentos complexos nos dados.
- Time Series Data: uma série de features que permitem o gerenciamento de dados temporais e um conjunto de parâmetros que permitem controlar a granularidade e tempo de expiração de dados antigos.
- Ad-Hoc Queries: um comando de vida curta cujo resultado depende de uma variável. Cada vez que uma query ad-hoc é executada, o resultado pode ser diferente dependendo da variável em questão. Desenvolvedores podem modificar essas queries em tempo real com grandes ganhos em performance. As queries podem retornar a campos específicos e também levar em conta funções definidas pelo usuário.
- Indexing: uma variedade de índices e features com ordenação de acordo com o idioma com suporte para padrões de acesso complexos. Os índices podem ser criados sob demanda para acomodar padrões de query que se alteram em tempo real e requisitos de aplicação.
- Load Balancing: através de escalamento horizontal com replicação e sharding, o MongoDB possui suporte para load balancing em larga escala. A plataforma consegue tratar de múltiplas requisições de leitura e escrita concorrentes em cima de um mesmo dado.
Does It Implement CA, CP, or AP? Why? [editar]
O teorema CAP afirma que um sistema distribuído pode fornecer apenas duas das três propriedades desejadas: consistência, disponibilidade e tolerância de partição.
No caso de um sistema distribuído, sabemos que ele deve ser tolerante a partições, sendo assim, as únicas opções são decidir entre disponibilidade e consistência.
É muito complicado classificar um sistema como esse usando CA ou CP ou AP, porque na verdade é uma troca entre C, A e P, dependendo da configuração do banco de dados/driver e do tipo de problema. Por exemplo, não podemos dizer que o MongoDB não possui alta disponibilidade, pois os Replica-Sets contrariam essa afirmativa em muitos casos.
No entanto, partindo para um exemplo, temos que: se parte de um cluster ficar indisponível, um sistema CP irá proteger a consistência dos dados, cancelando a solicitação mesmo que diminua a disponibilidade do sistema, que é exatamente o que o MongoDB faz. Sendo assim, podemos dizer que sempre que uma partição acontece e ele precisa decidir o que fazer, ele escolherá Consistência sobre Disponibilidade. [1]
DB Advantages [editar]
- ACID Transactions
- High speed com indexação correta
- Serverless Instances
- Documentação e suporte técnico
- Sharding
DB Disadvantages [editar]
- Low speed com indexação incorreta
- Suporte a Joins (left join)
- Limite de tamanho de documento
- Alto uso de recursos
Application Niches [editar]
Segundo a pesquisa "Stack Overflow Developer Survey 2022", MongoDB é o SGBD NoSQL mais popular, com 28,29% dos desenvolvedores profissionais utilizando-o. Essa popularidade vem da fácil integração com código JavaScript, via Node.js, o que faz com que o principal nicho de aplicação de MongoDB seja desenvolvimento web.
Porém, MongoDB não é um SGBD pensado exclusivamente para desenvolvimento web. Suas características permitem que ele seja usado em diversos tipos de aplicação. Dessa forma, o uso ou não de MongoDB depende mais das características do problema que está sendo resolvido (como por exemplo, se os dados são semi-estruturados e cujos esquemas evoluem com o tempo).
Segundo a empresa Hevo, e confirmado pela empresa MongoDB, alguns dos principais casos de uso da tecnologia são: "Content Management", "Internet of Things" e "Real-time Analytics". São 3 casos que SGBDs relacionais não lidam bem, seja por conta de transações mais custosas ou por conta da falta de flexibilidade na estrutura dos dados.