Algumas boas práticas a serem seguidas na modelagem dos dados a serem persistidos no MongoDB

2. Porém é necessário seguir uma série de boas
práticas para que os objetos realmente cumpram
os objetivos definidos pela aplicação e para que
não tenhamos futuros problemas na administração
do nosso banco de dados.
O Mongo é schemaless, ou seja, não tem um
padrão definido para armazenamento dos dados.
Isso nos proporciona grande flexibilidade na
modelagem dos dados que serão persistidos.

3. Algumas boas práticas
a serem seguidas.
https://s3.amazonaws.com/info-mongodb-com/MongoDB-Performance-
Best-Practices.pdf

4. Armazenar todos os dados de um registros
em um único documento
O MongoDb garante o ACID a nível de documento. Quando os dados estão armazenados em um único
documento ele pode ser recuperado rapidamente em apenas uma única operação. Isso é muito eficiente. Em
alguns casos, pode não ser muito prático armazenar os dados em apenas um único documento. Faça o trade-off
do que é realmente melhor para sua aplicação.

5. Evite grandes documentos
O tamanho máximo para documentos no MongoDB são de 16MB. Na prática os documentos são alguns
kilobytes ou menos. Podemos considerar os documentos mais como linhas de uma tabela do que propriamente
as tabelas. Em vez de manter listas de registros em único um documento, faça de um registro um documento.
Para grandes documentos de mídia, como vídeos ou imagens, considere usar GridFS, uma convenção aplicado
por todos os drivers que armazena automaticamente os dados binários através de documentos muito menores.

6. Evitar o crescimento ilimitado do documento
Quando um documento é atualizado no mecanismo de armazenamento MongoDB MMAPv1, os dados são
atualizados no local se houver espaço suficiente. Se o tamanho do documento é maior do que o espaço alocado,
então, o documento pode ter que ser re-escrito em uma nova localização. O processo de mover documentos e
atualizar os seus índices pode afetar o desempenho desnecessariamente. Para antecipar o crescimento futuro,
o atributo PowerOf2Sizes é ativado por padrão em cada coleção. Esta configuração arredonda tamanhos de
alocação para potências de 2. Essa configuração reduz as chances de aumento de I / O de disco caso seja
necessário algum tipo de armazenamento adicional.

7. Evite nomes de campo longos
Os nomes dos campos são repetidos em documentos e consomem espaço. Usar nomes de campos menores
consomem menos espaço, o que permite um maior número de documentos na memória RAM.

8. Tenha cuidado ao considerar
índices em campos de baixa
cardinalidade
Consultas sobre campos com baixa cardinalidade pode retornar grandes conjuntos de resultados, isso deve ser
evitado. Índices compostos podem incluir valores com baixa cardinalidade, mas o valor dos campos combinados
deve apresentar alta cardinalidade.

9. Remover índices que são
prefixos de outros índices.
Índices composto podem ser usado para consultas sobre campos principais dentro de um índice. Por exemplo,
um índice composto nos atributos primeiro nome e sobrenome, pode ser usado para filtrar consultas que
especificam apenas o sobrenome. Neste exemplo um índice adicional no campo sobrenome é desnecessário; o
índice composto é suficiente para consultas em ambos os campos.

10. Elimine índices desnecessários
Os índices fazem uso intenso de recursos da máquina: principalmente memória RAM. Outro ponto importante é
que quando os campos de um documento são atualizados os índices associados a ele também são atualizados, o
que pode ocasionar uma sobrecarga de I/O em disco.

11. Evite grandes
matrizes indexadas
Em vez de armazenar uma grande variedade de itens em um campo indexado, é mais eficiente para updates
armazenar grupos valores em vários campos.

12. FIM