MongoDB
Participei recentemente de dois projetos com MongoDB. O primeiro, uma base relativamente grande, com milhões de documentos de série temporal, onde cada segundo era um documento. O segundo projeto, uma base média, mas em crescimento exponencial.
O ponto em comum entre os dois projetos era perda de performance e servidores em uso excessivo de memória, processamento e com load sempre alto.
No projeto de série temporal, uma query demorava cerca de 90 segundos para ser executada, o load da máquina subia muito, assim como consumo de memória e CPU. No outro projeto, embora a modelagem estivesse bem feita, alguns índices não estavam sendo utilizados de forma adequada e existia a necessidade de aggregation para queries frequentes, o que deixava o load da máquina absurdamente alto. Com 100 acessos simultâneos, o servidor deixava de responder.
Para o projeto de série temporal, a primeira solução foi modificar a modelagem dos documentos. Ao invés de cada segundo ser um documento (tipo log), foi criado um schema para cada hora do dia e subdocumentos para cada minuto e depois outro subdocumento para cada segundo. O schema design adotado foi bem semelhante ao do MMS, da própria MongoDB, que pode ser lido aqui. Dessa forma, ao realizar uma query, não é necessário varrer um volume excessivo de documentos para encontrar o resultado, já que o mesmo fica concentrado em horas e a partir dai carrega os documentos filhos de minutos e segundos. Depois dessa melhoria, a query que levava 90 segundos passou para 2 segundos.
No outro projeto, o schema design foi modificado para quebrar a dependência do uso frequente de aggregation e usar queries com filtros no lugar, índices de data/hora foram criados, assim como índices geográficos e também full text search. De 100 queries simultâneas, depois dessa melhoria, o servidor passou a suportar em torno de 2.000 queries.
O que essa experiência mostra é que schema design é um dos pontos fundamentais para obter boa performance do MongoDB. Pensar apenas em infra-estrutura, máquinas potentes, não vai resolver se o schema não estiver adequado para a realidade do projeto. Entender o funcionamento de um banco não relacional e deixar de lado os vícios relacionais é a chave para o sucesso.
Com base nessas experiência, pretendo detalhar mais a importância de schema design, mostrando alguns exemplos práticos em outros posts.