Salut tout le monde! Je m'appelle Golov Nikolaï. Auparavant, j'ai travaillé chez Avito et géré la Data Platform pendant six ans, c'est-à-dire que j'ai travaillé sur toutes les bases de données : analytiques (Vertica, ClickHouse), streaming et OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Pendant ce temps, j'ai traité un grand nombre de bases de données - très différentes et inhabituelles, ainsi que des cas d'utilisation non standard.
Je travaille actuellement chez ManyChat. Essentiellement, il s’agit d’une startup – nouvelle, ambitieuse et en croissance rapide. Et lorsque j’ai rejoint l’entreprise, une question classique s’est posée : « Que doit désormais retenir une jeune startup du marché des SGBD et des bases de données ?
Dans cet article, basé sur mon rapport à , je vais répondre à cette question. Une version vidéo du rapport est disponible sur .
Bases de données communément connues 2020
Nous sommes en 2020, j'ai regardé autour de moi et j'ai vu trois types de bases de données.
Premier type - bases de données OLTP classiques: PostgreSQL, SQL Server, Oracle, MySQL. Ils ont été écrits il y a longtemps, mais sont toujours d'actualité car ils sont très familiers à la communauté des développeurs.
Le deuxième type est bases à partir de "zéro". Ils ont essayé de s'éloigner des modèles classiques en abandonnant SQL, les structures traditionnelles et ACID, en ajoutant le partitionnement intégré et d'autres fonctionnalités attrayantes. Par exemple, il s'agit de Cassandra, MongoDB, Redis ou Tarantool. Toutes ces solutions voulaient offrir au marché quelque chose de fondamentalement nouveau et occupaient leur niche car elles se révélaient extrêmement pratiques pour certaines tâches. Je désignerai ces bases de données par le terme générique NOSQL.
Les « zéros » sont terminés, nous nous sommes habitués aux bases de données NOSQL et le monde, de mon point de vue, a franchi l'étape suivante : bases de données gérées. Ces bases de données ont le même noyau que les bases de données OLTP classiques ou les nouvelles bases NoSQL. Mais ils n’ont pas besoin de DBA ni de DevOps et fonctionnent sur du matériel géré dans les cloud. Pour un développeur, il s'agit « juste d'une base » qui fonctionne quelque part, mais personne ne se soucie de savoir comment elle est installée sur le serveur, qui a configuré le serveur et qui le met à jour.
Exemples de telles bases de données :
- AWS RDS est un wrapper géré pour PostgreSQL/MySQL.
- DynamoDB est un analogue AWS d'une base de données basée sur des documents, similaire à Redis et MongoDB.
- Amazon Redshift est une base de données analytique gérée.
Il s'agit essentiellement d'anciennes bases de données, mais créées dans un environnement géré, sans qu'il soit nécessaire de travailler avec du matériel.
Note. Les exemples sont pris pour l'environnement AWS, mais leurs analogues existent également dans Microsoft Azure, Google Cloud ou Yandex.Cloud.
Quoi de neuf à ce sujet ? En 2020, rien de tout cela.
Concept sans serveur
Ce qui est vraiment nouveau sur le marché en 2020, ce sont les solutions sans serveur ou sans serveur.
Je vais essayer d'expliquer ce que cela signifie en utilisant l'exemple d'un service régulier ou d'une application backend.
Pour déployer une application backend classique, nous achetons ou louons un serveur, copions le code dessus, publions le point final à l'extérieur et payons régulièrement le loyer, l'électricité et les services du centre de données. C'est le schéma standard.
Est-ce qu'il y a un autre moyen? Avec les services sans serveur, c’est possible.
Quel est l'objectif de cette approche : il n'y a pas de serveur, il n'y a même pas de location d'instance virtuelle dans le cloud. Pour déployer le service, copiez le code (fonctions) dans le référentiel et publiez-le sur le point de terminaison. Ensuite, nous payons simplement pour chaque appel à cette fonction, en ignorant complètement le matériel sur lequel elle est exécutée.
Je vais essayer d'illustrer cette approche avec des images.
Déploiement classique. Nous avons un service avec une certaine charge. Nous élevons deux instances : des serveurs physiques ou des instances dans AWS. Les requêtes externes sont envoyées à ces instances et y sont traitées.
Comme vous pouvez le voir sur la photo, les serveurs ne sont pas disposés de la même manière. L’une est utilisée à 100 %, il y a deux demandes et l’autre n’est qu’à 50 % - partiellement inactive. Si ce n'est pas trois demandes qui arrivent, mais 30, alors l'ensemble du système ne sera pas en mesure de faire face à la charge et commencera à ralentir.
Déploiement sans serveur. Dans un environnement sans serveur, un tel service ne dispose ni d'instances ni de serveurs. Il existe un certain pool de ressources chauffées - de petits conteneurs Docker préparés avec un code de fonction déployé. Le système reçoit des requêtes externes et pour chacune d'elles le framework sans serveur crée un petit conteneur avec du code : il traite cette requête particulière et tue le conteneur.
Une demande - un conteneur soulevé, 1000 demandes - 1000 conteneurs. Et le déploiement sur les serveurs matériels est déjà l'œuvre du fournisseur de cloud. Il est complètement masqué par le framework sans serveur. Dans ce concept, nous payons pour chaque appel. Par exemple, un appel arrivait par jour - nous payions pour un appel, un million arrivait par minute - nous payions pour un million. Ou en une seconde, cela arrive aussi.
Le concept de publication d'une fonction sans serveur convient à un service sans état. Et si vous avez besoin d'un service avec état (état), nous ajoutons une base de données au service. Dans ce cas, lorsqu'il s'agit de travailler avec l'état, chaque fonction avec état écrit et lit simplement à partir de la base de données. De plus, à partir d'une base de données de l'un des trois types décrits au début de l'article.
Quelle est la limitation commune à toutes ces bases de données ? Il s'agit des coûts d'un serveur cloud ou matériel constamment utilisé (ou de plusieurs serveurs). Peu importe que nous utilisions une base de données classique ou gérée, que nous ayons ou non Devops et un administrateur, nous payons toujours le matériel, l'électricité et la location du centre de données 24h/7 et 10j/20. Si on a une base classique, on paie maître et esclave. S’il s’agit d’une base de données fragmentée très chargée, nous payons pour 30, XNUMX ou XNUMX serveurs, et nous payons en permanence.
La présence de serveurs réservés en permanence dans la structure de coûts était auparavant perçue comme un mal nécessaire. Les bases de données conventionnelles présentent également d'autres difficultés, telles que des limites sur le nombre de connexions, des restrictions de mise à l'échelle, un consensus géo-distribué - elles peuvent d'une manière ou d'une autre être résolues dans certaines bases de données, mais pas d'un seul coup et pas idéalement.
Base de données sans serveur - théorie
Question de 2020 : est-il également possible de créer une base de données sans serveur ? Tout le monde a entendu parler du backend sans serveur... essayons de rendre la base de données sans serveur ?
Cela semble étrange, car la base de données est un service complet, peu adapté à une infrastructure sans serveur. Dans le même temps, l'état de la base de données est très vaste : des gigaoctets, des téraoctets et même des pétaoctets dans les bases de données analytiques. Il n’est pas si simple de l’élever dans des conteneurs Docker légers.
D'un autre côté, presque toutes les bases de données modernes contiennent une énorme quantité de logique et de composants : transactions, coordination de l'intégrité, procédures, dépendances relationnelles et beaucoup de logique. Pour de nombreuses logiques de bases de données, un petit état suffit. Les gigaoctets et les téraoctets ne sont directement utilisés que par une petite partie de la logique de la base de données impliquée dans l'exécution directe des requêtes.
En conséquence, l'idée est la suivante : si une partie de la logique permet une exécution sans état, pourquoi ne pas diviser la base en parties avec et sans état.
Sans serveur pour les solutions OLAP
Voyons à quoi pourrait ressembler la découpe d'une base de données en parties avec et sans état à l'aide d'exemples pratiques.
Par exemple, nous avons une base de données analytique: des données externes (cylindre rouge à gauche), un processus ETL qui charge les données dans la base de données, et un analyste qui envoie des requêtes SQL à la base de données. Il s’agit d’un schéma d’exploitation classique d’un entrepôt de données.
Dans ce schéma, ETL est exécuté conditionnellement une fois. Ensuite, vous devez constamment payer pour les serveurs sur lesquels la base de données s'exécute avec des données remplies d'ETL, afin qu'il y ait quelque chose à qui envoyer des requêtes.
Examinons une approche alternative implémentée dans AWS Athena Serverless. Il n'existe pas de matériel dédié en permanence sur lequel les données téléchargées sont stockées. Au lieu de cela:
- L'utilisateur soumet une requête SQL à Athena. L'optimiseur Athena analyse la requête SQL et recherche dans le magasin de métadonnées (métadonnées) les données spécifiques nécessaires à l'exécution de la requête.
- L'optimiseur, sur la base des données collectées, télécharge les données nécessaires à partir de sources externes vers un stockage temporaire (base de données temporaire).
- Une requête SQL de l'utilisateur est exécutée dans un stockage temporaire et le résultat est renvoyé à l'utilisateur.
- Le stockage temporaire est effacé et les ressources sont libérées.
Dans cette architecture, nous ne payons que le processus d'exécution de la requête. Aucune demande - aucun frais.
Il s'agit d'une approche efficace qui est implémentée non seulement dans Athena Serverless, mais également dans Redshift Spectrum (dans AWS).
L'exemple Athena montre que la base de données Serverless fonctionne sur des requêtes réelles avec des dizaines et des centaines de téraoctets de données. Des centaines de téraoctets nécessiteront des centaines de serveurs, mais nous n'avons pas à les payer : nous payons pour les requêtes. La rapidité de chaque requête est (très) faible par rapport aux bases de données analytiques spécialisées comme Vertica, mais nous ne payons pas les périodes d'indisponibilité.
Une telle base de données est applicable pour de rares requêtes analytiques ad hoc. Par exemple, lorsque nous décidons spontanément de tester une hypothèse sur une quantité gigantesque de données. Athéna est parfaite pour ces cas. Pour des demandes régulières, un tel système coûte cher. Dans ce cas, mettez les données en cache dans une solution spécialisée.
Sans serveur pour les solutions OLTP
L'exemple précédent portait sur les tâches OLAP (analytiques). Examinons maintenant les tâches OLTP.
Imaginons PostgreSQL ou MySQL évolutif. Créons une instance gérée standard PostgreSQL ou MySQL avec un minimum de ressources. Lorsque l'instance recevra plus de charge, nous connecterons des répliques supplémentaires auxquelles nous distribuerons une partie de la charge de lecture. S'il n'y a pas de requêtes ou de chargement, nous désactivons les répliques. La première instance est le maître et les autres sont des répliques.
Cette idée est implémentée dans une base de données appelée Aurora Serverless AWS. Le principe est simple : les requêtes des applications externes sont acceptées par le parc proxy. Voyant la charge augmenter, il alloue des ressources informatiques à partir d'instances minimales préchauffées - la connexion s'établit le plus rapidement possible. La désactivation des instances se produit de la même manière.
Au sein d'Aurora, il existe le concept d'Aurora Capacité Unit, ACU. Il s'agit (sous condition) d'une instance (serveur). Chaque ACU spécifique peut être maître ou esclave. Chaque unité de capacité possède sa propre RAM, son processeur et son disque minimal. En conséquence, l’un est maître, les autres sont des répliques en lecture seule.
Le nombre de ces unités de capacité Aurora en cours d'exécution est un paramètre configurable. La quantité minimale peut être un ou zéro (dans ce cas, la base de données ne fonctionne pas s'il n'y a pas de demandes).
Lorsque la base reçoit des demandes, la flotte proxy augmente les unités de capacité Aurora, augmentant ainsi les ressources de performances du système. La possibilité d'augmenter et de diminuer les ressources permet au système de « jongler » avec les ressources : afficher automatiquement les ACU individuelles (en les remplaçant par de nouvelles) et déployer toutes les mises à jour actuelles des ressources retirées.
La base Aurora Serverless peut faire évoluer la charge de lecture. Mais la documentation ne le dit pas directement. On peut avoir l'impression qu'ils peuvent soulever un multi-maître. Il n'y a pas de magie.
Cette base de données est bien adaptée pour éviter de dépenser d’énormes sommes d’argent sur des systèmes dont l’accès est imprévisible. Par exemple, lors de la création de sites MVP ou de sites de cartes de visite marketing, nous ne nous attendons généralement pas à une charge stable. Par conséquent, s'il n'y a pas d'accès, nous ne payons pas pour les instances. Lorsqu'une charge inattendue se produit, par exemple après une conférence ou une campagne publicitaire, des foules de personnes visitent le site et la charge augmente considérablement, Aurora Serverless prend automatiquement cette charge et connecte rapidement les ressources manquantes (ACU). Puis la conférence passe, tout le monde oublie le prototype, les serveurs (ACU) s'éteignent et les coûts tombent à zéro - c'est pratique.
Cette solution ne convient pas à une charge élevée stable car elle ne modifie pas la charge d'écriture. Toutes ces connexions et déconnexions de ressources se produisent au "point d'échelle" - un moment dans le temps où la base de données n'est pas prise en charge par une transaction ou des tables temporaires. Par exemple, en une semaine, le point d'échelle peut ne pas se produire et la base fonctionne avec les mêmes ressources et ne peut tout simplement pas s'étendre ou se contracter.
Il n’y a pas de magie – c’est du PostgreSQL classique. Mais le processus d’ajout et de déconnexion de machines est partiellement automatisé.
Sans serveur par conception
Aurora Serverless est une ancienne base de données réécrite pour le cloud afin de profiter de certains des avantages de Serverless. Et maintenant, je vais vous parler de la base, initialement écrite pour le cloud, pour l'approche sans serveur - Serverless-by-design. Il a été immédiatement développé sans supposer qu’il fonctionnerait sur des serveurs physiques.
Cette base s'appelle Snowflake. Il comporte trois blocs clés.
Le premier est un bloc de métadonnées. Il s'agit d'un service en mémoire rapide qui résout les problèmes de sécurité, de métadonnées, de transactions et d'optimisation des requêtes (illustré dans l'illustration de gauche).
Le deuxième bloc est un ensemble de clusters informatiques virtuels pour les calculs (dans l'illustration il y a un ensemble de cercles bleus).
Le troisième bloc est un système de stockage de données basé sur S3. S3 est un stockage d'objets sans dimension dans AWS, un peu comme Dropbox pour les entreprises sans dimension.
Voyons comment fonctionne Snowflake, en supposant un démarrage à froid. Autrement dit, il existe une base de données, les données y sont chargées, aucune requête n'est en cours d'exécution. Par conséquent, s'il n'y a aucune requête vers la base de données, nous avons activé le service rapide de métadonnées en mémoire (premier bloc). Et nous avons le stockage S3, où les données des tables sont stockées, divisées en micropartitions. Pour simplifier : si la table contient des transactions, alors les micropartitions sont les jours de transactions. Chaque jour est une micropartition distincte, un fichier distinct. Et lorsque la base de données fonctionne dans ce mode, vous ne payez que l'espace occupé par les données. De plus, le tarif par siège est très faible (surtout compte tenu de la compression importante). Le service de métadonnées fonctionne également en permanence, mais vous n'avez pas besoin de beaucoup de ressources pour optimiser les requêtes et le service peut être considéré comme un shareware.
Imaginons maintenant qu'un utilisateur accède à notre base de données et envoie une requête SQL. La requête SQL est immédiatement envoyée au service Métadonnées pour traitement. Ainsi, dès réception d'une demande, ce service analyse la demande, les données disponibles, les autorisations des utilisateurs et, si tout va bien, établit un plan de traitement de la demande.
Ensuite, le service initie le lancement du cluster informatique. Un cluster informatique est un cluster de serveurs qui effectuent des calculs. Autrement dit, il s'agit d'un cluster pouvant contenir 1 serveur, 2 serveurs, 4, 8, 16, 32 - autant que vous le souhaitez. Vous lancez une requête et le lancement de ce cluster commence immédiatement. Cela prend vraiment quelques secondes.
Ensuite, une fois le cluster démarré, les micropartitions nécessaires au traitement de votre demande commencent à être copiées dans le cluster à partir de S3. Autrement dit, imaginons que pour exécuter une requête SQL, vous ayez besoin de deux partitions d'une table et d'une de la seconde. Dans ce cas, seules les trois partitions nécessaires seront copiées sur le cluster, et non toutes les tables dans leur intégralité. C'est précisément pourquoi, et précisément parce que tout est situé dans un seul centre de données et connecté par des canaux très rapides, l'ensemble du processus de transfert se déroule très rapidement : en quelques secondes, très rarement en minutes, à moins qu'il ne s'agisse de demandes monstrueuses. En conséquence, les micropartitions sont copiées sur le cluster informatique et, une fois terminée, la requête SQL est exécutée sur ce cluster informatique. Le résultat de cette requête peut être une ligne, plusieurs lignes ou un tableau - ils sont envoyés en externe à l'utilisateur pour qu'il puisse le télécharger, l'afficher dans son outil BI, ou l'utiliser d'une autre manière.
Chaque requête SQL peut non seulement lire des agrégats à partir de données précédemment chargées, mais également charger/générer de nouvelles données dans la base de données. Autrement dit, il peut s'agir d'une requête qui, par exemple, insère de nouveaux enregistrements dans une autre table, ce qui entraîne l'apparition d'une nouvelle partition sur le cluster informatique, qui, à son tour, est automatiquement enregistrée dans un seul stockage S3.
Le scénario décrit ci-dessus, depuis l'arrivée de l'utilisateur jusqu'à la montée du cluster, le chargement des données, l'exécution des requêtes, l'obtention des résultats, est rémunéré au tarif des minutes d'utilisation du cluster informatique virtuel surélevé, entrepôt virtuel. Le tarif varie en fonction de la zone AWS et de la taille du cluster, mais il s'élève en moyenne à quelques dollars par heure. Un cluster de quatre machines coûte deux fois plus cher qu’un cluster de deux machines, et un cluster de huit machines reste deux fois plus cher. Des options de 16, 32 machines sont disponibles, selon la complexité des demandes. Mais vous ne payez que pour les minutes pendant lesquelles le cluster est réellement en cours d'exécution, car lorsqu'il n'y a aucune demande, vous lâchez en quelque sorte la main, et après 5 à 10 minutes d'attente (un paramètre configurable), il s'éteindra tout seul, libérer des ressources et devenir libre.
Un scénario tout à fait réaliste est que lorsque vous envoyez une requête, le cluster apparaît, relativement parlant, en une minute, il compte encore une minute, puis cinq minutes pour s'arrêter, et vous finissez par payer sept minutes de fonctionnement de ce cluster, et pas avant des mois et des années.
Le premier scénario décrit l'utilisation de Snowflake dans un environnement mono-utilisateur. Imaginons maintenant qu'il y ait de nombreux utilisateurs, ce qui est plus proche du scénario réel.
Disons que nous avons de nombreux analystes et rapports Tableau qui bombardent constamment notre base de données avec un grand nombre de requêtes SQL analytiques simples.
De plus, disons que nous avons des Data Scientists inventifs qui tentent de faire des choses monstrueuses avec les données, fonctionnent avec des dizaines de téraoctets, analysent des milliards et des milliards de lignes de données.
Pour les deux types de charge de travail décrits ci-dessus, Snowflake permet de créer plusieurs clusters de calcul indépendants de capacités différentes. De plus, ces clusters informatiques fonctionnent de manière indépendante, mais avec des données communes cohérentes.
Pour un grand nombre de requêtes légères, vous pouvez créer 2 à 3 petits clusters, d'environ 2 machines chacun. Ce comportement peut être implémenté, entre autres, à l'aide de paramètres automatiques. Alors vous dites : « Flocon de neige, élève une petite grappe. Si la charge augmente au-dessus d'un certain paramètre, augmentez une deuxième, une troisième similaire. Lorsque la charge commence à s’atténuer, éteignez l’excédent. Ainsi, quel que soit le nombre d’analystes qui viennent examiner les rapports, chacun dispose de suffisamment de ressources.
Dans le même temps, si les analystes dorment et que personne ne regarde les rapports, les clusters peuvent devenir complètement sombres et vous ne payez plus pour eux.
Dans le même temps, pour les requêtes lourdes (des Data Scientists), vous pouvez créer un très gros cluster pour 32 machines. Ce cluster sera également payé uniquement pour les minutes et heures pendant lesquelles votre requête géante y est exécutée.
L'opportunité décrite ci-dessus vous permet de diviser non seulement 2, mais également davantage de types de charges de travail en clusters (ETL, surveillance, matérialisation de rapports,...).
Résumons Snowflake. La base combine une belle idée et une mise en œuvre réalisable. Chez ManyChat, nous utilisons Snowflake pour analyser toutes les données dont nous disposons. Nous n’avons pas trois clusters, comme dans l’exemple, mais de 5 à 9, de tailles différentes. Nous disposons de machines conventionnelles à 16 machines, de 2 machines et également de très petites machines à 1 machine pour certaines tâches. Ils répartissent avec succès la charge et nous permettent d'économiser beaucoup.
La base de données adapte avec succès la charge de lecture et d’écriture. C'est une énorme différence et une énorme avancée par rapport à la même «Aurora», qui ne supportait que la charge de lecture. Snowflake vous permet d'augmenter votre charge de travail d'écriture avec ces clusters informatiques. Autrement dit, comme je l'ai mentionné, nous utilisons plusieurs clusters dans ManyChat, les petits et super petits clusters sont principalement utilisés pour ETL, pour le chargement des données. Et les analystes vivent déjà sur des clusters moyens, qui ne sont absolument pas affectés par la charge ETL, ils travaillent donc très rapidement.
En conséquence, la base de données est bien adaptée aux tâches OLAP. Malheureusement, cela n’est pas encore applicable aux charges de travail OLTP. Premièrement, cette base de données est en colonnes, avec toutes les conséquences qui en découlent. Deuxièmement, l'approche elle-même, où pour chaque requête, si nécessaire, vous soulevez un cluster informatique et l'inondez de données, n'est malheureusement pas encore assez rapide pour les charges OLTP. Attendre quelques secondes pour les tâches OLAP est normal, mais pour les tâches OLTP, c'est inacceptable ; 100 ms serait mieux, ou 10 ms serait encore mieux.
Total
Une base de données sans serveur est possible en divisant la base de données en parties sans état et avec état. Vous avez peut-être remarqué que dans tous les exemples ci-dessus, la partie Stateful stocke, relativement parlant, des micro-partitions dans S3, et Stateless est l'optimiseur, travaillant avec les métadonnées, gérant les problèmes de sécurité qui peuvent être soulevés en tant que services Stateless légers et indépendants.
L'exécution de requêtes SQL peut également être perçue comme des services légers qui peuvent apparaître en mode sans serveur, comme les clusters informatiques Snowflake, télécharger uniquement les données nécessaires, exécuter la requête et « sortir ».
Des bases de données de niveau production sans serveur sont déjà disponibles, elles fonctionnent. Ces bases de données sans serveur sont déjà prêtes à gérer les tâches OLAP. Malheureusement, pour les tâches OLTP, ils sont utilisés... avec des nuances, car il existe des limitations. D'une part, c'est un inconvénient. Mais d’un autre côté, c’est une opportunité. Peut-être que l'un des lecteurs trouvera un moyen de créer une base de données OLTP complètement sans serveur, sans les limitations d'Aurora.
J'espère que vous l'avez trouvé intéressant. Le sans serveur est l'avenir :)
Source: habr.com