La primera versión de mi repositorio de análisis bursátil ejecutaba los análisis en un motor OLTP, y la segunda ejecuta la misma carga de trabajo en una pila OLAP. Elegí la pila OLAP por una única optimización, pero tuve que entender todo el lakehouse para aprovecharla.
El diseño de InnoDB ofrece tres garantías que moldearon mis primeras decisiones. Almacena todas las columnas de una fila juntas, así que obtener una barra de un símbolo toca un único punto del disco, lo que resulta adecuado para la ingesta. Sin embargo, un indicador que necesita solo dos columnas sigue leyendo todas las columnas a través del buffer pool. Los índices aceleran las lecturas pero ralentizan las escrituras, ya que cada escritura debe actualizar cada árbol B de la tabla. Esto es excelente para lecturas selectivas y pésimo para la ingesta con muchas escrituras, por lo que mis tablas Raw* solo tienen una clave primaria.
InnoDB también usa un registro de deshacer (undo log), que permite lecturas y escrituras concurrentes. Cuando una fila se actualiza o se elimina, el valor anterior se conserva para que otras sesiones puedan seguir leyéndolo. Las inserciones generan un registro de deshacer más pequeño que se purga al confirmar. Los registros de deshacer de actualizaciones y eliminaciones se unen a una lista global de historial, que InnoDB purga una vez que han terminado todas las sesiones iniciadas antes de la confirmación. Este mecanismo es el Control de Concurrencia Multiversión, o MVCC, que permite que las inserciones y actualizaciones se produzcan sin bloquear las lecturas.
Sin darme cuenta, había diseñado mi base de datos InnoDB con un fundamento OLAP. Mi tabla financialdata contenía la fecha y hora junto con los precios OHLC, y cada indicador técnico requería un join sobre ella para encontrar la fecha. Fue uno de mis peores diseños de datos, y solo me di cuenta cuando la base de datos superó los 100 GB. Corregirlo fue brutal.
Fuente: Hacker News · Resumido por HeadlinesBriefing