Marcos, sharding não deve resolver o problema. Régis, o limite do
tamanho dos documentos nem é o problema. O problema é que você não
deve embedar um vetor de subdocumentos que pode crescer para um
tamanho arbitrário.
O motivo é que quando um documento é inserido, o MongoDB aloca espaço
no disco para o tamanho dele mais algum padding para que ele possa
crescer. Se o documento crescer além desse tamanho determinado na
inserção, o MongoDB vai ter de copiar os dados para o final da
collection no disco e isso degrada a performance de updates bastante.
Pra documentos que sejam extremamente voláteis, você pode mudar o
padding envolta do documento manualmente [1].
Em termos gerais de modelagem, a recomendação é nunca ter arrays que
possam crescer indefinidamente, só arrays que tenham um tamanho
previsível. Assim, há algum fator de padding sobre o tamanho dos
documentos que garantira que updates não movem as coisas no disco
todas as vezes.
Dependendo do seu workload, vale a pena misturar referências com
sub-documentos. Por exemplo, mantenha um vetor de tamanho limitado no
documento cidade, com os ids e informações gerais das últimas
denúncias da cidade e todas as denúncias em sua própria collection,
com mais informações. Assim, você pode buscar todas as informações
"necessárias" para mostrar uma única cidade, sem fazer dois queries.
Mas acaba tendo um modelo muito mais flexível para as denúncias.
Quando você for atualizar uma cidade e adicionar mais denúncias, você
pode atualizar esse field com as últimas denúncias usando o $slice
[2].
[1] -
http://docs.mongodb.org/v2.4/core/record-padding/
[2] -
http://docs.mongodb.org/manual/reference/operator/update/slice/
https://github.com/yamadapc
https://twitter.com/yamadapc
https://keybase.io/ym