Você notou corretamente que os documentos terão tamanhos diferentes. Assim, você economizará pelo menos 15 bytes por documento (60% para documentos semelhantes) se você decidir adotar o segundo esquema. Isso terminará em algo como 140MB para seus 10 million registros. Isso lhe dará a seguinte vantagem:

• Economia de HDD. O único problema é que, olhando para os preços do HDD atual, isso é praticamente inútil.
• Economia de RAM. Em comparação com discos rígidos, isso pode ser útil para indexação. No conjunto de trabalho do mongodb de os índices devem caber na RAM para obter um bom desempenho . Portanto, se você tiver índices nesses dois campos, não apenas economizará 140MB de espaço no disco rígido, mas também 140MB de espaço RAM potencial (que é realmente perceptível).
• E/S . Muitos gargalos acontecem devido à limitação do sistema de entrada/saída (a velocidade de leitura/gravação do disco é limitada). Para seus documentos, isso significa que com o esquema 2 você pode potencialmente ler/escrever twice as many documents por 1 segundo.
• rede . Em muitas situações, a rede é ainda mais lenta que o IO, e se o servidor de banco de dados estiver em uma máquina diferente do servidor de aplicativos, os dados devem ser enviados pela rede. E você também poderá enviar o dobro de dados.

Depois de falar sobre as vantagens, tenho que contar uma desvantagem para chaves pequenas:

• legibilidade do banco de dados. Quando você faz db.coll.findOne() e vê {_id: 1, t: 13423, a: 3, b:0.2} é muito difícil entender o que exatamente está armazenado aqui.
• legibilidade do aplicativo semelhante com o banco de dados, mas pelo menos aqui você pode ter uma solução. Com uma lógica de mapeamento, que transforma currentDate para c e price para p você pode escrever um código limpo e ter um esquema curto.