Design Mongo DB, incorporação versus relacionamentos

Question

Estou construindo um sistema contábil simples, onde um usuário tem muitas contas. Agora estou tentando decidir se as contas devem ser sua própria coleção ou aninhadas no usuário. Estou me inclinando para o primeiro, mas nunca fiz nenhuma coisa noSQL, então só estou indo de tentativa e erro e o que acho que faz sentido para mim.

Entendo que o Mongo tem um limite de tamanho de documento de 4 MB, que é o que está me fazendo pensar que eu deveria ter uma coleção separada para contas, pois elas se acumulam diariamente e podem eventualmente ocupar uma grande quantidade de espaço.

Estou apenas procurando opiniões sobre o assunto. Basicamente, estarei consultando as contas de um usuário entre diferentes períodos de data (como você pode imaginar um sistema contábil faria).

Não que isso realmente importa, mas estou usando o Mongoid em um projeto Rails3. Eu imaginei que faria algo como:

class User
  references_many :bills
end

class Bill
  referenced_in :user
end

Quaisquer comentários ou sugestões de design são muito apreciados.

Answer 1

1) Em relação ao limite de documentos de 4 MB, é isso que o "MongoDB: The Definitive Guide" diz:

Documentos maiores que 4 MB (quando convertidos em BSON) não podem ser salvos no banco de dados. Este é um limite um tanto arbitrário (e pode ser levantado no futuro); É principalmente para evitar o design de esquema ruim e garantir um desempenho consistente. Para ver o tamanho do BSON (em bytes) do documento Doc, execute object.bsonsize (Doc) da concha.

Para lhe dar uma idéia de quanto 4 MB é, todo o texto de Guerra e Paz é apenas 3,14 MB.

No final, depende de quão grande você espera que as contas de um usuário cresçam. Espero que o trecho acima lhe dê uma idéia dos limites impostos pelo tamanho do documento.

2) Esquema desnormalizado (as contas vão com o documento do usuário) é o caminho a percorrer se você souber que nunca vai executar consultas globais em contas (exemplo dessa consulta é se você deseja recuperar as dez contas mais recentes inserido no sistema). Você precisará usar o Reduce do MAP para recuperar resultados para essas consultas se usar um esquema desnormalizado.

O esquema normalizado (usuário e contas em documentos separados) é uma escolha melhor se você quiser flexibilidade na maneira como as contas são consultadas. No entanto, como o MongoDB não suporta junções, você precisará executar várias consultas toda vez que deseja recuperar as contas correspondentes a um usuário.

Dado o caso de uso que você mencionou, eu iria com esquema desnomalizado.

3) Todas as atualizações no MongoDB são atômicas e serializadas. Isso deve responder à preocupação de Steve.

Você pode achar esses slides úteis. http://www.slideshare.net/kbanker/mongodb-meetup

Você também pode olhar para a página de implantações de produção do MongoDB. Você pode encontrar os slides SF.NET úteis.

Answer 2

Uma pergunta que você pode querer considerar é que haverá um momento em que você precisará fazer referência às contas individualmente, além de sua associação a um usuário? Nesse caso, será mais simples se eles tiverem uma existência independente.

Além disso, o problema de limite de tamanho que você já identificou é um bom motivo para dividi -los.

Também pode haver um problema transacional, se você estiver escrevendo um grande usuário com muitas contas incluídas, o que acontece se você receber gravações razoavelmente simultâneas de alterações no mesmo usuário de diferentes conexões? Não sei o suficiente sobre Mongo para saber como isso resolveria isso - meu palpite seria que, se as gravações contivessem diferentes contas adicionais, você conseguiria os dois, mas se eles contivessem diferentes mudanças nas contas existentes, você obteria substituição - Espero que outra pessoa comente sobre isso, mas pelo menos eu testaria. Se você está escrevendo as contas para uma coleção separada, isso não é uma preocupação.

Answer 3

Faz muito tempo desde que essa pergunta foi abordada, mas eu estava lidando com algo semelhante e achei que acrescentaria minhas descobertas para qualquer outra pessoa pesquisando esse problema.

Meu entendimento é que o documento de 4 MB foi expandido para 16 MB nas versões 1.8+. Isso foi de uma apresentação em vídeo de Banker, que é um dos membros do MongoDB. Não verifiquei esse valor, mas estou aceitando sua palavra (já que ele esperançosamente saiba do que está falando).

Quanto à pergunta sobre o que acontece quando várias atualizações ocorrem no mesmo usuário com contas incorporadas ... novamente na mesma apresentação em vídeo, a resposta fornecida é que o MongoDB atualiza as informações tão rapidamente que geralmente não é um problema. A instância do MongoDB está bloqueada enquanto as atualizações ocorrem, portanto, várias atualizações não devem ser um problema.

Uma preocupação que eu tinha sobre documentos incorporados é que eles não podem ser tratados independentemente do documento pai. Isso, na minha opinião, torna os documentos incorporados um pouco inúteis. Eles são úteis apenas para casos de nicho que atendem a casos de uso específicos.

Pessoalmente, descobri que o MongoDB (e o NOSQL DBS) são úteis para casos específicos, mas que o SQL/RDMSS tradicional ainda é melhor para a maioria dos problemas. Se você é alguém como o Craigslist e uma alteração de esquema leva 2 meses para executar seus dados arquivados, então sim, MongoDB e NoSQL fazem sentido. Mas, para a grande maioria dos aplicativos, não acho que lidar com essa quantidade de dados será uma grande preocupação.