O armazenamento tempor\u00e1rio \u00e9 limpo e os recursos s\u00e3o liberados.<\/li>\n<\/ul>\nNesta arquitetura, pagamos apenas pelo processo de execu\u00e7\u00e3o da consulta. N\u00e3o h\u00e1 consultas \u2014 n\u00e3o h\u00e1 gastos.<\/p>\n
No exemplo do Athena, fica claro que o banco de dados Serverless funciona com consultas reais contendo dezenas e centenas de terabytes de dados. Para centenas de terabytes, precisar\u00edamos de centenas de servidores, mas n\u00e3o precisamos pagar por eles \u2014 pagamos pelas consultas. A velocidade de cada consulta \u00e9 (muito) baixa em compara\u00e7\u00e3o com bancos de dados anal\u00edticos especializados como o Vertica, mas, em troca, n\u00e3o pagamos por per\u00edodos de inatividade.<\/p>\n
Esse banco de dados \u00e9 aplic\u00e1vel para consultas anal\u00edticas ad-hoc raras. Por exemplo, quando decidimos espontaneamente verificar uma hip\u00f3tese em um volume gigantesco de dados. Para esses casos, o Athena \u00e9 ideal. Para consultas regulares, esse sistema se torna caro. Neste caso, fa\u00e7a cache dos dados em alguma solu\u00e7\u00e3o especializada. <\/p>\n
Serverless para solu\u00e7\u00f5es OLTP<\/h2>\n \nNo exemplo anterior, foram consideradas tarefas OLAP (anal\u00edticas). Agora, vamos considerar tarefas OLTP.<\/p>\n
Vamos apresentar um PostgreSQL ou MySQL escal\u00e1vel. Vamos levantar uma inst\u00e2ncia gerenciada comum de PostgreSQL ou MySQL com recursos m\u00ednimos. Quando a inst\u00e2ncia enfrentar uma carga maior, adicionaremos r\u00e9plicas adicionais, nas quais distribuiremos parte da carga de leitura. Se n\u00e3o houver solicita\u00e7\u00f5es e carga, desativamos as r\u00e9plicas. A primeira inst\u00e2ncia \u00e9 o mestre, e as demais s\u00e3o as r\u00e9plicas.<\/p>\n
Essa ideia est\u00e1 implementada em uma base chamada Aurora Serverless da AWS. O princ\u00edpio \u00e9 simples: as solicita\u00e7\u00f5es de aplicativos externos s\u00e3o recebidas por uma frota de proxy. Ao perceber um aumento na carga, ela allocate recursos computacionais das inst\u00e2ncias m\u00ednimas previamente aquecidas \u2014 a conex\u00e3o \u00e9 realizada o mais r\u00e1pido poss\u00edvel. A desativa\u00e7\u00e3o das inst\u00e2ncias ocorre da mesma forma.<\/p>\n
Dentro da Aurora, existe o conceito de Unidade de Capacidade Aurora, ACU. Isso \u00e9 (condicionalmente) uma inst\u00e2ncia (servidor). Cada ACU espec\u00edfico pode ser mestre ou escravo. Cada Unidade de Capacidade possui sua pr\u00f3pria mem\u00f3ria RAM, processador e disco m\u00ednimo. Portanto, um \u00e9 o mestre, e os demais s\u00e3o r\u00e9plicas somente de leitura.<\/p>\n
O n\u00famero dessas Unidades de Capacidade Aurora em funcionamento \u00e9 um par\u00e2metro configur\u00e1vel. O n\u00famero m\u00ednimo pode ser um ou zero (neste caso, a base n\u00e3o funciona se n\u00e3o houver solicita\u00e7\u00f5es).<\/p>\n
A base Aurora Serverless pode escalar a carga de leitura. Mas isso n\u00e3o \u00e9 dito explicitamente na documenta\u00e7\u00e3o. Pode parecer que eles conseguem levantar um multi-mestre. No entanto, n\u00e3o h\u00e1 nenhuma m\u00e1gica. <\/p>\n
Essa base \u00e9 ideal para evitar gastar grandes quantias em sistemas com acesso imprevis\u00edvel. Por exemplo, ao criar um MVP ou sites de marketing, geralmente n\u00e3o esperamos uma carga est\u00e1vel. Assim, na aus\u00eancia de acesso, n\u00e3o pagamos por inst\u00e2ncias. Quando uma carga inesperada ocorre, como ap\u00f3s uma confer\u00eancia ou campanha publicit\u00e1ria, grandes volumes de visitantes acessam o site e a carga aumenta rapidamente; o Aurora Serverless assume automaticamente essa carga e conecta rapidamente os recursos ausentes (ACU). Depois da confer\u00eancia, todos esquecem do prot\u00f3tipo, os servidores (ACU) desligam e os custos caem para zero \u2014 \u00e9 conveniente.<\/p>\n
Esta solu\u00e7\u00e3o n\u00e3o \u00e9 adequada para alta carga est\u00e1vel, pois n\u00e3o consegue escalar a carga de grava\u00e7\u00e3o. Todas essas conex\u00f5es e desconex\u00f5es de recursos ocorrem no chamado \"ponto de escala\" \u2014 o momento em que a base n\u00e3o est\u00e1 bloqueada por uma transa\u00e7\u00e3o ou por tabelas tempor\u00e1rias. Por exemplo, ao longo de uma semana, o ponto de escala pode n\u00e3o ocorrer, e a base opera com os mesmos recursos sem poder se expandir ou se contrair. <\/p>\n
N\u00e3o h\u00e1 m\u00e1gica \u2014 \u00e9 um PostgreSQL comum. Mas o processo de adicionar m\u00e1quinas e desconectar \u00e9 parcialmente automatizado.<\/p>\n
Serverless por design<\/h2>\n \nO Aurora Serverless \u00e9 uma base antiga reescrita para a nuvem, aproveitando as vantagens do Serverless. Agora, deixe-me falar sobre uma base que foi escrita desde o in\u00edcio para a nuvem, com uma abordagem serverless \u2014 Serverless-by-design. Ela foi desenvolvida sem a suposi\u00e7\u00e3o de que funcionaria em servidores f\u00edsicos.<\/p>\n
Essa base \u00e9 chamada Snowflake. Ela possui tr\u00eas blocos principais.<\/p>\n
O segundo bloco \u2014 \u00e9 um conjunto de v\u00e1rios clusters computacionais virtuais para c\u00e1lculos (na ilustra\u00e7\u00e3o \u2014 um conjunto de c\u00edrculos azuis).<\/p>\n
O terceiro bloco \u2014 \u00e9 um sistema de armazenamento de dados baseado em S3. O S3 \u00e9 um armazenamento de objetos escal\u00e1vel na AWS, semelhante a um Dropbox sem limites para empresas.<\/p>\n
Vamos ver como o Snowflake funciona, assumindo um in\u00edcio a frio. Ou seja, o banco de dados existe, os dados est\u00e3o carregados, mas n\u00e3o h\u00e1 consultas em execu\u00e7\u00e3o. Assim, se n\u00e3o h\u00e1 consultas ao banco, temos um r\u00e1pido servi\u00e7o de Metadados em mem\u00f3ria levantado (o primeiro bloco). E temos um armazenamento S3, onde os dados das tabelas est\u00e3o armazenados, divididos em chamadas micr\u00f4parti\u00e7\u00f5es. Para simplificar: se a tabela cont\u00e9m neg\u00f3cios, as micr\u00f4parti\u00e7\u00f5es s\u00e3o dias de neg\u00f3cios. Cada dia \u00e9 uma micr\u00f4parti\u00e7\u00e3o separada, um arquivo separado. E quando o banco est\u00e1 operando nesse modo, voc\u00ea paga apenas pelo espa\u00e7o ocupado pelos dados. Al\u00e9m disso, a tarifa por espa\u00e7o \u00e9 muito baixa (especialmente considerando a compress\u00e3o significativa). O servi\u00e7o de metadados tamb\u00e9m est\u00e1 sempre ativo, mas para otimiza\u00e7\u00e3o de consultas, n\u00e3o precisa de muitos recursos, e o servi\u00e7o pode ser considerado condicionalmente gratuito. <\/p>\n
Agora, vamos imaginar que um usu\u00e1rio se conectou ao nosso banco de dados e enviou uma consulta SQL. A consulta SQL \u00e9 imediatamente enviada para processamento pelo servi\u00e7o de Metadados. Assim, ao receber a consulta, esse servi\u00e7o analisa a consulta, os dados dispon\u00edveis, as permiss\u00f5es do usu\u00e1rio e, se tudo estiver bem, elabora um plano de processamento da consulta.<\/p>\n
Em seguida, o servi\u00e7o inicia a execu\u00e7\u00e3o de um cluster de computa\u00e7\u00e3o. O cluster de computa\u00e7\u00e3o \u00e9 um conjunto de servidores que realizam c\u00e1lculos. Ou seja, \u00e9 um cluster que pode conter 1 servidor, 2 servidores, 4, 8, 16, 32 \u2014 quantos voc\u00ea quiser. Voc\u00ea envia a consulta e, imediatamente, o in\u00edcio desse cluster come\u00e7a. Isso realmente leva apenas alguns segundos.<\/p>\n
Cada consulta SQL pode n\u00e3o apenas calcular agregados a partir de dados previamente carregados, mas tamb\u00e9m carregar\/formar novos dados no banco. Ou seja, pode ser uma consulta que, por exemplo, insere novos registros em outra tabela, o que resulta na cria\u00e7\u00e3o de uma nova parti\u00e7\u00e3o no cluster computacional, que, por sua vez, \u00e9 automaticamente salva no armazenamento S3 unificado.<\/p>\n
O cen\u00e1rio descrito acima, desde a chegada do usu\u00e1rio at\u00e9 a ativa\u00e7\u00e3o do cluster, carregamento de dados, execu\u00e7\u00e3o de consultas e obten\u00e7\u00e3o de resultados, \u00e9 cobrado por tarifa por minutos de uso do cluster computacional virtual ativado, o warehouse virtual. A tarifa varia dependendo da zona AWS e do tamanho do cluster, mas, em m\u00e9dia, custa alguns d\u00f3lares por hora. Um cluster de quatro m\u00e1quinas \u00e9 duas vezes mais caro do que um de duas m\u00e1quinas, e um de oito m\u00e1quinas \u00e9 ainda duas vezes mais caro. Est\u00e3o dispon\u00edveis op\u00e7\u00f5es de 16, 32 m\u00e1quinas, dependendo da complexidade das consultas. Mas voc\u00ea paga apenas pelos minutos em que o cluster realmente est\u00e1 em opera\u00e7\u00e3o, pois, quando n\u00e3o h\u00e1 consultas, voc\u00ea 'retira a m\u00e3o', e ap\u00f3s 5-10 minutos de espera (um par\u00e2metro configur\u00e1vel), ele se desligar\u00e1 automaticamente, liberando recursos e tornando-se gratuito.<\/p>\n
\u00c9 completamente vi\u00e1vel que voc\u00ea fa\u00e7a uma solicita\u00e7\u00e3o, e o cluster apare\u00e7a, digamos, em um minuto, depois ele leva mais um minuto para calcular, em seguida, cinco minutos para desligar, e no final voc\u00ea paga apenas por sete minutos de opera\u00e7\u00e3o desse cluster, e n\u00e3o por meses ou anos.<\/p>\n
O primeiro cen\u00e1rio descreveu o uso do Snowflake em um modo para um \u00fanico usu\u00e1rio. Agora vamos imaginar que h\u00e1 muitos usu\u00e1rios, o que j\u00e1 se aproxima de um cen\u00e1rio real.<\/p>\n
Suponha que temos muitos analistas e relat\u00f3rios do Tableau que est\u00e3o constantemente bombardeando nosso banco de dados com uma grande quantidade de consultas SQL anal\u00edticas simples.<\/p>\n
Al\u00e9m disso, suponha que temos Data Scientists inventivos que est\u00e3o tentando fazer coisas monstruosas com os dados, lidando com dezenas de Terabytes, analisando bilh\u00f5es e trilh\u00f5es de linhas de dados. <\/p>\n
Para os dois tipos de carga descritos acima, o Snowflake permite a cria\u00e7\u00e3o de v\u00e1rios clusters de computa\u00e7\u00e3o independentes de diferentes pot\u00eancias. Esses clusters de computa\u00e7\u00e3o funcionam de maneira independente, mas com dados comuns e consistentes.<\/p>\n
Para um grande n\u00famero de consultas leves, \u00e9 poss\u00edvel criar 2-3 pequenos clusters, com, digamos, 2 m\u00e1quinas cada. Esse comportamento \u00e9 vi\u00e1vel, inclusive, por meio de configura\u00e7\u00f5es autom\u00e1ticas. Ou seja, voc\u00ea diz: \"Snowflake, levante um pequeno cluster. Se a carga aumentar al\u00e9m de um par\u00e2metro espec\u00edfico, levante um segundo ou terceiro semelhante. Quando a carga diminuir, desligue os extras.\" Assim, independentemente de quantos analistas se apresentem e comecem a olhar os relat\u00f3rios, todos ter\u00e3o recursos suficientes.<\/p>\n
Nesse caso, se os analistas estiverem dormindo e ningu\u00e9m estiver olhando os relat\u00f3rios, os clusters podem ser completamente desligados, e voc\u00ea para de pagar por eles.<\/p>\n
Para consultas pesadas (dos Data Scientists), voc\u00ea pode levantar um grande cluster com cerca de 32 m\u00e1quinas. Esse cluster tamb\u00e9m ser\u00e1 cobrado apenas pelos minutos e horas em que sua consulta gigante estiver sendo executada.<\/p>\n
A possibilidade descrita acima permite dividir em clusters n\u00e3o apenas 2, mas tamb\u00e9m mais tipos de carga (ETL, monitoramento, materializa\u00e7\u00e3o de relat\u00f3rios,...).<\/p>\n
Vamos resumir sobre o Snowflake. A base combina uma ideia bonita com uma implementa\u00e7\u00e3o funcional. No ManyChat, usamos o Snowflake para a an\u00e1lise de todos os dados dispon\u00edveis. Temos clusters n\u00e3o tr\u00eas, como no exemplo, mas entre 5 e 9, de tamanhos diferentes. Temos clusters de 16 m\u00e1quinas, de 2 m\u00e1quinas e at\u00e9 super pequenos, com 1 m\u00e1quina para algumas tarefas. Eles distribuem a carga com sucesso e nos permitem economizar significativamente.<\/p>\n
A base escala com sucesso a carga de leitura e escrita. Esta \u00e9 uma grande diferen\u00e7a e um grande avan\u00e7o em compara\u00e7\u00e3o com a 'Aurora', que apenas suportava a carga de leitura. O Snowflake permite escalar tamb\u00e9m a carga de escrita com esses clusters computacionais. Ou seja, como mencionei, usamos v\u00e1rios clusters no ManyChat, sendo que os pequenos e super pequenos clusters s\u00e3o usados principalmente para ETL, para carregar dados. E os analistas operam em clusters m\u00e9dios, que n\u00e3o s\u00e3o afetados pela carga de ETL, portanto trabalham muito rapidamente. <\/p>\n
Assim, a base \u00e9 bem adequada para tarefas OLAP. No entanto, infelizmente, ainda n\u00e3o \u00e9 aplic\u00e1vel a cargas OLTP. Primeiro, esta base \u00e9 coluna, com todas as consequ\u00eancia que isso traz. Em segundo lugar, essa abordagem, onde se cria um cluster computacional para cada consulta \u00e0 medida que necess\u00e1rio e o alimenta com dados, infelizmente, n\u00e3o \u00e9 r\u00e1pida o suficiente para cargas OLTP. Segundos de espera para tarefas OLAP s\u00e3o aceit\u00e1veis, mas para OLTP, \u00e9 inaceit\u00e1vel, \u00e9 melhor ter 100 ms, e ainda melhor \u2014 10 ms.<\/p>\n
Resultado<\/h2>\n \nA base de dados sem servidor \u00e9 poss\u00edvel devido \u00e0 separa\u00e7\u00e3o da base de dados em partes Stateless e Stateful. Voc\u00ea deve ter notado que em todos os exemplos citados, a parte Stateful \u00e9, por assim dizer, o armazenamento de microparti\u00e7\u00f5es no S3, enquanto a parte Stateless \u00e9 o otimizador, a manipula\u00e7\u00e3o de metadados e o tratamento de quest\u00f5es de seguran\u00e7a, que podem ser levantadas como servi\u00e7os Stateless leves e independentes.<\/p>\n
A execu\u00e7\u00e3o de consultas SQL tamb\u00e9m pode ser vista como servi\u00e7os com estado leve, que podem surgir em modo sem servidor, como clusters computacionais do Snowflake, baixar apenas os dados necess\u00e1rios, executar a consulta e 'desligar-se'.<\/p>\n
As bases de dados serverless de n\u00edvel de produ\u00e7\u00e3o j\u00e1 est\u00e3o dispon\u00edveis para uso e est\u00e3o operacionais. Essas bases de dados serverless j\u00e1 est\u00e3o prontas para lidar com tarefas OLAP. Infelizmente, para tarefas OLTP, elas s\u00e3o aplicadas... com nuances, uma vez que existem limita\u00e7\u00f5es. Por um lado, isso \u00e9 uma desvantagem. Mas, por outro lado, \u00e9 uma oportunidade. \u00c9 poss\u00edvel que algum dos leitores encontre uma maneira de tornar uma base de dados OLTP completamente serverless, sem as limita\u00e7\u00f5es do Aurora.<\/p>\n
Espero que tenha achado interessante. Rumo ao futuro 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