Após alguns testes, decidimos utilizar a importação com algumas opções, como abaixo:

mongoimport -d [DB_NAME] --upsert --stopOnError -c [COLLECTION] [IMPORT_FILE]

onde:

• DB_NAME: nome do database
• --upsert: atualiza documentos que já existirem (abaixo falarei mais sobre isso);
• --stopOnError: interrompe a importação caso ocorra algum erro em alguma linha do arquivo de importação;
• COLLECTION: nome da collection;
• IMPORT_FILE: arquivo com os os dados a serem importados (falarei mais sobre isso)

Quando utilizada a opção --upsert, ao importar uma linha, o mongo irá procurar se existe algum documento com esse ID no banco e se existir sobrescreverá esse pelo que está no arquivo de importação, mas atenção, ele não faz e não tem como fazer um MERGE, que é uma feature request no mongodb, ele irá sobrescrever todos atributos desse documento!

Se não utilizada a opção --upsert, as linhas que já existirem no mongo serão ignoradas pela importação

Para rodar o mongoimport, é preciso gerar um arquivo de importação seguindo o exemplo na documentação do mongoimport

É preciso tomar cuidado ao gerar esse arquivo, por exemplo alguns campos como created_at e updated_at que são criados automaticamente ao inserir um novo documento, não são criados se não forem colocados nesse arquivo de importação. Também precisamos tomar cuidado com os campos de relacionamento, mesmo que esse documento não esteja relacionado, é preciso colocar no json o campo com o valor vazio.

Na nossa implementação para geração desse arquivo, fizemos um metodo to_mongo_json no modelo a ser importado, para que gerasse o json esperado pelo mongoimport de cada documento.

Para isso utilizamos o método attributes para pegar todos atributos do documento e gerar o json, além disso precisamos converter alguns valores (data, object_ids, etc..) de acordo com essa página

Ao rodar o comando mongoimport, é impresso a taxa de importação. Nos testes que fizemos chegamos a taxas de até 9mil documentos por segundo, muito rapido! Se fizéssemos o create de cada documento individualmente no Rails, demoraria muito mais.

Como no mongoimport não existe a opção de merge dos dados, como mencionado acima, a solução seria gerar o json desse documento com todos os dados existentes e rodar o mongoimport com a opção --upsert. Assim poderíamos ter problemas, pois se enquanto a importação estivesse sendo processada, se um documento fosse atualizado pela aplicação, e ele já tivesse seu json gravado no arquivo de importação, ao rodar o mongoimport, os dados atualizados nesse meio tempo seriam perdidos.

O ideal nesse caso seria atualizar somente os novos dados com uma opção de merge que não existe, como falamos acima. Nossa solução foi separar os documentos que já existem no mongo dos que são novos. Para os novos utilizamos o mongoimport normalmente, já para os existentes, não colocamos no arquivo de importação e simplesmente rodamos a query de update direto no mongo, como o exemplo abaixo:

MODEL.collection.update({_id: MODEL.id}, { "$set" => { lala: "popo" }, "$addToSet" => { list_ids: {"$each" => lists.map(&:id)} } })

O método collection.update é o que o mongoid utiliza internamente para executar as queries no mongodb e pelos testes que fizemos é muito mais rápido do que se utilizássemos o método save do objeto.

* Créditos também ao @marciotrindade e Claudio Bruno Martins

A primeira idéia seria se aproveitar do fato do Mongo não ter uma estrutura definida para as collections (tabelas) e criar os campos customizáveis dinamicamente no modelo. No mongoid existe a configuração allow_dynamic_fields que permite que sejam inseridos campos dinamicos no modelo. Mas nessa solução temos alguns problemas, entre eles:

1. perdemos o controle dos campos customizados que foram criados, pois teriamos que varrer cada documento e ver quais campos existem
2. nao temos o controle do tipo de campo customizado que foi criado, por exemplo não saberíamos se ele deve se comportar como uma string, data ou inteiro
3. temos que nos preocupar em proteger os campos default, por exemplo state, id, created_at, etc.. e não permitir que o usuário consiga apagar ou editar esses campos
4. teríamos que implementar getters e setters no modelo para esses campos, pois não conseguiríamos definir os fields que é o jeito padrão do mongoid

A sugestão é criar um campo no modelo chamado custom_fields (ou algo parecido) e externamente um cadastro de campos customizáveis, desse jeito temos algumas vantagens:

1. temos a lista dos campos customizáveis que existem e seus tipos (data, string, inteiro, etc..)
2. só precisamos liberar o campo custom_fields para alteração e os campos default podem ficar protegidos no modelo
3. podemos fazer buscas tipadas, por exemplo se um campo for do tipo data, buscar por um range de datas

Utilizando mongoid, a implementação ficaria desse jeito:

field :custom_fields, type: Hash   , default: {}

Desse jeito, no mongodb, os campos customizáveis ficam armazenados do mesmo jeito que se fossem embed documents

Criando índice de campos customizáveis

O Mongo permite que sejam criados índices desses campos customizáveis mesmo que alguns documentos dessa collection não tenham esse campo, e melhor ainda, mesmo que nenhum documento tenha esse campo customizável. Desse jeito podemos por exemplo, criar um índice em "custom_fields.empresa" mesmo que esse campo ainda não exista, mas quando ele for criado já terá um índice!

No exemplo abaixo temos uma busca feita no mongo sem o índice e logo após a criação do índice e a nova busca. Podemos ver que na primeira, foram percorridos os 1002 documentos e na 2a, somente os 482 do sexo "fem"

*Créditos também ao @marciotrindade e Claudio Bruno Martins por esse conteúdo