Tout le monde connaît MongoDB chez les utilisateurs de bases NoSQL. Kelly Stirman, Directeur Marketing Produit chez MongoDB répond à nos questions concernant cette version 2.6. Parmi toutes les améliorations, nous avons enfin plus d'informations concernant une des fonctionnalités les plus suivies et les plus demandées du JIRA MongoDB : le verrouillage au niveau des collections.
En MongoDB, la fragmentation du stockage peut produire des latences inattendues lorsque des mises à jour obligent le moteur à déplacer un document dans le stockage BSON. Peux-tu nous expliquer comment la 2.6 permet d'atténuer ce problème ?
Lorsqu'un document est mis à jour en MongoDB, la mise à jour est faite sur place si l'espace est suffisant. Si la taille du document mis à jour dépasse celle de l'espace alloué, alors le document est copié ailleurs. MongoDB finira par réutiliser l'espace initial mais cela peut prendre du temps et l'espace alloué peut être trop important.
En MongoDB 2.6, l'espace de stockage alloué par défaut aura une stratégie en puissance de 2 (powerOf2Sizes), une option qui existe depuis MongoDB 2.2. Cette configuration permet à MongoDB d'arrondir l'espace alloué à la puissance de 2 (ex : 2, 4, 8, 16, 32, 64, etc). Cela permet de réduire les chances de devoir déplacer un document et d'utiliser l'espace de manière plus efficace, ce qui conduit à moins de sur-allocation et à des niveaux de performances davantage prévisibles. Les utilisateurs peuvent continuer à utiliser la stratégie d'allocation fixe qui est plus efficace dans la gestion de l'espace si la taille des documents n'augmente pas.
L'indexation peut être très utile en SQL comme en NoSQL, mais elle peut devenir un vrai problème pour le maintien des performances d'écriture quand le système grandit. Peux-tu nous expliquer comment l'intersection d'index en 2.6 peut aider à réduire le nombre d'index nécessaires ?
Prenons par exemple une application de rapports de ventes : un chef de produit veut identifier tous les clients qui ont acheté plus qu'une certaine quantité d'un numéro de pièce spécifique. Grâce à l'intersection d'index, les index sur les numéros de pièce et sur les quantités peuvent être combinés pour optimiser la requête, plutôt que d'avoir besoin d'un index composé spécifique. Cela signifie également une réduction de la taille de la base et des mises à jour plus efficaces.
L'intersection d'index supporte pour le moment l'intersection de 2 index et obtient ses meilleurs résultats lorsque la cardinalité des ensembles est proche, en particulier pour les requêtes pouvant être résolues par des index couverts. En cas de prédicats multi-champs connus à l'avance, les requêtes seront résolues plus rapidement avec des index composés.
Les intersections d'index amélioreront également les performances de certaines requêtes à index simple qu'on pourrait qualifier d'auto-intersection. Avec des opérateurs comme
inouall, MongoDB 2.6 pourra scanner plusieurs fois l'index et faire l'intersection des résultats. Cela peut réduire considérablement le nombre de documents complets devant être remontés par une requête.
Les documents orphelins peuvent produire des résultats incorrects pour certaines requêtes. Peux-tu nous dire comment la 2.6 va nous aider à résoudre ce problème ?
En conditions normales, il n'y aura pas de documents orphelins dans votre système. Cependant, dans certains cas d'échec lors de la migration de blocs, des documents orphelins peuvent être laissés de côté. Leur présence peut produire des résultats incorrects sur certaines requêtes. Bien que ces documents soient supprimables, dans les versions avant la 2.6, il n'y avait pas de façon simple pour le faire. Avec MongoDB 2.6, nous avons implémenté une nouvelle commande d'administration pour les clusters partagés : cleanupOrphaned(). Cette commande supprime les documents orphelins d'un shard pour un intervalle de données. Un de nos ingénieurs support a d'ailleurs publié un article de blog sur ce sujet.
MongoDB en entreprise est devenu de plus en plus commun. Comment se positionne MongoDB dans l'écosystème NoSQL en termes d'adoption en entreprise et quelles sont les fonctionnalités clés que cette 2.6 vient améliorer ?
MongoDB est largement utilisé dans de nombreuses organisations, dont 30 des entreprises du Fortune 100. Nous voyons des entreprises à la recherche de bases de données pour standardiser leur système et qui se tournent vers MongoDB car on peut l'utiliser pour une grande variété d'applications grâce à son modèle de données très flexible, ses index riches, sa scalabilité et comment cette base permet d'accroître la productivité de leurs équipes de développement.
MongoDB 2.6 apporte de nombreuses améliorations de sécurité qui sont critiques pour le monde de l'entreprise. Parmi ces fonctionnalités, on trouve le LDAP, x.509, l'authentification Kerberos, le chiffrage SSL, les rôles utilisateurs, l'audit, et la sécurité au niveau des champs. IBM Guardium permet aussi l'intégration avec MongoDB ce qui apporte davantage de capacités d'audit.
Un autre avantage non négligeable est la taille de notre écosystème qui inclut maintenant plus de 400 partenaires. Bon nombre de ces partenaires proposent des intégrations de MongoDB comme Informatica, Microstrategy, QlikTech, Pentaho, Talend et bien d'autres.
La recherche texte intégral est une fonctionnalité qui a été massivement réclamée et même si la 2.4 bénéficiait d'une implémentation expérimentale, commitée par Eliot lui-même, avec la 2.6 l'opérateur $text fait son apparition. L'implémentation est-elle mature en 2.6 et quelle position cela apporte-t-il dans la compétition des bases de données NoSQL ?
Nous avons travaillé conjointement pendant toute l'année passée sur la recherche texte intégral et comment intégrer ces possibilités avec les autres fonctionnalités. Maintenant qu'elle n'est plus en beta, cette fonctionnalité est prête pour la production en MongoDB 2.6 et offre :
L'intégration avec le moteur de requête de MongoDB, de telle sorte que les recherches textes puissent aller de pair avec les opérateurs de requête pour profiter des fonctions comme limit, skip, sort et filter. Par exemple, un utilisateur pourrait rechercher une phrase dans une collection d'articles de blog puis restreindre les résultats aux 7 derniers jours grâce à une condition supplémentaire ; nous supportons également les documents dans plusieurs langues ; les expressions de texte peuvent être utilisées avec le Framework d'aggrégation, permettant ainsi d'accéder à des fonctionnalités plus avancées pour compter et grouper les résultats.
D'autres fournisseurs de NoSQL proposent des intégrations à des solutions tierces, dédiées à la recherche texte comme SOLR et Elastic Search. Cette approche ajoute de la complexité et des coûts de déploiement, nécessite des compétences supplémentaires et ces index sont inconsistants avec les données sous-jacentes. Nous pensons que la recherche texte native offre une facilité de déploiement, des coûts moindres et la capacité de profiter de compétences préexistantes, tout en restant consistant avec les données sous-jacentes. Cependant, certaines fonctionnalités disponibles dans les moteurs dédiés ne sont pas disponibles dans MongoDB. Dans ce cas-là, nous proposons des solutions d'intégration comme les autres fournisseurs de NoSQL. Les utilisateurs peuvent choisir l'option qui leur convient le mieux.
Une des fonctionnalités probablement les plus demandées est une pose de verrou plus fin. Quelle est votre roadmap pour aller plus en profondeur que le niveau de la base de données ? Quels sont les points majeurs qui bloquent la progression pour des verrous au-delà du niveau d'une collection ?
C'est important de se souvenir qu'en MongoDB, les verrous sont très proches des loquets en RDBMS (NDT : Relational database management system) – ils sont très simples et généralement maintenus pour 10 microsecondes ou moins. Les verrous plus avancés qui ont été introduits en MongoDB 2.2 ont considérablement réduit le nombre de problèmes remontés par la communauté concernant la concurrence pour les verrous. Cependant, nous sommes conscients qu'il y a encore de la place pour améliorer la concurrence, entre autres avec une meilleure granularité des verrous.
MongoDB 2.8 aura un système de verrous au niveau des documents. Nous pensons que le gain sera nettement plus avantageux que celui apporté par les verrous au niveau des collections, pour un grand nombre d'applications. Mais l'affinage des verrous n'est pas le seul biais d'amélioration de la concurrence et il y aura d'autres parties de la base de données qui seront améliorées pour améliorer la gestion de la concurrence. MongoDB 2.6 apporte déjà des améliorations, et il y en aura encore plus en MongoDB 2.8.
MongoDB 2.6 apporte-t-il d'autres améliorations aux problématiques de verrous ?
Oui, plusieurs axes ont contribué à améliorer la concurrence. Par exemple, l'intersection d'index réduit le nombre d'index nécessaires pour de nombreuses applications, ce qui devrait améliorer la scalabilité des écritures. Une grosse partie du travail que nous faisions auparavant dans le verrou est maintenant effectué à l'extérieur, comme la lecture et la génération d'
_id. Nous avons également beaucoup travaillé sur l'amélioration de la concurrence d'écriture de l'oplog, à la fois en augmentant la vitesse d'écriture et en modifiant la gestion des verrous. Cela améliore la concurrence en 2.6 et était nécessaire avant tout travail pour affiner la granularité des verrous où ils seraient devenus le prochain goulot d'étranglement.