Dr. Martin Kleppmann es investigador en sistemas distribuidos en la Universidad de Cambridge y autor de la muy aclamada
"Diseño de aplicaciones intensivas en datos" (O'Reilly Media, 2017).
Kevin Scott, CTO de Microsoft
dijo una vez : “Este libro debería ser leído para ingenieros de software. "El diseño de aplicaciones intensivas en datos es un recurso raro que conecta la teoría y la práctica para ayudar a los desarrolladores a tomar decisiones inteligentes mientras diseñan e implementan infraestructura y sistemas de datos".
Los principales intereses de investigación de Martin incluyen software de colaboración, CRDT y verificación formal de algoritmos distribuidos. Anteriormente fue ingeniero de software y empresario en varias compañías de Internet, incluidas LinkedIn y Rapportive, donde trabajó en infraestructura de datos a gran escala.
Vadim Tsesko (
@incubos ) es un ingeniero de software líder en
Odnoklassniki que trabaja en el equipo de Core Platform. Los intereses científicos y de ingeniería de Vadim incluyen sistemas distribuidos, almacenes de datos y verificación de sistemas de software.
Contenidos:
- Pasar de la investigación empresarial a la académica;
- Discusión de "Diseño de aplicaciones intensivas en datos";
- Sentido común contra el bombo artificial y el marketing agresivo;
- Errores del teorema CAP y otros errores de la industria;
- Beneficios de la descentralización;
- Blockchains, Dat, IPFS, Filecoin, WebRTC;
- Nuevos CRDT. Verificación formal con Isabelle;
- Abastecimiento de eventos. Enfoque de bajo nivel. Transacciones XA
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Cómo aplicar todas esas herramientas a la vida real;
- Público objetivo esperado de las conversaciones de Martin y la conferencia Hydra.
Pasar de la investigación empresarial a la académica
Vadim : La primera pregunta que me gustaría hacerte es realmente importante para mí. Usted fundó Go Test It y Rapportive, y había estado diseñando e diseñando sistemas a gran escala en LinkedIn por un tiempo. Entonces decidiste cambiar de ingeniería industrial a academia. ¿Podría explicar la motivación de esa decisión? ¿Qué has ganado y qué has tenido que sacrificar?
Martin : Ha sido un proceso muy interesante. Como parece estar insinuando, no muchas personas hacen el cambio en esa dirección. Mucha gente va de la academia a la industria, pero no muchos regresan. Lo cual es comprensible, porque tuve que tomar un recorte salarial bastante grande para volver a la academia. Pero lo que realmente me gusta de la investigación es la libertad de trabajar en temas que me parecen interesantes y que creo que son importantes, incluso si esos temas no conducen inmediatamente a un producto comercialmente viable en los próximos 6 meses más o menos. Por supuesto, en una empresa, las cosas que construyes deben convertirse en un producto que se pueda vender de una forma u otra. Por otro lado, las cosas en las que ahora estoy trabajando son temas que son realmente importantes para el futuro de cómo construimos software y cómo funciona Internet. Pero realmente no entendemos estos temas lo suficientemente bien como para comenzar a construir productos comerciales: todavía estamos en el nivel de tratar de descubrir, fundamentalmente, cómo deben verse estas tecnologías. Y dado que esta es una investigación fundamental, me di cuenta de que es mejor hacerlo en una universidad que intentar hacerlo en una empresa, porque en una universidad soy libre de trabajar en cosas que podrían no ser comercialmente viables por otros diez años, y Eso está bien. Está bien trabajar con un horizonte de tiempo mucho más largo cuando estás investigando.
"Diseño de aplicaciones intensivas en datos"
Vadim : Definitivamente volveremos a sus intereses de investigación actuales. Mientras tanto, hablemos de su último libro
Diseño de aplicaciones intensivas en datos . Soy un gran admirador de su libro y creo que es una de las mejores guías para construir sistemas distribuidos modernos. Has cubierto casi todos los logros notables hasta la fecha.
Martin : Gracias, me alegra que lo encuentres útil.
Vadim : Solo para aquellos lectores desafortunados que aún no han leído su libro, ¿podrían nombrar varios logros importantes en el campo de los sistemas distribuidos en la actualidad?
Martin : Bueno, el objetivo del libro no es tanto explicar una tecnología en particular; el objetivo es más bien brindarle una guía del panorama completo de los diferentes sistemas que se utilizan para almacenar y procesar datos. Hay tantas bases de datos diferentes, procesadores de flujo, herramientas de procesamiento por lotes, todo tipo de herramientas de replicación, etc., y es realmente difícil obtener una visión general. Si está intentando crear una aplicación en particular, es realmente difícil saber qué base de datos debe usar y qué herramientas son las más adecuadas para el problema que está tratando de resolver. Muchos libros informáticos existentes simplemente no respondieron a ese problema de manera satisfactoria. Descubrí que si estás leyendo un libro sobre Cassandra, por ejemplo, te diría por qué Cassandra es maravillosa, pero en general no te diría sobre cosas para las que no encaja. Entonces, lo que realmente quería hacer en este libro era identificar las preguntas principales que debe hacerse si está tratando de construir algún tipo de sistema a gran escala. Y al responder esas preguntas, puede ayudar a determinar qué tecnologías son apropiadas y cuáles son menos apropiadas para el problema particular que está tratando de resolver, porque, en general, no hay una tecnología que sea perfecta para todo. Y así, el libro está tratando de ayudarlo a descubrir los pros y los contras de las diferentes tecnologías en diferentes entornos.
Sentido común contra el bombo artificial y el marketing agresivo
Vadim : De hecho, a menudo, si no siempre, hay muchas tecnologías con funciones, características y modelos de datos superpuestos. Y no puedes creer todas esas palabras de moda de marketing. Debe leer los libros blancos para aprender los aspectos internos, e incluso tratar de leer el código fuente para comprender cómo funciona exactamente.
Martin : Y descubrí que a menudo tienes que leer entre líneas porque a menudo la documentación realmente no te dice para qué cosas apesta una base de datos en particular. La verdad es que cada base de datos apesta en algún tipo de carga de trabajo, la pregunta es simplemente saber cuáles son. Entonces, sí, a veces tiene que leer las pautas de implementación para las personas de operaciones e intentar realizar ingeniería inversa a partir de lo que realmente está sucediendo en el sistema.
Vadim : ¿No cree que la industria carece del vocabulario común o de un conjunto de criterios para comparar diferentes soluciones para el mismo problema? Las cosas similares se llaman con diferentes nombres, se omiten algunas cosas que siempre deben ser claras y explícitas, como las garantías de transacción. Que piensas
Martin : Sí, creo que un problema que tiene nuestra industria es que, a menudo, cuando la gente habla de una herramienta en particular, hay mucha publicidad sobre todo. Lo cual es comprensible, porque las herramientas están hechas por varias compañías, y obviamente esas compañías quieren promocionar sus productos, por lo que esas compañías enviarán personas a conferencias para hablar sobre lo maravilloso que es su producto, esencialmente. Se disfrazará como una charla tecnológica, pero esencialmente sigue siendo una actividad de ventas. Como industria, realmente podríamos hacerlo con más honestidad sobre las ventajas y desventajas de algunos productos. Y parte de eso requiere una terminología común, porque de lo contrario simplemente no puede comparar las cosas en igualdad de condiciones. Pero más allá de una terminología compartida, necesitamos formas de razonar sobre cosas en las que ciertas tecnologías son buenas o malas.
Errores del teorema CAP y otros errores de la industria
Vadim : Mi siguiente pregunta es bastante controvertida. ¿Podría por favor mencionar algún error importante en la industria con la que se topó durante su carrera? ¿Quizás tecnologías sobrevaloradas o soluciones ampliamente practicadas de las que deberíamos habernos librado hace mucho tiempo? Puede ser un mal ejemplo, pero compare JSON sobre HTTP / 1.1 frente al gRPC mucho más eficiente sobre HTTP / 2. ¿O hay un punto de vista alternativo?
Martin : Creo que en muchos casos hay muy buenas razones por las cuales una tecnología hace una cosa y no otra. Así que dudo mucho en llamar a las cosas errores, porque en la mayoría de los casos es una cuestión de compensaciones. En su ejemplo de JSON sobre HTTP / 1.1 versus Protocol Buffers sobre HTTP / 2, creo que en realidad hay argumentos bastante razonables para ambas partes. Por ejemplo, si desea utilizar Protocol Buffers, debe definir su esquema, y un esquema puede ser algo maravilloso porque ayuda a documentar exactamente qué comunicación está ocurriendo. Pero algunas personas encuentran molestos los esquemas, especialmente si están en las primeras etapas de desarrollo y cambian los formatos de datos con mucha frecuencia. Así que ahí lo tienes, hay una cuestión de compensaciones; en algunas situaciones uno es mejor, en otros el otro es mejor.
En términos de errores reales que siento que son simplemente malos, solo hay un número bastante pequeño de cosas. Una opinión que tengo es que el teorema de CAP es fundamentalmente malo y simplemente no es útil. Cada vez que las personas usan el teorema CAP para justificar las decisiones de diseño, creo que a menudo están malinterpretando lo que realmente dice CAP o declarando lo obvio de alguna manera. CAP como teorema tiene el problema de que en realidad solo está diciendo lo obvio. Además, se refiere a un solo modelo de consistencia muy definido, a saber, la linealización, y un modelo de disponibilidad muy definido, que es: desea que cada réplica esté completamente disponible para lecturas y escrituras, incluso si no puede comunicarse con ninguna otra réplica. Estas son definiciones razonables, pero son muy limitadas, y muchas aplicaciones simplemente no caen en el caso de necesitar precisamente esa definición de consistencia o precisamente esa definición de disponibilidad. Y para todas las aplicaciones que usan una definición diferente de esas palabras, el teorema de CAP no le dice nada en absoluto. Es simplemente una declaración vacía. De modo que, siento, es un error.
Y mientras estamos despotricando, si me está pidiendo que nombre los errores, otro gran error que veo en la industria de la tecnología es la extracción de criptomonedas, que creo que es un desperdicio de electricidad tan atroz. No puedo entender por qué la gente piensa que es una buena idea.
Vadim : Hablando del teorema CAP, muchas tecnologías de almacenamiento son realmente ajustables, en términos de cosas como AP o CP. Puede elegir el modo en que operan.
Martin : si. Además, hay muchas tecnologías que no son consistentes ni están disponibles bajo la definición estricta del Teorema de la PAC. ¡Literalmente son solo P! No CP, no CA, no AP, solo P. Nadie dice eso, porque eso se vería mal, pero honestamente, esta podría ser una decisión de diseño perfectamente razonable. Hay muchos sistemas para los que eso está totalmente bien. Esta es en realidad una de las razones por las que creo que CAP es una forma tan inútil de hablar sobre las cosas: porque hay una gran parte del espacio de diseño que simplemente no captura, donde hay buenos diseños perfectamente razonables para el software que simplemente no te permite hablar.
Beneficios de la descentralización.
Vadim : Hablando de aplicaciones intensivas en datos hoy en día, ¿qué otros desafíos importantes, problemas no resueltos o temas de investigación candentes pueden nombrar? Hasta donde yo sé, eres un gran defensor de la computación y el almacenamiento descentralizados.
Martin : si. Una de las tesis detrás de mi investigación es que en este momento confiamos demasiado en los servidores y la centralización. Si piensa en cómo se diseñó Internet originalmente en el día en que evolucionó de ARPANET, se pensó que era una red muy resistente donde los paquetes podían enviarse a través de varias rutas diferentes, y aún llegarían al destino. Y si una bomba nuclear golpeara una ciudad estadounidense en particular, el resto de la red seguiría funcionando porque simplemente se encaminaría por las partes fallidas del sistema. Este fue un diseño de la Guerra Fría.
Y luego decidimos poner todo en la nube, y ahora básicamente todo tiene que pasar por uno de los centros de datos de AWS, como us-east-1 en algún lugar de Virginia. Hemos eliminado este ideal de poder usar descentralmente varias partes diferentes de la red, y hemos puesto en estos servidores en los que todo se basa, y ahora está extremadamente centralizado. Por lo tanto, estoy interesado en la descentralización, en el sentido de trasladar parte del poder y el control sobre los datos lejos de esos servidores y volver a los usuarios finales.
Una cosa que quiero agregar en este contexto es que muchas personas que hablan de descentralización están hablando de cosas como las criptomonedas, porque también están intentando una forma de descentralización mediante la cual el control se aleja de una autoridad central como un banco y se conecta a una red. de nodos cooperantes. Pero ese no es realmente el tipo de descentralización en la que estoy interesado: encuentro que estas criptomonedas en realidad aún están extremadamente centralizadas, en el sentido de que si desea realizar una transacción de Bitcoin, debe hacerlo en la red de Bitcoin: usted tiene que usar la red de Bitcoin, por lo que todo está centralizado en esa red en particular. La forma en que está construida está descentralizada en el sentido de que no tiene un solo nodo de control, pero la red en su conjunto está extremadamente centralizada, ya que cualquier transacción que tenga que hacer debe hacerlo a través de esta red. No puedes hacerlo de otra manera. Siento que todavía es una forma de centralización.
En el caso de una criptomoneda, esta centralización puede ser inevitable, porque debe hacer cosas como evitar el doble gasto, y hacerlo es difícil sin una red que logre un consenso sobre qué transacciones han sucedido exactamente y cuáles no. Y esto es exactamente lo que hace la red Bitcoin. Pero hay muchas aplicaciones que no requieren algo como una cadena de bloques, que en realidad puede hacer frente a un modelo de datos mucho más flexible que fluye por el sistema. Y ese es el tipo de sistema descentralizado que más me interesa.
Vadim : ¿Podría nombrar tecnologías prometedoras o infravaloradas en el campo de los sistemas descentralizados aparte de blockchain? He estado usando IPFS por un tiempo.
Martin : Para IPFS, lo he investigado un poco, aunque en realidad no lo he usado yo mismo. Hemos trabajado un poco con el proyecto
Dat , que es algo similar a
IPFS en el sentido de que también es una tecnología de almacenamiento descentralizada. La diferencia es que IPFS tiene
Filecoin , una criptomoneda, unida a ella como una forma de pagar los recursos de almacenamiento, mientras que Dat no tiene ninguna cadena de bloques adjunta, es simplemente una forma de replicar datos en múltiples máquinas de una manera P2P.
Para el proyecto en el que he estado trabajando, Dat ha encajado bastante bien, porque queríamos crear un software de colaboración en el que varios usuarios diferentes pudieran editar algún documento o base de datos, y cualquier cambio en esos datos se enviaría a cualquiera más que necesita tener una copia de estos datos. Podemos usar Dat para hacer esta replicación de una manera P2P, y Dat se encarga de todas las cosas a nivel de red, como el recorrido de NAT y atravesar firewalls; es un problema bastante complicado simplemente llevar los paquetes de un extremo al otro . Y luego creamos una capa además de eso, usando CRDT, que es una forma de permitir que varias personas editen algún documento o conjunto de datos e intercambien esas ediciones de una manera eficiente. Creo que probablemente también pueda construir este tipo de cosas en IPFS: probablemente pueda ignorar el aspecto Filecoin y simplemente usar el aspecto de replicación P2P, y probablemente hará el trabajo igual de bien.
Vadim : Claro, aunque el uso de IPFS podría conducir a una menor capacidad de respuesta, porque el Dat subyacente de WebRTC conecta los nodos P2P directamente, e IPFS funciona como una cosa de tabla hash distribuida.
Martin : Bueno, WebRTC está en un nivel diferente de la pila, ya que está destinado principalmente a conectar a dos personas que podrían estar teniendo una videollamada; de hecho, el software que estamos usando para esta entrevista en este momento puede estar usando WebRTC. Y WebRTC le brinda un canal de datos que puede usar para enviar datos binarios arbitrarios sobre él, pero construir un sistema de replicación completo además de eso todavía es bastante trabajo. Y eso es algo que Dat o IPFS ya hacen.
Usted mencionó la capacidad de respuesta, eso es ciertamente una cosa en la que pensar. Supongamos que desea crear los próximos Google Docs de forma descentralizada. Con Google Docs, la unidad de cambios que realiza es una sola pulsación de tecla. Cada letra que escriba en su teclado puede enviarse en tiempo real a sus colaboradores, lo cual es excelente desde el punto de vista de una colaboración rápida en tiempo real. Pero también significa que en el transcurso de la redacción de un documento grande, es posible que se acumulen cientos de miles de estas ediciones de un solo carácter, y muchas de estas tecnologías en este momento no son muy buenas para comprimir este tipo de datos de edición. Puede conservar todas las ediciones que haya realizado en su documento, pero incluso si envía solo cien bytes por cada pulsación de tecla que hace y escribe un documento un poco más grande con, digamos, 100,000 pulsaciones de teclas, de repente ahora tener 10 MB de datos para un documento que normalmente solo serían unas pocas decenas de kilobytes. Por lo tanto, tenemos esta enorme sobrecarga para la cantidad de datos que deben enviarse, a menos que seamos más inteligentes al comprimir y empaquetar los cambios.
En lugar de enviar a alguien la lista completa de todos los caracteres que se han escrito alguna vez, podríamos enviar el estado actual del documento y luego enviar las actualizaciones que hayan sucedido desde entonces. Pero muchos de estos sistemas peer-to-peer todavía no tienen una manera de hacer esas instantáneas de estado de una manera que sea lo suficientemente eficiente como para usarlas para algo como Google Docs. Esta es en realidad un área en la que estoy trabajando activamente, tratando de encontrar mejores algoritmos para sincronizar diferentes usuarios para algo como un documento de texto, donde no queremos mantener cada pulsación de tecla porque sería demasiado costoso, y queremos para hacer un uso más eficiente del ancho de banda de la red.
Nuevos CRDT. Verificación formal con isabelle
Vadim : ¿Has logrado comprimir esos datos de pulsación de tecla sustancialmente? ¿Has inventado nuevos CRDT o algo similar?
Martin : si. Hasta ahora solo tenemos prototipos para esto, aún no está completamente implementado, y todavía tenemos que hacer algunos experimentos más para medir qué tan eficiente es en la práctica. Pero hemos desarrollado algunos esquemas de compresión que parecen muy prometedores. En mi prototipo lo reduje de aproximadamente 100 bytes por edición a algo así como 1.7 bytes de sobrecarga por edición. Y eso es mucho más razonable, por supuesto. Pero como digo, estos experimentos aún están en curso, y el número aún podría cambiar ligeramente. Pero creo que la conclusión es que todavía hay mucho espacio para la optimización, por lo que aún podemos mejorarlo mucho.
Vadim : Entonces de esto se tratará tu charla en la
conferencia de Hydra , ¿estoy en lo cierto?
Martin : Sí, exactamente Daré una introducción rápida al área de CRDT, software colaborativo y algunos de los problemas que surgen en ese contexto. Luego describiré algunas de las investigaciones que hemos estado haciendo en esta área. Ha sido bastante divertido porque la investigación que hemos estado haciendo ha abarcado una amplia gama de preocupaciones diferentes. En el lado muy aplicado, tenemos una implementación de JavaScript de estos algoritmos, y la estamos usando para construir piezas reales de software, tratando de usar ese software nosotros mismos para ver cómo se comporta. En el otro extremo del espectro, hemos estado trabajando con métodos formales para probar que estos algoritmos son correctos, porque algunos de estos algoritmos son bastante sutiles y queremos estar muy seguros de que los sistemas que estamos fabricando son realmente correctos, es decir, que siempre alcanzan un estado consistente. Ha habido muchos algoritmos en el pasado que realmente no han podido hacer eso, que simplemente estaban equivocados, es decir, en ciertos casos extremos, permanecerían permanentemente inconsistentes. Entonces, para evitar estos problemas que los algoritmos han tenido en el pasado, hemos estado utilizando métodos formales para probar que nuestros algoritmos son correctos.
Vadim : Wow. ¿Realmente utilizas demostradores de teoremas, como Coq o Isabelle o cualquier otra cosa?
Martin : Exactamente, hemos estado usando a Isabelle para eso.
Puede asistir a la charla de Martin "Pruebas de corrección de sistemas distribuidos con Isabelle" en la conferencia de The Strange Loop en septiembre.
Vadim : ¡Suena genial! ¿Se publicarán esas pruebas?
Martin : Sí, nuestro primer conjunto de pruebas ya es público. Lo publicamos hace un año y medio: era un marco para verificar los CRDT, y verificamos tres CRDT particulares dentro de ese marco, el principal de los cuales era RGA (
Replicated Growable Array ), que es un CRDT para la edición de texto en colaboración. Si bien no es muy complicado, es un algoritmo bastante sutil, por lo que es un buen caso en el que se necesitan pruebas, porque no es obvio solo al mirarlo que realmente es correcto. Y así, la prueba nos da la certeza adicional de que realmente es correcta. Nuestro trabajo anterior fue verificar un par de CRDT existentes, y nuestro trabajo más reciente en esta área es sobre nuestros propios CRDT para los nuevos modelos de datos que hemos estado desarrollando, y también para probar que nuestros CRDT son correctos.
Vadim : ¿Cuánto más grande es la prueba en comparación con la descripción del algoritmo? Porque a veces puede ser un problema.
Martin : Sí, eso es un problema, las pruebas son a menudo mucho trabajo. Creo que en nuestro último ejemplo ... En realidad, déjame echar un vistazo rápido al código. La descripción del algoritmo y las estructuras de datos es de aproximadamente 60 líneas de código. Entonces es un algoritmo bastante pequeño. La prueba es más de 800 líneas. Así que tenemos aproximadamente una proporción de 12: 1 entre la prueba y el código. Y eso es desafortunadamente bastante típico. La prueba es una gran cantidad de trabajo adicional. Por otro lado, una vez que tenemos la prueba, hemos ganado una certeza muy fuerte en la corrección del algoritmo. Además, nosotros mismos, como humanos, entendemos el algoritmo mucho mejor. A menudo encuentro que al tratar de formalizarlo, terminamos entendiendo lo que estamos tratando de formalizar mucho mejor que antes. Y eso en sí mismo es en realidad un resultado útil de este trabajo: además de la prueba en sí, obtenemos una comprensión más profunda, y eso a menudo es muy útil para crear mejores implementaciones.
Vadim : ¿Podría por favor describir el público objetivo de su charla, qué tan duro va a ser? ¿Cuál es el conocimiento preliminar que espera que tenga la audiencia?
Martin : Me gusta que mis charlas sean accesibles con el menor requisito de conocimiento previo posible, y trato de elevar a todos al mismo nivel. Cubro mucho material, pero empiezo con una base baja. Esperaría que las personas tengan experiencia general en sistemas distribuidos: ¿cómo se envían algunos datos a través de una red utilizando TCP, o tal vez una idea aproximada de cómo funciona Git, que es un buen modelo para estas cosas? Pero eso es todo lo que necesitas, de verdad. Entonces, comprender el trabajo que hemos estado haciendo además de eso en realidad no es demasiado difícil. Explico todo con ejemplos, usando imágenes para ilustrar todo. Con suerte, todos podrán seguirlo.
Abastecimiento de eventos. Enfoque de bajo nivel. Transacciones XA
Vadim : Suena muy bien. En realidad, tenemos algo de tiempo y me gustaría hablar sobre uno de sus
artículos recientes sobre el procesamiento de eventos en línea. Eres un gran defensor de la idea del abastecimiento de eventos, ¿es correcto?
Martin : Sí, claro.
Vadim : Hoy en día, este enfoque está cobrando impulso, y en la búsqueda de todas las ventajas del registro de operaciones ordenado globalmente, muchos ingenieros intentan implementarlo en todas partes. ¿Podría describir algunos casos en los que el abastecimiento de eventos no es la mejor opción? Solo para evitar su mal uso y posible decepción con el enfoque en sí.
Martin : Hay dos capas diferentes de la pila de las que debemos hablar primero. El abastecimiento de eventos, según lo propuesto por Greg Young y algunos otros, pretende ser un mecanismo para el modelado de datos, es decir: si tiene un esquema de base de datos y está comenzando a perder el control porque hay muchas tablas diferentes y ' Todos están siendo modificados por diferentes transacciones, entonces el abastecimiento de eventos es una forma de aportar una mayor claridad a este modelo de datos, porque los eventos pueden expresar muy directamente lo que está sucediendo a nivel comercial. ¿Cuál es la acción que tomó el usuario? Y luego, las consecuencias de esa acción podrían estar actualizando varias tablas, etc. Efectivamente, lo que está haciendo con el abastecimiento de eventos es separar la acción (el evento) de sus efectos, que suceden en algún punto posterior.
He llegado a esta área desde un ángulo ligeramente diferente, que es un punto de vista de nivel inferior del uso de sistemas como Kafka para construir sistemas altamente escalables. Esta vista es similar en el sentido de que si está usando algo como Kafka está usando eventos, pero no significa que necesariamente esté usando el abastecimiento de eventos. Y, a la inversa, no es necesario que estés usando Kafka para realizar el abastecimiento de eventos; puede realizar el abastecimiento de eventos en una base de datos normal o puede usar una base de datos especial diseñada específicamente para el abastecimiento de eventos. Entonces, estas dos ideas son similares, pero ninguna requiere la otra, solo tienen cierta superposición.
El argumento para querer usar un sistema como Kafka es principalmente el argumento de escalabilidad: en ese caso, simplemente tiene tantos datos entrantes que no puede procesarlos de manera realista en una base de datos de un solo nodo, por lo que debe particionarlos en algunos y el uso de un registro de eventos como Kafka le brinda una buena forma de difundir ese trabajo en varias máquinas. Proporciona una buena forma de principios para escalar sistemas. Es especialmente útil si desea integrar varios sistemas de almacenamiento diferentes. Entonces, si, por ejemplo, desea actualizar no solo su base de datos relacional sino también, por ejemplo, un índice de búsqueda de texto completo como Elasticsearch, o un sistema de almacenamiento en caché como Memcached o Redis o algo así, y desea que un evento tenga un efecto de actualización en todos estos sistemas diferentes, entonces algo como Kafka es muy útil.
En términos de la pregunta que hizo (¿cuáles son las situaciones en las que no usaría esta fuente de eventos o enfoque de registro de eventos?), Creo que es difícil de decir con precisión, pero como regla general diría: use lo que sea más simple . Es decir, lo que sea más cercano al dominio que está intentando implementar. Por lo tanto, si lo que está tratando de implementar mapas se adapta muy bien a una base de datos relacional, en la que simplemente inserta, actualiza y elimina algunas filas, simplemente use una base de datos relacional e inserte, actualice y elimine algunas filas. No hay nada de malo en las bases de datos relacionales y en usarlas tal como están. Han funcionado bien para nosotros durante bastante tiempo y continúan haciéndolo. Pero si se encuentra en una situación en la que realmente está luchando por usar ese tipo de base de datos, por ejemplo, porque la complejidad del modelo de datos se está yendo de las manos, entonces tiene sentido cambiar a algo como un abastecimiento de eventos enfoque
Y de manera similar, en el nivel inferior (escalabilidad), si el tamaño de sus datos es tal que puede ponerlo en PostgreSQL en una sola máquina, probablemente esté bien, solo use PostgreSQL en una sola máquina. Pero si está en el punto donde no hay forma de que una sola máquina pueda manejar su carga, debe escalar a través de un sistema grande, entonces comienza a tener sentido buscar sistemas más distribuidos como Kafka. Creo que el principio general aquí es: use lo que sea más simple para la tarea particular que está tratando de resolver.
Vadim : Es realmente un buen consejo. A medida que su sistema evoluciona, no puede predecir con precisión la dirección del desarrollo, todas las consultas, patrones y flujos de datos.
Martin : Exactamente, y para ese tipo de situaciones, las bases de datos relacionales son increíbles, porque son muy flexibles, especialmente si incluye el soporte JSON que tienen ahora. PostgreSQL ahora tiene bastante buen soporte para JSON. Simplemente puede agregar un nuevo índice si desea realizar una consulta de una manera diferente. Simplemente puede cambiar el esquema y seguir ejecutándose con los datos en una estructura diferente. Por lo tanto, si el tamaño del conjunto de datos no es demasiado grande y la complejidad no es demasiado grande, las bases de datos relacionales funcionan bien y proporcionan una gran flexibilidad.
Vadim : Hablemos un poco más sobre el abastecimiento de eventos. Usted mencionó un ejemplo interesante con varios consumidores que consumieron eventos de una cola basada en Kafka o algo similar. Imagine que se publican nuevos documentos y varios sistemas están consumiendo eventos: un sistema de búsqueda basado en Elasticsearch, que permite buscar los documentos, un sistema de almacenamiento en caché que los coloca en la memoria caché de valor clave basado en Memcached, y un sistema de base de datos relacional que actualiza algunos tablas en consecuencia. Un documento puede ser una oferta de venta de automóviles o un anuncio de bienes raíces. Todos estos sistemas consumidores funcionan de forma simultánea y simultánea.
Martin : Entonces, su pregunta es ¿cómo lidiar con el hecho de que si tiene estos varios consumidores, algunos de ellos podrían haber sido actualizados, pero los otros aún no han visto una actualización y todavía están rezagados?
Vadim : Sí, exactamente. Un usuario llega a su sitio web, ingresa una consulta de búsqueda, obtiene algunos resultados de búsqueda y hace clic en un enlace. Pero obtiene el código de estado HTTP 404 porque no existe tal entidad en la base de datos, que aún no ha podido consumir y persistir el documento.
Martin : Sí, esto es un desafío en realidad. Idealmente, lo que quiere es lo que llamaríamos "consistencia causal" en estos diferentes sistemas de almacenamiento. Si un sistema contiene algunos datos de los que depende, los otros sistemas que observe también contendrán esas dependencias. Desafortunadamente, reunir ese tipo de coherencia causal en diferentes tecnologías de almacenamiento es realmente muy difícil, y esto no es realmente la culpa del origen del evento, porque no importa qué enfoque o qué sistema use para enviar las actualizaciones a los diferentes sistemas, usted siempre puede terminar con algún tipo de problemas de concurrencia.
En su ejemplo de escritura de datos en Memcached y Elasticsearch, incluso si intenta hacer las escrituras en los dos sistemas simultáneamente, es posible que tenga un poco de retraso en la red, lo que significa que llegan en momentos ligeramente diferentes en esos sistemas diferentes, y procesarse con un tiempo ligeramente diferente. Entonces, alguien que está leyendo en esos dos sistemas puede ver un estado inconsistente. Ahora, hay algunos proyectos de investigación que al menos están trabajando para lograr ese tipo de coherencia causal, pero aún así es difícil si solo quieres usar algo como Elasticsearch o Memcached o algo así.
Una buena solución aquí sería que te presentaran, conceptualmente, con una instantánea consistente de un punto en el tiempo tanto en el índice de búsqueda como en el caché y la base de datos. Si está trabajando solo dentro de una base de datos relacional, obtiene algo llamado aislamiento de instantáneas, y el punto del aislamiento de instantáneas es que si está leyendo desde la base de datos, parece que tiene su propia copia privada de toda la base de datos Cualquier cosa que mire en la base de datos, cualquier dato que consulte será el estado a partir de ese momento, de acuerdo con la instantánea. Entonces, incluso si los datos han sido modificados luego por otra transacción, en realidad verá los datos más antiguos, porque esos datos más antiguos forman parte de una instantánea consistente.
Y ahora, en el caso de que tenga Elasticsearch y Memcached, lo que idealmente querría es una instantánea consistente en estos dos sistemas. Pero desafortunadamente, ni Memcached ni Redis ni Elasticsearch tienen un mecanismo eficiente para hacer ese tipo de instantáneas que puedan coordinarse con diferentes sistemas de almacenamiento. Cada sistema de almacenamiento solo piensa por sí mismo y generalmente le presenta el último valor de cada clave, y no tiene esta facilidad para mirar hacia atrás y presentar una versión un poco más antigua de los datos, porque la versión más reciente de los datos aún no consistente
Realmente no tengo una buena respuesta sobre cómo sería la solución. Me temo que la solución requeriría cambios de código en cualquiera de los sistemas de almacenamiento que participan en este tipo de cosas. Por lo tanto, requerirá cambios en Elasticsearch, Redis, Memcached y cualquier otro sistema. Y tendrían que agregar algún tipo de mecanismo para las instantáneas de un punto en el tiempo que sea lo suficientemente barato como para que pueda usarlo todo el tiempo, porque es posible que desee la instantánea varias veces por segundo; no es solo una vez instantánea de un día, es muy fino. Y por el momento, los sistemas subyacentes no están allí en términos de poder hacer este tipo de instantáneas en diferentes sistemas de almacenamiento. Es un tema de investigación realmente interesante. Espero que alguien trabaje en ello, pero hasta ahora no he visto ninguna respuesta realmente convincente a ese problema.
Vadim : Sí, necesitamos algún tipo de
Control de concurrencia multiversion compartida.
Martin : Exactamente, como los sistemas de transacciones distribuidas. Las transacciones distribuidas de XA lo llevarán a algún lado, pero desafortunadamente, XA, tal como está, en realidad no es muy adecuado porque solo funciona si está utilizando un control de concurrencia basado en bloqueo. Esto significa que si lee algunos datos, debe bloquearlos para que nadie pueda modificarlos mientras tenga ese bloqueo. Y ese tipo de control de concurrencia basado en el bloqueo tiene un rendimiento terrible, por lo que ningún sistema realmente lo usa en la práctica hoy en día. Pero si no tiene ese bloqueo, no obtendrá el comportamiento de aislamiento necesario en un sistema como las transacciones distribuidas XA. Entonces, quizás lo que necesitamos es un nuevo protocolo para transacciones distribuidas que permita el aislamiento de instantáneas como mecanismo de aislamiento en diferentes sistemas. Pero no creo haber visto nada que lo implemente todavía.
Vadim : Sí, espero que alguien esté trabajando en eso.
Martin : Sí, sería realmente importante. También en el contexto de los microservicios, por ejemplo: la forma en que las personas promueven que usted debe crear microservicios es que cada microservicio tiene su propio almacenamiento, su propia base de datos y no tiene un servicio que acceda directamente a la base de datos de otro servicio, porque eso rompería la encapsulación del servicio. Por lo tanto, cada servicio solo administra sus propios datos.
Por ejemplo, tiene un servicio para administrar usuarios, y tiene una base de datos para los usuarios, y todos los que quieran averiguar algo sobre los usuarios deben pasar por el servicio de usuario. Desde el punto de vista de la encapsulación, eso es bueno: está ocultando detalles del esquema de la base de datos de los otros servicios, por ejemplo.
But from the point of view of consistency across different services — well, you've got a huge problem now, because of exactly the thing we were discussing: we might have data in two different services that depends upon each other in some way, and you could easily end up with one service being slightly ahead of or slightly behind the other in terms of timing, and then you could end up with someone who reads across different services, getting inconsistent results. And I don't think anybody building microservices currently has an answer to that problem.
Vadim : It is somewhat similar to workflows in our society and government, which are inherently asynchronous and there are no guarantees of delivery. You can get your passport number, then you can change it, and you need to prove that you changed it, and that you are the same person.
Martin : Yes, absolutely. As humans we have ways of dealing with this, for example, we might know that oh, sometimes that database is a bit outdated, I'll just check back tomorrow. And then tomorrow it's fine. But if it's software that we're building, we have to program all that kind of handling into the software. The software can't think for itself.
Vadim : Definitely, at least not yet. I have another question about the advantages of event sourcing. Event sourcing gives you the ability to stop processing events in case of a bug, and resume consuming events having deployed the fix, so that the system is always consistent. It's a really strong and useful property, but it might not be acceptable in some cases like banking where you can imagine a system that continues to accept financial transactions, but the balances are stale due to suspended consumers waiting for a bugfix from developers. What might be a workaround in such cases?
Martin : I think it's a bit unlikely to stop the consumer, deploying the fix and then restart it, because, as you say, the system has got to continue running, you can't just stop it. I think what is more likely to happen is: if you discover a bug, you let the system continue running, but while it continues running with the buggy code, you produce another version of the code that is fixed, you deploy that fixed version separately and run the two in parallel for a while. In the fixed version of the code you might go back in history and reprocess all of the input events that have happened since the buggy code was deployed, and maybe write the results to a different database. Once you've caught up again you've got two versions of the database, which are both based on the same event inputs, but one of the two processed events with the buggy code and the other processed the events with the correct code. At that point you can do the switchover, and now everyone who reads the data is going to read the correct version instead of the buggy version, and you can shut down the buggy version. That way you never need to stop the system from running, everything keeps working all the time. And you can take the time to fix the bug, and you can recover from the bug because you can reprocess those input events again.
Vadim : Indeed, it's a really good option if the storage systems are under your control, and we are not talking about side effects applied to external systems.
Martin : Yes, you're right, once we send the data to external systems it gets more difficult because you might not be able to easily correct it. But this is again something you find in financial accounting, for example. In a company, you might have quarterly accounts. At the end of the quarter, everything gets frozen, and all of the revenue and profit calculations are based on the numbers for that quarter. But then it can happen that actually, some delayed transaction came in, because somebody forgot to file a receipt in time. The transaction comes in after the calculations for the quarter have been finalized, but it still belongs in that earlier quarter.
What accountants do in this case is that in the next quarter, they produce corrections to the previous quarter's accounts. And typically those corrections will be a small number, and that's no problem because it doesn't change the big picture. But at the same time, everything is still accounted for correctly. At the human level of these accounting systems that has been the case ever since accounting systems were invented, centuries ago. It's always been the case that some late transactions would come in and change the result for some number that you thought was final, but actually, it wasn't because the correction could still come in. And so we just build the system with the mechanism to perform such corrections. I think we can learn from accounting systems and apply similar ideas to many other types of data storage systems, and just accept the fact that sometimes they are mostly correct but not 100% correct and the correction might come in later.
Vadim : It's a different point of view to building systems.
Martin : It is a bit of a new way of thinking, yes. It can be disorienting when you come across it at first. But I don't think there's really a way round it, because this impreciseness is inherent in the fact that we do not know the entire state of the world — it is fundamental to the way distributed systems work. We can't just hide it, we can't pretend that it doesn't happen, because that imprecision is necessarily exposed in the way we process the data.
Professional growth and development
Vadim : Do you think that conferences like
Hydra are anticipated? Most distributed systems are quite different, and it is hard to imagine that many attendees will get to work and will start applying what they have learned in day-to-day activities.
Martin : It is broad, but I think that a lot of the interesting ideas in distributed systems are conceptual. So the insights are not necessarily like «use this database» or «use this particular technology». They are more like ways of thinking about systems and about software. And those kinds of ideas can be applied quite widely. My hope is that when attendees go away from this conference, the lessons they take away are not so much what piece of software they should be using or which programming language they should be using – really, I don't mind about that – but more like how to
think about the systems they are building.
Vadim : Why do you think it's important to give conference talks on such complex topics as your talk, compared to publishing papers, covering all their details and intricacies? Or should anyone do both?
Martin : I think they serve different purposes. When we write papers, the purpose is to have a very definitive, very precise analysis of a particular problem, and to go really deep in that. On the other hand, the purpose of a talk is more to get people interested in a topic and to start a conversation around it. I love going to conferences partly because of the discussions I then have around the talk, where people come to me and say: «oh, we tried something like this, but we ran into this problem and that problem, what do you think about that?» Then I get to think about other people's problems, and that's really interesting because I get to learn a lot from that.
So, from my point of view, the selfish reason for going to conferences is really to learn from other people, what their experiences have been, and to help share the experiences that we've made in the hope that other people will find them useful as well. But fundamentally, a conference talk is often an introduction to a subject, whereas a paper is a deep analysis of a very narrow question. I think those are different genres and I think we need both of them.
Vadim : And the last question. How do you personally grow as a professional engineer and a researcher? Could you please recommend any conferences, blogs, books, communities for those who wish to develop themselves in the field of distributed systems?
Martin : That's a good question. Certainly, there are things to listen to and to read. There's no shortage of conference talks that have been recorded and put online. There are books like my own book for example, which provides a bit of an introduction to the topic, but also lots of references to further reading. So if there are any particular detailed questions that you're interested in, you can follow those references and find the original papers where these ideas were discussed. They can be a very valuable way of learning about something in greater depth.
A really important part is also trying to implement things and seeing how they work out in practice, and talking to other people and sharing your experiences. Part of the value of a conference is that you get to talk to other people as well, live. But you can have that through other mechanisms as well; for example, there's a Slack channel that people have set up for people
interested in distributed systems . If that's your thing you can join that. You can, of course, talk to your colleagues in your company and try to learn from them. I don't think there's one right way of doing this — there are many different ways through which you can learn and get a deeper experience, and different paths will work for different people.
Vadim : Thank you very much for your advice and interesting discussion! It has been a pleasure talking to you.
Martin : No problem, yeah, it's been nice talking to you.
Vadim : Let's meet
at the conference .