Mongoid ou MongoMapper? [fechadas]

Eu tentei o MongoMapper e ele é completo (oferecendo quase todas as funcionalidades de AR), mas não fiquei muito feliz com o desempenho ao usar grandes conjuntos de dados. Alguém comparou com o Mongoid? Algum ganho de desempenho?

Eu usei o MongoMapper por um tempo, mas decidi migrar para o MongoId. O motivo são questões ocultas e arrogância com os usuários. Eu tive que pular para fazer o MongoMapper funcionar com o Cucumber (conseguiu no final) e colocar alguns patches até o projeto ser simples, mas não é o ponto. Quando tentei enviar uma correção de bug (devido à incompatibilidade com ActiveRecord), eles aparentemente ficaram irritados porque eu encontrei um problema e fui empurrado. Enquanto eu estava testando, também encontrei um grande bug com a implementação da consulta, enquanto o teste foi ajustado de forma que os testes passassem. Depois da minha experiência anterior, não ousei enviá-lo.

Eles têm um número significativamente menor de solicitações pull e envio de bug / recursos do que o MongoId, ou seja, a participação da comunidade é muito menor. Mesma experiência que a minha?

Não sei qual tem mais recursos agora, mas não vejo muito futuro no MongoMapper. Não me importo em consertar problemas e adicionar funcionalidades, mas me importo em situações em que eles não consertariam bugs.

Tenho usado os dois nas últimas semanas. Mongomapper tem melhor suporte para associações relacionais (não incorporadas) e tem maior suporte de terceiros. O Mongoid tem melhor suporte a consultas, documentação muito melhor (MM tem quase nenhum, embora um site esteja supostamente em obras), suporte Rail 3 (e, portanto, suporte Devise) e uma comunidade um pouco mais ativa no Google Groups.

Acabei indo com Mongoid.

Diferenças

MongoMapper

• Alegou ter melhor suporte para associações relacionais.
• Considerado mais extensível por causa de sua arquitetura de plug-in.
• Usa um DSL para fazer consultas.
• As associações muitos-para-muitos são atualizadas apenas de um lado no MongoMapper.
• Suporte menos robusto para documentos incorporados. Atualiza todo o modelo, mesmo se apenas alguns atributos forem modificados.

Mongóide

• Sugerido para ser mais rápido que o MongoMapper por evidências anedóticas.
• Suporte mais robusto para documentos embutidos, usando operações atômicas MongoDB ($ set, $ push, $ pull, etc.) para atualizar documentos aninhados no local.
• Suporta associações muitos-para-muitos bidirecionais.
• Usa uma sintaxe semelhante a ARel que pode ser encadeada para consultas.

Semelhanças

• Ambos MongoMapper e Mongoid têm sites com boa documentação. MongoMapper foi alegado por muito tempo ter uma documentação ruim, mas seu novo site parece fechar a lacuna.
• Ambos podem ser configurados por meio de um arquivo YAML e ambos têm um gerador de trilhos para esse arquivo.
• Ambos são totalmente compatíveis com 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 suporte de terceiros. Github revela o seguinte:

• Pesquisar por "Mongoid" produz 12671 resultados.
• Pesquisar por "MongoMapper" produz 4708 resultados.

Notavelmente, o Devise não oferece suporte ao MongoMapper.

Confirmar atividade

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

MongoMapper

Mongóide

Uma diferença que descobri é que update_attributeno MongoMapper parece escrever todo o documento, independentemente dos atributos realmente alterados. No Mongoid, ele grava apenas os atributos alterados. Isso pode ser um problema de desempenho significativo para registros grandes. 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

Em save, MongoMapper salvará todo o profileregistro, mas MongoId usará o$set operador com lógica posicional para atualizar apenas o rótulo que mudou.

Outro problema é selecionar quais campos retornar. Ambos suportam um onlycritério, mas o Mongoid também suporta umwithout critério, que é nativamente compatível com o Mongo.

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

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

Também faça como eles recomendam no site monogdb, selecione apenas os campos que você precisa.

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

Nenhuma conclusão de velocidade ainda - mas a troca foi indolor - funciona com Rails 3 também.

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

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

Eu usei os dois e eles estão quase iguais em funcionalidade, mas olhe para as estatísticas do código

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

Você pode calcular essas estatísticas por si mesmo, aqui está o analisador https://github.com/alexeypetrushin/code_stats

Acho que o Mongoid é muito melhor em configuração e mapeamento.

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

sudo gem install mongo_ext é a chave para obter desempenho.

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

Referência: http://www.snailinaturtleneck.com/blog/?p=74

O Devise não suportava MongoMapper, e eu também prefiro mover no modo Rails3. Então mudei para mongóide.

Mongoid está tendo um suporte completo com Rails3 e tendo recurso de mapa de identidade.

Mais documentos estão em http://mongoid.org

Veja o desempenho aqui http://mongoid.org/performance.html

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

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

2.Mongoid oficialmente suporta e funciona no cabeçote Ruby 1.8.7, 1.9.1 e 1.9.2.

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

4.MongoMapper tem melhor suporte de associação relacional e funciona assim como padrão.

5.MongoMapper é mais extensível, com uma arquitetura de plug-in que torna muito fácil para as pessoas estendê-lo com suas próprias bibliotecas. Mongoid não tem isso.

6.MM suporta mapas de identidade, Mongoid não.

7.MM tem uma comunidade maior e provavelmente mais suporte para bibliotecas de terceiros. Eu fiquei louco com documentação e rdoc.

8.Mongoid suporta clusters de replicação Master / Slave. (Grava para o mestre, o round robin lê para os escravos) MM não.

9.Mongoid tem uma API de critérios de estilo ARel extremamente rica, o MM usa localizadores de estilo AR2.