Ce à quoi vous faites référence est souvent appelé "compression de clé"*. Il y a plusieurs raisons pour lesquelles il n'a pas été implémenté :
- Si vous le souhaitez, vous pouvez actuellement le faire assez facilement au niveau Application/ORM/ODM.
- Ce n'est pas nécessairement un avantage en termes de performances** dans tous les cas :pensez à des collections avec de nombreux noms de clé et/ou des noms de clé qui varient énormément d'un document à l'autre.
- Il est possible que cela n'offre aucun avantage mesurable en termes de performances** tant que vous n'avez pas des millions de documents.
- Si le serveur le fait, les noms de clé complets doivent encore être transmis sur le réseau.
- Si les noms de clé compressés sont transmis sur le réseau, alors la lisibilité vraiment souffre de l'utilisation de la console javascript.
- La compression de l'intégralité du document JSON
pourrait offriroffre un avantage encore meilleur en termes de performances.
Comme toutes les fonctionnalités, il existe une analyse coûts-avantages pour l'implémenter, et (du moins jusqu'à présent) d'autres fonctionnalités ont offert plus de "rapport qualité-prix".
La compression complète du document est [en cours d'examen][1] pour une future version de MongoDB. disponible à partir de la version 3.0 (voir ci-dessous)
* Une table de recherche en mémoire pour les noms de clé est essentiellement un cas particulier de compression de style LZW - c'est plus ou moins ce que font la plupart des algorithmes de compression.
** La compression offre à la fois un avantage d'espace et un avantage de performance. Des documents plus petits signifient que plus de documents peuvent être lus par IO, ce qui signifie que dans un système avec des IO fixes, plus de documents par seconde peuvent être lus.
Mettre à jour
Les versions 3.0 et supérieures de MongoDB ont désormais une capacité de compression complète des documents avec WiredTiger moteur de stockage.
Deux algorithmes de compression sont disponibles :snappy , et zlib . L'intention est que snappy soit le meilleur choix pour des performances globales, et que zlib soit le meilleur choix pour une capacité de stockage maximale.
Dans mon expérimentation personnelle (non scientifique, mais liée à un projet commercial), la compression rapide (nous n'avons pas évalué zlib) offrait une densité de stockage considérablement améliorée sans coût de performance net notable. En fait, les performances ont été légèrement meilleures dans certains cas, ce qui correspond à peu près à mes commentaires/prédictions précédents.
