Match de rancune NoSQL: MongoDB contre Couchbase Server

Choisir la bonne base de données pour le travail peut être une tâche ardue, en particulier si vous utilisez tout l'espace des options SQL et NoSQL. Si vous recherchez une option flexible et polyvalente qui permet des schémas fluides et des structures de données imbriquées complexes, une base de données de documents peut vous convenir. MongoDB et Couchbase Server sont deux choix populaires. Comment choisir?

MongoDB combine les avantages d'une immense popularité, de la prise en charge de recherches de graphiques simples et de la possibilité d'effectuer des requêtes SQL via un connecteur BI. Couchbase possède sa propre grande communauté d'utilisateurs, une architecture clé-valeur performante et un langage de requête de type SQL capable de naviguer dans les structures de documents imbriquées.

En bref, MongoDB et Couchbase sont des bases de données puissantes et flexibles orientées document avec de nombreux extras. Cela dit, ils présentent des différences importantes qui font pencher la balance d'une manière ou d'une autre, en fonction de vos besoins. Pour vous aider à prendre une décision, nous allons parcourir ces bases de données à travers le gant de considérations clés, couvrant les performances de chacune en ce qui concerne l'installation et la configuration, l'administration, la facilité d'utilisation, l'évolutivité et la documentation.

Cette discussion est basée sur MongoDB 3.4 et Couchbase Server 4.6. Vous pouvez également consulter mes critiques autonomes de MongoDB 3.4 et Couchbase Server 4.0.

Installation et configuration

L'installation et la configuration peuvent être vues sous deux angles: les développeurs travaillant sur une instance locale et les ingénieurs d'infrastructure configurant un cluster de production initial. De nombreuses bases de données NoSQL ont des histoires fortes sur la convivialité des développeurs, augmentant les chances d'un développeur d'essayer le produit et de l'introduire dans ses systèmes. Une configuration locale simple est un argument de vente fort. D'autre part, la base de données prouvera finalement sa valeur en production, de sorte que la configuration de la production est tout aussi importante pour bien faire.

Configuration du développeur

Plutôt que d'utiliser des binaires s'exécutant sur le bare metal, nous examinerons ce qu'il faut pour configurer ces deux bases de données dans un environnement Docker. La configuration de Docker pour MongoDB et Couchbase est assez simple. Couchbase nécessite quelques ports supplémentaires pour être exposés, mais c'est une question simple à gérer. Une fois que les images sont extraites et que les conteneurs démarrent, il y a une différence notable dans l'expérience du développeur. Avec MongoDB, vous avez terminé. Vous pouvez vous connecter via une application ou le shell Mongo et vous mettre au travail immédiatement. En revanche, Couchbase vous guide à travers un processus de configuration obligatoire via l'interface utilisateur où vous êtes confronté à un tas d'options de configuration destinées aux ingénieurs d'infrastructure. En tant que développeur, vous pouvez conserver les options sélectionnées et utiliser un bucket par défaut, mais cela ajoute de la friction à l'expérience.

MongoDB remporte celui-ci, mais non sans mise en garde. Ce n'est pas parce que le déploiement local a été facile que vous pouvez faire la même chose en production. Il peut sembler évident que les environnements de production nécessitent plus de soins et de configuration, mais les attaques de rançon généralisées contre les instances MongoDB non sécurisées et accessibles au public plus tôt cette année suggèrent que de nombreux magasins prennent des raccourcis dangereux.

Vainqueur du tour: MongoDB.

Configuration de la production

Le déploiement d'une base de données distribuée en production implique généralement de nombreuses étapes et un degré raisonnable de coordination; MongoDB et Couchbase ne sont pas différents. Dans les deux cas, la difficulté de la configuration dépendra des exigences du déploiement, avec différents compromis de performances impliquant différents niveaux de complexité.  

Les clusters MongoDB seront soit constitués d'un jeu de réplicas, soit d'un cluster partitionné. Un jeu de répliques est un groupe de serveurs MongoDB qui contiennent tous les mêmes données, tandis qu'un cluster partitionné distribue les données sur un certain nombre de jeux de répliques. Les jeux de réplicas sont simples à configurer et consistent en un seul type de serveur à déployer. Les clusters fragmentés sont plus impliqués, nécessitant le déploiement de trois types de serveurs différents, où chacun est répliqué. Les clusters peuvent être configurés via des indicateurs de ligne de commande, des fichiers de configuration et des commandes de base de données.

Les clusters Couchbase peuvent être constitués d'un seul type de serveur ou de plusieurs types de serveurs, selon les caractéristiques de performances dont vous avez besoin pour le cluster. L'architecture Couchbase se compose de différents services qui peuvent être activés ou désactivés par nœud. Dans un scénario simple, vous activez tous les services sur tous les nœuds. Cependant, si vous souhaitez vous adapter aux besoins de chaque service ou si vous souhaitez mettre à l'échelle chaque service indépendamment, vous devrez commencer à configurer différents types de serveurs, à allouer du matériel de base pour le service de données, des disques SSD pour le service d'index, des processeurs optimisés pour le service de requête, et ainsi de suite. Les clusters peuvent être configurés via l'interface utilisateur Web intégrée, l'interface de ligne de commande et l'API REST.

En ce qui concerne la configuration de la production de l'infrastructure de données, MongoDB et Couchbase sont assez clairs. Bien sûr, vous pouvez plonger dans les options de configuration et de réglage sans jamais sortir, mais dans la plupart des cas, ce sera le plus facile pour les ingénieurs d'infrastructure.

Gagnant du tour: Cravate. 

Administration

Une fois que la base de données est en cours de production et accepte le trafic, l'administration devient une préoccupation majeure. Pour évaluer la facilité d'administration, je vais examiner le processus de sauvegarde, les mises à niveau de la base de données et les approches de surveillance.

Sauvegardes

Les sauvegardes sont un élément important de l'hygiène des bases de données de production, et l'exécution des bases de données de manière hautement disponible et distribuée ne change rien à cela.

MongoDB propose plusieurs options pour sauvegarder les données d'un cluster en cours d'exécution. Si le système d'exploitation sous-jacent prend en charge les instantanés à un moment précis, vous pouvez vous fier à cette fonctionnalité pour capturer une sauvegarde à un moment précis. Cela devient un peu délicat pour la sauvegarde de clusters partitionnés car vous devrez prendre un instantané de chaque partition et d'un serveur de configuration en même temps.

Les outils de niveau système tels que cp ou rsync peuvent être utilisés pour copier les fichiers de base de données vers un autre emplacement, mais les écritures doivent être interrompues pendant le processus en raison de la nature de ces outils. Bien que MongoDB soit livré avec des outils de ligne de commande pour sauvegarder et restaurer les bases de données, ces outils ne sont pas recommandés pour les clusters plus importants. Vous pouvez également payer pour Cloud Manager ou Ops Manager, ou déployer via la plate-forme MongoDB Atlas DBaaS pour obtenir des outils basés sur l'interface utilisateur qui prendront en charge les sauvegardes et les restaurations pour vous.

Couchbase est livré avec des outils de ligne de commande pour sauvegarder les données des différents services, et ceux-ci peuvent être configurés pour exécuter des sauvegardes complètes ou deux types de sauvegardes incrémentielles. Les sauvegardes incrémentielles peuvent être soit incrémentielles à partir de la dernière sauvegarde complète (incrémentielle cumulative), soit incrémentielles à partir de la dernière sauvegarde de tout type (incrémentielle différentielle). Cela permet des structures de sauvegarde complexes qui nécessitent différents niveaux d'espace de stockage et impliquent différents niveaux de complexité de restauration.

Les entreprises clientes peuvent s'appuyer sur l'utilitaire cbbackupmgr, qui utilise différentes structures de données sous-jacentes pour obtenir de meilleures performances lors de la sauvegarde des données.

Gagnant du tour: Couchbase, en raison de sa plus grande flexibilité et de sa prise en charge des sauvegardes incrémentielles.

Mise à jour

Un cluster de longue durée doit avoir un chemin de mise à niveau clair et facile. Plus la mise à niveau est difficile, moins elle sera mise à jour. Cela signifie que les développeurs et les administrateurs manqueront de nouvelles fonctionnalités.

Les mises à niveau de MongoDB sont mieux comprises à partir du niveau du jeu de réplicas. Si vous exécutez un cluster partitionné, vous suivez principalement les étapes de mise à niveau des ensembles de réplicas sur chaque partition. Dans un jeu de réplicas, chaque secondaire est arrêté, mis à niveau sur place et démarré. Une fois que les secondaires sont en fonctionnement et cohérents avec le primaire, un basculement est induit et l'ancien primaire peut être arrêté et mis à niveau. Il redémarrera en tant que secondaire et rattrapera les écritures manquées en mode hors connexion. Ainsi, les mises à niveau sont principalement un processus en ligne, mais le basculement principal entraînera probablement 10 à 20 secondes sans écriture, donc une fenêtre de maintenance avec un temps d'arrêt acceptable est nécessaire.

Couchbase aborde les mises à niveau de la même manière que vous ajouteriez ou supprimeriez un nœud d'un cluster. Toutes les données du nœud de mise à niveau doivent être rééquilibrées sur le cluster, puis de nouveau rééquilibrées lorsque la mise à niveau est terminée et que le nœud rejoint le cluster. Ce processus de rééquilibrage doit avoir lieu pour chaque nœud du cluster, l'un après l'autre. Cela prendra beaucoup plus de temps que la mise à niveau d'un cluster MongoDB, en raison de toutes les données qui doivent être déplacées. Une autre option consiste à mettre l'ensemble du cluster hors ligne, à mettre à niveau chaque nœud et à tous les remettre en ligne.

Alors que le chemin de mise à niveau de Couchbase ne nécessite aucun temps d'arrêt, le processus est long et nécessite une quantité importante de brassage de données pour fonctionner.

Gagnant du tour: Cravate. Tiebreaker: Si les temps d'arrêt pour maintenance sont acceptables, MongoDB l'emporte. Sinon, Couchbase est le seul choix.

surveillance

La visibilité dans un cluster en cours d'exécution est évidemment essentielle à une administration réussie de la base de données. Quand les choses vont mal, rien n'est pire que d'avoir une vision limitée de la vérité dans le cluster.

MongoDB propose des outils et des commandes CLI dans le shell qui fournissent des métriques sur l'activité et les performances de l'instance. Au-delà de cela, MongoDB vous orientera utilement vers des outils tiers ou ses propres produits d'entreprise (Cloud Manager, Ops Manager, Atlas).

Couchbase, d'autre part, est livré avec une interface utilisateur Web qui comprend des statistiques et des visualisations pour les instances, les nœuds, les performances des requêtes, etc. De plus, Couchbase peut être configuré pour envoyer des alertes par e-mail lorsque certaines statistiques sont hors de portée.

Gagnant du tour: Couchbase, pour des visualisations et des alertes prêtes à l'emploi.

Facilité d'utilisation

Une fois la base de données configurée et tous nos besoins administratifs satisfaits, la préoccupation majeure passe des opérations à l'utilisation. Je vais décomposer cela en modélisation de données, conception d'index, requêtes de base et agrégations.

La modélisation des données

En tant que bases de données de documents, ni MongoDB ni Couchbase ne peuvent éviter le défi de gérer les données relationnelles. Les deux offrent la possibilité de stocker des données relationnelles sous forme de données imbriquées et dénormalisées ainsi que sous la forme de références à d'autres documents de premier niveau. Cette approche du stockage de données finit par être le principal point à considérer pour la modélisation des données pour les deux bases de données, bien que chacune prenne en charge un éventail croissant de cas d'utilisation, de fonctionnalités et de modèles de requête.

Gagnant du tour: Cravate.

Conception d'index

Les index remplissent la même fonction dans les bases de données de documents que dans les bases de données relationnelles. Autrement dit, ils représentent certaines données de manière plus efficace pour améliorer les performances des requêtes. MongoDB et Couchbase adoptent des approches très différentes de la conception et de la création d'index.

MongoDB prend en charge la création d'index pour un ou plusieurs champs dans un document, vous permettant de spécifier l'ordre et la direction (ascendante ou décroissante) des index standard. Il est également possible d'inclure des index géospatiaux spéciaux et des index de texte intégral dans le cadre de la même syntaxe. Le moteur de requête utilisera ces index, les préfixes de ces index ou une combinaison de plusieurs index pour accélérer les requêtes.

Couchbase s'appuie sur deux mécanismes différents pour améliorer les performances des requêtes: les vues MapReduce et le Global Secondary Index (GSI). Les vues MapReduce se composent de code JavaScript défini par l'utilisateur qui traite les données lors de leur passage dans le système, comme une pré-agrégation incrémentielle. Les vues MapReduce peuvent être aussi simples que permettre des recherches de documents sur un champ interne, ou elles peuvent inclure une logique plus complexe qui effectue des calculs et des agrégations sur les données dans les documents.

Écrire MapReduce en JavaScript pour prendre en charge les requêtes est un peu compliqué, vous voudrez donc généralement utiliser le GSI lorsque cela est possible. Les index dans le GSI sont décrits en utilisant N1QL (prononcé «nickel»), une implémentation SQL partielle au-dessus de Couchbase. La syntaxe N1QL est assez claire et les requêtes N1QL sont bien meilleures que MapReduce, mais vous devez placer l'index sur un nœud spécifique. Si vous souhaitez qu'un index soit hautement disponible, vous devez créer manuellement cet index sur plusieurs nœuds.

Gagnant du tour: MongoDB, pour son API d'indexation consolidée et sa capacité à éviter complètement MapReduce.

Requêtes de base

Étant donné un modèle de données approprié, la plupart des requêtes adressées à la base de données sont généralement simples. Au-delà des opérations CRUD où l'ID du document en question est connu, il est important de pouvoir exprimer différentes manières de filtrer les documents et de choisir les champs qui nous intéressent.

MongoDB décrit les requêtes en JSON, en fournissant une syntaxe déclarative pour spécifier des conditions et des filtres sur les champs. Le document de requête peut être composé de n'importe quel nombre de sélecteurs de requête qui décrivent à quoi devrait ressembler le jeu de résultats. Les plages, l'égalité, la recherche de texte et les requêtes géospatiales peuvent toutes être définies dans ce document de requête. Le document prend en charge les opérateurs booléens, de sorte que plusieurs clauses de requête peuvent être logiquement reliés entre eux avec AND, ORet ainsi de suite. Le document de requête peut rapidement devenir un document JSON fortement imbriqué, ce qui peut parfois être accablant et nécessite certainement un certain temps pour s'y habituer. Il est également possible d'utiliser des projections dans les requêtes, ce qui vous permet de ne renvoyer que les champs qui vous intéressent et de réduire la taille globale du résultat sur le fil.