Le stockage temporaire est nettoy\u00e9, les ressources sont lib\u00e9r\u00e9es.<\/li>\n<\/ul>\nDans cette architecture, nous ne payons que pour le traitement de la requ\u00eate. Pas de requ\u00eates = pas de frais.<\/p>\n
L'exemple d'Athena montre que la base de donn\u00e9es Serverless fonctionne sur de r\u00e9elles requ\u00eates avec des dizaines et des centaines de t\u00e9raoctets de donn\u00e9es. Pour des centaines de t\u00e9raoctets, il en faudrait des centaines de serveurs, mais nous n'avons pas besoin de payer pour eux \u2014 nous payons pour les requ\u00eates. La vitesse de chaque requ\u00eate est (tr\u00e8s) faible par rapport aux bases de donn\u00e9es analytiques sp\u00e9cialis\u00e9es comme Vertica, mais nous ne payons pas pour les p\u00e9riodes d'inactivit\u00e9.<\/p>\n
Une telle base de donn\u00e9es est applicable pour des requ\u00eates analytiques ad-hoc rares. Par exemple, lorsque nous d\u00e9cidons spontan\u00e9ment de tester une hypoth\u00e8se sur un immense volume de donn\u00e9es. Pour ces cas, Athena est parfaitement adapt\u00e9e. Pour des requ\u00eates r\u00e9guli\u00e8res, un tel syst\u00e8me devient co\u00fbteux. Dans ce cas, mettez en cache les donn\u00e9es dans une solution sp\u00e9cialis\u00e9e. <\/p>\n
Serverless pour les solutions OLTP<\/h2>\n \nDans l'exemple pr\u00e9c\u00e9dent, nous avons examin\u00e9 des t\u00e2ches OLAP (analytiques). Maintenant, examinons des t\u00e2ches OLTP.<\/p>\n
Imaginons un PostgreSQL ou MySQL \u00e9volutif. \u00c9levons une instance PostgreSQL ou MySQL g\u00e9r\u00e9e classique avec des ressources minimales. Lorsque l'instance subira plus de charge, nous connecterons des r\u00e9pliques suppl\u00e9mentaires pour r\u00e9partir une partie de la charge de lecture. Si aucune requ\u00eate n'est pr\u00e9sente, nous d\u00e9sactiverons les r\u00e9pliques. La premi\u00e8re instance est le ma\u00eetre, et les autres sont des r\u00e9pliques.<\/p>\n
Cette id\u00e9e est mise en \u0153uvre dans une base nomm\u00e9e Aurora Serverless AWS. Le principe est simple : les requ\u00eates des applications externes sont accept\u00e9es par une flotte de proxy. En observant une augmentation de la charge, elle alloue des ressources de calcul \u00e0 partir d'instances minimales pr\u00e9chauff\u00e9es \u2014 la connexion est effectu\u00e9e le plus rapidement possible. La d\u00e9sactivation des instances se fait de la m\u00eame mani\u00e8re.<\/p>\n
Dans le cadre d'Aurora, il existe le concept d'Aurora Capacity Unit, ACU. Cela repr\u00e9sente (conditionnellement) une instance (serveur). Chaque ACU sp\u00e9cifique peut \u00eatre ma\u00eetre ou esclave. Chaque Capacity Unit dispose de sa propre m\u00e9moire vive, de son processeur et d'un disque minimal. Par cons\u00e9quent, une instance est le ma\u00eetre, les autres sont des r\u00e9pliques en lecture seule.<\/p>\n
Le nombre d'Aurora Capacity Units fonctionnels est un param\u00e8tre configurable. Le nombre minimum peut \u00eatre un ou z\u00e9ro (dans ce cas, la base ne fonctionne pas s'il n'y a pas de requ\u00eates).<\/p>\n
La base Aurora Serverless peut mettre \u00e0 l'\u00e9chelle la charge de lecture. Mais il n'est pas clairement mentionn\u00e9 dans la documentation. Il peut donner l'impression qu'ils peuvent \u00e9lever un multi-ma\u00eetre. Mais il n'y a vraiment rien de magique. <\/p>\n
Cette base est id\u00e9ale pour \u00e9viter de d\u00e9penser d'\u00e9normes sommes sur des syst\u00e8mes \u00e0 acc\u00e8s impr\u00e9visible. Par exemple, lors de la cr\u00e9ation d'un MVP ou de sites web marketing, nous ne pr\u00e9voyons g\u00e9n\u00e9ralement pas une charge stable. En cons\u00e9quence, en l'absence d'acc\u00e8s, nous ne payons pas pour les instances. Lorsque la charge survient soudainement, par exemple apr\u00e8s une conf\u00e9rence ou une campagne publicitaire, des foules de visiteurs acc\u00e8dent au site et la charge augmente rapidement, Aurora Serverless g\u00e8re automatiquement cette charge et connecte rapidement les ressources manquantes (ACU). Apr\u00e8s la conf\u00e9rence, tout le monde oublie le prototype, les serveurs (ACU) se mettent en veille et les co\u00fbts tombent \u00e0 z\u00e9ro \u2014 pratique.<\/p>\n
Cette solution n'est pas adapt\u00e9e pour une haute charge stable, car elle ne sait pas g\u00e9rer la mont\u00e9e en charge de l'\u00e9criture. Toutes ces connexions et d\u00e9connexions de ressources se produisent au moment appel\u00e9 \u00ab scale point \u00bb \u2014 le moment o\u00f9 la base n'est pas maintenue par une transaction, ni par des tables temporaires. Par exemple, durant une semaine, il se peut qu'aucun scale point ne se produise, et la base fonctionne sur les m\u00eames ressources sans pouvoir ni s'\u00e9tendre, ni se r\u00e9duire. <\/p>\n
Il n'y a pas de magie \u2014 c'est du PostgreSQL ordinaire. Mais le processus d'ajout et de suppression de machines est partiellement automatis\u00e9.<\/p>\n
Serverless par conception<\/h2>\n \nAurora Serverless est une ancienne base r\u00e9\u00e9crite pour le cloud, afin de tirer parti des avantages distincts du Serverless. Maintenant, parlons d'une base qui a \u00e9t\u00e9 con\u00e7ue d\u00e8s le d\u00e9part pour le cloud, sous l'approche serverless \u2014 Serverless-by-design. Elle a \u00e9t\u00e9 d\u00e9velopp\u00e9e sans aucune hypoth\u00e8se sur son fonctionnement sur des serveurs physiques.<\/p>\n
Cette base s'appelle Snowflake. Elle comprend trois blocs cl\u00e9s.<\/p>\n
Le deuxi\u00e8me bloc \u2014 ce sont de nombreux clusters de calcul virtuels pour les calculs (sur l'illustration \u2014 un ensemble de cercles bleus).<\/p>\n
Le troisi\u00e8me bloc \u2014 c'est le syst\u00e8me de stockage de donn\u00e9es bas\u00e9 sur S3. S3 est un stockage d'objets infini sur AWS, quelque chose de semblable \u00e0 un Dropbox illimit\u00e9 pour les entreprises.<\/p>\n
Voyons comment fonctionne Snowflake, en supposant un d\u00e9marrage \u00e0 froid. C'est-\u00e0-dire que la base est pr\u00e9sente, les donn\u00e9es sont charg\u00e9es, mais il n'y a pas de requ\u00eates en cours. En cons\u00e9quence, s'il n'y a pas de requ\u00eates vers la base, nous avons un service de m\u00e9tadonn\u00e9es in-memory rapide (le premier bloc). Et nous avons un stockage S3, o\u00f9 se trouvent les donn\u00e9es des tables, divis\u00e9es en ce que l'on appelle des micropartitions. Pour simplifier : si la table contient des transactions, les micropartitions repr\u00e9sentent des jours de transactions. Chaque jour est une micropartition distincte, un fichier distinct. Et lorsque la base fonctionne dans ce mode, vous ne payez que pour l'espace occup\u00e9 par les donn\u00e9es. De plus, le tarif pour l'espace est tr\u00e8s bas (surtout compte tenu de la compression significative). Le service de m\u00e9tadonn\u00e9es fonctionne \u00e9galement en permanence, mais pour optimiser les requ\u00eates, il n'est pas n\u00e9cessaire de disposer de nombreuses ressources, et le service peut \u00eatre consid\u00e9r\u00e9 comme conditionnellement gratuit. <\/p>\n
Imaginons maintenant qu'un utilisateur essaie d'acc\u00e9der \u00e0 notre base et envoie une requ\u00eate SQL. La requ\u00eate SQL est imm\u00e9diatement trait\u00e9e par le service de m\u00e9tadonn\u00e9es. En cons\u00e9quence, apr\u00e8s avoir re\u00e7u la requ\u00eate, ce service analyse la requ\u00eate, les donn\u00e9es disponibles, les autorisations de l'utilisateur et, si tout va bien, \u00e9labore un plan de traitement de la requ\u00eate.<\/p>\n
Par la suite, le service initie le d\u00e9marrage d'un cluster de calcul. Un cluster de calcul est un ensemble de serveurs qui effectuent des calculs. Cela signifie que ce cluster peut contenir 1 serveur, 2 serveurs, 4, 8, 16, 32 \u2014 autant que vous le souhaitez. Vous soumettez une requ\u00eate et le d\u00e9marrage de ce cluster commence imm\u00e9diatement. Cela prend r\u00e9ellement quelques secondes.<\/p>\n
Chaque requ\u00eate SQL peut non seulement lire des agr\u00e9gats \u00e0 partir des donn\u00e9es d\u00e9j\u00e0 charg\u00e9es, mais \u00e9galement charger\/cr\u00e9er de nouvelles donn\u00e9es dans la base. C'est-\u00e0-dire qu'il peut s'agir d'une requ\u00eate qui, par exemple, ins\u00e8re de nouveaux enregistrements dans une autre table, ce qui conduit \u00e0 l'apparition d'une nouvelle partition sur le cluster de calcul, qui, \u00e0 son tour, est automatiquement sauvegard\u00e9e dans le stockage S3 unique.<\/p>\n
Le sc\u00e9nario d\u00e9crit ci-dessus, depuis l'arriv\u00e9e de l'utilisateur jusqu'au d\u00e9marrage du cluster, le chargement des donn\u00e9es, l'ex\u00e9cution des requ\u00eates et la r\u00e9ception des r\u00e9sultats, est factur\u00e9 au tarif par minute d'utilisation du cluster de calcul virtuel d\u00e9marr\u00e9, le warehouse virtuel. Le tarif varie en fonction de la zone AWS et de la taille du cluster, mais en moyenne, cela co\u00fbte plusieurs dollars par heure. Un cluster de quatre machines co\u00fbte deux fois plus cher qu'un cluster de deux machines, et un cluster de huit machines co\u00fbte encore deux fois plus cher. Des options sont disponibles avec 16, 32 machines, selon la complexit\u00e9 des requ\u00eates. Mais vous ne payez que pour les minutes o\u00f9 le cluster est r\u00e9ellement en fonction, car lorsque les requ\u00eates ne sont pas pr\u00e9sentes, vous pouvez \u00ab retirer vos mains \u00bb, et apr\u00e8s 5 \u00e0 10 minutes d'attente (param\u00e8tre configurable), il s'\u00e9teindra automatiquement, lib\u00e9rera les ressources et deviendra gratuit.<\/p>\n
Il est tout \u00e0 fait r\u00e9aliste de lancer une requ\u00eate, un cluster se met en place, disons, en une minute, il calcule pendant une minute de plus, puis cinq minutes pour s'\u00e9teindre, et vous payez au final pour sept minutes de fonctionnement de ce cluster, et non pour des mois ou des ann\u00e9es.<\/p>\n
Le premier sc\u00e9nario d\u00e9crivait l'utilisation de Snowflake dans un mode monopenreur. Imaginons maintenant qu'il y ait de nombreux utilisateurs, ce qui est plus proche du sc\u00e9nario r\u00e9el.<\/p>\n
Supposons que nous ayons de nombreux analystes et des rapports Tableau qui bombardent constamment notre base de donn\u00e9es avec un grand volume de requ\u00eates SQL analytiques simples.<\/p>\n
De plus, supposons que nous ayons des Data Scientists ing\u00e9nieux qui tentent de r\u00e9aliser des choses incroyables avec les donn\u00e9es, en manipulant des dizaines de t\u00e9raoctets et en analysant des milliards et des trillions de lignes de donn\u00e9es. <\/p>\n
Pour les deux types de charge d\u00e9crits ci-dessus, Snowflake permet de d\u00e9ployer plusieurs clusters de calcul ind\u00e9pendants de diff\u00e9rentes tailles. Ces clusters fonctionnent de mani\u00e8re ind\u00e9pendante, mais avec des donn\u00e9es coh\u00e9rentes partag\u00e9es.<\/p>\n
Pour un grand nombre de requ\u00eates l\u00e9g\u00e8res, vous pouvez d\u00e9ployer 2 \u00e0 3 petits clusters, chacun occupant, disons, 2 machines. Ce comportement est r\u00e9alisable, y compris gr\u00e2ce \u00e0 des r\u00e9glages automatiques. Vous pouvez dire : \u00ab Snowflake, d\u00e9ploie un petit cluster. Si la charge d\u00e9passe un certain seuil, d\u00e9ploie un deuxi\u00e8me ou troisi\u00e8me similaire. Lorsque la charge commence \u00e0 diminuer, \u00e9teins les superflus. \u00bb Ainsi, peu importe combien d'analystes se pr\u00e9sentent et commencent \u00e0 consulter les rapports, il y a toujours suffisamment de ressources.<\/p>\n
De plus, si les analystes dorment et que personne ne consulte les rapports, les clusters peuvent \u00eatre compl\u00e8tement \u00e9teints, et vous ne payez plus pour eux.<\/p>\n
En outre, pour les requ\u00eates lourdes (celles des Data Scientists), vous pouvez d\u00e9ployer un tr\u00e8s grand cluster de 32 machines, par exemple. Ce cluster sera \u00e9galement factur\u00e9 uniquement pour les minutes et heures pendant lesquelles votre \u00e9norme requ\u00eate y est ex\u00e9cut\u00e9e.<\/p>\n
La capacit\u00e9 d\u00e9crite ci-dessus permet de s\u00e9parer les charges en clusters, non seulement pour 2, mais \u00e9galement pour davantage de types de charges (ETL, monitoring, mat\u00e9rialisation de rapports,\u2026).<\/p>\n
R\u00e9sumons notre propos sur Snowflake. La base combine une belle id\u00e9e avec une r\u00e9alisation fonctionnelle. Chez ManyChat, nous utilisons Snowflake pour analyser toutes nos donn\u00e9es. Nous avons non pas trois clusters comme dans l'exemple, mais entre 5 et 9, de tailles diff\u00e9rentes. Nous disposons de clusters dits de 16 machines, de 2 machines et m\u00eame de tr\u00e8s petits clusters de 1 machine pour certaines t\u00e2ches. Ils r\u00e9partissent la charge avec succ\u00e8s et nous permettent d'\u00e9conomiser consid\u00e9rablement.<\/p>\n
La base g\u00e8re avec succ\u00e8s la charge de lecture et d'\u00e9criture. C'est une grande diff\u00e9rence et un \u00e9norme progr\u00e8s par rapport \u00e0 l'Aurora, qui ne supportait que la charge de lecture. Snowflake permet de scalabiliser cette charge d'\u00e9criture avec ces clusters de calcul. Ainsi, comme je l'ai mentionn\u00e9, plusieurs clusters sont utilis\u00e9s chez ManyChat, les petits et super petits clusters \u00e9tant principalement destin\u00e9s \u00e0 l'ETL pour le chargement des donn\u00e9es. Les analystes utilisent d\u00e9j\u00e0 des clusters de taille moyenne, qui ne sont absolument pas affect\u00e9s par la charge ETL, ce qui leur permet de fonctionner tr\u00e8s rapidement. <\/p>\n
Par cons\u00e9quent, la base est bien adapt\u00e9e aux t\u00e2ches OLAP. Malheureusement, elle n'est pas encore applicable aux charges OLTP. Premi\u00e8rement, cette base est colonne, avec toutes les cons\u00e9quences qui en d\u00e9coulent. Deuxi\u00e8mement, le principe m\u00eame selon lequel vous levez un cluster de calcul pour chaque requ\u00eate selon les besoins et versez des donn\u00e9es dessus n'est malheureusement pas encore assez rapide pour les charges OLTP. Des secondes d'attente pour les t\u00e2ches OLAP sont normales, mais inacceptables pour les charges OLTP, il vaudrait mieux avoir 100 ms, et encore mieux \u2014 10 ms.<\/p>\n
Conclusion<\/h2>\n \nUne base de donn\u00e9es sans serveur est possible gr\u00e2ce \u00e0 la division de la base de donn\u00e9es en parties Stateless et Stateful. Vous avez d\u00fb remarquer que dans tous les exemples donn\u00e9s, la partie Stateful est, pour le dire simplement, le stockage des micropartitions dans S3, tandis que la partie Stateless concerne l'optimiseur, le travail avec les m\u00e9tadonn\u00e9es, le traitement des questions de s\u00e9curit\u00e9, qui peuvent \u00eatre activ\u00e9es en tant que services Stateless l\u00e9gers et ind\u00e9pendants.<\/p>\n
L'ex\u00e9cution des requ\u00eates SQL peut \u00e9galement \u00eatre per\u00e7ue comme des services avec un \u00e9tat l\u00e9ger, qui peuvent surgir en mode sans serveur, comme les clusters de calcul Snowflake, t\u00e9l\u00e9charger uniquement les donn\u00e9es n\u00e9cessaires, ex\u00e9cuter la requ\u00eate et \"s'\u00e9teindre\".<\/p>\n
Des bases de donn\u00e9es serverless de niveau production sont d\u00e9j\u00e0 disponibles et fonctionnent. Ces bases serverless sont pr\u00eates \u00e0 g\u00e9rer des t\u00e2ches OLAP. Malheureusement, pour les t\u00e2ches OLTP, elles sont utilis\u00e9es... avec des nuances, car il existe des limitations. D'un c\u00f4t\u00e9, c'est un inconv\u00e9nient. Mais d'un autre c\u00f4t\u00e9, c'est une opportunit\u00e9. Peut-\u00eatre que certains lecteurs trouveront une fa\u00e7on de rendre une base de donn\u00e9es OLTP compl\u00e8tement serverless, sans les limitations d'Aurora.<\/p>\n
J'esp\u00e8re que vous avez trouv\u00e9 cela int\u00e9ressant. Vers un avenir serverless \ud83d\ude42habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0413\u043e\u043b\u043e\u0432 \u041d\u0438\u043a\u043e\u043b\u0430\u0439. \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0432 \u0410\u0432\u0438\u0442\u043e \u0438 \u0448\u0435\u0441\u0442\u044c \u043b\u0435\u0442 \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u043b Data Platform, \u0442\u043e \u0435\u0441\u0442\u044c \u0437\u0430\u043d\u0438\u043c\u0430\u043b\u0441\u044f \u0432\u0441\u0435\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438: \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c\u0438 (Vertica, ClickHouse), \u043f\u043e\u0442\u043e\u043a\u043e\u0432\u044b\u043c\u0438 \u0438 OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). \u0417\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u044f \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u043b\u0441\u044f \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u2014 \u0441\u0430\u043c\u044b\u0445 \u0440\u0430\u0437\u043d\u044b\u0445 \u0438 \u043d\u0435\u043e\u0431\u044b\u0447\u043d\u044b\u0445, \u0438 \u0441 \u043d\u0435\u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u044b\u043c\u0438 \u043a\u0435\u0439\u0441\u0430\u043c\u0438 \u0438\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91636,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t