wordpress-logo-stacked-rgb

Como salvei /dev/Kico dos spammers

Demorou mas aconteceu: este blog foi descoberto pelos spammers. Neste post mostro como adaptei o site, baseado em WordPress, para lidar com o problema sem precisar aumentar a capacidade do servidor.

Evolução do problema

Quando criei /dev/Kico em 2008 era raríssimo receber alguma mensagem de spam por uma razão simples: ninguém acessava este blog. Conforme o tempo foi passando, o spam começou a se manifestar sob a forma de comentários com propaganda.

A partir do meio daquele ano, conforme o número de acessos aumentou, começaram a aparecer os primeiros comentários com spam. Era algo em torno de uns dois ou três por semana. O plugin Akismet os detectava, eu checava se eram realmente spam e, sendo, os apagava. O interessante é que até onde pude perceber, este plugin conseguiu detectar 100% dos casos até os dias de hoje.

Conforme o tempo passa começo a ver dois ou três posts com spam no site. E isto vai progredindo até chegar a uns 400 por dia. Até então era tranquilo: ia na aba de comentários e simplesmente clicava em apagar todo o spam. Só que neste mês comecei a ver 1000, 2000 comentários por dia, até que nesta semana, em um único dia, 40.000 posts foram incluídos!

Para piorar a situação, como meu servidor é bastante modesto, os serviços simplesmente caiam. Se você é visitante contínuo do site deve ter percebido uma “certa” lentidão. Agora sabe a razão. Algo em torno de 60000 acessos/dia, mais da metade bots postando conteúdo.

(dica: sempre tenha um job que de tempos em tempos verifique se os principais serviços estão em execução ;) )

Como resolvi o problema (ao menos por enquanto)

Reduzindo os custos de renderização dos posts e acessos ao MySQL

O primeiro passo é tentar reduzir ao máximo as consultas ao MySQL e o custo de renderização dos posts. O primeiro passo é instalar algum plugin de cacheamento. No caso do /dev/Kico uso o Quick Cache. O funcionamento é simples: no primeiro acesso a um post o plugin irá criar uma versão estática da página e a armazenará em seu servidor. A partir do segundo acesso será servido o conteúdo estático da página. O desempenho do seu site aumenta e as consultas ao SGBD diminuem. Quando um novo comentário é aprovado para o post o cache é removido para ser gerado novamente no próximo acesso.

Isto dá uma bela folga ao servidor, mas ainda não resolveu o problema, pois os bots continuam enviando comentários para o seu site.

Banindo os spammers pelo IP

O plugin Akismet que mencionei acima é maravilhoso: como disse, ele consegue detectar 100% do spam, mas não evita que novos registros sejam inseridos na tabela de comentários do WordPress, pois ele apenas os marca como mensagens indesejadas. Se o número de registros nesta tabela for muito grande seu blog irá sofrer com isto, especialmente quando tentamos acessar a lista de comentários na área administrativa.

A solução para o problema foi bloquear os spammers pelo IP. Há dois caminhos para isto: você pode alterar o firewall do seu servidor ou usar algum plugin do WordPress. Optei pela segunda opção pois assim tenho uma interface mais amigável para este tipo de manutenção e, ao mesmo tempo, não preciso ficar acessando o servidor via SSH. O plugin que adotei foi o WP-Ban.

É muito fácil de usar: observe a imagem abaixo que contém um comentário de spam:

Um maldito spammer!

Um maldito spammer!

Como pode ser visto, na listagem de comentários do WordPress é exposto o IP de quem enviou a mensagem. No WP-Ban basta fornecer este valor: todos os visitantes provenientes deste endereço sequer acessarão seu blog: eles serão saudados com uma mensagem de bloqueio, simples assim. Qual a vantagem disto? Além de não serem incluídos registros na sua tabela de comentários o processamento do seu servidor para este usuário será significativamente menor. Qual o resultado no meu servidor? Mais memória livre, menos consultas ao SGBD e um desempenho superior aos usuários que realmente me interessam: vocês!

Dica importante: o spammer nunca usa um único IP como na imagem acima. Normalmente é um range. O Wp-Ban me permite incluir máscaras. Sendo assim, incluindo o valor 93.174.*.* já excluí todas as máquinas do spammer acima. Simples e direto.

Otimizando seu banco de dados

Claro, você não irá banir todos os IPs do planeta, sendo assim ainda haverá um ou outro spammer te atazanando de tempos em tempos. Dá pra melhorar ainda mais a situação. Como? Automatizando a exclusão de spam do seu banco de dados.

Se você usa Linux, basta criar uma tarefa com o CRON que esporadicamente exclua todos os registros da tabela comments que possuam o valor ‘spam’ no campo comment_approved. Você perderá a chance de evitar a exclusão de mensagens que não são indesejadas, mas em contrapartida garantirá que sua tabela só contenha comentários reais e mantenha-se com o menor tamanho possível.

No caso de /dev/Kico, esta tarefa é executada agora de duas em duas horas.

Troca do Apache HTTPD pelo Nginx

nginx-logo-1

Sou um cara muito sortudo: mês passado troquei o meu servidor web. Como o número de acessos ao blog vêm crescendo muito, uma ideia que passou de imediato na minha cabeça foi aumentar a capacidade do servidor. Como gosto muito de uma economia, antes de fazer o upgrade, por que não experimentar o Nginx?

Fiz a troca e não me arrependi: o desempenho melhorou significativamente e o consumo de memória foi bastante reduzido. Acredito que se não tivesse feito esta troca o estrago deste mês teria sido muito maior. Sendo assim, fica a dica: se puder, troque seu Apache pelo Nginx pois vale muito à pena.

No final das contas

Estas mudanças no WordPress foram muito fáceis de serem feitas e resolveram por enquanto meu problema com spam. Com elas consegui postergar em alguns meses o upgrade do servidor. Com certeza há soluções mais interessantes ou eficientes, mas o objetivo foi apenas mostrar que com custo mínimo é possível lidar bem com este problema.

A propósito, algum tempo atrás escrevi sobre o primeiro “upgrade” do /dev/Kico. Você pode ler o post neste link.

chaplin_tempos_modernos

Produtividade pra que, quem e como?

Diversas vezes caio nestas conversas em que a palavra produtividade pula como pipoca. Terminado o diálogo me afasto das pessoas, relembro o que dissemos e fico com a certeza de que só falamos bobagem. Por que?

O que é produtividade afinal?

Se você trabalha com desenvolvimento de sistemas ou qualquer outra atividade que envolva a geração de algum produto o termo produtividade sempre surge em conversas com gestores ou colegas ao tratarmos o modo como executamos nossas tarefas. E sabem o que é mais interessante? Não é raro vermos alguém sair chateado destas conversas. Quem é esta danada? Da forma mais ingênua possível, poderíamos defini-la como

Quanto você produz em determinado período de tempo.

Quantas linhas de código, funcionalidades, casos de uso, módulos, textos, imagens você produz por dia? Será que você consegue superar sua média? Existe uma meta em nosso ambiente de trabalho: será que você vai conseguir batê-la nesta sprint?

Percebem algo errado em todas estas perguntas e na própria definição? Eu sim: são vazias. Por que vazias? Por que raríssimas vezes tem um contexto. Não existe produtividade, mas produtividades.

As produtividades

Existe ferramenta de mais alta produtividade que o velho copiar e colar? Precisamos criar uma série de páginas, o tempo é mínimo, seu aperto máximo, sua mente em transe te diz para copiar e colar diversos trechos de código HTML e JavaScript em todas aquelas páginas. Você não pensa, age! O relógio, assim como você, não para: ctrl-c pra cá, ctrl-v pra lá, executa aqui, executa ali e voilá: as páginas estão prontas no prazo e você conseguiu! Algum gestor passa por você e te encara com satisfação naquele momento de cumplicidade efêmera.

Aquele dia foi de imensa produtividade, mas sempre a criatura volta para visitar seus pais cobrando as falhas de sua formação. E de repente o criador se vê sofrendo buscando tratar os traumas de sua criatura. Você fica horas (quando não dias ou meses) pagando o preço da sua economia porca.

A criatura sempre volta

A criatura sempre volta

No nosso amigo copiar e colar vemos um tipo específico de produtividade: a de curtíssimo prazo. É possível ter altíssima produtividade a curto prazo de tal modo que nossa criatura, ao visitar-nos, traga boas notícias? Sim, mas são raras estas situações.

Há também aquela outra ferramenta interessante que nos permite uma produtividade média a curto prazo (para a aflição dos gestores ansiosos) que nos propicia entregar bem próximo do prazo o que nos foi proposto fazer: se chama “pensar com calma”. A usamos quando projetamos aquilo que desejamos obter. Por algum tempo nossa criatura não irá se mostrar de forma concreta, e dependendo de quão rico é o seu conhecimento a respeito do problema, pode ser que o prazo não seja cumprido.

A diferença é que sua criatura é melhor formada: as cicatrizes quando existem são mais discretas e fáceis de serem corrigidas. Seu cliente pode estar até chateado devido ao leve atraso, mas ele a vê funcionando e, ainda mais legal, você sente orgulho da sua criatura e  mostra suas entranhas para seus colegas!

A criatura sempre volta

A criatura sempre volta

Todos sabemos que a maior parte da vida de um software ocorre após este ter sido entregue (em média 85% do tempo é gasto em manutenção). Aquele seu custo inicial transforma-se em lucro. Sua produtividade agora é altíssima na época que mais importa: manutenção.

Há uma balança aqui: alta produtividade no início, baixa no fim e vice-versa. Claro: quando você reaproveita conhecimento é possível ter altíssima produtividade durante todo o ciclo de vida do seu sistema, mas infelizmente estas situações são muito raras (ainda).

Kico: aonde você quer chegar com este papo?

Produtividade e valor. O que é valor?

enso

Este é o ponto fundamental deste post. O termo produtividade só possuí sentido quando pensado como valor. “Valor” é outra destas palavras que usamos em vão. Algum tempo atrás passei a buscar seu real significado e isto mudou radicalmente (e de forma muito positiva) minha visão do mundo. Segue sua definição:

Valor é a justificativa por trás da escolha.

Por que você diz que seu Macintosh vale mais que um PC? Por que pagar mais pelo produto ou profissional X? Quanto vale Y? Produtividade por que? Pra quem? O que quero com isto?

Você comprou um Mac talvez por que considere uma máquina melhor montada, com excelentes componentes e um sistema operacional superior que não irá estragar tanto quanto o oferecido pela concorrência. Você pagou a mais pelo profissional X por que sabe que ele lhe entregará um resultado positivo dentro dos seus padrões e expectativas de qualidade. Estas razões são justificativas. Valorizar é apresentar justificativas para uma escolha. O tal do valor agregado? Um conjunto de justificativas a mais que mostrem que você estava certo.

Quando tratamos produtividade como valor a história muda. Aqui seguem dois exemplos baseados nas situações que falei acima:

  • Pode usar e abusar do copiar e colar, pois o que você está fazendo será usado uma única vez para em seguida ser jogado fora e não temos dinheiro o suficiente para algo melhor elaborado. (uma justificativa tosca, mas uma justificativa!)
  • Invista na arquitetura do seu sistema o máximo que puder pois queremos algo que durará 10, 15 anos e sabemos que 85% deste tempo será gasto em manutenção.

Percebe agora por que aquela conversa com seu gestor sobre produtividade te incomodava? Este é o tal do “contexto” que falei acima: as justificativas necessárias para que lhe seja cobrado determinado nível de produtividade.

Ainda mais importante: para quem você está sendo produtivo? Será que todos os seus clientes exigem o mesmo nível de produtividade? Esta questão deixo como dever de casa para você.

Produtividade e ferramentas

toolbox

Ouvimos muito o termo produtividade quando o assunto é ferramental. “Programadores .net geram X pontos de função por hora, enquanto profissionais Java Y”. Sério? Em quais contextos e restrições? Entende agora por que estas métricas normalmente não fazem sentido?

É aquela velha história da ferramenta certa para o trabalho certo. Programadores Java escrevem X linhas de código por hora. Me pergunto quanto produzirão caso precisem escrever algo de baixíssimo nível. Será que se aplica? Acho que o cara do Assembler ganha hein?

E tem também toda aquela história sobre o mito da bala de prata que o Fred Brooks fala com absoluta autoridade no “Mythical Man Month”. O que é uma ferramenta valiosa?

É aquela que você adota em um dado contexto e se sente seguro com sua escolha por ter se baseado em um número significativo de justificativas. Dica: uma justificativa isolada não é suficiente para adotar um framework/linguagem/etc. E se a justificativa for apenas preferências pessoais… abre o olho!

Conclusões

A mensagem é simples: não existe produtividade em si. O termo produtividade só faz sentido com base em uma série de justificativas que, na prática, serão as restrições do seu problema.

E a produtividade? Em si é outro valor. Você a usará como um dos parâmetros para delinear seu caminho. Ela te responderá coisas do tipo: “este projeto é viável no prazo que recebi pois minha produtividade, baseada nestas justificativas, é X”.

Uma justificativa, baseada em justificativas: uma meta-justificativa. :)

semana_groovy

Semana Groovy 18!

Esta foi uma semana bem sem graça para os desenvolvedores Groovy e Grails: sem muitas novidades, mas talvez seja apenas minha impressão pelo fato de estar preparando algumas coisas que pretendo lançar no próximo mês (vocês gostarão) e não ter navegado tanto assim pela Internet e redes sociais. :)

Posts

Groovy e Java – Instanciações e chamada de método dinâmicamente: Leonardo Silva posta em seu blog um experimento de desempenho envolvendo reflexão em Groovy e Java. Um material bem interessante para quem se interessa pelo assunto: http://leonardosilva.eti.br/groovy-e-java-performance-instanciacoes-e-chamada-de-metodo-dinamicamente/

Groovy recebe o prêmio “Geeks Choice Award” na Java One – Este é o post no qual Guillaume LaForge fala sobre sua viagem, o prêmio e também expõe os slides de suas apresentações. http://glaforge.appspot.com/article/back-from-javaone

Uma JSR só para desenvolvimento de aplicações desktop? – Esta é a proposta de Andres Almiray (criador do Griffon) e sou completamente a favor! – http://www.jroller.com/aalmiray/entry/it_s_time_for_a

Um commit simbólico: diga adeus ao antigo sistema de build do Grails! – Uma das novidades do Grails 3.0 será a adoção do Gradle como sistema de build e não mais o bom e velho Gant. – https://github.com/grails/grails-core/commit/02cc333a38a8ee854a82d9cbfb1f03469ed621d4

DevDay 2014 – Estarei falando sobre Groovy e Grails!

Este ano resolvi que voltarei a participar de eventos e, como fui convidado para palestrar no DevDay aqui em Belo Horizonte, por que não juntar a fome com a vontade de comer? O evento ocorrerá no dia primeiro de novembro e irei palestrar sobre nosso assunto favorito. Se você for de Belo Horizonte, será uma excelente oportunidade para nos conhecermos pessoalmente! – http://devday.devisland.com/

Groovy Brasil Meetup!

Já contamos com 30 membros no Groovy Brasil Meetup, mas para que eventos possam ocorrer, precisamos de mais gente! Caso queira conhecer outras pessoas que trabalhem com Groovy e Grails pessoalmente, esta é uma excelente oportunidade. Basta que se registre no site do meetup! – http://www.meetup.com/groovybr/

Lançamentos

Spring Boot 1.1.8 – basicamente apenas alguns bug fixes – http://spring.io/blog/2014/10/11/spring-boot-1-1-8-released

Spring Boot 1.2.0 M2 – um release bem mais interessante para quem está acompanhando este framework. http://spring.io/blog/2014/10/11/spring-boot-1-2-0-m2-available-now

Posts clássicos

Na seção posts clássicos desta semana não vou incluir algo sobre história da computação, algoritmos ou similar, mas sim um livro excelente e gratuito que li nesta semana: “Don’t Just Roll the Dice”, de Neil Davidson. Trata de um assunto fundamental para todos nós que trabalhamos com desenvolvimento: quanto seu produto deve custar? Excelentes dicas e uma leitura muito agradável! – http://download.red-gate.com/ebooks/DJRTD_eBook.pdf

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

semana_groovy

Semana Groovy 17!

Esta foi uma semana bastante atípica para mim, razão pela qual não deu para postar tantos links quanto gostaria em nossa newsletter. Isto pode ocorrer periódicamente, sendo assim, peço a ajuda de vocês para manter sempre rica esta nossa publicação semanal.

Se você escreveu algo sobre Groovy, Grails, Spring, Java ou qualquer outro tópico sobre computação que ache interessante e gostaria de compartilhar aqui, faça como o Michael Schuenck e me mande o link para que seja divulgado aqui!

Posts

Por que usamos Grails (e Groovy) – Um excelente post de Michael Schuenck no qual explica as razões que fizeram sua equipe adotar Groovy e Grails no TRE-TO – http://michaelss.org/post/98223714497/por-que-adotamos-grails-e-groovy

Why I recomend Spring – um webinar muito interessante no qual Michael Plod expõe as razões pelas quais recomenda o Spring para seus clientes. Excelentes respostas para a pergunta: “por que Spring?” – http://spring.io/blog/2014/09/26/webinar-replay-why-i-recommend-spring

Dica bacana: como exportar as mensagens dos arquivos de interancionalização do Grails para JavaScript. – http://razum.si/blog/grails-javascript-i18n-messages

Lançamentos

Spring Framework 4.1.1 – http://spring.io/blog/2014/10/01/spring-framework-4-1-1-released

Spring XD 1.0.1 – http://spring.io/blog/2014/10/02/spring-xd-1-0-1-released

Uma iniciativa muito bacana: Clube dos Posts

Tomei conhecimento de uma iniciativa excelente chamada “Clube dos Posts”. Trata-se de um incentivo para que a nossa comunidade publique mais posts em seus blogs e com isto mais conhecimento seja compartilhado.

Seguindo o clube pelo Twitter você lerá muitos posts interessantes escritos pela comunidade. É algo que realmente vale à pena seguir no Twitter: https://twitter.com/ClubeDosPosts

Comunidade poderosa: Pangea!

O post de hoje é para aqueles que se interessam por arquitetura de software e é 100% nacional. Trata-se da comunidade Pangea: feita e mantida por arquitetos, para arquitetos. É muito difícil navegar por seus tópicos sem aprender alguma coisa.

Sou um dos membros, e adoraria ter vocês como contatos nela: http://pangeanet.org/

Posts clássicos – Um “pouco mais” de arquitetura

Que tal não um bom livro sobre arquitetura de software gratuito, mas três, e dos bons? É o que você encontrará no site “The Architecture of Open Source Applications”. Há três volumes que você pode ler online no site: os volumes 1 e 2 que seguem o nome do site e um terceiro, incluído recentemente, chamado “The Performance of Open Source Applications”. É fascinante conhecer a arquitetura de projetos super famosos como Nginx, Eclipse, Sendmail e tantos outros.

Nota importante: os autores vendem versões em PDF e ePub dos livros, mas você pode lê-los no formato HTML sem qualquer restrição. http://aosabook.org/en/index.html

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

 

 

semana_groovy

Semana Groovy 16!

Uma semana do novo Grails Brasil

Uma semana bem densa para o Grails Brasil. Nova versão lançada, e diversas correções feitas e outras a caminho. Peço novamente a ajuda de vocês a respeito do que podemos melhorar em nossa comunidade. O foco do desenvolvimento até o dia 15/10/2014 será apenas em layout e usabilidade. A partir daí virão uma série de novidades que, acredito, irão agradar todos vocês. ;)

Seu feedback é importantíssimo! Criei um formulário para que você nos forneça suas opiniões (especialmente críticas). Basta preenchê-lo aqui: https://docs.google.com/forms/d/1Ci-AApxKKDeeYwFQhoi4v3KGhd6Jrnv0CMinK3naWUU/viewform?usp=send_form

Posts

Exploring Micro-frameworks: Spring Boot – estou terminando um artigo para a Java Magazine sobre Spring Boot. E na minha pesquisa encontrei um excelente artigo no site InfoQ que explica muito bem os conceitos por trás desta poderosa ferramenta. Leitura obrigatória para todos aqueles que estão interessados pelo assunto. – http://www.infoq.com/articles/microframeworks1-spring-boot

What’s new in Spock 1.0 – Um post bem interessante sobre as novidades que nos esperam no Spock 1.0. Ainda hoje a maior parte dos desenvolvedores Grails ainda não conhece este framework: seu conhecimento é fundamental se você trabalha com alguma versão posterior à 2.2, que o tornou a opção oficial para escrita de testes. – http://solidsoft.wordpress.com/2014/09/17/whats-new-in-upcoming-spock-1-0-simpler-conditional-test-execution-with-requires-and-ignoreif/

Minha experiência com MongoDB: erros, acertos e dicas – Muitos desenvolvedores Grails estão pensando em usar MongoDB em seus projetos. Neste post relato minha experiência com este SGBD, com foco nos erros que cometi e vi sendo cometidos. Também falo por alto sobre uma alternativa muito interessante ao MongoDB, o TokuMX que, na minha opinião, é o MongoDB como deveria ter sido desde o primeiro release. – http://www.itexto.net/devkico/?p=1983

Casos de sucesso

Esta semana apareceu mais um caso de sucesso no Grails Brasil: o 4minds. A projeto é uma ferramenta de gestão de conhecimento adotada pela empresa Mobile Mind Tecnologia. Vale muito à pena conferir este uso interessante do Grails – http://grailsbrasil.com.br/caso/show/35

A propósito, há uma mudança sutil no Grails Brasil agora. Todos os casos de sucesso estou cadastrando também como notícias, aumentando assim sua visibilidade.

Discussão: Grails precisa de hype?

Grails needs a revolution for adoption by the younger dev community – Na lista de discussão de desenvolvedores Grails surgiu esta interessante discussão na qual seu proponente diz que basicamente devemos alimentar o hype para aumentar o público do framework entre os desenvolvedores iniciantes. Como podem ver, minha discussão é a contrária nesta discussão. Vale muito à pena conferir, pois foram freitas críticas ao framework que considero extremamente relevantes. – https://groups.google.com/forum/#!topic/grails-dev-discuss/u5gvuwWXoTk

Livro gratuito sobre Gradle!

Encontrei um livro muito interessante sobre Gradle. Se chama “Building and Testing with Gradle”, e você pode obter acesso gratuito à versão em HTML no site da Gradleware. Basta que preencha o formulário presente neste link: http://www.gradleware.com/registered-access?content=books%2Fbuilding-and-testing%2F

Lançamentos

Groovy 2.3.7 – http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&version=20543

Spring Boot 1.1.7 – http://spring.io/blog/2014/09/26/spring-boot-1-1-7-released

Posts clássicos: um pouco de Clojure e Lisp

Que tal experimentar outras linguagens da JVM. Dentre estas, uma das mais interessantes sem sombra de dúvida é o Clojure. A Object Computing tem um excelente livro sobre o assunto que você pode acessar gratuitamente neste link: http://java.ociweb.com/mark/clojure/article.html

Clojure é um dialeto de Lisp, que na minha opinião é um dos grandes feitos da história da Ciência da Computação. Quem escreve excelentes artigos sobre o assunto é o Paul Graham. Você pode acessá-los neste link: http://www.paulgraham.com/lisp.html

Dica: estes artigos do Paul Graham valem cada letra!

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

Link para baixar o PDF

Minha experiência com MongoDB: erros, acertos e dicas

Um ano e meio atrás embarquei em um projeto que antes da minha entrada já havia adotado o MongoDB. Meu objetivo neste post é relatar alguns dos nossos erros e acertos.

O que deu certo

Não tivemos os problemas que lemos por aí como locks em bases de dados e o desempenho que obtivemos foi excelente. Montar um cluster com replicação de dados do tipo replica-set se mostrou um procedimento super tranquilo, assim como a configuração de sharding.

Se você tem estruturas de dados cujos atributos podem variar bastante de um elemento para outro em uma mesma coleção e não liga para redundância de informações, MongoDB se mostra uma solução muito interessante. Ele funciona.

Já sabia algum tempo atrás de algumas das suas limitações. É importante lembrar que limitação divulgada pelo fabricante não é defeito, mas sim característica. Uma limitação que surge “acidentalmente”, esta sim é um defeito. Aliás, na época cheguei a escrever sobre isto, alguns de vocês devem se lembrar. Aqueles pontos que falei em outubro de 2013 ainda se mantém (inclusive a versão em inglês deste site foi parar no Hacker News graças a este post).

Sobre desempenho a crítica que faço é sempre a mesma: benchmarks de internet não são válidos até que você tenha experiência no seu projeto. No nosso caso o que deu certo ocorreu por que satisfez dois requisitos.

  • As estruturas de dados tinham atributos que realmente variavam bastante. Algo com atributos fixos não seria adequado. Além disto documentos embarcados eram uma alternativa interessante: redundância de dados não era um problema.
  • Precisávamos de algo cujo tempo de escrita fosse o menor possível e sabíamos exatamente como estas estruturas deveriam se comportar.

Aonde estes dois requisitos se aplicavam, obtivemos sucesso.

E onde deu errado

Sabe estes dois requisitos que citei acima? São aonde vejo MongoDB funcionar perfeitamente até hoje nos projetos que passei. O principal problema foi causado por aquilo que mais temo: inércia mental.

Há aqueles momentos em que as pessoas estão tão habituadas com o modelo relacional que simplesmente não conseguem aceitar alguns fatos fundamentais sobre o MongoDB:

  • Ele não foi feito para lidar com relacionamentos entre diferentes documentos. Documentos embarcados funcionam bem, mas quando você vai lidar com documentos em outras coleções, ou mesmo na mesma, o máximo que você tem é um quebra galho.
  • MongoDB não foi feito para ter integridade referencial.
  • Se os atributos da sua estrutura de dados são fixos e previsíveis, o registro é a melhor opção, não o documento.
  • MongoDB não é uma base de dados relacional
  • Não há uma implementação nativa de transações ACID entre documentos e nem era objetivo dos projetistas deste SGBD fazer isto.

Se seu sistema exige relacionamentos e integridade referencial  por que não usar uma base relacional? Quer fazer bonito pra algum idiota? Use persistência poliglota! MongoDB e seu SGBD relacional favorito, cada um em seu galho. Por que não tirar o melhor dos dois mundos?

(implementar integridade referencial manualmente é muito triste)

Dicas

A seguir estão algumas dicas que ajudam bastante na adoção do MongoDB. Claro que há inúmeras outras, mas estas são as que considero mais importantes.

Use alguma biblioteca/framework de mapeamento

Uma boa opção é o Spring Data para MongoDB. O modo como lida com o mapeamento de relacionamento entre documentos é muito simples e próximo daquele que estamos acostumados a trabalhar com JPA.

(reparem na frase: “que estamos acostumados a trabalhar com JPA”. É a tentativa inconsciente de aproximar o MongoDB do modelo relacional! (ainda escrevo mais sobre isto no futuro))

Mas já lhe digo que o Spring Data para MongoDB não é perfeito: longe disto. Há bugs e limitações, mas o lado positivo é que se você abrir uma issue para a equipe de desenvolvimento do projeto e esta  for bem descrita (dica: envie código reproduzindo o problema), eles resolverão rapidamente o problema. Quase todas as issues que abri foram atendidas em no máximo duas semanas, algumas na mesma semana de abertura.

Há outras alternativas também, como o Morphia, que funcionam muito bem, mas como nosso projeto era baseado em Spring, era mais interessante usar algo pertencente ao mesmo stack.

(ao que tudo indica o desenvolvimento do Spring Data está bem mais ativo também)

Conheça BEM o driver Java (ou da sua linguagem) do MongoDB

Estes frameworks de mapeamento quebram um bom galho mas há um preço: muitas vezes são lentos. Em aplicações que precisem de alto desempenho você irá observar que seu gargalo não estará no MongoDB, mas sim no código Java presente nestas bibliotecas.

Sendo assim, conhecendo bem o driver Java do MongoDB irá lhe ajudar horrores na hora em que precisar lidar com estes gargalos. Se seu sistema for basicamente CRUD, aí sim você pode ficar apenas com as bibliotecas.

Outro ponto fundamental é que pelo driver Java você consegue fazer praticamente qualquer coisa no MongoDB. Muitas vezes há um ou outro recurso que não está presente ainda na sua API de mapeamento favorita.

Precisa de transacionalidade entre documentos com MongoDB?

Se respondeu a sim esta pergunta e não quer usar uma base relacional, sua vida acaba de ficar  difícil, mas não impossível. MongoDB oferece atomicidade em operações sobre um único documento, mas não entre documentos. Sempre tenha isto em mente.

Você pode implementar manualmente transacionalidade entre documentos, mas esta será bem limitada. No site do MongoDB há um tutorial que você pode consultar. O problema é que isto dá muito trabalho.

Vou falar sobre uma solução melhor para este problema mais a frente.

Não pensou no espaço que estes bancos de dados ocupam?

Yeap, eu já havia falado sobre isto antes. As bases de dados do MongoDB podem crescer bastante se você não ficar atento. Leve isto em consideração se não quiser levar um susto com o custo do seu storage. É sempre bom fazer algumas simulações do ambiente de produção antes de adotar o MongoDB: irá lhe poupar muito tempo, dinheiro e saúde.

Lembra aquela solução que havia prometido? Ei-la!

Considere seriamente a adoção do TokuMX ao invés do MongoDB

tokutek

Sabia que o MongoDB tem um irmão gêmeo bem mais charmoso? Trata-se de uma distribuição alternativa chamada TokuMX: também é open source e é desenvolvido por uma empresa chamada TokuTek.

Bom: o que ele tem de bom?

  • Resolve seu problema de espaço de armazenamento: uma de nossas bases no MongoDB ocupa 400Mb. No TokuMX? 15Mb.
  • TokuMX implementa transação ACID entre documentos. Sim, você leu certo, e ela funciona MUITO bem.
  • Apresenta desempenho bastante superior

E o melhor: 100% compatível. Se você trocar sua instalação MongoDB pelo TokuMX sua aplicação não notará diferença alguma além da melhoria de desempenho. Até este momento só vi dois poréns com o TokuMX:

  • Ainda não há uma distribuição para Windows.
  • Infelizmente as bibliotecas atuais não oferecem suporte nativo à implementação ACID do MongoDB: você terá de usar o driver nativo para obter este resultado. Existe uma issue no projeto Spring Data pedindo este suporte, mas não é prioritária ainda (mesmo eu pedindo :) ).

Treine BEM a sua equipe

Este é um ponto fundamental: você precisa expor para os membros do seu time o modo como devemos pensar a persistência fora do modelo relacional. É a única cura que conheço para o problema da inércia mental.

Conclusões

Estas foram minhas experiências com o MongoDB. Quanto mais cedo você detectar estas dificuldades que mencionei, melhor. Espero com este post ter dado minha contribuição. Devo confessar que até hoje a maior parte das reclamações que vejo sobre o MongoDB não são culpas da ferramenta, mas sim do seu mal uso.

E, pra finalizar MESMO: experimentem o TokuMX, é um produto muito superior e vai te poupar muito tempo. :)