Bases de datos de streaming

Capítulo 6. Coherencia

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Si estás familiarizado con las bases de datos, das por sentada la coherencia. Sabes que los resultados de tus consultas van a ser coherentes con los datos de entrada. Ahora imagina que te atreves a cruzar el puente de la base de datos al mundo del streaming. ¿Puedes contar aquí con garantías de coherencia similares, incluso con la complejidad adicional de los datos que llegan tarde y fuera de orden, así como el énfasis en la baja latencia y el alto rendimiento?

Para los procesadores de flujo clásicos, la respuesta es no. Garantizan una forma más débil de consistencia llamada consistencia eventual. Para los casos de uso clásicos del procesamiento de flujos, que a menudo implican agregaciones sobre datos en ventanas, la consistencia eventual encaja a la perfección, y además permite canalizar datos con latencia ultrabaja, con un rendimiento muy alto y a escala extremadamente grande. El problema es que, si vienes del mundo de las bases de datos, la consistencia eventual puede resultar una experiencia confusa y contraintuitiva, especialmente en combinación con datos sin ventanas.

En este capítulo, utilizaremos un ejemplo de juguete del ámbito bancario para demostrar lo que puede ir mal en procesadores de flujo eventualmente consistentes como Flink, ksqlDB y Proton si te limitas a seguir tus intuiciones del mundo de las bases de datos.

Curiosamente, ...