Vous avez correctement remarqué que les documents auront une taille différente. Vous économiserez donc au moins 15 bytes par document (60% pour des documents similaires) si vous décidez d'adopter le second schéma. Cela se terminera par quelque chose comme 140MB pour vos 10 million enregistrements. Cela vous donnera l'avantage suivant :
- Économies de disque dur. Le seul problème est qu'en regardant les prix des disques durs actuels, cela est généralement inutile.
- Économie de RAM. En comparaison avec les disques durs, cela peut être utile pour l'indexation. Dans mongodb, l'ensemble de travail les index doivent tenir dans la RAM pour obtenir un bon performances
. Donc, si vous avez des index sur ces deux champs, vous économiserez non seulement
140MBd'espace disque dur mais aussi140MBd'espace RAM potentiel (ce qui est en fait perceptible). - E/S . De nombreux goulots d'étranglement se produisent en raison de la limitation du système d'entrée/sortie (la vitesse de lecture/écriture à partir du disque est limitée). Pour vos documents, cela signifie qu'avec le schéma 2 vous pouvez potentiellement lire/écrire
twice as many documentspar 1 seconde. - réseau . Dans de nombreuses situations, le réseau est encore plus lent que les E/S, et si votre serveur de base de données se trouve sur une machine différente de votre serveur d'applications, les données doivent être envoyées via le réseau. Et vous pourrez également envoyer deux fois plus de données.
Après avoir parlé des avantages, je dois vous dire un inconvénient pour une petite clé :
- lisibilité de la base de données. Lorsque vous faites
db.coll.findOne()et voit{_id: 1, t: 13423, a: 3, b:0.2}il est assez difficile de comprendre ce qui est exactement stocké ici. - lisibilité de l'application similaire avec la base de données, mais au moins ici, vous pouvez avoir une solution. Avec une logique de mappage, qui transforme
currentDateàcetpriceàpvous pouvez écrire un code propre et avoir un schéma court.
