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.