00:00:00Cuando estás iniciando un nuevo proyecto y necesitas una base de datos, ¿cuál es la primera opción que
00:00:03te viene a la mente? ¿SQLite? Probablemente sea SQLite, ¿verdad? Es genial, confiable,
00:00:09no requiere configuración y es un estándar de la industria. Pero a medida que nuestros datos locales pesan más y nuestras consultas
00:00:14se vuelven más complejas, empezamos a alcanzar el límite de lo que un motor de bloqueo de archivos
00:00:20de un solo hilo puede hacer. Pero ahora hay un nuevo competidor que intenta resolver estos problemas.
00:00:25Se llama Stulab y es un motor de base de datos escrito enteramente en Rust que acaba de lanzar
00:00:31un controlador nativo de Node.js que, sinceramente, está mostrando un rendimiento realmente sólido.
00:00:36La base de datos es 138 veces más rápida que SQLite. Así que en este video, vamos a ver
00:00:43las entrañas de Stulab, ver cómo funciona y realizar una prueba de referencia en vivo para ver si es tan potente
00:00:50como dice ser. Va a ser muy divertido, así que entremos en materia. ¿Qué es exactamente Stulab?
00:01:00En esencia, Stulab es una base de datos de procesamiento analítico en línea o OLAP integrada.
00:01:06Si estás acostumbrado a bases de datos estándar como SQLite o Postgres, esas suelen ser bases de datos
00:01:14OLTP o de procesamiento de transacciones en línea, que, como su nombre indica, están optimizadas para transacciones.
00:01:20Pero Stulab es diferente. Está diseñado para cargas de trabajo analíticas y construido desde cero en Rust
00:01:27enfocándose en el procesamiento de datos a alta velocidad. Imagínalo con la portabilidad de un archivo SQLite,
00:01:33pero con la potencia analítica bruta de algo como DuckDB o BigQuery. Pero lo mejor
00:01:39es que ahora puedes usarlo con Node.js gracias a su controlador nativo de Node.
00:01:45Cuando digo que es un controlador nativo, no me refiero a un simple envoltorio estándar. Normalmente,
00:01:49cuando una base de datos está escrita en otro lenguaje como Rust o C++, tu aplicación Node.js se comunica mediante un puente.
00:01:56A menudo eso significa convertir tus datos a JSON u otro formato, enviarlos por un socket de red local
00:02:02y luego volver a convertirlos en el otro extremo. Eso se llama sobrecarga de serialización y
00:02:08es un asesino del rendimiento. Pero Stulab Node hace las cosas de forma distinta. Utiliza NAPI-RS,
00:02:15un framework que permite compilar el motor Rust en un binario nativo que se carga
00:02:21directamente en tu proceso de Node.js. Así que no hay puente ni traductor intermedio. Al enviar
00:02:27una consulta, Node.js y Rust comparten básicamente el mismo espacio de memoria. Y hay tres razones
00:02:33principales por las que Stulab es increíblemente rápido. Primero, utiliza MVCC o control de concurrencia multiversión.
00:02:40A diferencia de SQLite, donde un solo escritor puede bloquear toda la base de datos, Stulab permite que múltiples
00:02:47lectores y escritores trabajen al mismo tiempo. En segundo lugar, utiliza la ejecución paralela. Stulab usa un planificador
00:02:53llamado Rayon. Con Rayon, cuando ejecutas una consulta masiva, en lugar de procesarla en un solo núcleo, la divide
00:03:00y utiliza cada núcleo que tenga tu máquina. Y en tercer lugar, utiliza un optimizador
00:03:06basado en costos. No ejecuta tu SQL a ciegas; analiza tus datos, estima
00:03:13el costo de diferentes rutas y elige la forma más rápida de obtener los resultados. Se supone que eso es lo que
00:03:19hace que Stulab sea mucho más rápido que SQLite. Pero pongámoslo a prueba para ver si es verdad.
00:03:25Para esta prueba, usaremos un proyecto sencillo de Node.js e instalaremos tanto Stulab como
00:03:30SQLite como dependencias. Uno de los mayores triunfos de Stulab es el uso de count distinct.
00:03:37Tengo mucha curiosidad por saber si realmente es así. Así que preparé este script donde iniciamos
00:03:43una versión en memoria de cada base de datos y creamos una tabla de ventas simple. Luego la poblamos
00:03:49con 10,000 filas de datos de ventas aleatorios donde cada fila representa una venta de un usuario cuyo ID varía
00:03:56de 0 a 1,000 y que tiene una categoría específica. Luego insertaremos los datos por lotes
00:04:03en ambas bases de datos y ejecutaremos el benchmark para seleccionar un recuento distintivo de ventas por
00:04:10un usuario específico en una categoría específica y calcularemos el rendimiento. Debo
00:04:16mencionar que es un poco frustrante que, por ahora, el paquete instalado no funcione. Si ejecutamos
00:04:22la prueba ahora, vemos que se queja de un binding nativo faltante. Claramente,
00:04:28al autor del proyecto se le olvidó añadir los binarios o enlazar los correctos al paquete. Así que lo que tuve
00:04:34que hacer fue construirlo desde la fuente. Cloné el repositorio, ejecuté la compilación allí y luego volví
00:04:39a mi proyecto de benchmark y enlacé mi directorio fuente como la dependencia. Esto es un poco
00:04:44frustrante por ahora, así que espero que los autores lo solucionen pronto. Pero
00:04:49aun así, tras hacer eso, finalmente podemos ejecutar el benchmark. Hagámoslo ahora.
00:04:54Como pueden ver, la operación count distinct es de hecho mucho más rápida en Stulab, aunque no
00:05:01tanto como se anunciaba. Solo es cuatro veces más rápida. ¿Y si añadimos otro cero a la cantidad de
00:05:07datos y volvemos a ejecutar la prueba con 1,000,000 de filas? Probemos eso ahora.
00:05:12Incluso con un millón de filas, Stulab es solo seis veces más rápido, no 138 veces. Pero aun así,
00:05:20es un resultado excelente. Esa fue la prueba de count distinct. Decidí hacer otro benchmark
00:05:26para probar la operación distinct + order by. En esta segunda prueba, configuré una ingesta
00:05:33de registros aleatorios con diferentes direcciones IP y códigos de estado, para luego intentar encontrar registros
00:05:39distintos por par de IP y código de estado, y ordenarlos por IP ascendente y código de estado
00:05:47descendente. Y como pueden ver, al ejecutar la prueba, Stulab sigue rindiendo mejor que SQLite,
00:05:53pero no por 14 veces, sino solo de 1 a 1.5 veces más rápido. Las medidas publicadas están un poco
00:06:01infladas, en mi opinión. Pero sea como sea, Stulab es más rápido que SQLite, como acabamos de ver.
00:06:08Para ser justos, el autor también menciona áreas donde SQLite rinde mejor que Stulab.
00:06:13Suelen ser situaciones en las que se realizan operaciones de una sola fila. Stulab es ideal para
00:06:19consultas analíticas y complejas. Entonces, ¿es Stulab el asesino de SQLite? Sinceramente, no. Están hechos
00:06:26para cosas totalmente diferentes. SQLite sigue siendo tu herramienta diaria confiable para transacciones,
00:06:32pero Stulab podría ser tu coche de carreras de alto rendimiento para el análisis de datos. Pero el hecho
00:06:38de tener ahora un motor analítico puro en Rust que podemos integrar en un proyecto de Node.js con NAPI-RS
00:06:45es algo fantástico. Los dueños del proyecto solo deben arreglar su paquete de NPM actual
00:06:50para que no tengamos que construirlo desde la fuente. Ahí lo tienen, amigos. Eso es Stulab en pocas palabras.
00:06:55¿Qué opinan ustedes? ¿Vale la pena el aumento de rendimiento cambiarse a Stulab, o prefieren
00:07:01la fiabilidad de SQLite? Déjennoslo saber en los comentarios de abajo. Y si les resultó útil
00:07:06este video, por favor denle al botón de me gusta. Tampoco olviden
00:07:11suscribirse a nuestro canal. Soy Andris de Better Stack y los veré en
00:07:17los próximos videos.