Numberly has been using both ScyllaDB and MongoDB in production for 5+ years. Learn which NoSQL database they rely on for different use cases and why. Dans le domaine NoSQL, ScyllaDB et MongoDB sont deux animaux complètement différents. MongoDB n'a pas besoin d'une introduction. Son adoption simple et son vaste communauté / écosystème l'ont fait la norme de fait pour commencer avec L'architecture proche du métal de ScyllaDB permet une latence faible prévisible à haute vitesse. , à et beaucoup d'autres qui s'envolent et frapper le mur avec leurs bases de données existantes. Noël discorde Traceur Applications Data Intensive Au lieu de cela, regardons comment ces deux bases de données distinctement différentes pourraient coexister au sein de la même pile technologique – comment elles sont fondamentalement différentes, et les meilleurs cas d’utilisation pour chacun. Tout comme les chaussures différentes fonctionnent mieux pour courir un marathon vs. évoluer le Mont Everest vs. assister à votre mariage, les bases de données différentes fonctionnent mieux pour différents cas d’utilisation avec des charges de travail et des attentes de latence / débit différentes. Alors, quand devriez-vous utiliser ScyllaDB contre MongoDB et pourquoi? Au lieu de fournir la perspective du fournisseur, nous allons partager les idées d'un enthousiaste de l'open source qui a une vaste expérience en utilisant ScyllaDB et MongoDB dans la production: Alexys Jacob, le CTO de Numberly. Voici trois prises de vue clés de son discours technique détaillé: Scaling Writes est plus complexe sur MongoDB L'unité de base d'une topologie MongoDB est appelée un ensemble de répliques, qui se compose d'un nœud primaire et généralement de plusieurs nœuds secondaires (pensez aux répliques chaudes). Seul le nœud primaire est autorisé à écrire des données. Après que vous ayez maxé l'écriture verticale à l'échelle sur MongoDB, votre seule option pour évaluer les écrits devient ce qu'on appelle un cluster fragmenté. Cela nécessite l'ajout de nouveaux ensembles de répliques parce que vous ne pouvez pas avoir plusieurs primaries dans un seul ensemble de répliques. Le partage des données sur les ensembles de répliques de MongoDB nécessite l'utilisation d'une clé spéciale pour spécifier les données pour lesquelles chaque ensembles de répliques est responsable, ainsi que la création d'un ensemble de répliques de métadonnées qui suit quelle tranche de données vit sur chaque réplique (le triangle bleu dans le diagramme ci-dessous). La complexité de l'écriture à l'échelle dans MongoDB Avoir tous ces nœuds entraîne des coûts d'exploitation et de maintenance plus élevés, ainsi que des ressources gaspillées car vous ne pouvez pas appuyer sur l'IO des nœuds de réplication pour écrire, ce qui rend les clusters MongoDB déchirés le pire ennemi de votre coût total de propriété comme Alexys a noté. Pour ScyllaDB, l’écriture à l’échelle est beaucoup plus simple. Il a expliqué : « Du côté de ScyllaDB, si vous voulez ajouter plus de débit, vous ajoutez simplement des nœuds. Alexis a raccordé ce fil d'échelle: "Évitez de créer des clusters MongoDB, s'il vous plaît! Je pourrais écrire un livre avec des histoires de guerre sur ce même sujet. La principale raison est que MongoDB ne lie pas la charge de travail aux CPU. Et le sharding, la distribution des données entre les ensembles de répliques dans un cluster est faite par un travail de fond (l'équilibreur). Cet équilibreur fonctionne toujours, en regardant toujours comment le sharding devrait être fait, et en veillant toujours à ce que les données soient dispersées et équilibrées sur le cluster. Ce n'est pas naturel car il n'est pas basé sur un hachage cohérent. C'est quelque chose qui doit être calculé encore et encore. Il divise les données en morceaux et les déplace ensuite MongoDB favorise la flexibilité par rapport à la performance, tandis que ScyllaDB favorise la performance constante par rapport à la polyvalence ScyllaDB et MongoDB ont des priorités distinctement différentes en ce qui concerne la flexibilité et la performance. Sur le front de modélisation des données, MongoDB prend en charge nativement les requêtes géospatiales, la recherche de texte, les pipelines d’agrégation, les requêtes graphiques et les flux de changement. Bien que ScyllaDB – un magasin large-colonne (a.k.a. key-value) – supporte les types définis par l’utilisateur, les compteurs et les transactions légères, les options de modélisation des données sont plus limitées que sur MongoDB. Alexys a noté, « D’un point de vue de développement, interagir avec un objet JSON se sent tout simplement plus naturel que d’interagir avec une ligne. de la validation du schéma avant l'insertion des données, ScyllaDB Ces données correspondent au schéma défini. Options nécessite La requête est également plus simple avec MongoDB puisque vous ne faites que filtrer et interagir avec JSON. Il est également plus flexible, pour mieux ou pour pire. MongoDB vous permet d'émettre tout type de requête, y compris les requêtes qui causent des performances sous-optimales avec votre charge de travail de production. ScyllaDB ne permettra pas cela. Si vous essayez, ScyllaDB vous avertira. Alexys a résumé les différences clés du point de vue du développement : « MongoDB favorise la flexibilité par rapport à la performance. Il est facile à interagir avec et il ne vous entrera pas en chemin. Mais il aura des impacts sur la performance – des impacts qui sont bons pour certaines charges de travail, mais inacceptables pour d’autres. D’autre part, ScyllaDB favorise une performance cohérente par rapport à la polyvalence. Il a l’air un peu plus fixe et un peu plus rigide à l’extérieur. Mais encore une fois, c’est pour votre bien afin que vous puissiez avoir une performance cohérente, fonctionner bien et interagir bien avec le système. À mon avis, cela fait une réelle différence lorsque vous avez des charges de travail sensibles à la latence et à la performance. » Il est important de noter que même les requêtes qui suivent les meilleures pratiques de performance se comporteront différemment sur MongoDB que sur ScyllaDB. Peu importe votre prudence, vous ne surmonterez pas la pénalité de performance résultant de différences architecturales fondamentales. Ensemble, ScyllaDB et MongoDB sont une grande combinaison NoSQL "Ce n'est pas un match de mort; nous sommes des utilisateurs heureux de MongoDB et de ScyllaDB", a poursuivi Alexys. Numerly sélectionne la meilleure base de données pour les exigences techniques de chaque usage. Chez Numerly, MongoDB est utilisé pour deux types de cas d'utilisation: Web backend avec REST APIs et éventuellement des schémas flexibles. Recherches en temps réel sur des données comportementales imprévisibles. Par exemple, certaines des applications de Numberly sont inondées de données de suivi Web que leurs clients collectent et envoient (chaque client avec ses propres applications développées en interne). Numberly n'a pas de moyen d'imposer un schéma strict sur ces données, mais il doit pouvoir les consulter et les traiter. ScyllaDB est utilisé pour trois types de cas d'utilisation chez Numberly : Des pipelines de données sensibles à la latence en temps réel. Cela implique beaucoup d’enrichissement de données, où il existe plusieurs sources de données qui doivent être corrélées, en temps réel, sur les pipelines de données. Selon Alexys, «C’est difficile à faire... et vous avez besoin de garanties de latence solides pour ne pas enfreindre les SLA [accords de niveau de service] des applications et des processus de données sur lesquels vos clients comptent. » Numerly mélange également beaucoup de charges de travail en lots et en temps réel dans ScyllaDB parce qu’il fournit le meilleur des deux mondes (comme Numerly l’a partagé précédemment). « Nous avions Hive sur un chemin et MongoDB sur l’autre. Certains des backends Web de Numberly sont mis en œuvre dans GraphQL. Lorsque vous travaillez avec des API basées sur des schémas, il est parfaitement logique d’avoir une base de données basée sur des schémas avec une faible latence et une haute disponibilité. Alexys a conclu: «Beaucoup de nos ingénieurs de back-end, et les ingénieurs de front-end aussi, adoptent ScyllaDB. Nous voyons une tendance des gens à adopter ScyllaDB, de plus en plus de gens de technologie demandant ‘J’ai ce cas d’utilisation, ScyllaDB serait-il un bon endroit?’ La plupart du temps, la réponse est ‘oui.’ Donc, l’adoption de ScyllaDB est en croissance. Bonus: Plus d'informations de Alexys Jacob Alexys est un contributeur extrêmement généreux aux communautés open source, en ce qui concerne à la fois le code et les conversations de conférence. https://ultrabug.fr/ à propos par Cynthia Dunlop Cynthia est directrice générale de la stratégie de contenu chez ScyllaDB. Elle écrit sur le développement de logiciels et l'ingénierie de la qualité depuis plus de 20 ans.
