Se revisará la contribución de Yandex a las siguientes bases de datos.
- casa de clics
- Odyssey
- Recuperación a un momento determinado (WAL-G)
- PostgreSQL (incluidos logerrors, Amcheck, heapcheck)
- Ciruela verde
Vídeo:
¡Hola Mundo! Mi nombre es Andrey Borodin. Y lo que hago en Yandex.Cloud es desarrollar bases de datos relacionales abiertas en interés de Yandex.Cloud y los clientes de Yandex.Cloud.
En esta charla, hablaremos sobre los desafíos que enfrentan las bases de datos abiertas a escala. ¿Por qué es importante? Porque pequeños, pequeños problemas que, como los mosquitos, luego se convierten en elefantes. Se vuelven grandes cuando tienes muchos grupos.
Pero eso no es lo principal. Suceden cosas increíbles. Cosas que suceden en uno entre un millón de casos. Y en un entorno de nube, hay que estar preparado para eso, porque cosas increíbles se vuelven altamente probables cuando algo existe a escala.
¡Pero! ¿Cuál es la ventaja de las bases de datos abiertas? El hecho es que tienes una oportunidad teórica de abordar cualquier problema. Tienes el código fuente, tienes conocimientos de programación. Lo combinamos y funciona.
¿Qué enfoques existen al trabajar con software de código abierto?
- El enfoque más sencillo es utilizar software. Si usa protocolos, si usa estándares, si usa formatos, si escribe consultas en software de código abierto, entonces ya lo admite.
- Estás haciendo que su ecosistema sea más grande. Aumenta la probabilidad de detección temprana de un error. Aumenta la confiabilidad de este sistema. Aumentas la disponibilidad de desarrolladores en el mercado. Mejoras este software. Ya eres un colaborador si acabas de conseguir estilo y modificaste algo allí.
- Otro enfoque comprensible es patrocinar software de código abierto. Por ejemplo, el conocido programa Google Summer of Code, en el que Google paga a un gran número de estudiantes de todo el mundo un dinero comprensible para que desarrollen proyectos de software abierto que cumplan ciertos requisitos de licencia.
- Este es un enfoque muy interesante porque permite que el software evolucione sin desviar el foco de la comunidad. Google, como gigante tecnológico, no dice que queremos esta característica, queremos corregir este error y aquí es donde tenemos que profundizar. Google dice: “Haz lo que haces. Simplemente sigue trabajando como lo has estado haciendo y todo estará bien”.
- El siguiente enfoque para participar en el código abierto es la participación. Cuando tienes un problema en el software de código abierto y hay desarrolladores, tus desarrolladores empiezan a resolver los problemas. Comienzan a hacer que su infraestructura sea más eficiente y sus programas más rápidos y confiables.
Uno de los proyectos de Yandex más famosos en el campo del software de código abierto es ClickHouse. Esta es una base de datos que nació como respuesta a los desafíos que enfrenta Yandex.Metrica.
Y como base de datos, se creó en código abierto para crear un ecosistema y desarrollarlo junto con otros desarrolladores (no solo dentro de Yandex). Y ahora este es un gran proyecto en el que participan muchas empresas diferentes.
En Yandex.Cloud, creamos ClickHouse encima de Yandex Object Storage, es decir, encima del almacenamiento en la nube.
¿Por qué es esto importante en la nube? Porque cualquier base de datos funciona en este triángulo, en esta pirámide, en esta jerarquía de tipos de memoria. Tiene registros rápidos pero pequeños y SSD, discos duros y algunos otros dispositivos de bloque baratos, grandes pero lentos. Y si eres eficiente en la cima de la pirámide, entonces tienes una base de datos rápida. Si es eficiente en la base de esta pirámide, entonces tendrá una base de datos escalada. Y en este sentido, agregar otra capa desde abajo es un enfoque lógico para aumentar la escalabilidad de la base de datos.
¿Cómo podría hacerse? Este es un punto importante en este informe.
- Podríamos implementar ClickHouse sobre MDS. MDS es una interfaz interna de almacenamiento en la nube de Yandex. Es más complejo que el protocolo S3 común, pero es más adecuado para un dispositivo de bloque. Es mejor para registrar datos. Requiere más programación. Los programadores programarán, incluso es bueno, es interesante.
- S3 es un enfoque más común que simplifica la interfaz a costa de una menor adaptación a ciertos tipos de cargas de trabajo.
Naturalmente, al querer proporcionar funcionalidad a todo el ecosistema de ClickHouse y realizar la tarea necesaria dentro de Yandex.Cloud, decidimos asegurarnos de que toda la comunidad de ClickHouse se beneficiara de ello. Implementamos ClickHouse sobre S3, no ClickHouse sobre MDS. Y esto es mucho trabajo.
Enlaces:
“Capa de abstracción del sistema de archivos”
"Integración de AWS SDK S3"
“Implementación básica de la interfaz IDisk para S3”
"Integración de motores de almacenamiento de logs con interfaz IDisk"
"Soporte del motor de registro para S3 y SeekableReadBuffer"
"Soporte de almacenamiento Stripe Log S3"
"Soporte inicial de Storage MergeTree para S3"
"MergeTree es totalmente compatible con S3"
"Soporte ReplicatedMergeTree sobre S3"
"Agregue credenciales predeterminadas y encabezados personalizados para el almacenamiento s3"
"S3 con configuración de proxy dinámico"
"S3 con resolución de proxy"
Esta es una lista de solicitudes de extracción para implementar un sistema de archivos virtual en ClickHouse. Esta es una gran cantidad de solicitudes de extracción.
Enlaces:
"Implementación óptima de enlaces duros DiskS3"
"Cliente HTTP S3: evite copiar el flujo de respuesta en la memoria"
"Evite copiar el flujo de respuesta completo en la memoria en S3 HTTP
cliente"
"Capacidad de almacenar en caché marcas e indexar archivos para disco S3"
"Mover partes de DiskLocal a DiskS3 en paralelo"
Pero el trabajo no terminó ahí. Una vez creada la función, fue necesario trabajar más para optimizarla.
Enlaces:
"Agregar eventos SelectedRows y SelectedBytes"
"Agregar eventos de creación de perfiles desde la solicitud S3 a system.events"
"Agregar QueryTimeMicrosegundos, SelectQueryTimeMicrosegundos e InsertQueryTimeMicrosegundos"
Y luego fue necesario hacerlo diagnosticable, establecer un seguimiento y hacerlo manejable.
Y todo esto se hizo para que toda la comunidad, todo el ecosistema ClickHouse, recibiera el resultado de este trabajo.
Pasemos a las bases de datos transaccionales, a las bases de datos OLTP, que personalmente están más cerca de mí.
Esta es la división de desarrollo de DBMS de código abierto. Estos chicos están haciendo magia callejera para mejorar las bases de datos transaccionales abiertas.
Uno de los proyectos, usando un ejemplo del cual podemos hablar sobre cómo y qué hacemos, es Connection Pooler en Postgres.
Postgres es una base de datos de procesos. Esto significa que la base de datos debe tener la menor cantidad posible de conexiones de red que manejen transacciones.
Por otro lado, en un entorno de nube, una situación típica es cuando miles de conexiones llegan a un clúster a la vez. Y la tarea del agrupador de conexiones es empaquetar mil conexiones en una pequeña cantidad de conexiones de servidor.
Podemos decir que el pooler de conexiones es el operador telefónico que reordena los bytes para que lleguen eficientemente a la base de datos.
Desafortunadamente, no existe una buena palabra rusa para agrupador de conexiones. A veces se le llama conexiones multiplexoras. Si sabe cómo llamar al agrupador de conexiones, asegúrese de decírmelo; estaré encantado de hablar el idioma técnico ruso correcto.
Investigamos agrupadores de conexiones que eran adecuados para un clúster de Postgres administrado. Y PgBouncer fue la mejor opción para nosotros. Pero encontramos una serie de problemas con PgBouncer. Hace muchos años, Volodya Borodin informó que usamos PgBouncer, nos gusta todo, pero hay matices, hay algo en lo que trabajar.
Y trabajamos. Solucionamos los problemas que encontramos, parcheamos a Bouncer e intentamos enviar solicitudes de extracción en sentido ascendente. Pero era difícil trabajar con un solo subproceso fundamental.
Tuvimos que recolectar cascadas de Bouncers parcheados. Cuando tenemos muchos Bouncers de un solo subproceso, las conexiones de la capa superior se transfieren a la capa interna de Bouncers. Este es un sistema mal administrado que es difícil de construir y escalar hacia adelante y hacia atrás.
Llegamos a la conclusión de que creamos nuestro propio grupo de conexiones, que se llama Odyssey. Lo escribimos desde cero.
En 2019, en la conferencia PgCon, presenté este pooler a la comunidad de desarrolladores. Ahora tenemos un poco menos de 2 estrellas en GitHub, es decir, el proyecto está vivo, el proyecto es popular.
Y si crea un clúster de Postgres en Yandex.Cloud, será un clúster con Odyssey incorporado, que se reconfigura cuando el clúster se escala hacia adelante o hacia atrás.
¿Qué aprendimos de este proyecto? Lanzar un proyecto competidor es siempre un paso agresivo, es una medida extrema cuando decimos que hay problemas que no se están solucionando con la suficiente rapidez, no se están solucionando en los intervalos de tiempo que nos convendrían. Pero esta es una medida eficaz.
PgBouncer comenzó a desarrollarse más rápido.
Y ahora han aparecido otros proyectos. Por ejemplo, pgagroal, desarrollado por desarrolladores de Red Hat. Persiguen objetivos similares e implementan ideas similares, pero, por supuesto, con sus propias particularidades, que están más cerca de los desarrolladores de pgagroal.
Otro caso de trabajo con la comunidad de Postgres es la restauración de un momento determinado. Esto es recuperación después de una falla, esto es recuperación a partir de una copia de seguridad.
Hay muchas copias de seguridad y todas son diferentes. Casi todos los proveedores de Postgres tienen su propia solución de respaldo.
Si toma todos los sistemas de respaldo, crea una matriz de características y calcula en broma el determinante en esta matriz, será cero. ¿Qué quiere decir esto? ¿Qué pasa si toma un archivo de copia de seguridad específico y no se puede ensamblar a partir de partes de todos los demás? Es único en su implementación, es único en su propósito, es único en las ideas que contiene. Y todos son específicos.
Mientras trabajábamos en este tema, CitusData lanzó el proyecto WAL-G. Este es un sistema de respaldo que se creó teniendo en cuenta el entorno de la nube. Ahora CitusData ya forma parte de Microsoft. Y en ese momento, nos gustaron mucho las ideas que se establecieron en los lanzamientos iniciales de WAL-G. Y comenzamos a contribuir a este proyecto.
Ahora hay muchas docenas de desarrolladores en este proyecto, pero entre los 10 principales contribuyentes a WAL-G se encuentran 6 Yandexoids. Trajimos muchas de nuestras ideas allí. Y, por supuesto, los implementamos nosotros mismos, los probamos nosotros mismos, los implementamos en producción nosotros mismos, los usamos nosotros mismos, averiguamos hacia dónde movernos a continuación, mientras interactuamos con la gran comunidad WAL-G.
Y desde nuestro punto de vista, ahora este sistema de respaldo, incluso teniendo en cuenta nuestros esfuerzos, se ha vuelto óptimo para un entorno de nube. Este es el mejor costo de realizar una copia de seguridad de Postgres en la nube.
¿Qué significa? Estábamos promoviendo una idea bastante grande: la copia de seguridad debería ser segura, económica de operar y lo más rápida posible de restaurar.
¿Por qué debería ser barato de operar? Cuando nada está roto, no debes saber que tienes copias de seguridad. Todo funciona bien, desperdicia la menor cantidad de CPU posible, utiliza la menor cantidad posible de recursos de disco y envía la menor cantidad de bytes posible a la red para no interferir con la carga útil de sus valiosos servicios.
Y cuando todo se estropea, por ejemplo, el administrador dejó caer los datos, algo salió mal y necesitas volver al pasado con urgencia, te recuperas con todo el dinero, porque quieres recuperar tus datos rápidamente e intactos.
Y promovimos esta simple idea. Y nos parece que logramos implementarlo.
Pero eso no es todo. Queríamos una pequeña cosa más. Queríamos muchas bases de datos diferentes. No todos nuestros clientes utilizan Postgres. Algunas personas usan MySQL, MongoDB. En la comunidad, otros desarrolladores han apoyado a FoundationDB. Y esta lista se amplía constantemente.
A la comunidad le gusta la idea de que la base de datos se ejecute en un entorno administrado en la nube. Y los desarrolladores mantienen sus bases de datos, de las que se puede realizar una copia de seguridad de manera uniforme junto con Postgres con nuestro sistema de copia de seguridad.
¿Qué hemos aprendido de esta historia? Nuestro producto, como división de desarrollo, no son líneas de código, no son declaraciones, no son archivos. Nuestro producto no son solicitudes de extracción. Estas son las ideas que transmitimos a la comunidad. Se trata de experiencia tecnológica y el movimiento de la tecnología hacia un entorno de nube.
Existe una base de datos como Postgres. Me gusta más el núcleo de Postgres. Dedico mucho tiempo a desarrollar el núcleo de Postgres con la comunidad.
Pero aquí hay que decir que Yandex.Cloud tiene una instalación interna de bases de datos administradas. Y comenzó hace mucho tiempo en Yandex.Mail. La experiencia que ahora ha llevado a Postgres administrado se acumuló cuando el correo quiso pasar a Postgres.
El correo tiene requisitos muy similares a los de la nube. Necesita que pueda escalar a un crecimiento exponencial inesperado en cualquier punto de sus datos. Y el correo ya estaba cargado con unos cientos de millones de buzones de correo de una gran cantidad de usuarios que constantemente hacen muchas solicitudes.
Y este fue un desafío bastante serio para el equipo que estaba desarrollando Postgres. En aquel entonces, cualquier problema que encontráramos se informaba a la comunidad. Y estos problemas fueron corregidos y corregidos por la comunidad en algunos lugares incluso al nivel de soporte pago para algunas otras bases de datos e incluso mejores. Es decir, puede enviar una carta al hacker PgSQL y recibir una respuesta en 40 minutos. El soporte pago en algunas bases de datos puede pensar que hay cosas más prioritarias que su error.
Ahora la instalación interna de Postgres es de unos petabytes de datos. Se trata de algunos millones de solicitudes por segundo. Estos son miles de grupos. Es de muy gran escala.
Pero hay un matiz. No vive en unidades de red sofisticadas, sino en hardware bastante simple. Y hay un entorno de prueba específico para cosas nuevas e interesantes.
Y en un momento determinado en el entorno de prueba recibimos un mensaje indicando que se violaron los invariantes internos de los índices de la base de datos.
Una invariante es algún tipo de relación que esperamos mantener siempre.
Una situación muy crítica para nosotros. Indica que es posible que se hayan perdido algunos datos. Y la pérdida de datos es algo francamente catastrófico.
La idea general que seguimos en las bases de datos gestionadas es que incluso con esfuerzo será difícil perder datos. Incluso si los eliminas deliberadamente, tendrás que ignorar su ausencia durante un largo período de tiempo. La seguridad de los datos es una religión que seguimos con bastante diligencia.
Y aquí surge una situación que sugiere que puede haber una situación para la que quizás no estemos preparados. Y comenzamos a prepararnos para esta situación.
Lo primero que hicimos fue enterrar los troncos de estos miles de racimos. Descubrimos cuáles de los clústeres estaban ubicados en discos con firmware problemático que estaban perdiendo actualizaciones de páginas de datos. Marcó todo el código de datos de Postgres. Y marcamos esos mensajes que indican violaciones de invariantes internas con código diseñado para detectar corrupción de datos.
Este parche fue prácticamente aceptado por la comunidad sin mucha discusión, porque en cada caso específico era obvio que había sucedido algo malo y debía informarse en el registro.
Después de esto, llegamos al punto en que tenemos un monitoreo que escanea los registros. Y en caso de mensajes sospechosos, despierta al oficial de guardia y el oficial de guardia lo repara.
¡Pero! Escanear registros es una operación económica en un clúster y catastróficamente costosa para mil clústeres.
Escribimos una extensión llamada . Crea una vista de la base de datos en la que puede seleccionar de forma económica y rápida estadísticas sobre errores pasados. Y si necesitamos despertar al oficial de servicio, lo descubriremos sin escanear archivos de gigabytes, sino extrayendo algunos bytes de la tabla hash.
Esta extensión ha sido adoptada, por ejemplo, en el repositorio de . Si desea utilizarlo, puede instalarlo usted mismo. Por supuesto que es de código abierto.
Pero eso no es todo. Comenzamos a utilizar Amcheck, una extensión creada por la comunidad, para encontrar violaciones invariantes en los índices.
Y descubrimos que si lo operas a escala, hay errores. Empezamos a arreglarlos. Nuestras correcciones han sido aceptadas.
Descubrimos que esta extensión no puede analizar índices GiST y GIT. Les hicimos apoyar. Pero la comunidad todavía está discutiendo este soporte, porque es una funcionalidad relativamente nueva y hay muchos detalles allí.
Y también descubrimos que al verificar los índices en busca de violaciones en el líder de replicación, en el maestro, todo funciona bien, pero en las réplicas, en el seguidor, la búsqueda de corrupción no es tan efectiva. No se verifican todas las invariantes. Y una invariante nos molestó mucho. Y pasamos un año y medio comunicándonos con la comunidad para permitir esta verificación de las réplicas.
Escribimos código que debería seguir todos los protocolos can.... Hablamos de este parche durante bastante tiempo con Peter Gaghan de Crunchy Data. Tuvo que modificar ligeramente el árbol B existente en Postgres para poder aceptar este parche. Fue aceptado. Y ahora la comprobación de índices en las réplicas también se ha vuelto lo suficientemente eficaz como para detectar las infracciones que encontramos. Es decir, estas son las violaciones que pueden ser causadas por errores en el firmware del disco, errores en Postgres, errores en el kernel de Linux y problemas de hardware. Una lista bastante extensa de fuentes de problemas para los que nos estábamos preparando.
Pero además de los índices, existe una parte llamada montón, es decir, el lugar donde se almacenan los datos. Y no hay muchas invariantes que puedan comprobarse.
Tenemos una extensión llamada Heapcheck. Empezamos a desarrollarlo. Y en paralelo, junto con nosotros, la empresa EnterpriseDB también comenzó a escribir un módulo, al que llamaron de la misma forma Heapcheck. Solo que lo llamamos PgHeapcheck y ellos simplemente lo llamaron Heapcheck. Lo tienen con funciones similares, una firma ligeramente diferente, pero con las mismas ideas. Los implementaron un poco mejor en algunos lugares. Y lo publicaron en código abierto antes.
Y ahora estamos desarrollando su expansión, porque ya no es su expansión, sino la expansión de la comunidad. Y en el futuro, esto es parte del núcleo que se proporcionará a todos para que puedan conocer de antemano los problemas futuros.
En algunos lugares incluso llegamos a la conclusión de que tenemos falsos positivos en nuestros sistemas de seguimiento. Por ejemplo, el sistema 1C. Cuando se utiliza una base de datos, Postgres a veces escribe datos que puede leer, pero pg_dump no puede leer.
Esta situación parecía corrupción para nuestro sistema de detección de problemas. Despertaron al oficial de guardia. El oficial de guardia observó lo que estaba sucediendo. Después de un tiempo, vino un cliente y dijo que tenía problemas. El asistente le explicó cuál era el problema. Pero el problema está en el núcleo de Postgres.
Encontré una discusión sobre esta característica. Y escribió que nos encontramos con esta característica y fue desagradable, una persona se despertaba por la noche para descubrir qué era.
La comunidad respondió: "Oh, realmente necesitamos arreglarlo".
Tengo una analogía simple. Si caminas con un zapato que tiene un grano de arena, en principio puedes seguir adelante, no hay problema. Si vendes botas a miles de personas, entonces haremos botas sin arena. Y si uno de los usuarios de sus zapatos va a correr un maratón, entonces querrá hacer muy buenos zapatos y luego escalarlos para todos sus usuarios. Y esos usuarios inesperados siempre se encuentran en el entorno de la nube. Siempre hay usuarios que explotan el cluster de alguna forma original. Siempre debes prepararte para esto.
¿Qué hemos aprendido aquí? Aprendimos una cosa sencilla: lo más importante es explicarle a la comunidad que hay un problema. Si la comunidad ha reconocido el problema, entonces surge la competencia natural para resolverlo. Porque todo el mundo quiere resolver un problema importante. Todos los vendedores, todos los hackers entienden que ellos mismos pueden pisar este rastrillo, por eso quieren eliminarlos.
Si está trabajando en un problema, pero no molesta a nadie más que a usted, pero trabaja en ello sistemáticamente y, en última instancia, se considera un problema, entonces su solicitud de extracción definitivamente será aceptada. Su parche será aceptado, sus mejoras o incluso sus solicitudes de mejora serán revisadas por la comunidad. Al final del día, mejoramos la base de datos entre nosotros.
Una base de datos interesante es Greenplum. Es una base de datos altamente paralela basada en el código base de Postgres, con el que estoy muy familiarizado.
Y Greenplum tiene una funcionalidad interesante: agregar tablas optimizadas. Estas son tablas a las que puede agregar rápidamente. Pueden ser de columnas o de filas.
Pero no había agrupación, es decir, no había ninguna funcionalidad que permitiera organizar los datos ubicados en la tabla de acuerdo con el orden en que se encuentran en uno de los índices.
Los chicos del taxi se acercaron a mí y me dijeron: “Andrey, conoces Postgres. Y aquí es casi lo mismo. Cambie a 20 minutos. Tómalo y hazlo”. Pensé que sí, conozco Postgres, cambié durante 20 minutos; necesito hacer esto.
Pero no, no fueron 20 minutos, lo escribí durante meses. En la conferencia PgConf.Russia, me acerqué a Heikki Linakangas de Pivotal y le pregunté: “¿Hay algún problema con esto? ¿Por qué no hay ninguna agrupación de tablas optimizada para agregar? Él dice: “Tú tomas los datos. Tú ordenas, tú reordenas. Es sólo un trabajo". Yo: "Oh, sí, sólo tienes que tomarlo y hacerlo". Él dice: "Sí, necesitamos manos libres para hacer esto". Pensé que definitivamente necesito hacer esto.
Y unos meses después envié una solicitud de extracción que implementaba esta funcionalidad. Pivotal revisó esta solicitud de extracción junto con la comunidad. Por supuesto, hubo errores.
Pero lo más interesante es que cuando se fusionó esta solicitud de extracción, se encontraron errores en el propio Greenplum. Hemos descubierto que las tablas de montón a veces rompen la transaccionalidad cuando se agrupan. Y esto es algo que hay que arreglar. Y ella está en el lugar que acabo de tocar. Y mi reacción natural fue: está bien, déjame hacer esto también.
Arreglé este error. Envió una solicitud de extracción a los reparadores. Él fue asesinado.
Después de lo cual resultó que esta funcionalidad debe obtenerse en la versión Greenplum para PostgreSQL 12. Es decir, la aventura de 20 minutos continúa con nuevas aventuras interesantes. Fue interesante tocar el desarrollo actual, donde la comunidad está incorporando características nuevas y más importantes. Esta congelado.
Pero no terminó ahí. Después de todo, resultó que necesitábamos escribir documentación para todo esto.
Empecé a escribir documentación. Por suerte, vinieron los documentalistas de Pivotal. El inglés es su lengua materna. Me ayudaron con la documentación. De hecho, ellos mismos reescribieron lo que propuse en inglés real.
Y aquí, al parecer, terminó la aventura. ¿Y sabes qué pasó entonces? Los chicos del taxi se acercaron a mí y me dijeron: "Aún quedan dos aventuras, cada una de 10 minutos". ¿Y qué debería decirles? Dije que ahora daré un informe a escala, luego veremos tus aventuras, porque este es un trabajo interesante.
¿Qué aprendimos de este caso? Porque trabajar con código abierto siempre es trabajar con una persona específica, siempre es trabajar con la comunidad. Porque en cada etapa trabajé con algún desarrollador, algún evaluador, algún hacker, algún documentalista, algún arquitecto. No trabajé con Greenplum, trabajé con gente de Greenplum.
¡Pero! Hay otro punto importante: es solo trabajo. Es decir, vienes, tomas café, escribes código. Funcionan todo tipo de invariantes simples. Hazlo normalmente, ¡todo irá bien! Y es un trabajo bastante interesante. Hay una solicitud para este trabajo por parte de los clientes de Yandex.Cloud, usuarios de nuestros clústeres tanto dentro como fuera de Yandex. Y creo que aumentará el número de proyectos en los que participamos y también aumentará la profundidad de nuestra implicación.
Eso es todo. Pasemos a las preguntas.
Sesión de preguntas
¡Hola! Tenemos otra sesión de preguntas y respuestas. Y en el estudio Andrei Borodin. Esta es la persona que acaba de hablarles sobre la contribución de Yandex.Cloud y Yandex al código abierto. Nuestro informe ahora no trata exclusivamente de la nube, pero al mismo tiempo nos basamos en dichas tecnologías. Sin lo que hiciste dentro de Yandex, no habría servicio en Yandex.Cloud, así que te lo agradezco personalmente. Y la primera pregunta de la transmisión: “¿En qué está escrito cada uno de los proyectos que mencionaste?”
El sistema de respaldo en WAL-G está escrito en Go. Este es uno de los proyectos más nuevos en los que hemos trabajado. Literalmente tiene sólo 3 años. Y una base de datos suele tener que ver con la confiabilidad. Y esto significa que las bases de datos son bastante antiguas y suelen estar escritas en C. El proyecto Postgres comenzó hace unos 30 años. Entonces el C89 fue la elección correcta. Y Postgres está escrito en él. Las bases de datos más modernas, como ClickHouse, suelen estar escritas en C++. Todo el desarrollo del sistema se basa en C y C++.
Una pregunta de nuestro gerente financiero, responsable de los gastos en Cloud: "¿Por qué Cloud gasta dinero en respaldar el código abierto?"
Aquí hay una respuesta sencilla para el director financiero. Hacemos esto para mejorar nuestros servicios. ¿De qué manera podemos hacerlo mejor? Podemos hacer las cosas de manera más eficiente, más rápida y hacerlas más escalables. Pero para nosotros, esta historia trata principalmente de confiabilidad. Por ejemplo, en un sistema de respaldo revisamos el 100% de los parches que le aplican. Sabemos cuál es el código. Y nos sentimos más cómodos lanzando nuevas versiones a producción. Es decir, en primer lugar, se trata de confianza, de preparación para el desarrollo y de confiabilidad.
Otra pregunta: "¿Son los requisitos de los usuarios externos que viven en Yandex.Cloud diferentes a los de los usuarios internos que viven en la nube interna?"
El perfil de carga, por supuesto, es diferente. Pero desde el punto de vista de mi departamento, todos los casos especiales e interesantes se crean con una carga no estándar. Es probable que se encuentren desarrolladores con imaginación, desarrolladores que hacen lo inesperado, tanto interna como externamente. En este sentido, todos somos aproximadamente iguales. Y, probablemente, la única característica importante dentro del funcionamiento de las bases de datos de Yandex será que dentro de Yandex tenemos una enseñanza. En algún momento, alguna zona de disponibilidad queda completamente en la sombra y, a pesar de esto, todos los servicios de Yandex deben continuar funcionando de alguna manera. Ésta es una pequeña diferencia. Pero genera mucho desarrollo de investigación en la interfaz de la base de datos y la pila de red. De lo contrario, las instalaciones externas e internas generan las mismas solicitudes de funciones y solicitudes similares para mejorar la confiabilidad y el rendimiento.
Siguiente pregunta: “¿Cómo se siente personalmente acerca del hecho de que gran parte de lo que hace es utilizado por otras Nubes?” No nombraremos algunos específicos, pero muchos proyectos que se realizaron en Yandex.Cloud se utilizan en las nubes de otras personas.
Esto es genial. Primero, es una señal de que hemos hecho algo bien. Y rasca el ego. Y tenemos más confianza en que tomamos la decisión correcta. Por otro lado, tenemos la esperanza de que en el futuro esto nos traiga nuevas ideas, nuevas solicitudes de terceros usuarios. La mayoría de los problemas en GitHub son creados por administradores de sistemas individuales, administradores de bases de datos individuales, arquitectos individuales, ingenieros individuales, pero a veces personas con experiencia sistemática vienen y dicen que en el 30% de ciertos casos tenemos este problema y pensemos en cómo resolverlo. Esto es lo que más esperamos. Esperamos compartir experiencias con otras plataformas en la nube.
Hablaste mucho sobre el maratón. Sé que corriste un maratón en Moscú. ¿Como resultado? ¿Superaste a los chicos de PostgreSQL?
No, Oleg Bartunov corre muy rápido. Terminó una hora antes que yo. En general, estoy contento con lo lejos que llegué. Para mí, simplemente terminar fue un logro. En general, es sorprendente que haya tantos corredores en la comunidad de Postgres. Me parece que existe algún tipo de relación entre los deportes aeróbicos y el deseo de programación de sistemas.
¿Estás diciendo que no hay corredores en ClickHouse?
Estoy seguro de que están ahí. ClickHouse también es una base de datos. Por cierto, Oleg me escribe ahora: "¿Salimos a correr después del informe?" Esta es una gran idea.
Otra pregunta de la transmisión de Nikita: "¿Por qué arreglaste el error en Greenplum tú mismo y no se lo diste a los jóvenes?" Es cierto que no está muy claro cuál es el error y en qué servicio, pero probablemente se refiere al que usted mencionó.
Sí, en principio se lo podrían haber regalado a alguien. Era solo el código que acabo de cambiar. Y era natural seguir haciéndolo de inmediato. En principio, la idea de compartir conocimientos con el equipo es una buena idea. Definitivamente compartiremos las tareas de Greenplum entre todos los miembros de nuestra división.
Ya que estamos hablando de jóvenes, aquí hay una pregunta. La persona decidió crear el primer compromiso en Postgres. ¿Qué necesita hacer para realizar el primer compromiso?
Ésta es una pregunta interesante: "¿Por dónde empezar?" Generalmente es bastante difícil comenzar con algo en el kernel. En Postgres, por ejemplo, hay una lista de tareas pendientes. Pero, en realidad, esta es una hoja de lo que intentaron hacer, pero no lo consiguieron. Estas son cosas complejas. Y normalmente puedes encontrar algunas utilidades en el ecosistema, algunas extensiones que se pueden mejorar, que atraen menos la atención de los desarrolladores del kernel. Y, en consecuencia, allí hay más puntos para crecer. En el programa Google Summer of code, cada año la comunidad de postgres presenta muchos temas diferentes que podrían abordarse. Este año tuvimos, creo, tres estudiantes. Uno incluso escribió en WAL-G sobre temas importantes para Yandex. En Greenplum, todo es más sencillo que en la comunidad de Postgres, porque los hackers de Greenplum tratan muy bien las solicitudes de extracción y comienzan a revisarlas de inmediato. Enviar un parche a Postgres es cuestión de meses, pero Greenplum llegará en un día y verá lo que ha hecho. Otra cosa es que Greenplum necesita resolver los problemas actuales. Greenplum no se usa mucho, por lo que encontrar su problema es bastante difícil. Y primero que nada, por supuesto, tenemos que resolver los problemas.
Fuente: habr.com