Coisas que não te contam sobre MongoDB

mongodb-leafMongoDB: rápido (muito), fácil de usar (eu acho), estável e adequado para diversas das situações com as quais preciso lidar. Sou fã condicional e como tal neste post exponho algumas das limitações deste produto que, confesso, me assustaram quando descobri (mea culpa). Quem sabe eu te contando antes sua experiência de adoção do MongoDB não será bem mais tranquila que a minha, não é mesmo?

Faminto por bytes

Algo interessante no MongoDB é o modo como este consome rapidamente seu espaço em disco caso você não tome cuidado. Para evitar problemas com fragmentação de arquivos (e com isto obter mais performance) o MongoDB pré aloca seus arquivos de dados. O primeiro arquivo se chamará [nome do seu banco de dados].0 e terá 64 Mb de tamanho. Conforme você usa o espaço alocado, quando estiver usando metade deste arquivo, um novo chamado [nome do seu bd].1 será criado com 128 Mb. E isto prosseguirá para arquivos com 256, 512, 1024 e finalmente 2048 Mb. A partir de então todo novo arquivo possuirá 2 Gb de tamanho.

Se espaço em disco for uma restrição para você talvez o MongoDB não seja uma boa opção.  Como o espaço é pré-alocado, é importante que de tempos em tempos você dê a manutenção necessária em seu banco de dados. Os comandos repairDatabase e compact podem te economizar algum espaço, mas isto irá depender da sua configuração.

Para este problema existe uma solução comercial muito interessante chamada TokuMX que é um storage engine que reduz em 90% o consumo de espaço em disco do MongoDB. Neste link há maiores detalhes sobre o produto.

Replicação de dados com replica-set é fantástica mas há limites

Configurar um cluster com MongoDB é muito fácil. A estratégia replica-set para replicação de dados é fantástica e funciona extremamente bem. No entanto caso replicação seja um dos seus requisitos aqui segue uma restrição importante: você só pode trabalhar com no máximo 12 nós. Mais que isto não funciona e você terá de bolar alguma estratégia mais complicada.

O pessoal já está pensando em superar esta limitação. Existe inclusive uma issue para isto. Se quiser, você pode botar pressão no time de desenvolvimento votando nesta.

Replicação com a estratégia mestre escravo é ridícula e desrecomendada

Se você precisa de mais de 12 nós para replicar seus dados, há uma estratégia considerada obsoleta e desrecomendada pelo pessoal da MongoDB que é a mestre-escravo. Com ela é possível ter quantos nós você sonhar. Funciona assim: no nó mestre é feita a escrita, e nos escravos a cópia dos dados (ficam para consulta). Então em teoria você teria alta disponibilidade, certo? Certo, desde que seu nó mestre não caia.

Caso o mestre caia, para eleger um novo mestre você terá de parar todas as instâncias do MongoDB do seu cluster (sim, você leu certo) e reconfigurá-las manualmente para escolher um novo servidor principal. Duvida? Leia a documentação a respeito. “Altíssima” disponibilidade.

Fuja da versão de 32 bits

A versão de 32 bits do MongoDB só trabalha com no máximo 2 Gb de informação (incluindo índices), sendo assim evite ao máximo esta versão no ambiente de produção especialmente pelo primeiro fato que mencionei neste post. O pessoal da MongoDB mesmo já nos informa isto.. Use-a no máximo para aprender a usar o Mongo ou para desenvolvimento.

Cuidado com documentos excessivamente complexos

Este é um vacilo muito comum por aqueles que se apaixonam pelo paradigma documental: armazenar objetos ultra complexos. Tenha em mente algumas limitações do MongoDB:

  • Seu documento pode ter no máximo 16 Mb de tamanho.
  • O nível máximo de profundidade de um documento é 100.

Convenhamos: escrever um documento desta magnitude não é uma boa idéia em lugar algum, mas já ouvi alguns casos nos quais ocorreu. Sendo assim tenha isto em mente.

Consultoria CARA mas com alguns treinamentos gratuitos

Caso precise de uma consultoria MongoDB direto “da fábrica”, prepare o bolso. Ao menos para o mercado brasileiro o valor é bem salgado. Tá sentado? US$ 450,00 por hora no plano light (mínimo de duas horas). Duvida? Aqui o link.

Mas há cursos gratuitos também que podem reduzir a probabilidade de você precisar por a mão no bolso. Neste link há mais informações sobre isto.

Ferramentas para administração ainda são ruins

Infelizmente as ferramentas para administração do MongoDB ainda são bem ruins. Existem alternativas pagas, mas ainda não testei. Até este momento a única que me satisfez e mesmo assim com ressalvas foi o RoboMongo. Há algumas que tentam imitar tabelas (o nome me escapa agora) que apenas tornam sua vida mais complicada do que devia. Evite-as. Aliás, dica: no primeiro contato com MongoDB tente focar-se em documentos e esqueça as tabelas.

Conheça as limitações do MongoDB

O MongoDB é uma solução fantástica, no entanto é muito comum nos apaixonarmos por uma tecnologia e com isto nos esquecermos de que esta sempre possuí limitações. E aí no futuro acabam surgindo frases do tipo: “MongoDB não presta”, “isto devia se chamar MongoDBosta”, etc.

Aliás, este é um conselho que dou na adoção de QUALQUER sistema gerenciador de banco de dados. Sempre o fornecedor divulga as limitações do seu produto. No caso do MongoDB, sugiro que você leia atentamente a documentação a respeito destes limites. Neste post expus apenas alguns que me surpreenderam. Uma lista bem mais completa pode ser encontrada neste link oficial.

8 thoughts on “Coisas que não te contam sobre MongoDB

  1. O 1° item eu já tinha notado. Realmente parece haver esse grande consume em disco mesmo.
    Sobre o caso do Master/Slave, se não me engano a partir da versão 2.2 a eleição do novo master é feita de forma automática, desde que seja configurado para isso.

    Sobre documentos maiores que 16MB, tem como usar o sistema GridFS para esse caso, que aceita documentos maiores que 16MB, é algo contornável.

    A versão de 32bits realmente é desaconselhada, pelo menos isso é bem fácil de descobrir, como você mesmo postou o link.

    Não sabia que a consultoria era tão cara assim. $450 por hora? Puxa vida. Sei que os cursos presenciais chegam perto de 2000 reais.

    As ferramentas de administração ainda estão devendo mesmo. Eu não testei ainda esse RoboMongo, parece interessante. Tem um chamado RockMongo, estilo PhpAdmin, quebra o galho.

    Sobre os documentos complexos, acho que isso é mais responsabilidade de quem cria os documentos do que um ponto negativo do Mongo. Por isso que se diz para pensar nas consultas antes de pensar em como salvar os dados. Assim fica mais fácil criar um documento que fuja da complexidade.

  2. Oi Marcio,
    este problema do mestre-escravo continua. Estou usando a última versão do MongoDB e tivemos de partir para uma arquitetura alternativa de rede justamente por causa disto. Acredito que a coisa não deva mudar tão cedo, pois a arquitetura mestre-escravo já é considerada deprecated pela própria empresa. :\

  3. Oi Oneide, obrigado.

    Só pro replica-set que é a solução indicada pelo pessoal da MongoDB. Para a outra abordagem que resolve o problema do limite de 12 nós ainda não (e provávelmente nem vai por ser considerada hoje uma abordagem a ser evitada)

  4. Opa cara tranquilo?

    Muito bom o post. Deu pra clarear algumas dúvidas que tinha.
    Só queria deixar uma “dica”. Realmente as ferramentas de administração são difíceis, testei o RoboMongo por um tempo e confesso q atendeu fracamente às minhas necessidades.
    Hoje uso o Genghisapp e é bem bacana. Roda com php ou ruby (inclusive via gem).

  5. Oi Gustavo, valeu!
    Vou experimentar este que me falou.

  6. Show de bola!

    Muito bom saber as limitações. Isso ajuda ainda mais a usar a tecnologia com sabedoria!

    Parabens!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.