Despejamos logs de depuração e transações em arquivos MongoDB.
Gostamos muito MongoDBporque:
- Perf de inserção brilhante
- orientado a documentos
- Capacidade de permitir que o motor solte as pastilhas quando necessário para desempenho
Mas há um grande problema MongoDB: o índice deve caber na RAM física. Na prática, isso nos limita a 80-150 GB de dados brutos (atualmente rodamos em um sistema com 16 GB de RAM).
Então, para termos 500 GB ou TB de dados, precisaríamos de 50 GB ou 80 GB de RAM.
Sim, eu sei que isso é possível. Podemos adicionar servidores e usar arquivos MongoDB sharding. Podemos comprar uma caixa de servidor especial que pode acomodar 100 ou 200 GB de RAM, mas esse é o rabo abanando o cachorro! Poderíamos gastar muito dinheiro em hardware para executar FOSS, quando o SQL Server Express pode lidar com MUITO mais dados em MUITO menos hardware do que Mongo(o SQL Server não atende aos nossos desejos arquitetônicos, ou nós o usaríamos!) Não vamos gastar muito $ em hardware aqui, porque é necessário apenas por causa da Mongoarquitetura, não por causa das necessidades inerentes de processamento/armazenamento. (E a fragmentação? Deixando de lado os custos, quem precisa da complexidade contínua de três, cinco ou mais servidores para gerenciar uma carga relativamente pequena?)
Resumindo: MongoDBé FOSS, mas temos que gastar $$$$$$$ em hardware para executá-lo? Deveríamos preferir comprar software comercial!
Tenho certeza de que não somos os primeiros a abordar esse problema, por isso perguntamos à comunidade:
Para onde vamos a seguir?
(Já rodamos o Mongo v2)
Responder1
Se você estiver em um ponto em que o desempenho atual é muito lento ou os limites foram atingidos, você tem três opções. E eles são verdadeiros para qualquer problema.
- Dimensionar verticalmente: Significa aumentar a potência da sua máquina. Mais CPU ou mais RAM.
- Dimensionar horizontalmente: Significa aumentar a quantidade de trabalhadores. Mais processos, mais threads, mais máquinas.
- Alterar design: Faça diferente. Outros softwares, outros algoritmos, outros sistemas de armazenamento, outros.
Como você excluiu 1) e 2) de suas opções, resta apenas a solução 3). Então vá em frente...
Responder2
Postamos essa mesma pergunta no fórum do Mongo, e o CTO do Mongo respondeu, dizendo para revisar sua apresentação sobre como otimizar índices
http://www.10gen.com/presentations/mongosf2011/schemascale
Nesta apresentação, o Sr. Horowitz afirma explicitamente que o sharding/horiz scaling pode ser um exagero em muitas situações, e que as abordagens de design (incluindo algumas abordagens bastante não intuitivas que são específicas do Mongo) podem fazer com que um determinado servidor seja escalonado muito mais longe.
Isso apresentou alguns conceitos interessantes, incluindo o uso da lógica do lado do cliente para otimizar como o banco de dados é usado de diversas maneiras "não normalizadas". Há um subtexto claro na apresentação no sentido de "se você apenas construir de acordo com o livro, poderá facilmente encontrar problemas indesejados relacionados ao dimensionamento". Por exemplo, Horowitz (o CTO da 10Gen, criador do MongoDB) apresenta um design "híbrido" no qual, em vez de um documento por "registro", você coloca talvez 100 "registros" em um documento, resultando em um tipo de "balde". de abordagem. Isso é feito explicitamente para reduzir a pegada do índice. Isso é algo codificado no cliente e não é um “recurso” do MongoDB. Essa abordagem híbrida pode funcionar para nós e nos proporcionar uma melhoria de 4x ou 8x no tamanho do índice.
Ele também discute btrees "equilibradas corretamente", que basicamente otimizam o design do índice para que a maioria das consultas acesse apenas a "peça direita" do índice (em oposição ao acesso aleatório em todo o índice, que, para ter um bom desempenho, requer que o todo o índice cabe na RAM). Essa abordagem não nos ajudará, pois precisamos consultar todo o índice.
Usaremos esses conceitos como parte de uma revisão de nosso sistema.
(Interessante que de todos os lugares onde postei esta pergunta, a única pessoa com uma resposta construtiva é o próprio CTO do MongoDB.)
ATUALIZAÇÃO (2017)
Descobrimos que o Mongodb, em última análise, não é apropriado em um ambiente de produção. A cada dois meses, ele despeja/lixa todo o banco de dados e todos os dados são perdidos. (Não é uma fonte de dados primária, portanto podemos conviver com o problema, embora não felizes.)
Agora concluímos um projeto para migrar para a pilha elasticsearch e estamos lançando-o para produção agora. (Usamos o elasticsearch com sucesso há anos.) Os dados do Elasticsearch não são tão duráveis, como, digamos, o Microsoft SQL Server (tivemos clusters do elasticsearch que falharam com perda irrecuperável de dados), mas o elasticsearch é pelo menos 10x (experimentalmente, mais de 100x ) mais confiável que o Mongodb. (O Elasticsearch, de forma inteligente, não tem a pretensão de oferecer suporte ao Windows como plataforma de produção, um dos grandes pecados do Mongodb.)
Esperamos ter eliminado todo o nosso ambiente do Mongodb nas próximas semanas.
Avante!
ATUALIZAÇÃO (2018-2019)
A pilha elasticsearch foi entregue. Descobrimos que ele é muito confiável, muito escalável e nunca olhamos para trás. Mongo cheirava muito bem na época, mas já se foi há anos e já vai longe. Estamos executando dois clusters elásticos, um para dados de log (que substituiu nosso servidor Mongo) e um segundo para dados reais de aplicativos. Cada cluster possui de 1 a 2 TB de dados. Demorou ummuitodo trabalho de arquitetura (particularmente no lado do aplicativo) para obter elasticidade tanto para escalar quanto para executar, mas entrega isso acontece.
Responder3
Você pode não gostar das respostas para o seu problema de "dimensionamento" porque na verdade não tem um problema de dimensionamento; você tem um problema de design e implementação. Você não está indexando de forma eficiente.
Sério, se você acha que é absolutamente necessário manter índices desse tamanho, você terá o mesmo problema de manter índices abominavelmente enormes na RAM em qualquer produto de banco de dados que procurar. Você teria que comprar um servidor de alta capacidade (DL380 G7 pode fazer isso, e é um servidor comum de médio porte; nada exótico) para armazenar esses índices.
Para ajudar, uma busca por "índices de otimização do mongodb" revela vários links úteis:
http://www.mongodb.org/display/DOCS/Optimization
http://www.10gen.com/events/indexingmatters
http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/
http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer
Você pode ficar na defensiva por ter feito sua pesquisa, mas aqueles de nós que usam o MongoDB em produção sabem que estão faltando muitos pontos.
Além disso, o comentário "Resumindo: MongoDB é FOSS, mas precisamos gastar $$$$$$$ em hardware para executá-lo? Preferimos comprar SW comercial!" gritos de ignorância e arrogância.
Responder4
Por que você diria "O SQL Server Express pode lidar com MUITO mais dados em MUITO menos hardware que o Mongo (o SQL Server não atende aos nossos desejos arquitetônicos, ou nós o usaríamos!)". Se você precisar alterar a arquitetura do seu banco de dados (já que seu outro banco de dados não pode ser dimensionado como você precisa e você usaria o SQL Server, a resposta para mim é corrigir o design do seu banco de dados para funcionar com o SQL Server. A única coisa que eu posso pensar que isso não é "corrigível" se você realmente deseja um banco de dados sem ACID (o que me pareceria estranho que as inserções de depuração e log de transações possam ser descartadas)