A look at two databases that have made claims to the Kubernetes native label: TiDB and DataStax Astra DB.  La révolution du cloud computing a inspiré et bénéficié de multiples tendances interdépendantes. La disponibilité d'une infrastructure de cloud public en libre-service a contribué à l'adoption d'architectures de microservices et de pratiques DevOps, y compris l'automatisation et l'observabilité.  La tendance à la conteneurisation et à l'orchestration des conteneurs a conduit à l'adoption généralisée de Kubernetes comme environnement de gestion des applications cloud natives.  Mais l'un des domaines à la traîne de cette révolution a été les données et l'infrastructure de données. Pendant trop longtemps, les données ont vécu en dehors de Kubernetes, ce qui a entraîné beaucoup d'efforts et de complexité supplémentaires pour les développeurs lors du déploiement d'applications cloud natives.  Un axiome souvent répété dans les premières années de Kubernetes était qu'il n'était pas encore prêt pour les charges de travail avec état. Heureusement, un changement majeur a été tranquillement en cours et a atteint un point de maturité.  La transformation s'est d'abord produite lentement, en commençant par des efforts pour conteneuriser les bases de données existantes. Cela fonctionnait relativement bien dans les petites bases de données qui s'exécutaient sur un seul nœud de calcul ou dans les bases de données conçues dans un monde natif du cloud, comme Apache Cassandra et DynamoDB, mais des défis subsistaient.  Au cours des deux à trois dernières années, une nouvelle génération de bases de données a émergé. Ces bases de données "natives Kubernetes" ont été conçues dès le départ pour fonctionner sur ce système d'orchestration open source.  Ici, nous définirons les qualités qui rendent une base de données native Kubernetes et les avantages de l'adoption d'une base de données native Kubernetes. Pour ce faire, nous allons examiner deux bases de données revendiquant le label natif Kubernetes : TiDB et DataStax Astra DB.  MySQL natif Kubernetes avec TiDB  Examinons d'abord une base de données à accent relationnel :   (abréviation de Titanium Database). TiDB est un système open source construit par PingCAP qui fournit une   et une base de données en colonnes pour prendre en charge le traitement transactionnel et analytique hybride (appelé HTAP, en abrégé). TiDB base de données compatible MySQL  Comme le montre la figure 1 ci-dessous, TiDB a une conception de microservice. La couche de requête TiDB, les bases de données MySQL TiKV, les bases de données en colonnes TiFlash, les nœuds Spark et la gestion des métadonnées sont chacun déployés en tant que microservices évolutifs dans leurs clusters. Cette conception sépare le travail intensif en calcul du travail intensif en stockage, car les couches de requête et de base de données sont indépendamment évolutives.   Un engagement critique pris par les créateurs de TiDB était que la base de données ne fonctionne que sur Kubernetes.   Est-ce suffisant pour le rendre natif de Kubernetes ?  Creusons un peu plus profondément.  Tout d'abord, TiDB est déployé et géré par un opérateur Kubernetes à l'aide   (CRD). Les CRD TiDB incluent le TiDBCluster, qui vous permet de spécifier la mise à l'échelle et la configuration de chaque microservice et la manière dont les composants de la couche de base de données utilisent le stockage via les volumes persistants Kubernetes. Des CRD supplémentaires sont utilisés pour déployer des outils de surveillance et gérer des tâches opérationnelles telles que la sauvegarde et la restauration. de ressources personnalisées    qui s'interface avec le planificateur K8s par défaut pour prendre des décisions de planification plus sensibles aux applications. Cet accent mis sur l'utilisation des fonctionnalités Kubernetes existantes lorsqu'elles sont disponibles est la marque d'une base de données native Kubernetes. TiDB dispose également d'une extension de planificateur facultative  Cassandre native Kubernetes avec DataStax Astra DB  Maintenant, regardez une autre base de données native Kubernetes et notez quelques similitudes et différences.    qui a été l'une des premières à prétendre être native du cloud, mais à quoi ressemble le déploiement de Cassandra dans Kubernetes ?  est une base de données NoSQL hautement évolutive Cassandra    qui a été intégrée aux microservices, comme le montre la figure 2.  est une version de Cassandra DataStax Astra DB  Comme TiDB, la base de données comprend des microservices concernés par le traitement des requêtes et le stockage des données, ainsi que des services de contrôle d'identité et d'accès, de réparation des données et de sauvegarde/restauration.  Les services de données sont particulièrement intéressants dans leur utilisation du   , avec les volumes persistants Kubernetes utilisés uniquement pour la mise en cache et le stockage objet utilisé pour la persistance à plus long terme. La séparation du compactage dans son service permet à ce traitement intensif de calcul de se produire en arrière-plan sans affecter les performances des services de données desservant le trafic de lecture et d'écriture.  stockage  Astra DB est proposé en tant que service géré disponible dans plusieurs régions cloud. Chaque région contient un plan de données composé des services mentionnés ci-dessus, gérés par un opérateur Kubernetes, ainsi que des services d'infrastructure, dont la pile   pour l'observabilité et   pour la gestion des métadonnées. Kube-Promethus etcd  Les plans de données sont gérés par un plan de contrôle qui peut s'exécuter dans un ou plusieurs clouds pour gérer les comptes clients et les bases de données et provisionner les clusters Kubernetes dans de nouvelles régions.    dans laquelle plusieurs bases de données utilisateur peuvent partager les mêmes microservices et infrastructure de support, réduisant ainsi l'économie unitaire pour les utilisateurs à plus petite échelle. Un nouvel aspect d'Astra DB est son architecture multi-tenant  Au fur et à mesure que les utilisateurs développent leurs applications, ils peuvent passer à des ressources dédiées pour obtenir des performances optimales à grande échelle, le tout sur une base «  ».  pay-as-you-go  Principes de la base de données native Kubernetes  Sur la base de nos observations sur TiDB et Astra DB, nous pouvons tirer quelques idées de ce qui rend une base de données Kubernetes native. Beaucoup d'entre eux correspondent à une liste de principes pour les données natives du cloud, que j'ai décrites dans un   : article précédent    premièrement, une base de données divisée en microservices constitutifs permet à chaque service d'être mis à l'échelle indépendamment. Certains types de traitement à forte intensité de calcul peuvent même être réduits à zéro pour une véritable solution sans serveur, en particulier lorsqu'ils sont combinés à une conception mutualisée. Architecture de microservice composable :    les microservices composés d'une base de données native Kubernetes doivent utiliser au maximum les API Kubernetes pour gérer les ressources fondamentales des applications cloud natives : ressources de calcul telles que   , l'entrée Kubernetes et les services pour exposer l'accès réseau aux données et plus encore. Cela inclut l'exploitation des fonctionnalités déjà présentes dans Kubernetes, telles que etcd pour la gestion des métadonnées, au lieu d'apporter des composants avec des fonctionnalités de duplication. Traiter le calcul, le réseau et le stockage comme des produits : StatefulSets et déploiements pour gérer les charges de travail, le sous-système de volume persistant pour le stockage    le fait de suivre des modèles communs pour les applications Kubernetes apportera de nombreux avantages opérationnels, par exemple,   . Par défaut, Kubernetes lui-même donne un excellent exemple que les bases de données doivent suivre pour savoir comment être sécurisées : utiliser les secrets Kubernetes pour distribuer les informations d'identification de sécurité, exposer uniquement les ports nécessaires, etc. Tirez parti des meilleures pratiques de Kubernetes : en exposant des contrôles de vivacité et de préparation sur chaque microservice pour aider à la disponibilité et en exposant des métriques via l'API Prometheus PromQL pour l'observabilité    une base de données native Kubernetes doit incarner les principes Kubernetes de gestion déclarative via des opérateurs et des ressources personnalisées, plutôt que de s'appuyer sur des interfaces utilisateur et des CLI de gestion de base de données héritées. Si nécessaire,   . L'objectif est une séparation nette de la fonctionnalité du plan de données (gestion des données) de la fonctionnalité du plan de contrôle (gestion de la base de données). Gestion déclarative via des opérateurs : les points d'extension Kubernetes, tels que les extensions de planificateur, peuvent être utilisés pour ajouter un comportement spécifique à l'application  Les bases de données et autres infrastructures de données qui adoptent fidèlement ces principes apporteront des avantages, notamment des   , une complexité opérationnelle réduite entraînant une mise sur le marché plus rapide et des solutions conformes aux normes répondant aux exigences actuelles de haute disponibilité et de sécurité. performances élevées pour un coût optimal à toutes les échelles  L'avenir de l'infrastructure de données native Kubernetes  De nombreux progrès restent à faire, et ils ne se limitent pas aux seules bases de données. Les principes natifs de Kubernetes peuvent être appliqués à d'autres types d'infrastructure de données, notamment le streaming, l'analyse et l'apprentissage automatique.  Les solutions natives de Kubernetes continueront de faire des progrès dans les déploiements multicluster et multicloud pour évoluer à l'échelle mondiale et adopteront les principes de multitenancy et sans serveur pour une meilleure optimisation des coûts.  Kubernetes lui-même peut être amélioré en ajoutant plus de flexibilité aux StatefulSets et en prenant en charge la fédération multicluster.  La clé du progrès continu est une collaboration ouverte. La   est un groupe très actif de geeks de données réunissant des créateurs d'applications gourmandes en données et l'infrastructure qui les prend en charge. communauté Data on Kubernetes  Rejoignez-nous pour discuter d'idées telles que le développement d'opérateurs réutilisables capables de gérer plusieurs bases de données ou la définition d'un ensemble commun de CRD pour des concepts tels que la sauvegarde/restauration et le chargement de données. Ensemble, nous continuerons à repousser l'horizon du cloud computing pour le bénéfice de tous.   Apprenez-en plus sur les bases de données natives de Kassandra et bien plus encore lors du sommet numérique   le 14 mars 2023. Cassandra Forward       Cet article est basé sur le chapitre 7, « La base de données native Kubernetes », du livre O'Reilly « Managing Cloud Native Data on Kubernetes » de Jeff Carpenter et Patrick McFadin.  [   Par Jeff Carpenter, DataStax   Jeff Carpenter a travaillé comme ingénieur logiciel et architecte dans plusieurs secteurs et comme défenseur des développeurs chez DataStax, aidant les ingénieurs à réussir avec Apache Cassandra. Il est impliqué dans plusieurs projets open source dans les écosystèmes Cassandra et Kubernetes, notamment Stargate et K8ssandra. Il est co-auteur des livres O'Reilly "Cassandra : The Definitive Guide" et "Managing Cloud Native Data on Kubernetes".

The writer was physically present in relevant location(s) to this story.

DataStax Astra DB is the vector database for getting GenAI apps into production, fast. Try it for free today!

DataStax

Cet audio est produit dans la langue originale de l'histoire !

Base de données native Kubernetes : TiDB Vs. DataStax Astra DB

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps