El almacenamiento temporal se limpia, y los recursos se liberan.<\/li>\n<\/ul>\nEn esta arquitectura, solo pagamos por el proceso de ejecuci\u00f3n de la consulta. No hay consultas, no hay gastos.<\/p>\n
El ejemplo de Athena muestra que la base de datos Serverless funciona con consultas reales con decenas y cientos de Terabytes de datos. Para cientos de Terabytes se necesitar\u00edan cientos de servidores, pero no necesitamos pagarlos: pagamos por las consultas. La velocidad de cada consulta es (muy) baja en comparaci\u00f3n con bases de datos anal\u00edticas especializadas como Vertica, pero no pagamos por per\u00edodos de inactividad.<\/p>\n
Esta base de datos es aplicable para consultas anal\u00edticas ad-hoc raras. Por ejemplo, cuando decidimos espont\u00e1neamente verificar una hip\u00f3tesis sobre un volumen gigantesco de datos. Para estos casos, Athena es perfecta. Para consultas regulares, este sistema resulta costoso. En este caso, almacene en cach\u00e9 los datos en alguna soluci\u00f3n especializada. <\/p>\n
Serverless para soluciones OLTP<\/h2>\n \nEn el ejemplo anterior, se consideraron tareas OLAP (anal\u00edticas). Ahora analicemos las tareas OLTP.<\/p>\n
Imaginemos un PostgreSQL o MySQL escalable. Vamos a levantar una instancia administrada de PostgreSQL o MySQL con recursos m\u00ednimos. Cuando la instancia reciba m\u00e1s carga, conectaremos r\u00e9plicas adicionales a las que distribuiremos parte de la carga de lectura. Si no hay solicitudes ni carga, desactivamos las r\u00e9plicas. La primera instancia es el maestro, y las dem\u00e1s son r\u00e9plicas.<\/p>\n
Esta idea se implementa en una base llamada Aurora Serverless de AWS. El principio es simple: un proxy fleet recibe las solicitudes de aplicaciones externas. Al observar un aumento en la carga, asigna recursos computacionales de instancias m\u00ednimas previamente calentadas, realizando la conexi\u00f3n lo m\u00e1s r\u00e1pido posible. La desconexi\u00f3n de instancias ocurre de la misma manera.<\/p>\n
Dentro de Aurora existe el concepto de Aurora Capacity Unit, ACU. Esto es (aproximadamente) una instancia (servidor). Cada ACU espec\u00edfico puede ser maestro o esclavo. Cada Capacity Unit tiene su propia memoria RAM, procesador y disco m\u00ednimo. As\u00ed, hay un maestro y las dem\u00e1s son r\u00e9plicas de solo lectura.<\/p>\n
La cantidad de Aurora Capacity Units en funcionamiento es un par\u00e1metro configurable. El n\u00famero m\u00ednimo puede ser uno o cero (en este caso, la base no funciona si no hay solicitudes).<\/p>\n
La base Aurora Serverless puede escalar la carga de lectura. Pero esto no se menciona expl\u00edcitamente en la documentaci\u00f3n. Puede dar la impresi\u00f3n de que pueden levantar un multi-master. Sin embargo, no hay magia en esto. <\/p>\n
Esta base es ideal para no gastar grandes sumas de dinero en sistemas con acceso impredecible. Por ejemplo, al crear un MVP o sitios web de presentaci\u00f3n, generalmente no esperamos una carga estable. Por lo tanto, en ausencia de acceso, no pagamos por las instancias. Cuando surge una carga inesperada, como despu\u00e9s de una conferencia o una campa\u00f1a publicitaria, un gran n\u00famero de personas accede al sitio y la carga aumenta dr\u00e1sticamente. Aurora Serverless maneja autom\u00e1ticamente esta carga y conecta r\u00e1pidamente los recursos faltantes (ACU). Luego, cuando la conferencia termina, todos olvidan el prototipo, los servidores (ACU) se apagan y los gastos caen a cero: es conveniente.<\/p>\n
Esta soluci\u00f3n no es adecuada para cargas altas y estables, porque no puede escalar la carga de escritura. Todas estas conexiones y desconexiones de recursos ocurren en el momento del llamado 'punto de escala', que es cuando la base de datos no est\u00e1 siendo mantenida por transacciones ni tablas temporales. Por ejemplo, durante una semana puede que no ocurra ning\u00fan punto de escala, y la base opera con los mismos recursos, incapaz de expandirse o contraerse. <\/p>\n
No hay magia: es un PostgreSQL ordinario. Pero el proceso de a\u00f1adir y desconectar m\u00e1quinas est\u00e1 parcialmente automatizado.<\/p>\n
Serverless por dise\u00f1o<\/h2>\n \nAurora Serverless es una base de datos antigua reescrita para la nube, aprovechando las ventajas del enfoque serverless. Ahora, les hablar\u00e9 de una base de datos que fue dise\u00f1ada desde el principio para la nube, con un enfoque serverless: Serverless-by-design. Se desarroll\u00f3 sin la suposici\u00f3n de que funcionar\u00eda en servidores f\u00edsicos.<\/p>\n
Esta base de datos se llama Snowflake. Tiene tres bloques clave.<\/p>\n
El segundo bloque consiste en m\u00faltiples cl\u00fasteres de computaci\u00f3n virtual para c\u00e1lculos (en la ilustraci\u00f3n, un conjunto de c\u00edrculos azules).<\/p>\n
El tercer bloque es un sistema de almacenamiento de datos basado en S3. S3 es un almacenamiento de objetos a escala en AWS, similar a un Dropbox ilimitado para negocios.<\/p>\n
Veamos c\u00f3mo funciona Snowflake, asumiendo un inicio en fr\u00edo. Es decir, la base de datos est\u00e1 creada, los datos han sido cargados, y no hay consultas activas. En consecuencia, si no hay consultas a la base de datos, se ha levantado un servicio de Metadata en memoria r\u00e1pida (el primer bloque). Y tenemos un almacenamiento S3, donde se encuentran los datos de las tablas, divididos en lo que se llaman microparticiones. Para simplificar: si en la tabla se encuentran transacciones, las microparticiones son d\u00edas de transacciones. Cada d\u00eda representa una micropartici\u00f3n, un archivo separado. Y cuando la base de datos funciona en este modo, solo pagas por el espacio que ocupan los datos. Adem\u00e1s, la tarifa por el espacio es muy baja (especialmente teniendo en cuenta la compresi\u00f3n significativa). El servicio de metadatos tambi\u00e9n funciona constantemente, pero para optimizar las consultas no se requieren muchos recursos, y se puede considerar que el servicio es pr\u00e1cticamente gratuito. <\/p>\n
Ahora imaginemos que un usuario llega a nuestra base de datos y lanza una consulta SQL. La consulta SQL se env\u00eda inmediatamente al servicio de Metadata para su procesamiento. Por lo tanto, al recibir la consulta, este servicio analiza la misma, los datos disponibles, los privilegios del usuario y, si todo est\u00e1 bien, elabora un plan de procesamiento de la consulta.<\/p>\n
Luego, el servicio inicia el arranque del cl\u00faster de computaci\u00f3n. Un cl\u00faster de computaci\u00f3n es un conjunto de servidores que realizan c\u00e1lculos. Es decir, es un cl\u00faster que puede contener 1 servidor, 2 servidores, 4, 8, 16, 32\u2014\u00a1cuantos desees! Env\u00edas la consulta y, para ella, se inicia instant\u00e1neamente el arranque de este cl\u00faster. Esto realmente toma unos segundos.<\/p>\n
Cada consulta SQL puede no solo sumarizar datos previamente cargados, sino tambi\u00e9n cargar\/formar nuevos datos en la base. Esto puede ser una consulta que, por ejemplo, inserta nuevos registros en otra tabla, lo que provoca la creaci\u00f3n de una nueva partici\u00f3n en el cl\u00faster de c\u00f3mputo, que, a su vez, se guarda autom\u00e1ticamente en el almacenamiento S3.<\/p>\n
El escenario descrito anteriormente, desde la llegada del usuario hasta el inicio del cl\u00faster, la carga de datos, la ejecuci\u00f3n de consultas y la obtenci\u00f3n de resultados, se factura por las minutos de uso del cl\u00faster de c\u00f3mputo virtual levantado, el warehouse virtual. La tarifa var\u00eda seg\u00fan la zona de AWS y el tama\u00f1o del cl\u00faster, pero, en promedio, cuesta varios d\u00f3lares por hora. Un cl\u00faster de cuatro m\u00e1quinas cuesta el doble que uno de dos m\u00e1quinas, y uno de ocho m\u00e1quinas cuesta el doble de eso. Hay opciones de 16, 32 m\u00e1quinas, dependiendo de la complejidad de las consultas. Pero solo pagas por los minutos en que el cl\u00faster est\u00e1 realmente funcionando, porque cuando no hay consultas, puedes quitar las manos; despu\u00e9s de 5-10 minutos de espera (parametrizable), se apaga autom\u00e1ticamente, libera recursos y se vuelve gratuito.<\/p>\n
Es un escenario completamente realista en el que env\u00edas una solicitud, el cl\u00faster se activa, por as\u00ed decirlo, en un minuto, cuenta durante otro minuto, luego cinco minutos para apagarse, y al final pagas por siete minutos de funcionamiento de ese cl\u00faster, y no por meses o a\u00f1os.<\/p>\n
El primer escenario describ\u00eda el uso de Snowflake en una variante de un solo usuario. Ahora imaginemos que hay muchos usuarios, que se acerca m\u00e1s a un escenario real.<\/p>\n
Supongamos que tenemos muchos analistas y reportes de Tableau que constantemente est\u00e1n bombardeando nuestra base de datos con una gran cantidad de consultas SQL anal\u00edticas simples.<\/p>\n
Adem\u00e1s de eso, supongamos que tenemos cient\u00edficos de datos ingeniosos que intentan hacer cosas monstruosas con los datos, operando con decenas de Terabytes, analizando miles de millones y billones de filas de datos. <\/p>\n
Para los dos tipos de carga descritos anteriormente, Snowflake permite levantar varios cl\u00fasteres de computaci\u00f3n independientes de diferente capacidad. Y estos cl\u00fasteres de computaci\u00f3n funcionan de manera independiente, pero con datos coherentes compartidos.<\/p>\n
Para una gran cantidad de consultas ligeras, se pueden levantar 2-3 cl\u00fasteres peque\u00f1os, de un tama\u00f1o, digamos, de 2 m\u00e1quinas cada uno. Este comportamiento se puede implementar, entre otras cosas, con configuraciones autom\u00e1ticas. Es decir, le dices: \"Snowflake, levanta un cl\u00faster peque\u00f1o. Si la carga en \u00e9l supera un par\u00e1metro determinado, levanta un segundo o un tercero similar. Cuando la carga comience a disminuir, apaga los adicionales\". Para que, independientemente de cu\u00e1ntos analistas lleguen y comiencen a ver los reportes, haya recursos suficientes para todos.<\/p>\n
Al mismo tiempo, si los analistas est\u00e1n durmiendo y nadie est\u00e1 mirando los reportes, los cl\u00fasteres pueden apagarse completamente, y dejas de pagar por ellos.<\/p>\n
Al mismo tiempo, para consultas pesadas (por parte de los cient\u00edficos de datos), puedes levantar un cl\u00faster muy grande con, digamos, 32 m\u00e1quinas. Este cl\u00faster tambi\u00e9n se cobrar\u00e1 solo por los minutos y horas en que tu gigantesca consulta est\u00e9 en funcionamiento.<\/p>\n
La posibilidad descrita anteriormente permite separar en cl\u00fasteres no solo 2, sino m\u00e1s tipos de carga (ETL, monitoreo, materializaci\u00f3n de reportes, \u2026).<\/p>\n
Hagamos un resumen sobre Snowflake. La base combina una idea atractiva con una implementaci\u00f3n funcional. En ManyChat utilizamos Snowflake para la anal\u00edtica de todos los datos disponibles. No tenemos tres cl\u00fasteres como en el ejemplo, sino entre 5 y 9, de diferentes tama\u00f1os. Disponemos de cl\u00fasteres de 16 m\u00e1quinas, de 2 m\u00e1quinas, as\u00ed como muy peque\u00f1os de 1 m\u00e1quina para algunas tareas. Distribuyen la carga de manera efectiva y nos permiten ahorrar significativamente.<\/p>\n
La base escala con \u00e9xito la carga de lectura y escritura. Esta es una gran diferencia y un gran avance en comparaci\u00f3n con la 'Aurora', que solo manejaba la carga de lectura. Snowflake permite escalar la carga de escritura utilizando esos cl\u00fasteres computacionales. Es decir, como mencion\u00e9, en ManyChat usamos varios cl\u00fasteres, los peque\u00f1os y superpeque\u00f1os se utilizan principalmente para ETL, para la carga de datos. En cambio, los analistas trabajan en cl\u00fasteres medianos, que no se ven afectados por la carga ETL, por lo que funcionan muy r\u00e1pido. <\/p>\n
En consecuencia, la base es adecuada para tareas OLAP. Sin embargo, desafortunadamente, todav\u00eda no es aplicable a cargas OLTP. En primer lugar, esta base es columnar, con todas las consecuencias que eso conlleva. En segundo lugar, el enfoque mismo, donde se levanta un cl\u00faster computacional para cada solicitud seg\u00fan sea necesario y se le inunda con datos, a\u00fan es insuficientemente r\u00e1pido para las cargas OLTP. Segundos de espera para tareas OLAP son normales, pero inaceptables para tareas OLTP; preferir\u00edamos 100 ms, y a\u00fan mejor, 10 ms.<\/p>\n
Summary<\/h2>\n \nLa base de datos sin servidor es posible gracias a la separaci\u00f3n de la base de datos en partes Stateless y Stateful. Debe haber notado que en todos los ejemplos dados, la parte Stateful es, por as\u00ed decirlo, el almacenamiento de micro-particiones en S3, mientras que Stateless es el optimizador, el manejo de los metadatos, y el tratamiento de cuestiones de seguridad que pueden ser levantadas como servicios livianos Stateless independientes.<\/p>\n
La ejecuci\u00f3n de consultas SQL tambi\u00e9n puede considerarse como servicios con un ligero estado, que pueden desplegarse en modo sin servidor, como los cl\u00fasteres computacionales de Snowflake, descargar solo los datos necesarios, ejecutar la consulta y 'apagarse'.<\/p>\n
Las bases de datos serverless de nivel productivo ya est\u00e1n disponibles para su uso, est\u00e1n en funcionamiento. Estas bases de datos serverless ya est\u00e1n preparadas para manejar tareas OLAP. Desafortunadamente, para las tareas OLTP se utilizan... con matices, ya que hay limitaciones. Por un lado, esto es una desventaja. Pero, por otro lado, es una oportunidad. Quiz\u00e1s alguno de los lectores encuentre la manera de hacer que una base de datos OLTP sea completamente serverless, sin limitaciones de Aurora.<\/p>\n
Espero que haya sido interesante para ustedes. Hacia un futuro sin servidor \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