Martin Kleppman es investigador de la Universidad de Cambridge y trabaja en CRDT y verificación formal de algoritmos. Su libro
Designing Data-Intensive Applications , publicado en 2017, se ha convertido en un éxito de ventas en almacenamiento y procesamiento de datos.
Kevin Scott (CTO de Microsoft)
dijo una vez: “Este libro debería ser imprescindible para los ingenieros de desarrollo. Este es un recurso raro que combina teoría y práctica, ayudando a los desarrolladores a pensar más profundamente sobre el diseño e implementación de infraestructura y sistemas de procesamiento de datos ". Jay Kreps, el creador de Apache Kafka y CEO Confluent, dijo algo similar.
Antes de comenzar la investigación académica, Martin trabajó en la industria y cofundó dos startups exitosas: Rapportive (comprada por LinkedIn en 2012) y Go Test It (comprada por RedGate).
Este habrapost es una entrevista detallada con Martin. Ejemplos de temas de discusión:
- Transición de la investigación empresarial a la académica;
- Requisitos previos para la escritura de diseño de aplicaciones intensivas en datos;
- Sentido común contra el bombo artificial y las herramientas publicitarias;
- Innecesidad del teorema CAP y otros errores de la industria;
- La utilidad de la descentralización;
- Blockchains, Dat, IPFS, Filecoin, WebRTC;
- Nuevo CRDT. Verificación formal en Isabelle;
- Discusión sobre el abastecimiento de eventos. Enfoque de bajo nivel. Transacciones XA
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Usándolo todo en la vida real;
- El umbral para ingresar a los informes de Martin y la conferencia de Hydra.
La entrevista fue realizada por
Vadim Tsesko (
@incubos ), un desarrollador líder en el equipo de la compañía Odnoklassniki Platform. Los intereses científicos y de ingeniería de Vadim se relacionan con sistemas distribuidos y almacenes de datos, así como con la verificación de sistemas de software.
De la empresa a la investigación académica
Vadim : Me gustaría comenzar con una pregunta que es muy importante para mí personalmente. Usted fundó Go Test It y Rapportive, y durante mucho tiempo participó en el desarrollo de grandes sistemas en LinkedIn, pero luego decidió abandonar el desarrollo comercial e investigar en la universidad. ¿Podrías decirme qué te empujó a esto? ¿Cuáles son los beneficios de trabajar en una universidad y qué has sacrificado?
Martin : Fue una transición muy interesante. Según tengo entendido, está interesado en mi decisión debido al hecho de que muchas personas se están yendo a la investigación académica del desarrollo comercial, con mucha más frecuencia hay un movimiento en la dirección opuesta. Esto es comprensible, ya que las ganancias en las universidades son significativamente más bajas que en los negocios. Personalmente, me atrae el puesto de investigador por el hecho de que puedo decidir por mí mismo en qué temas trabajar, y hago esta elección en función de lo que me parece interesante e importante, incluso si trabajar en un tema no promete obtener ganancias durante los próximos 6 meses Todo lo que trabajas para una empresa debe venderse de una forma u otra. En este momento, estoy trabajando en temas que son importantes para el futuro de Internet y el software, pero nuestra comprensión de ellos aún no es lo suficientemente profunda como para crear un producto terminado. Hasta ahora, ni siquiera tenemos una idea general de cómo deberían funcionar estas tecnologías. Dado que estos estudios son fundamentales, decidí que es mejor llevarlos a cabo en la universidad y no en la empresa: la universidad tiene más libertad, allí puede hacer cosas que no generarán ganancias durante otros 10 años. El horizonte de planificación es mucho más amplio.
Libro que diseña aplicaciones intensivas en datos
Vadim : Definitivamente volveremos al tema de la investigación, pero por ahora hablemos de su libro,
Diseño de aplicaciones intensivas en datos . En mi opinión, esta es una de las mejores guías sobre sistemas distribuidos modernos, casi una enciclopedia: enumera todos los logros más importantes que existen hoy en día.
Martin : Gracias, me alegra que haya sido útil.
Vadim : Es poco probable que nuestros lectores aún no estén familiarizados con él, pero por si acaso, analicemos los logros más significativos en el campo de los sistemas distribuidos sobre los que está escribiendo.
Martin : En realidad, al escribir este libro, no establecí una meta para describir ciertas tecnologías. Más bien, quería hacer una guía sobre el mundo de los sistemas utilizados para almacenar y procesar datos. Ahora hay una gran cantidad de bases de datos, procesadores de flujo, herramientas de procesamiento por lotes, todo tipo de herramientas de replicación y similares, por lo que es muy difícil componer una imagen general de esta área. Y si necesita una base de datos para resolver un problema específico, es difícil elegir uno de los muchos existentes. Muchos libros escritos sobre tales sistemas son simplemente inútiles en este caso. Por ejemplo, en un libro sobre Apache Cassandra se puede escribir sobre lo maravillosa que es Cassandra, pero nada se dirá sobre tareas para las que no es adecuado. Por lo tanto, en mi libro, trato de identificar las preguntas básicas que debes hacerte al escribir sistemas grandes. Las respuestas a estas preguntas ayudarán a determinar qué tecnologías son adecuadas para resolver el problema actual y cuáles no son muy buenas. Lo principal es que no hay tecnología que pueda hacer todo. Estoy tratando de mostrar cuáles son las ventajas y desventajas de diferentes tecnologías en diferentes contextos.
Vadim : De hecho, muchas tecnologías tienen características y funcionalidades comunes y proporcionan el mismo modelo de datos. Al mismo tiempo, no se puede confiar en la publicidad, y para comprender la estructura interna del sistema hay que leer no solo informes técnicos y documentación, sino incluso códigos fuente.
Sentido común versus publicidad artificial y publicidad de herramientas
Martin : Además, a menudo hay que leer entre líneas, porque la documentación no dice para qué tareas la base de datos no es muy adecuada. De hecho, cualquier base de datos tiene sus propias limitaciones, por lo que siempre debe saber cuáles. A menudo, debe leer las guías de implementación y reconstruir el funcionamiento interno del sistema.
Vadim : Sí, este es un gran ejemplo. ¿No cree que en esta área no hay suficiente vocabulario común o un solo conjunto de criterios, utilizando el cual sería posible comparar diferentes soluciones para una tarea? Ahora se usan diferentes nombres para las mismas cosas, y muchos aspectos que deberían ser explicados de manera clara y clara no se mencionan en absoluto, por ejemplo, las garantías de transaccionalidad.
Martin : Sí, realmente lo es. Desafortunadamente, en nuestra industria muy a menudo hay una emoción excesiva en torno a diferentes instrumentos. Lo cual es comprensible, ya que estas herramientas son creadas por empresas interesadas en promocionar sus productos. Por lo tanto, estas compañías envían personas a las conferencias y, en esencia, hablan sobre lo que estos productos son excelentes. Esto se disfraza de informes técnicos, pero, en esencia, es un anuncio. Como industria, no nos perjudicaría ser más honestos acerca de las ventajas y desventajas de nuestros productos. Uno de los requisitos para esto es la terminología general; sin ella, es imposible comparar cosas. Pero además de esto, se necesitan métodos para analizar las ventajas y desventajas de diversas tecnologías.
Teoremas CAP innecesarios y otros errores de la industria
Vadim : Mi siguiente pregunta es bastante delicada. ¿Podría contarnos sobre algún error común en nuestra industria que haya encontrado durante su carrera? Por ejemplo, ¿sobre alguna tecnología sobrevalorada o una solución ampliamente utilizada de la que debiste deshacerte hace mucho tiempo? Puede que este no sea el mejor ejemplo, pero me viene a la mente usar JSON sobre HTTP / 1.1 en lugar de gRPC sobre HTTP / 2. ¿O tal vez no compartes este punto de vista?
Martin : La mayoría de las veces, al crear sistemas, para lograr una cosa, debes sacrificar otra cosa, y aquí prefiero no hablar de errores. En el caso de una elección entre JSON sobre HTTP / 1.1 y, por ejemplo, Protocol Buffers sobre HTTP / 2, ambas opciones tienen derecho a existir. Si decide usar Protocol Buffers, debe definir un esquema, y puede ser muy útil, ya que ayuda a determinar con precisión el comportamiento del sistema. Pero en algunas situaciones, tal esquema no causa más que molestia, especialmente en las primeras etapas de desarrollo, cuando los formatos de datos cambian con bastante frecuencia. Nuevamente, aquí para alcanzar un objetivo determinado, uno tiene que sacrificar algo, y en algunas situaciones esto está justificado, pero en otras no. No hay tantas soluciones que realmente puedan llamarse incorrectas. Pero ya que estamos hablando de esto, hablemos del teorema de CAP: en mi opinión, no hay absolutamente ningún beneficio. Cuando se usa en el diseño de sistemas, hay un malentendido sobre el significado del teorema CAP, o las declaraciones evidentes se corroboran con la ayuda de este. Utiliza un modelo de consistencia muy limitado: linealidad y un modelo de accesibilidad muy limitado: cada réplica debe ser totalmente accesible, incluso si no puede establecer una conexión con ninguna otra réplica. Por un lado, estas definiciones son bastante correctas, pero, por otro lado, son demasiado limitadas: muchas aplicaciones simplemente no necesitan esa definición de consistencia o accesibilidad. Y si la aplicación usa una definición diferente de estas palabras, el teorema CAP es inútil para él. Así que no veo mucho sentido en aplicarlo. Por cierto, desde que comenzamos a hablar de errores en nuestra industria, admitamos honestamente que la minería de criptomonedas es un desperdicio de electricidad. No entiendo cómo puedes hacer esto en serio.
Vadim : Además, la mayoría de las tecnologías de almacenamiento ahora son personalizables para una tarea específica, es decir. Puede seleccionar el modo de operación apropiado en presencia de fallas.
Martin : Eso es correcto. Además, una parte importante de las tecnologías no se incluye en la definición estricta de consistencia y accesibilidad del teorema CAP, es decir, no son CP, ni AP ni CA, sino solo P. Nadie escribirá sobre este software directamente, pero en realidad puede Ser una estrategia de desarrollo perfectamente racional. Esta es una de las razones por las que creo que CAP al analizar software es más dañino que bueno: una parte significativa de las decisiones de diseño no se presentan de ninguna manera, y pueden ser soluciones bastante racionales, pero CAP no permite que se describan.
Los beneficios de la descentralización.
Vadim : ¿Cuáles son los problemas más agudos en el desarrollo de aplicaciones intensivas en datos ahora? ¿Qué temas se exploran más activamente? Hasta donde yo sé, usted es partidario de la informática descentralizada y el almacenamiento descentralizado de datos.
Martin : si. Uno de los puntos que pruebo en mi investigación es que en este momento confiamos demasiado en los servidores y la centralización. En los primeros días de Internet, cuando evolucionó de ARPANET, se diseñó como una red altamente estable en la que se pueden enviar paquetes a lo largo de varias rutas, y aún así logran su objetivo. En el caso de una explosión nuclear en cualquier ciudad de América, la parte sobreviviente de la red continuaría operando, simplemente se utilizarían rutas alternativas para evitar las secciones fallidas. Fue un esquema generado por la Guerra Fría. Pero luego decidimos colocar todo en la nube, por lo que ahora casi todo pasa de alguna manera por uno de los centros de AWS en algún lugar de Virginia, en el este de los Estados Unidos. En algún momento, abandonamos el ideal del uso descentralizado de varias partes de la red e identificamos los servicios de los que ahora todo depende. Considero importante volver a un enfoque descentralizado, en el que un mayor control sobre los datos no pertenezca a los servicios, sino a los usuarios finales.
Cuando se trata de la descentralización, muy a menudo significan cosas como las criptomonedas, porque tienen redes de agentes que interactúan sobre las cuales no existe una autoridad centralizada única como un banco. Pero no estoy hablando de la descentralización, porque, en mi opinión, las criptomonedas también están extremadamente centralizadas: si necesita completar un acuerdo con Bitcoin, debe hacerse a través de la red de Bitcoin, por lo que todo está centralizado alrededor de esta red. La estructura de la red está descentralizada en el sentido de que no tiene un solo centro organizador, pero la red en su conjunto está extremadamente centralizada, ya que cada transacción debe realizarse a través de esta red y nada más. Creo que esto también es una forma de centralización. En el caso de las criptomonedas, esto es inevitable, ya que es necesario garantizar la ausencia de costos dobles, y esto es difícil de lograr sin una red que brinde consenso sobre qué transacciones se completaron y similares. Pero hay muchas aplicaciones que no requieren un sistema como blockchain; pueden funcionar con un modelo de datos mucho más flexible. Son estos sistemas descentralizados los que más me interesan.
Vadim : Dado que mencionó la cadena de bloques, ¿podría contarnos sobre tecnologías prometedoras o no conocidas en el campo de los sistemas descentralizados? Yo mismo jugué con IPFS, pero tienes mucha más experiencia en esta área.
Martin : De hecho, no sigo activamente tales tecnologías. Leí un poco sobre IPFS, pero no lo he usado yo mismo. Trabajamos un poco con
Dat , que, como
IPFS , es una tecnología de almacenamiento descentralizada. La diferencia es que la
criptomoneda de Filecoin está vinculada a IPFS, y se usa para pagar el almacenamiento de datos, y ninguna cadena de bloques está vinculada a Dat. Dat solo le permite replicar datos en múltiples máquinas en una base P2P, y para el proyecto en el que estábamos trabajando, Dat es excelente. Escribimos software para que los usuarios colaboren en un documento, datos o base de datos, y cada cambio en estos datos se envía a todos los que tienen una copia de los datos. En dicho sistema, Dat se puede usar de acuerdo con el principio P2P, de modo que se garantiza el funcionamiento a nivel de red, es decir, NAT Traversal y pasar a través de firewalls, que es una tarea bastante difícil. Además de esto, escribimos un nivel de CRDT, con la ayuda de la cual varias personas podían editar un documento o un conjunto de datos y que permitieron compartir ediciones de manera rápida y conveniente. Creo que se podría escribir un sistema similar sobre IPFS, ignorando Filecoin y usando solo la replicación P2P.
Vadim : Pero un sistema de este tipo no se volvería menos receptivo, porque WebRTC conecta directamente los nodos entre sí, y IPFS es más una tabla hash distribuida.
Martin : La cuestión es que WebRTC es un nivel de pila ligeramente diferente. Está destinado principalmente a videollamadas, con una alta probabilidad de que se utilice en el software a través del cual nos estamos comunicando. Además, WebRTC proporciona un canal a través del cual puede enviar datos binarios arbitrarios. Pero crear un sistema de replicación encima puede ser difícil. Pero en Dat e IPFS, no necesita hacer nada para esto.
Usted mencionó la capacidad de respuesta, y este es un factor realmente importante a tener en cuenta. Supongamos que queremos hacer que los próximos Google Docs sean descentralizados. En Google Docs, la unidad de cambio es una sola pulsación de tecla, y cada nuevo personaje se puede enviar en tiempo real a otras personas que trabajan con el mismo documento. Por un lado, esto garantiza una colaboración rápida, por otro lado, significa que al escribir un documento grande, debe enviar cientos de miles de cambios de un carácter, y muchas tecnologías existentes hacen frente pobremente a este tipo de compresión de datos. Incluso si suponemos que para cada pulsación de tecla es necesario enviar solo cien bytes, entonces para un documento de 100,000 caracteres será necesario enviar 10 MB de datos, aunque generalmente dicho documento no requiere más de varias decenas de kilobytes. Hasta que se haya inventado un ingenioso método de compresión, dicha sincronización de datos requiere un enorme costo adicional de recursos. Muchos sistemas P2P aún no tienen una forma efectiva de crear instantáneas del estado que les permita ser utilizados para un sistema como Google Docs. En este problema estoy trabajando actualmente, tratando de crear un algoritmo para una sincronización de documentos más eficiente para varios usuarios. Este debería ser un algoritmo que no almacenaría cada pulsación de tecla, porque esto requiere demasiados recursos, y debería proporcionar un uso más eficiente de la red.
Nuevo CRDT, verificación formal en Isabelle
Vadim : ¿Podrías contarnos más sobre esto? ¿Has logrado lograr más de 100x de compresión de datos? ¿Estás hablando de nuevas técnicas de compresión o CRDT especiales?
Martin : si. Hasta ahora, solo tenemos un prototipo; aún no se ha implementado completamente. Es necesario realizar experimentos adicionales para descubrir qué tan efectivo es en la práctica. Pero algunos de nuestros métodos son prometedores. En mi prototipo, pude reducir el tamaño de una sola edición de 100 a 1,7 bytes. Pero, repito, esta es solo una versión experimental hasta ahora, este indicador puede cambiar ligeramente. De una forma u otra, hay grandes oportunidades para la optimización en esta área.
Vadim : ¿Entonces su informe en la conferencia de Hydra será sobre esto?
Martin : si. Tendré una breve introducción sobre CRDT, software de colaboración y algunos problemas que surgen en este contexto. Luego hablaré sobre la investigación que estamos haciendo en esta área: abordan muchos problemas diferentes. En el lado de la aplicación, tenemos una implementación de estos algoritmos en JavaScript, en base a ella creamos programas funcionales para comprender mejor el comportamiento de los algoritmos. Al mismo tiempo, también estamos trabajando en métodos formales para probar la exactitud de estos algoritmos, porque algunos de ellos son bastante obvios, y queremos asegurarnos de que siempre lleguen a un estado consistente. Muchos algoritmos desarrollados previamente no proporcionan consistencia en algunos casos límite. Para evitar esto, recurrimos a métodos formales para probar la corrección.
Vadim : ¿Utiliza pruebas de teoremas como Coq o Isabelle para este sistema?
Martin : Sí,
Isabelle .
Nota del editor: Martin leerá una charla sobre Isabelle en The Strange Loop.
Vadim : ¿Estás planeando publicar esta evidencia?
Martin : Sí, el primer conjunto de evidencia que publicamos hace un año y medio, junto con el marco de verificación CRDT. Probamos tres CRDT utilizando este marco, el más importante de los cuales fue RGA (
Replicated Growable Array ), CRDT para la coedición de texto. Este algoritmo no es demasiado complicado, sino bastante obvio, en la opinión no está claro de inmediato si es correcto, por lo tanto, fue necesaria una prueba formal. También trabajamos para probar la exactitud de varios CRDT existentes, y lo último que hicimos en esta área fue crear nuestros propios CRDT para nuevos modelos de datos.
Vadim : ¿Cuánto más es el volumen de la prueba formal que el tamaño del código del algoritmo en sí? A veces hay dificultades con esto.
Martin : Realmente suficientes dificultades, tenemos que trabajar mucho con evidencia. : 60 , , 800 . , 12 . , . , . , . . , .
: , ? ?
: , . , . : TCP, Git . , , . , . . , .
Event sourcing, , XA-
:
, . , event sourcing. , - . event sourcing ? - , .
: . Event sourcing , , . , event sourcing . , , , . , event sourcing () .
event sourcing . Apache Kafka. Event sourcing Apache Kafka, , . event sourcing Apache Kafka , , , event sourcing. , , , . Apache Kafka , , , , , . Apache Kafka . Apache Kafka , . , Elasticsearch, Memcached Redis.
, , event sourcing. , . , , . — , . , event sourcing. : PostgreSQL , . , Kafka. , , .
: . , , , , .
: , , JSON (, PostgreSQL ) . , . . , .
: event sourcing. , . , (, ), : Elasticsearch, ; , key-value Memcached; , . .
: , , , — ?
: . , , , , , 404, .
: . (causal consitency) . , . , : , , . , , - . . , , , Elasticsearch Memcached. , , , . , snapshot isolation: , , . . , , . Memcached Elasticsearch . , , Memcached, Redis, Elasticsearch , . , , . , . . , . , , — , . . , . , - , .
: ,
Multiversion Concurrency Control .
: , . XA-, , , . , , . , , . XA . , , . .
: , - .
: , . , , , . , . - , . , . - , : , , , . . , .
: , . , . - , , , - .
: . . , , . , .
: , . event sourcing. , , , . , . , , , . , , , , , . ?
: , . , , . , , , , . . , . , , .
: , , , .
: . , . , . , , , . (, - ), . . - , . — , . , , , , 100%, .
: . .
: .
: , , . , — , . .
Hydra 2019,
: , Hydra? , , , .
: , , , , « » « ». . . , , - ; , , , , .
: , , , ? . , , ?
: , . , . , . - . , - , - . , . : , . — , — . , , , .
: . ? , - , , ?
: . . , . , , , . - — . , , . : . , , Slack ,
. , , . , , , .
: .
: , .
: ,
!
Les recuerdo que esta es una entrevista pregrabada. Cuando escriba comentarios, recuerde que Martin no los leerá. Solo podemos transmitir algo más interesante. Si realmente quiere hablar con el autor, él estará dando una presentación "Sincronizando datos entre dispositivos de usuario para colaboración distribuida" en la conferencia Hydra 2019, que se realizará del 11 al 12 de julio de 2019 en San Petersburgo. Las entradas se pueden comprar en el sitio web oficial .