Coisas que não te contam sobre MongoDB

MongoDB: 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.