Get best of the week

Google Cloud Spanner: bon, mauvais, mal

Salut, Habrovsk. Traditionnellement, nous continuons à partager du matériel intéressant en prévision du lancement de nouveaux cours. Aujourd'hui, spécialement pour vous, nous avons publié un article sur Google Cloud Spanner, programmé pour coïncider avec le lancement du cours AWS for Developers .



Publié à l' origine sur le blog Lightspeed HQ .

En tant qu'entreprise qui propose de nombreuses solutions de point de vente basées sur le cloud pour les détaillants, les restaurateurs et les détaillants en ligne du monde entier, Lightspeed utilise plusieurs types de plateformes de bases de données pour une variété de cas transactionnels, analytiques et de recherche. Chacune de ces plates-formes de bases de données a ses propres forces et faiblesses. Par conséquent, lorsque Google a introduit Cloud Spanner sur le marché, des fonctionnalités prometteuses sans précédent dans le monde des bases de données relationnelles, telles qu'une évolutivité horizontale pratiquement illimitée et un accord de niveau de service (SLA) à 99,999%, - nous ne pouvions pas manquer l'occasion de le mettre entre nos mains!

Pour donner un aperçu complet de notre expérience avec Cloud Spanner, ainsi que des critères d'évaluation que nous avons utilisés, nous couvrirons les sujets suivants:

  1. Nos critères d'évaluation
  2. Clé de nuage en bref
  3. Notre note
  4. Nos découvertes



1. Nos critères d'évaluation


Avant de nous plonger dans les fonctionnalités de Cloud Spanner, ses similitudes et différences avec les autres solutions du marché, parlons d'abord des principaux cas d'utilisateurs que nous avions en tête pour déterminer où déployer Cloud Spanner dans notre infrastructure:

  • En remplacement de la solution de base de données SQL traditionnelle (en vigueur)
  • Comment une solution OLTP avec prise en charge OLAP

Remarque: Pour plus de simplicité et de comparaison, cet article compare Cloud Spanner avec MySQL GCP Cloud SQL et la famille de solutions Amazon AWS RDS.

Utilisation de Cloud Spanner en remplacement d'une solution de base de données SQL traditionnelle


Dans un environnement de base de données traditionnel , lorsque le temps de réponse à une requête de base de données approche ou dépasse même les seuils d'application prédéfinis (principalement en raison d'une augmentation du nombre d'utilisateurs et / ou de requêtes), il existe plusieurs façons de réduire le temps de réponse à des niveaux acceptables. Cependant, la plupart de ces solutions incluent une intervention manuelle.

Par exemple, la première étape à suivre consiste à examiner les différents paramètres de base de données liés aux performances et à les configurer pour qu'ils correspondent au mieux aux modèles d'utilisation des applications. Si cela ne suffit pas, vous pouvez choisir de mettre la base de données à l'échelle verticalement ou horizontalement.

La mise à l'échelle d'une application implique la mise à jour de l'instance de serveur, généralement en ajoutant plus de processeurs / cœurs, plus de RAM, un stockage plus rapide, etc. L'ajout de plus de ressources matérielles entraîne une augmentation des performances de la base de données, mesurée principalement dans les transactions deuxièmement, et le délai de transaction pour les systèmes OLTP. Les systèmes de bases de données relationnelles (qui utilisent une approche multithread), tels que MySQL, évoluent bien verticalement.

Cette approche présente plusieurs inconvénients, mais le plus évident est la taille maximale du serveur sur le marché. Une fois que la limite de la plus grande instance de serveur est atteinte, il n'y a qu'une seule façon: la mise à l'échelle horizontale.

La mise à l'échelle horizontale est une approche dans laquelle plus de serveurs sont ajoutés au cluster pour augmenter idéalement de manière linéaire les performances avec l'ajout du nombre de serveurs. La plupart des systèmes de bases de données traditionnels n'évoluent pas bien horizontalement ou ne évoluent pas du tout. Par exemple, MySQL peut évoluer horizontalement pour les opérations de lecture en ajoutant des lecteurs esclaves, mais ne peut pas évoluer horizontalement pour les opérations d'écriture.

D'un autre côté, en raison de sa nature, Cloud Spanner peut facilement évoluer horizontalement avec un minimum d'interférences. SGBD

complet en tant que servicedoivent être évalués sous différents angles. Comme base, nous avons pris le SGBD le plus populaire dans le cloud - pour Google, GCP Cloud SQL et pour Amazon, AWS RDS. Dans notre évaluation, nous nous sommes concentrés sur les catégories suivantes:

  • Mappage des fonctionnalités: étendue SQL, DDL, DML; bibliothèques / connecteurs de connexion, prise en charge des transactions, etc.
  • Support au développement: facilité de développement et de test.
  • Support administratif: gestion des instances - par exemple, montée / descente et mise à niveau des instances; SLA, sauvegarde et restauration; sécurité / contrôle d'accès.

Utilisation de Cloud Spanner comme OLTP avec prise en charge OLAP


Bien que Google ne prétende pas explicitement que Cloud Spanner est destiné au traitement analytique, il partage certains attributs avec d'autres mécanismes, tels qu'Apache Impala & Kudu et YugaByte, qui sont conçus pour les charges de travail OLAP.

Même s'il n'y avait qu'une faible chance que Cloud Spanner inclue un moteur HTAP (traitement transactionnel / analytique hybride) évolutif cohérent avec un ensemble (plus ou moins) utilisable de fonctionnalités OLAP, nous pensons qu'il mériterait notre attention.

Dans cet esprit, nous avons examiné les catégories suivantes:

  • Prise en charge du chargement, des index et du partitionnement des données
  • Performances des requêtes et DML

2. Cloud Spanner en bref


Google Spanner est un système de gestion de base de données relationnelle en cluster (SGBDR) que Google utilise pour plusieurs de ses propres services. Google l'a rendu public pour les utilisateurs de Google Cloud Platform début 2017.

Voici quelques-uns des attributs de Cloud Spanner:

  • Cluster RDBMS évolutif hautement cohérent: utilise la synchronisation de l'heure matérielle pour assurer la cohérence des données.
  • Prise en charge des transactions entre tables: les transactions peuvent s'étendre sur plusieurs tables - pas nécessairement limitées à une seule table (contrairement à Apache HBase ou Apache Kudu).
  • : (), . , . , .
  • : . . , , , -.
  • : Cloud Spanner . . . . , , , . , .

«Cloud Spanner . , Cloud Spanner , - , ».


: Apache Tephra Apache HBase ( Apache Phoenix -).

3.


Nous lisons donc tous les déclarations de Google sur les avantages de Cloud Spanner - une mise à l'échelle horizontale pratiquement illimitée tout en conservant une cohérence élevée et un SLA très élevé. Bien que ces exigences soient, en tout cas, extrêmement difficiles à atteindre, notre objectif n'était pas de les réfuter. Au lieu de cela, concentrons-nous sur d'autres choses qui intéressent la plupart des utilisateurs de bases de données: la parité et la convivialité.

Nous avons évalué Cloud Spanner en remplacement de Sharded MySQL


Google Cloud SQL et Amazon AWS RDS, les deux SGBD OLTP les plus populaires sur le marché du cloud, disposent d'un ensemble de fonctionnalités très étendu. Cependant, pour faire évoluer ces bases de données au-delà de la taille d'un seul nœud, vous devez effectuer un partitionnement d'application. Cette approche crée une complexité supplémentaire pour les applications et l'administration. Nous avons examiné comment Spanner s'intègre dans le scénario de combinaison de plusieurs segments en une seule instance et quelles fonctionnalités (le cas échéant) doivent être sacrifiées.

Prise en charge de SQL, DML et DDL, ainsi que des connecteurs et des bibliothèques?


Tout d'abord, lorsque vous démarrez avec une base de données, vous devez créer un modèle de données. Si vous pensez que vous pouvez connecter JDBC Spanner à votre outil SQL préféré, vous constaterez que vous pouvez interroger vos données avec, mais vous ne pouvez pas l'utiliser pour créer une table ou modifier (DDL) ou toute opération d'insertion / mise à jour / suppression ( DML). Le JDBC officiel de Google ne prend pas en charge non plus.
"Les pilotes ne prennent actuellement pas en charge DML ou DDL."
Documentation de clé

Avec la console GCP, la situation n'est pas meilleure - vous ne pouvez envoyer que des requêtes SELECT. Heureusement, il existe un pilote JDBC avec prise en charge DML et DDL de la communauté, y compris les transactions github.com/olavloite/spanner-jdbc . Bien que ce pilote soit extrêmement utile, l'absence de propre pilote JDBC de Google est surprenante. Heureusement, Google offre un support assez large pour les bibliothèques clientes (basées sur gRPC): C #, Go, Java, node.js, PHP, Python et Ruby.

L'utilisation presque obligatoire des interfaces utilisateur de Cloud Spanner (en raison de l'absence de DDL et DML dans JDBC) conduit à certaines restrictions pour les domaines de code associés, tels que les pools de connexions ou les cadres de liaison de base de données (par exemple Spring MVC). En règle générale, lorsque vous utilisez JDBC, vous pouvez sélectionner librement votre pool de connexions préféré (par exemple, HikariCP, DBCP, C3PO, etc.), qui est testé et fonctionne bien. Dans le cas des API Spanner personnalisées, nous devons nous fier aux frameworks / pools de liaisons / sessions que nous avons créés nous-mêmes.

La conception de la clé primaire (PC) permet à Cloud Spanner d'être très rapide lors de l'accès aux données via un PC, mais entraîne également des problèmes de requête.

  • ; . ( / .)
  • UPDATE DELETE WHERE, , DELETE all — , : UPDATE xxx WHERE id IN (SELECT id FROM table1)
  • - , . , .

?


Google Cloud Spanner a une prise en charge intégrée des index secondaires. C'est une fonctionnalité très intéressante qui n'est pas toujours présente dans d'autres technologies. Apache Kudu ne prend actuellement pas en charge les index secondaires et Apache HBase ne prend pas directement en charge les index, mais peut les ajouter via Apache Phoenix.

Les index dans Kudu et HBase peuvent être modélisés comme une table distincte avec une composition différente de clés primaires, mais l'atomicité des opérations effectuées sur la table parent et les tables d'index associées doit être effectuée au niveau de l'application et n'est pas triviale dans la mise en œuvre correcte.

Comme mentionné dans la revue Cloud Spanner, ses index peuvent différer des index MySQL. Par conséquent, une attention particulière doit être apportée lors de la génération des requêtes et du profilage pour garantir que l'index approprié est utilisé là où il est nécessaire.

Représentation?


Les vues sont un objet très populaire et utile dans la base de données. Ils peuvent être utiles pour un grand nombre de cas d'utilisateurs; mes deux favoris sont le niveau d'abstraction logique et le niveau de sécurité. Malheureusement, Cloud Spanner ne prend pas en charge les soumissions. Cependant, cela ne nous limite que partiellement, car pour les autorisations d'accès, il n'y a pas de granularité au niveau de la colonne où les représentations peuvent être une solution acceptable.

La documentation de Cloud Spanner comporte une section qui détaille les quotas et les restrictions ( spanner / quotas), il y en a une qui peut être problématique pour certaines applications: Cloud Spanner prêt à l'emploi a une limite de 100 bases de données maximum par instance. Évidemment, cela peut être un obstacle sérieux pour une base de données conçue pour évoluer vers plus de 100 bases de données. Heureusement, après avoir discuté avec notre représentant technique Google, nous avons découvert que cette limite peut être augmentée à presque n'importe quelle valeur via l'assistance Google.

Aide au développement?


Cloud Spanner offre un support assez décent pour que les langages de programmation fonctionnent avec son API. Les bibliothèques officiellement prises en charge se trouvent dans les domaines C #, Go, Java, node.js, PHP, Python et Ruby. La documentation est assez détaillée, mais, comme avec d'autres technologies avancées, la communauté est assez petite par rapport aux technologies de base de données les plus populaires, ce qui peut entraîner une augmentation du temps consacré à la résolution de cas d'utilisation ou de problèmes moins courants.

Alors qu'en est-il du soutien au développement local?


Nous n'avons pas trouvé de moyen de créer une instance Cloud Spanner dans l'environnement local. Le plus proche que nous avons obtenu est l'image Docker CockroachDB , qui est en principe similaire, mais en pratique, elle est très différente. Par exemple, CockroachDB peut utiliser JDBC PostgreSQL. Étant donné que l'environnement de développement doit être aussi proche que possible de l'environnement de travail, Cloud Spanner n'est pas idéal, car vous devez vous fier à une instance Spanner complète. Pour réduire les coûts, vous pouvez choisir une instance pour une région.

Du support de la part de l'administration?


La création d'une instance Cloud Spanner est simple. Il vous suffit de choisir entre créer une multi-région ou une instance pour une région, spécifier la ou les régions et le nombre de nœuds. En moins d'une minute, l'instance sera opérationnelle.

Plusieurs mesures de base sont directement disponibles sur la page Spanner de la console Google. Des vues plus détaillées sont disponibles via Stackdriver, où vous pouvez également définir des mesures de seuil et des politiques d'alerte.

Accès aux ressources?


MySQL propose des paramètres d'autorisation et de rôle utilisateur détaillés et très détaillés. Vous pouvez facilement configurer l'accès à une table spécifique, ou même simplement à un sous-ensemble de ses colonnes. Cloud Spanner utilise l'outil Google Identity & Access Management (IAM), qui vous permet de définir des politiques et des autorisations uniquement à un niveau très élevé. L'option la plus détaillée est une résolution au niveau de la base de données qui ne convient pas à la plupart des cas de production. Cette restriction vous oblige à ajouter des mesures de sécurité supplémentaires à votre code, à votre infrastructure ou aux deux pour empêcher une utilisation non autorisée des ressources Spanner.

Sauvegardes?


En termes simples, il n'y a pas de sauvegardes dans Cloud Spanner. Bien que les exigences élevées du SLA de Google puissent garantir que vous ne perdrez aucune donnée en raison de défaillances matérielles ou de bases de données, d'erreurs humaines, de défauts d'application, etc. Nous connaissons tous la règle: la haute disponibilité ne remplace pas une stratégie de sauvegarde raisonnable. Pour le moment, la seule façon de sauvegarder des données est de les diffuser par programme de la base de données vers un environnement de stockage distinct.

Performances des requêtes?


Nous avons utilisé Yahoo! Pour télécharger des données et tester des requêtes. Benchmark de service cloud. Le tableau ci-dessous montre la charge de travail du YCSB B avec un taux de lecture de 95% et un taux d'écriture de 5%.



* Le test de charge a été effectué sur le moteur de calcul (CE) n1-standard-32 (32 vCPU, 120 Go de mémoire), et l'instance de test n'a jamais été un goulot d'étranglement dans les tests.
** Le nombre maximal de threads dans une instance de YCSB est de 400. Au total, six instances parallèles de tests YCSB ont dû être exécutées pour obtenir un total de 2400 threads.

En regardant les résultats des tests, en particulier la combinaison de la charge du processeur et du TPS, nous voyons clairement que Cloud Spanner évolue assez bien. La grande charge créée par un grand nombre de threads est compensée par le grand nombre de nœuds dans le cluster Cloud Spanner. Bien que le délai semble assez élevé, en particulier lorsque vous travaillez avec 2400 threads, un nouveau test avec 6 instances plus petites du moteur de calcul peut être nécessaire pour obtenir des nombres plus précis. Chaque instance exécutera un test YCSB au lieu d'une grande instance CE avec 6 tests parallèles. Ainsi, il sera plus facile de faire la distinction entre les retards de demande Cloud Spanner et les retards ajoutés par la connexion réseau entre Cloud Spanner et l'instance CE sur laquelle le test s'exécute.

Comment Cloud Spanner gère-t-il OLAP?


Partitionnement?


La division des données en segments physiquement et / ou logiquement indépendants, appelés partitions, est un concept très populaire inhérent à la plupart des mécanismes OLAP. Les partitions peuvent améliorer considérablement les performances des requêtes et la prise en charge de la base de données. Un approfondissement supplémentaire de la partition serait abordé dans un ou plusieurs articles distincts, alors mentionnons simplement l'importance d'avoir un schéma de partitionnement et un sous-partitionnement. La capacité de partitionner des données en partitions et encore plus en sous-partitions est essentielle pour la performance des requêtes analytiques.

Cloud Spanner ne prend pas en charge les partitions en soi. Il divise les données en interne en soi-disant splits en fonction des plages de clés primaires. La séparation est effectuée automatiquement pour équilibrer la charge dans le cluster Cloud Spanner. Une fonctionnalité très pratique de Cloud Spanner est de diviser la charge de base de la table parent (une table qui ne alterne pas avec une autre). Spanner détermine automatiquement si le fractionnement contient des données qui sont lues plus souvent que les données d'autres fractionnements et peut décider d'une séparation ultérieure. Ainsi, davantage de nœuds peuvent être impliqués dans la demande, ce qui augmente également efficacement le débit.

Chargement des données?


La méthode Cloud Spanner pour les données en masse est la même que pour les téléchargements réguliers. Pour obtenir des performances maximales, vous devez suivre certaines recommandations, notamment:

  • Triez vos données par clé primaire.
  • Divisez-les par 10 * le nombre de nœuds de sections individuelles.
  • Créez un ensemble de tâches de travail qui chargent des données en parallèle.

Avec ce téléchargement de données, tous les nœuds Cloud Spanner sont utilisés.

Nous avons utilisé la charge de travail A YCSB pour générer un ensemble de données de 10 millions de lignes.



* Le test de charge a été effectué sur le moteur de calcul n1-standard-32 (32 vCPU, 120 Go de mémoire), et l'instance de test n'a jamais été un goulot d'étranglement dans les tests.
** Une configuration à 1 nœud n'est pas recommandée pour toute charge de production.

Comme mentionné ci-dessus, Cloud Spanner traite automatiquement les split-s en fonction de leur charge, de sorte que les résultats s'améliorent après plusieurs répétitions successives du test. Les résultats présentés ici sont les meilleurs résultats que nous ayons reçus. En regardant les chiffres ci-dessus, nous pouvons voir comment Cloud Spanner évolue (bien) avec une augmentation du nombre de nœuds dans le cluster. Les chiffres qui ressortent sont des retards moyens extrêmement faibles qui contrastent avec les résultats de charges de travail mixtes (95% pour la lecture et 5% pour l'écriture), comme décrit dans la section ci-dessus.

Mise à l'échelle?


L'augmentation et la diminution du nombre de nœuds Cloud Spanner est une tâche en un clic. Si vous souhaitez charger rapidement les données, vous pouvez envisager de booster l'instance au maximum (dans notre cas, c'était 25 nœuds dans la région US-EAST), puis réduire le nombre de nœuds adaptés à votre charge régulière, après toutes les données de la base de données compte tenu de la limitation de 2 To / nœud.

On nous a rappelé cette limite même avec une base de données beaucoup plus petite. Après plusieurs exécutions de tests de charge, notre base de données avait une taille d'environ 155 Go, et lorsqu'elle a été réduite à une instance de 1 nœud, nous avons reçu l'erreur suivante:



nous avons pu réduire l'échelle de 25 à 2 instances, mais nous étions bloqués sur deux nœuds.

L'augmentation et la diminution du nombre de nœuds dans un cluster Cloud Spanner peuvent être automatisées à l'aide de l'API REST. Cela peut être particulièrement utile pour réduire la charge accrue sur le système pendant les heures de pointe.

Performances des requêtes OLAP?


Au départ, nous avions prévu de consacrer un temps considérable à notre évaluation de Spanner pour cette partie. Après plusieurs COUNT SELECT, nous avons immédiatement réalisé que les tests seraient courts et que Spanner ne serait PAS un moteur OLAP. Quel que soit le nombre de nœuds dans le cluster, une simple sélection du nombre de lignes dans un tableau de 10 millions de lignes a pris 55 à 60 secondes. De plus, toute demande nécessitant plus de mémoire pour stocker les résultats intermédiaires a échoué avec une erreur MOO.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

Quelques chiffres pour les demandes TPC-H peuvent être trouvés dans l'article Nosql-kudu-spanner-slides.html de Todd Lipcon , diapositives 42 et 43. Ces chiffres sont cohérents avec nos propres résultats (malheureusement).



4. Nos constatations


Compte tenu de l'état actuel des fonctionnalités de Cloud Spanner, il est difficile de l'imaginer comme un simple remplacement d'une solution OLTP existante, en particulier lorsque vos besoins la dépassent. Il faudrait consacrer beaucoup de temps à la création d'une solution qui prend en compte les défauts de Cloud Spanner.

Lorsque nous avons commencé à évaluer Cloud Spanner, nous nous attendions à ce que ses fonctionnalités de gestion soient au moins ou pas si éloignées des autres solutions Google SQL. Mais nous avons été surpris du manque total de sauvegardes et du contrôle très limité de l'accès aux ressources. Sans parler du manque de vues, de l'absence d'un environnement de développement local, de séquences non prises en charge, de JDBC sans prise en charge DML et DDL, etc.

Alors, où va celui qui a besoin de faire évoluer la base de données transactionnelle? Il semble qu'il n'y ait pas de solution unique sur le marché qui soit adaptée à tous les cas d'utilisation. Il existe de nombreuses solutions fermées et open source (dont certaines sont mentionnées dans cet article), chacune ayant ses propres forces et faiblesses, mais aucune d'entre elles n'offre le SaaS avec un SLA de 99,999% et un haut degré de cohérence. Si un SLA élevé est votre objectif principal et que vous n'êtes pas enclin à créer votre propre solution pour plusieurs environnements cloud, Cloud Spanner peut être la solution que vous recherchez. Mais vous devez être conscient de toutes ses limites.

En toute justice, il convient de noter que Cloud Spanner n'a pas été rendu public au printemps 2017, il est donc raisonnable de s'attendre à ce que certaines de ses lacunes actuelles finissent par disparaître (j'espère), et lorsque cela se produit, cela peut changer le jeu. Après tout, Cloud Spanner n'est pas seulement un projet tiers pour Google. Google l'utilise comme base pour d'autres produits Google. Et lorsque Google a récemment remplacé Megastore dans Google Cloud Storage par Cloud Spanner, cela a permis à Google Cloud Storage d'être strictement cohérent pour les listes d'objets à l'échelle mondiale (ce qui ne s'applique toujours pas au S3 d' Amazon ). Donc, il y a encore de l'espoir ... nous espérons.



C'est tout. Comme l'auteur de l'article, nous continuons également d'espérer, mais qu'en pensez-vous? Écrivez dans les commentaires.

Chacun est invité à visiter notre webinaire gratuit, dans le cadre duquel nous parlerons en détail du cours OTUS AWS for Developers .

More articles:


All Articles