Cosas que aprendí mientras escribía aplicaciones de JavaScript de alto rendimiento

Bienvenidos a todos a mi charla, Interrumpiendo la búsqueda de texto completo con JavaScript. Ya me han presentado, así que no seguiré con eso. Y estoy aquí para hablar de la búsqueda de texto completo porque es un dominio que me encanta y algo que realmente me mantiene despierto por la noche porque me gusta tanto que no puedo dejar de pensar en ello. Y hay una buena razón por la que me gusta tanto, y es principalmente por Elasticsearch. ¿Cuántos de ustedes conocen Elasticsearch? Todos. ¿Cuántos de ustedes han usado Elasticsearch? De nuevo, casi todos. Y debo decir que me introduje en el software de código abierto principalmente por Elasticsearch. Así que tengo una relación muy apasionada con él y tuve el placer y el honor de trabajar en Apache You Know Me, que es una plataforma de data de clientes que utiliza Elasticsearch como una database líder en su infraestructura. Y cuando era un poco más junior, no sé, hace casi 10 años, me impresionó el rendimiento de un sistema tan complejo y distribuido. Me impresionó ver que podía lanzar millones y millones de registros contra él y no degradaría el rendimiento tanto. Eso fue realmente impresionante para mí, y es ahí donde decidí entrar en el software de código abierto e intentar entender cómo funciona Elasticsearch. Así que mi primera pregunta como un ingeniero junior curioso fue ¿cómo es eso posible? Quiero decir, ¿cómo puede un software mantener un rendimiento tan bueno incluso con mil millones de registros? Más tarde descubrí que Elasticsearch no es en realidad un motor de búsqueda de texto completo, sino Apache Lucene. Así que Apache Lucene es la biblioteca de búsqueda de texto completo, que Elasticsearch envuelve proporcionando una interfaz RESTful, capacidades de sistema de discapacidad, fragmentación, consistencia de data, monitoreo, gestión de clústeres y así sucesivamente. Así que un gran saludo a Elasticsearch.

Y antes de continuar, permítanme aclarar que de nuevo me encanta Elasticsearch y me encanta Algolia. Me encanta MeliSearch. Me encanta MiniSearch. Me encanta cada motor de búsqueda que existe. Y la razón por la que, por supuesto, estaré hablando de algo que recreé con mi equipo. La razón por la que hice eso en primer lugar es porque quería aprender más y, por supuesto, quería resolver algunos problemas muy personales que tenía con ese software. Así que nada personal. Por favor, si estás usando Elasticsearch, sigue usándolo, si te sientes cómodo con él. No hay problema con eso, por supuesto. Estaba hablando del hecho de que tenía algunos problemas personales con Elasticsearch. Mi primer problema personal era que es bastante difícil de desplegar, en mi opinión. Podría ser simplificado. Difícil de actualizar. Tiene una gran huella de memoria. El consumo de CPU se vuelve terrible tan pronto como

Y por supuesto, siempre que empiezas a intentar entender cómo funciona un motor de búsqueda de texto completo, tienes que lidiar con la teoría detrás de la búsqueda de texto completo. Así que árboles, gráficos, engramas, similitud de causina BN25, TF-ADF, tokenización, derivación, y más y más y más. Así que te encuentras en esa situación típicamente, ¿verdad? Sí, todo está bien. Estoy entendiendo en el teclado y espero que algo bueno salga. Spoiler, no lo hace. Pero aún así, la dura verdad, cuando decides que quieres aprender algo así, es que necesitas estudiar algoritmos en data estructuras, y necesitas estudiarlos mucho.

Y por supuesto, en cierto punto tienes que encontrar o elegir un lenguaje de programación para implementarlos, ¿verdad? Y quería ser un tipo genial, así que elijo, oh no, ese es el equivocado. Y vi a gente en la audiencia así cuando mostré el logo de Haskell ¿verdad? Por supuesto que no elegí Haskell, aunque me encanta. Intenté implementar en Rust en primer lugar. Era demasiado complejo, tengo que decir. Empecé diciendo, oh sí, extraño el recolector de basura, así que tal vez puedo intentar Golang, ¿verdad? Intenté Golang por un poco, y todavía era decente, pero aún bastante complejo de implementar. Y luego recordé a Lou, el Lou de Atwood. ¿Sabes quién era Atwood? Es el fundador de Stack Overflow. Así que cualquier aplicación que pueda ser escrita en JavaScript eventualmente será escrita en JavaScript. Y no hay nada más cierto que eso. Así que JavaScript es el rey de los lenguajes de programación. Todos lo sabemos. Por favor, un gran aplauso para JavaScript. Sí, vale la pena. Entonces, sí, empecé a reimplementar cosas en JavaScript traduciendo el code fuente que empecé a trabajar en Rust y luego en Golang. Y sorprendentemente, descubrí que, wow, era muy eficiente cuando empecé a implementar data estructuras de una manera adecuada.

Entonces, sí, también quiero darles algunos ejemplos de cómo mejorar realmente su rendimiento en JavaScript, Node, Deno, lo que sea. Entonces, cuando estás escribiendo un motor de búsqueda de texto completo, en cierto punto, tienes que lidiar con consultas booleanas, ¿verdad? Y, o, etc. Y en cierto punto, tienes que calcular las intersecciones de los arrays. Entonces, tienes varios arrays y tienes que determinar los elementos que aparecen en cada array y devolver eso. Este es un ejemplo usando el paradigma MapReduce. Y como un antiguo, y destaco, antiguo programador functional, solía amar esto mucho. Y sí, básicamente, veo a Matteo allí, está llevándose las manos a la cara y tú eres la razón por la que ya no code de manera funcional. Espero que lo sepas. Llegaremos allí más tarde. Pero de todos modos, usar MapReduce, es muy útil, en mi opinión, pero no es la forma más eficiente de lidiar con ese tipo de algoritmos. Entonces, esto es, llamémoslo versión uno. Podemos optimizarlo, eliminando todo el material de MapReduce y usando una iteración simple. Y luego tenemos que entender cómo funciona JavaScript y cómo funcionan los algoritmos. Y tal vez podemos tener la versión dos, optimizarla aún más, e ir a la versión tres. Entonces, no es una cuestión de paridad, es una cuestión de algoritmos. Aquí, básicamente, solo estamos añadiendo una sola línea que básicamente comienza la intersección desde el array más pequeño. Es una sintonización de performance muy simple que puedes aplicar en este tipo de algoritmos. Cuando ejecutas los benchmarks, y ahí está la referencia para los benchmarks, así que puedes ejecutarlos tú mismo, verás que tienes como un 13% de mejora en el performance simplemente eliminando el material de MapReduce y usando bucles simples, porque así es como, al final del día, los ordenadores tienden a trabajar. Quiero darles otros ejemplos, pero antes de hacer eso, como dije, construí un completo motor de búsqueda de texto, y con este PR solo, incrementamos el rendimiento en un 50%, cinco cero, el 50% del rendimiento total del motor de búsqueda de texto es solo cuidar cómo se calculan las intersecciones. Por eso quería traer este ejemplo a la mesa. Pero otra cosa que me gustaría que pensaran es, por favor, tienen que conocer su lenguaje, su tiempo de ejecución, y cómo optimizar su code para el tiempo de ejecución en el que se está ejecutando. Y puedo darles un par de ejemplos de eso. En primer lugar, ¿quién sabe la diferencia entre monomorfismo y polimorfismo? Estoy seguro de que hay más gente que eso. Entonces, básicamente, el polimorfismo es cuando creas una función que toma múltiples argumentos, de uno a infinitos argumentos, y básicamente llamas a la misma función con los mismos tipos de argumentos. Entonces, si tienes una función de suma donde calculas la suma de dos números,

Y trabajando con ellos, decidimos optimizarlo un poco, hacerlo un poco más bonito, y liberarlo. Así que liberamos Lyra. Así que Lyra era un motor de búsqueda de texto completo destinado a ejecutar cualquier cosa que JavaScript ejecute. Y veremos cómo lo hace en solo un segundo. Una cosa bonita que pasó, y me gustaría que esto fuera una especie de historia inspiradora, si se quiere. Alguien tomó el enlace del proyecto Lyra y lo puso en Hacker News, sin decírmelo. Y al día siguiente descubrí que teníamos unas 3,000 estrellas en GitHub, lo cual fue una locura para mí. Nunca tuve ningún repositorio que creciera tan rápido en GitHub. Y decidimos que tal vez era el momento de crear algo alrededor de eso. Así que hablé con mi antiguo jefe en NearForm, y decidimos que sí, teníamos que crear una empresa alrededor de eso. Y llegaré allí en solo un segundo. Tuve la oportunidad de llevar a dos profesionales increíbles de NearForm, Paolo, que ha hablado hoy en este mismo escenario, que ahora está trabajando conmigo como arquitecto principal. Angela, que es la mejor diseñadora que uno puede soñar. Y yo, por supuesto. Pero aún así, necesitábamos a alguien con conocimiento del dominio, con conocimiento de cómo funciona el negocio. Y preguntando por ahí, nos sugirieron hablar con una persona que ahora se ha unido a la empresa como CEO y cofundador, una persona que fue una de las primeras en basarse en Node.js que creó OpenShift, Strongloop, Scalar, muchas hermosas startups ha servido a IBM como CTO. Y ahora es nuestro, estoy orgulloso de decirlo, cofundador y CEO, Sir Isaac Roth. Y estoy muy orgulloso de decir que fundamos juntos Orama. Así que Orama es la próxima evolución de Lira. Y aquí es donde queremos llevar la búsqueda de texto completo, que es de código abierto y gratuita. Sé que cuando digo empresas, la gente puede pensar, oh no, ahora estás comercializando algo. En realidad no. Esto es de código abierto. Tú

Entonces, una vez que lo importas, digamos que creas una database de películas. Entonces debes tener un esquema, que es fuertemente tipado. Y puedes decir, OK, tendré mi título, un nombre de director, algunos metadatos, como la calificación, que es un número, ha ganado un Oscar, que es un booleano. Y luego tienes que insertar cosas, como mi película favorita de todos los tiempos, The Prestige. ¿Hay alguien más compartiendo esta pasión por esta película? Wow, increíble. No, no. ¿Por qué dices que no? Necesitamos discutir esto más tarde, ya sabes. Bueno. De todos modos, en mi opinión, esta es la mejor película de todos los tiempos, . Y sí, de todos modos, no es por eso que estamos aquí. Discutiremos esto más tarde. Insertamos cosas y luego buscamos cosas. Entonces, busquemos Prestige. Y seleccionamos las propiedades en las que queremos buscar. O podemos usar el operador estrella para buscar en todas las propiedades. Y eso es realmente todo. Así es como funciona. Pero ahora puedes estar pensando, ¿qué hace que Orama sea tan especial, verdad? Tenemos varias bibliotecas de búsqueda de texto completo construidas en JavaScript. Tenemos mini-search, tenemos FUSE.js, tenemos FlexiSearch. Y déjame decirte, todas estas son bibliotecas excepcionales. Si ya las estás usando ahora,

Pero dije, queremos crear algo diferente. Así que, creamos un gran conjunto de características. Y esto no es ni siquiera todo lo que cubrimos. Pero creo que esto es lo más importante que cubrimos. Como, tenemos soporte para conjuntos de caras, filtrado, tipo de tolerancia, impulso de campo, derivación, 26 idiomas de serie, soporte para palabras de parada, plugins, componentes y hooks, que no están relacionados con React. Quiero decir, hooks significa, por ejemplo, antes de insertar cosas, hacer algo después de insertar cosas, hacer algo después de tokenizar antes de tokenizar. Hay mucho que puedes personalizar sobre Arama. Y lo mismo se aplica para los componentes. Como, por ejemplo, si indexas números, por convención, hicimos algunos benchmarks y descubrimos que los árboles AVL son la estructura de data que está más optimizada para números en nuestro caso. Pero tú podrías tener un caso de uso diferente. Así que, exportamos una interfaz opaca. Así que, puedes traer tu propia estructura de data lo que también significa que si quieres probar tus habilidades y crear nuevas estructuras de data, puedes usar nuestra suite de pruebas para probar tus algoritmos y estructuras de data. Eso es simplemente fácil y divertido de hacer, supongo. Lo bueno de Arama, es que funciona donde sea que JavaScript se ejecute. Funciona en Cloud 5.0 workers. No tenemos ninguna dependencia y lo hicimos compatible con literalmente todos los entornos de ejecución que existen, excepto para Rhino. ¿Hay alguien aquí que conozca Rhino? Oh Dios mío, lo siento mucho por ti. He estado trabajando con él durante cinco años. No tienes idea. No, tal vez sí la tengas. Tal vez sí la tengas. Aparte de eso, creo que la mayor ventaja de usar Orama, si necesitas búsqueda de texto completo en tu aplicación, es que es extensible en JavaScript puro. Tenemos los hooks y sistemas de componentes incorporados, pero no es solo eso. Es increíblemente rápido y medimos el tiempo, el tiempo de búsqueda, en microsegundos. ¿No me crees? Tal vez es hora de una pequeña demostración.

Veamos. Vaya. Desapareció. Oh, aquí está. De acuerdo. Permíteme darte un ejemplo. Así que tengo una base de datos que tomé de keggle.com. Básicamente son 20,000 productos llenos de título, descripción, precios, enlaces a imágenes, reseñas, lo que sea. Vamos a indexar 20,000 productos en el navegador ahora mismo y haremos algunas consultas sobre ellos. Para ser honesto, también desplegué la misma base de datos exacta en nuestra propia CDN. Hablaremos de eso más tarde para poder hacer algunas comparaciones. Bien. ¿Estás listo? Vamos a poblar 20,000 productos en la base de datos. Debería tomar alrededor de tres segundos. Sí, así fue. Y ahora estamos listos para hacer algunas consultas. Así que hagamos una consulta. Vale. Vaya. 17 milisegundos. Eso está bien. Intentemos con, no sé, caballo. 175 microsegundos. ¿Por qué estoy destacando esto? Porque estás ejecutando en una CDN, en un worker, y te están cobrando cada microsegundo que tu CPU funciona. Así que esto es lo que te están cobrando por ejecutar esto, ¿verdad? En AWS, por ejemplo, eso no es cierto. El mínimo es 1 milisegundo. Pero aún así, estamos ejecutando en una CDN. Una cosa a tener en cuenta es que, como, ahora tenemos 10 imágenes en esta página, ¿verdad? Algunas imágenes en realidad faltan debido a los datos corruptos. Pero estás pagando por la dirección desde tu CDN, ¿verdad? Así que estás pagando como 1 megabyte y

Java, ese fue el primero. ¿Por qué no elegiste Haskell? ¿Pregunta seria... quiero decir, respuesta seria? Depende de ti. De hecho, solía usar code Haskell durante un tiempo. No era bueno en eso. El problema es que si quieres ejecutar en un navegador, no querrás usar pure script. Sabes que puedes compilar Haskell a Javascript. No vale la pena, en mi opinión. No vale la pena compilar ningún lenguaje a Javascript. Simplemente usa Javascript en sí o usa TypeScript de una manera que solo puedas eliminar los tipos y obtener Javascript puro de él. Así es como sugiero escribir Javascript en absoluto. No uses ningún otro lenguaje en él. Sí, lo tengo.

Sí, siguiente pregunta, ¿cómo escala realmente? Oops. Sí, y se ha ido...

Sí, lo revertiré en un segundo. Cómo escala realmente. ¿Podríamos hacer una búsqueda de texto completo en PubMed? 35 millones de artículos descargables gratis. 50 gigabytes gratis de artículos en el campo médico. Claro que puedes. De la misma manera que puedes hacerlo... Por supuesto que no estás haciendo eso en un navegador porque no tienes tanta memoria RAM. Este es un motor de búsqueda de texto completo en memoria. La mejor manera de hacer eso, en mi opinión, es... Me entristece mucho decir esto pero esto es... ¿Cómo queremos comercializar RAM, de acuerdo? Proporcionando una solución ultra escalable para tus grandes conjuntos de data. Por supuesto que puedes usar los proyectos de código abierto y desplegarlo como prefieras. Puedes desplegarlo en una CDN pero tantos data en una CDN eso es bastante peligroso y bastante difícil de lograr. Encontramos una forma de lograrlo. Definitivamente deberíamos discutir esto. Lamento mucho no poder revelar esto públicamente aún. Lo siento, esa es una respuesta muy mala.

Muy bien. ¿Cómo pruebas que la búsqueda de texto funciona? Bueno, tenemos varias unit tests en primer lugar. Tenemos varias pruebas generativas y nos aseguramos cada vez que implementamos una nueva característica nos aseguramos de generar aún más unit tests en datos reales para garantizar su corrección. El mayor problema es determinar si la búsqueda está funcionando correctamente o no porque el contexto importa, el stemming importa y si ejecutas la misma búsqueda en Algolia y Elastic es muy poco probable que obtengas exactamente los mismos resultados por varias razones. Entonces, ¿cómo determinas si está funcionando o no? Un hecho interesante sobre Orama es que puedes inyectar tu code y hacerlo funcionar y buscar como prefieras. Así que solo puedo garantizarte que está funcionando bien porque tenemos una adopción de la community que lo demuestra, tenemos unit tests y pruebas de integración que lo demuestran pero si no está funcionando como quieres que funcione siempre puedes usar los hooks y componentes para hacerlo funcionar como prefieras.

Genial, creo que la siguiente pregunta irá. Sí, ¿será Orama diferente de Lyra? Hablando de características. Oh, en absoluto. Solo tuvimos que cambiar la marca del nombre básicamente porque Lyra era un códec de Google y tuvimos algunos problemas con el nombre. También hay muchas empresas llamadas Lyra donde incorporamos la empresa. Así que decidimos ir con Orama que en griego significa ver y siento que Orama también es un nombre divertido, ¿verdad? Para usar en inglés. Eso es lo que me dijeron, soy italiano. Siento que no lo sé. Tengo buenos sentimientos sobre el nombre pero eso es solo un cambio de nombre en realidad. No es nada más que eso.

Sí, pregunta sobre el recolector de basura. ¿Qué tan significativa es la penalización del recolector de basura en tu opinión para cargas de trabajo de alto volumen? Así que cada vez que ejecutas en una CDN, realmente no te importa eso en absoluto porque cada vez que haces una consulta es probable que golpees un nodo diferente o un nodo que ya está desgastado por la solicitud anterior y siempre está en caché. Así que el hecho es que la penalización del recolector de basura es mala si tienes un conjunto de datos grande en el navegador pero no es probable que tengas un gran conjunto de data en el navegador. Siento que tener un despliegue monolítico en un servidor Node.js, no es bueno. Si querías eso, por favor usa Algolia o Elasticsearch. Son buenos en esto y también porque tendrías que lidiar con protocolos de consenso para data distribuida, consistencia de data. Tienes que asegurarlo. Así que mi opinión es que los motores de búsqueda construidos en JavaScript para ejecutarse en el borde deberían ejecutarse en el borde o en el navegador. Eso es realmente todo.

De acuerdo, suena genial. Sí, hay algunas preguntas. ¿Por qué ya no usas un paradigma funcional? Por culpa de Matteo Collina, que está aquí sonriendo. No, porque tiene razón. Quiero decir, no es la forma más eficiente de escribir JavaScript code. Antes de unirme a NIRF y su equipo, trabajaba principalmente con JavaScript funcional. Luego descubrí que esta no es la mejor manera de escribir JavaScript. Y si cuentas el número... Quiero decir, los números son lo que importa en cierto punto y los números muestran que el JavaScript imperativo es mucho más rápido y mejor en muchos aspectos que el JavaScript orientado a objetos o funcional. Probablemente eso se deba a que estaba escribiendo un terrible JavaScript orientado a objetos o de programación funcional. Pero como lo escribo, mi código imperativo funciona mejor. Así que por eso es imperativo.

Sí, tiene sentido. Sí, también hay una pregunta sobre los benchmarks en comparación con Elastic Search. ¿Tienes alguna referencia?

Estamos a punto de publicarlos, de hecho, sí. Y aún no. No son públicos. Estamos a punto de publicarlos.

Bien, creo que necesito elegir una última. Permíteme rápidamente... Oh, esa es buena. Sí, absolutamente. Esto es bueno por una cosa que no mencioné. Pero por ahora, necesito hacerlo. Si implementas una base de datos inmutable en una CDN, tienes algunas ventajas. Por ejemplo, si nadie está buscando, no estás pagando nada. Lo que significa que si tienes 1000 usuarios, puedes construir 1000 índices diferentes, implementarlos en una CDN, y no estás pagando nada hasta que comiencen a buscar. Lo que significa que cada usuario puede tener una experiencia de búsqueda diferente y personalizable y personalizada. ¿Verdad? Así que sí, puedes potenciar documentos en lugar de campos. Y puedes decir como, a Michele le gustan, no sé, las camisetas violetas. Así que cada vez que busca camisetas, tendrá campos potenciados para Violeta y camisetas juntas, ¿verdad? Porque tal vez tengo un historial de búsqueda o historial de conversión en e-commerce. Tal vez a otras personas como Paolo, siempre bromeo con él porque le gustan las camisetas amarillas. Si busco camisetas, tendré un índice que potenciará las camisetas violetas. Paolo tendrá un índice que potenciará las camisetas amarillas. Como puedes ver, esto está aumentando la conversión para tus usuarios, con suerte. Y así que sí, definitivamente, puedes potenciar documentos y deberías potenciar documentos en lugar de campos.

Muy bien, muchas gracias. Gracias. Hay muchas más preguntas. Simplemente no puedo, sí. No sé cómo se llama, pero estaré allí. Sí, exactamente. Es una sala de preguntas y respuestas. Así que todos, por favor, únanse a la sala de preguntas y respuestas. Gracias. Y en realidad...