Mongoid ou Mongomapper? [fechado

Question

Eu tentei o MongoMapper e ele está completo (oferecendo quase toda a funcionalidade AR), mas não fiquei muito feliz com o desempenho ao usar grandes conjuntos de dados. Alguém tem comparado com mongóides? Algum ganhos de desempenho?

Answer 1

Eu usei MongoMapper há algum tempo, mas decidi migrar para o mongóide. O motivo são questões ocultas e arrogância em relação aos usuários. Eu tive que pular de argola para fazer o MongoMapper trabalhar com o pepino (sucedido no final) e colocar alguns patches até o projeto era simples, mas não é o ponto. Quando tentei enviar uma correção de bug (devido à incompatibilidade com o ActiveRecord), eles aparentemente ficaram chateados por encontrar um problema e fui empurrado. Enquanto estava testando, também encontrei um grande bug com a implementação da consulta, enquanto os testes foram ajustados de uma maneira que os testes passam. Após minha experiência anterior, não se atreva a enviá -la.

Eles têm um número significativamente menor de solicitações de tração e envios de bug/recurso do que o mongóide, ou seja, a participação da comunidade é muito menor. A mesma experiência que a minha?

Não sei qual deles tem mais recursos agora, mas não vejo muito futuro no MongoMapper. Não me importo de corrigir problemas e adicionar funcionalidade, mas eu me importo com situações em que eles não corrigiriam bugs.

Answer 2

Eu tenho usado os dois nas últimas duas semanas. O MongoMapper tem melhor suporte para associações relacionais (não incorporadas) e tem maior suporte de terceiros. O Mongoid tem melhor suporte à consulta, documentação muito melhor (MM tem quase nenhum, embora um site esteja supostamente em andamento), o suporte do Rail 3 (e, portanto, elabore o suporte) e uma comunidade um pouco mais ativa nos grupos do Google.

Acabei indo com mongóides.

Answer 3

Diferenças

MongoMapper

• Alegou ter um melhor apoio a associações relacionais.
• Alegou ser mais extensível por causa da arquitetura do plug -in.
• Usa um DSL para consulta.
• As associações muitas para muitas são atualizadas apenas unilaterais em MongoMapper.
• Suporte menos robusto para documentos incorporados. Atualiza o modelo inteiro, mesmo que apenas alguns atributos sejam modificados.

Mongóide

• Sugerido ser mais rápido que o MongoMapper por evidência anedótica.
• Suporte mais robusto para documentos incorporados, usando operações atômicas do MongoDB ($ set, $ push, $ pull etc.) para atualizar documentos aninhados no local.
• Suporta associações bidirecionais de muitos para muitos.
• Usa uma sintaxe do tipo Arel em cadeia para consulta.

Semelhanças

• Ambos MongoMapper e Mongóide Tenha sites com boa documentação. O MongoMapper afirmou há muito tempo ter uma documentação ruim, mas seu novo site parece fechar a lacuna.
• Ambos podem ser configurados através de um arquivo YAML e ambos têm um gerador de Rails para esse arquivo.
• Ambos são totalmente compatíveis com o Rails 3.

Configuração

MongoMapper

defaults: &defaults
  host: 127.0.0.1
  port: 27017

development:
  database: database_name

Mongóide

development:
  sessions:
    default:
      database: database_name
      hosts:
        - 127.0.0.1:27017

Bibliotecas de terceiros

Ambos os lados alegaram ter melhor apoio de terceiros. Github revela o seguinte:

• A pesquisa de "mongóides" produz 12671 resultados.
• A pesquisa de "Mongomapper" produz resultados 4708.

Notavelmente, o Devise não suporta MongoMapper.

Cometer atividade

No último ano, parece que o Mongoid foi mantido e atualizado com mais regularidade do que o MongoMapper.

MongoMapper

Mongóide

Answer 4

Uma diferença que encontrei é que update_attribute No MongoMapper, parece escrever o documento inteiro, independentemente de quais atributos realmente mudaram. Em Mongoid, ele escreve apenas os atributos alterados. Isso pode ser um problema de desempenho significativo para grandes registros. Isso é particularmente verdadeiro para documentos incorporados (aqui labels), por exemplo

profile = Profile.find(params[:id])
label = profile.labels.find_or_create_by(idx: params[:idx])
# MongoMapper doesn't have find_or_create_by for embedded docs
# -- you'll have to write custom code
profile.save

Sobre save, MongoMapper salvará o todo profile registro, mas o mongóide usará o $set Operador com lógica posicional para atualizar apenas o rótulo que mudou.

Outra questão é selecionar quais campos retornar. Ambos suportam um only critério, mas o mongóide também suporta um without Critério, que é apoiado nativamente por Mongo.

Parece -me que o mongóide é mais "arredondado" e completo em sua API, o que provavelmente explica que é uma base de código maior. Também parece documentado melhor.

Answer 5

Você instalou o mongo_ext? Eu acho que o desempenho está mais relacionado ao motorista do que o próprio mapeador. Ao olhar para o log de Mongo, posso ver sem a extensão, que o transer parece ter alguns atrasos.

Faça também o que eles recomendam no site MonogDB, selecione apenas os campos necessários.

Answer 6

Fiz alguns testes com MongoMapper na semana passada, estava estável, mas achei a interface de consulta um pouco limitada (também parte da lógica AR era peculiar), mudou para o mongóide hoje e é muito melhor usar - e mais intuitivo se você for usado para ar.

Ainda não há conclusões de velocidade - mas o interruptor foi indolor - também funciona com o Rails 3.

Answer 7

Se você estiver usando o Rails3, eu recomendo o Mongoid - ele também usa "incluir" em vez de herança "<" para persistir as aulas - usando "incluir" é o melhor paradigma em Ruby para adicionar persistência. Mongoid funciona bem para mim com o Devise.

Para melhorar o desempenho, tente usar seletivamente o acesso de nível inferior, por exemplo, ciclomotor - eu já vi isso até 10x mais rápido

Answer 8

Eu usei os dois e eles estão prestes a ser iguais em funcionalidade, mas olhe para as estatísticas de código

Parece que o MongoMapper tem uma qualidade de código muito melhor (se faz o mesmo com menos).

Você pode calcular essas estatísticas sozinho, aqui está o analisador https://github.com/alexepetrushin/code_stats

Answer 9

Eu acho que o mongóide é muito melhor na configuração e no mapeamento.

Answer 10

Eu esperaria que o desempenho fosse o mesmo, da última vez que verifiquei o MongoMapper não tinha suporte para Rails 3 - por isso estou olhando para o mongóide por enquanto.

Answer 11

sudo gem install mongo_ext é a chave para obter desempenho.

O MongoDB sopra o CouchDB em termos de velocidade bruta - embora o CDB tenha seu próprio conjunto de vantagens.

Benchmark: http://www.snailinurtleneck.com/blog/?p=74

Answer 12

O Devise não apoiou o MongoMapper, e eu também prefiro me mover no caminho do Rails3. Então eu mudei para mongóides.

Answer 13

O mongóide está tendo um suporte completo com o Rails3 e com o recurso de mapa de identidade.

Mais documento está em http://mongoid.org

Veja a performance aqui http://mongoid.org/performance.html

Answer 14

Espero que os pontos abaixo adicionem valores às respostas acima.

1.Mongoid é completamente compatível com o Rails 3 e usa o ActiveModel em todo o lugar (validações, serialização etc.), onde o MongoMapper ainda está focado nos Rails 2 e usa a gema validável para suas validações.

2.Mongoid Suporta e trabalha oficialmente no Ruby 1.8.7, 1.9.1 e 1.9.2 Head.

3.Mongoid suporta documentos incorporados de maneira mais robusta, executando as operações atômicas do MongoDB em qualquer área da hierarquia internamente. ($ SET, $ push, $ pull, etc). Com MM, você precisa dizer explicitamente para fazer essas operações.

4.Mongomapper possui melhor suporte de associação relacional e trabalha como esse como padrão.

5.MonGomapper é mais extensível, com uma arquitetura de plug -in que facilita a estendida de pessoas com suas próprias bibliotecas. Mongoid não tem isso.

6.MM suporta mapas de identidade, o mongóide não.

7.Mm tem uma comunidade maior e provavelmente mais suporte para bibliotecas de terceiros. Fiquei louco por documentação e rdoc.

8.Mongoid suporta clusters de replicação mestre/escravo. (Escreve para dominar, Round Robin lê para escravos) MM não.

9.Mongoid possui uma API de critério de estilo Arel extremamente rico, MM usa localizadores de estilo AR2.