Pensamientos sobre Algolia (vs Solr & Elasticsearch)
1 de junio de 2016 Doug Turnbull Categoría: Lucene
Después de ponerme de mal humor en un post del blog de Algolia, y de tener un episodio de Search Disco con Julien Lemoine CTO de Algolia, me he quedado fascinado con la solución.
Algolia, tan caliente ahora mismo!
Algolia presupone que todos vamos a querer una búsqueda instantánea (aka search-as-you-type). Así que han construido una búsqueda instantánea extremadamente buena y alojada. Todo lo que quieres hacer con la búsqueda instantánea está ahí. Sólo tienes que leer este increíble post sobre la comprensión de consultas
- Tolerancia a las erratas, «Doug Trunbull»
- Búsqueda de prefijos «Doug Turn»
- Prefijos con tolerancia a las erratas «Doug Trun»
- Descomposición (a veces puede ser tolerancia a las erratas) DougTrun
- Un lematizador en tiempo de consulta, y más…
Es como si en lugar de búsqueda, tuvieras autocompletado con esteroides. Si a esto le sumas una clasificación por defecto más sana que la de Elasticsearch o Solr, te queda un producto bastante convincente.
Digo todo esto como un lucenista bastante rabioso. Escribí un libro sobre la relevancia en Lucene. Soy muy parcial hacia Lucene, ya que he visto muchas soluciones convincentes construidas con Solr y Elasticsearch también.
Una cosa que he aprendido acerca de la búsqueda basada en Lucene es que puedes, con un buen equipo, construir casi cualquier cosa de búsqueda con él. Sin embargo, se necesita un equipo. La búsqueda basada en Lucene no está destinada a funcionar bien «fuera de la caja» para su solución. Independientemente de lo fácil que lo ha hecho Elasticsearch, la búsqueda basada en Lucene es un marco, no una solución. Es un conjunto de estructuras de datos centradas en la búsqueda realmente increíbles que puedes improvisar con relativa facilidad para hacer Tu Cosa™. Incluso si Tu Cosa™ significa alterar detalles de tan bajo nivel como la forma en que el índice se almacena en el disco!
Otra forma de decir esto es que podrías construir Algolia en Elasticsearch (o acercarte lo suficiente). No puedes construir Elasticsearch en Algolia. Usted gana de Algolia se centran en un problema específico. Se sacrifica la profunda personalización y extensibilidad del código abierto. Otra forma de decirlo es comparar las soluciones de búsqueda con las aplicaciones web. En muchos sentidos, Algolia es como construir un sitio con un constructor de sitios como Wix. Lucene es más como construir tu propia aplicación web con desarrolladores detrás, y todas las consideraciones de bajo nivel asociadas, las molestias, pero también el poder.
Un ejemplo es la comparación del rendimiento de Algolia con Elasticsearch. En las pruebas de Algolia, Algolia afirma una mejora de rendimiento de hasta 200 veces. En promedio, hay más bien una mejora de rendimiento de 10 a 20 veces (todavía impresionante). Sin embargo, Algolia eligió el mínimo común denominador en la búsqueda instantánea en Elasticsearch: consultas difusas y consultas de prefijo. Como está escrito en Elasticsearch: The Definitive Guide otro enfoque común que mejora enormemente la velocidad es el uso de ngramas. Básicamente evita el trabajo difuso en tiempo de consulta y construye una estructura de datos gigante que puede manejarlo.
Ahora los ngramas tienen sus propios problemas. Hacen crecer tu índice. Sin embargo, en el caso de 2 millones de documentos con mucho texto corto, puede que no haga crecer tanto el índice. Y sospecho que tendría mejoras de órdenes de magnitud en el rendimiento. Si un índice hinchado se convirtiera en un problema, podríamos producir menos ngramas de mayor tamaño. También hay que considerar el almacenamiento en caché: Apuesto a que ambas soluciones almacenan en caché los resultados de cada consulta de teclado. Así que me pregunto cómo colorea eso la consideración de Algolia vs. ES.
Incluso podríamos invertir los términos colocados en el índice para conseguir que las consultas de sufijo atrapen los errores tipográficos anteriores. O hacer cosas exóticas con consultas difusas y ngramas simultáneamente. Incluso podríamos escribir una consulta Lucene que se centre en los errores tipográficos. Mira todo el poder aquí!
El punto sin embargo es que te he hecho empezar a pensar en cómo resolverías el problema. Algolia ya ha construido una solución. ¿Por qué no seguir con la suya? Bueno, hay un par de reservas que tendría que ir todo el campo de Algolia:
- Turn-key a menudo puede convertirse en lock-in. Hay ejemplos de soluciones de búsqueda alojadas (y bases de datos que se adquieren y el nuevo propietario (en el caso de FoundationDB, Apple) no está interesado en apoyar el negocio existente.
- Tú te preocupas por «las cosas, no por las cadenas». La solución de Algolia se centra fuertemente en la coincidencia de cadenas específicas. El enfoque de Lucene a la relevancia se centra más abstractamente en los términos como características del contenido, utilizando TF*IDF como un sistema de similitud de características (nuestro libro discute en gran medida la relevancia en estos términos).
- Estás haciendo algo cercano a lo no tradicional. Tienes que implementar un lenguaje de consulta específico. Necesitas mapear explícitamente las lenguas vernáculas entre los expertos y los legos. Quieres hacer learning-to-rank. Quiere utilizar vocabularios controlados, construir una búsqueda semántica. Tiene preocupaciones geográficas específicas. Todas estas son características que puedes construir en Solr/ES y estás bloqueado en lo que Algolia te da.
- Quieres manipular profundamente el comportamiento del motor de búsqueda. Esta es una gran parte del punto dulce de Lucene.
Pero hay un par de razones por las que consideraría fuertemente Algolia
- Tienes un equipo pequeño, pero una buena búsqueda es importante. Algolia funciona bastante bien fuera de la caja. Tiene un buen nivel de configuración de la clasificación que puede incluir tanto el texto y los valores numéricos como la popularidad con un poco de apoyo geo.
- Usted necesita principalmente para apoyar las búsquedas de un solo elemento. El enfoque de Algolia es ideal para casos como la necesidad de buscar «plátano» y coincidir con los plátanos. Algolia puede no tener sentido para los usuarios que escriben «minion fruit» y esperan plátanos.
- Necesitas soportar errores tipográficos. Las soluciones de Lucene para esto son torpes. Espero que mejoren y sean más rápidas, pero la búsqueda difusa no es el punto dulce de Lucene.
Aquí hay un par de piezas de marketing de Algolia con las que no estoy de acuerdo:
- A Algolia le gusta señalar que alojar Elasticsearch va a ser difícil. Creo que con opciones como Bonsai y Elastic Cloud, este no es el caso. Con un buen alojamiento de ES, básicamente tienes una buena «API en la nube» que es tan fácil de trabajar como cualquier otro servicio.
- Algolia quiere que creas que Elasticsearch no es un buen motor de búsqueda. Sólo es bueno en el análisis de big data y en la «búsqueda de big data» (no sé qué significa eso). En el espíritu de encontrar «cosas que no son cadenas» no estoy de acuerdo. Sólo se necesita trabajo y la comprensión de lo que es especial acerca de su solución de búsqueda.
- Algolia espera que todo se va a convertir en la búsqueda instantánea. Sin embargo, en mi experiencia, la preponderancia de las experiencias de búsqueda (incluso muchas impulsadas por Algolia) son autocompletar primero para seleccionar palabras clave, y luego la búsqueda de palabras clave. Esto todavía está en el punto dulce de Lucene para la búsqueda.
- Creo en los puntos de referencia que Algolia proporciona, pero se nota que no prueban estrategias de búsqueda instantánea más rápidas en Elasticsearch. No podemos recrear sus puntos de referencia nosotros mismos. Algolia parece fiable, pero me gustaría poder probarlo de forma independiente. También me gustaría verlos correr de nuevo contra las nuevas versiones de Elasticsearch.
Pero Algolia señala importantes debilidades en el modelo de relevancia de Lucene
- Tipos y coincidencias difusas: En la medida en que el mundo quiere una búsqueda instantánea con tolerancia a los errores tipográficos, la búsqueda basada en Lucene es difícil de hacer funcionar. También creo que es más lento que la solución enfocada de Algolia (aunque no puedo recrear los puntos de referencia).
- Los valores predeterminados de Elasticsearch/Solr para la relevancia son difíciles de ajustar. Como Algolia señala correctamente, la función de clasificación dismax produce resultados bastante confusos. Escribimos sobre este fenómeno aquí. Usted puede y debe alejarse de estos valores predeterminados, pero me gustaría que la búsqueda tuviera más sentido fuera de la caja.
- Elasticsearch y Solr primitivas para la relevancia se sienten de bajo nivel. Las de Algolia parecen de más alto nivel y más enfocadas a crear un entendimiento común entre el negocio y los desarrolladores. Esta es una de las principales razones por las que construimos Quepid. Aun así, con todas las opciones de Solr/ES, la empresa te mirará fijamente cuando empieces a hablar en términos de consultas booleanas, consultas de funciones y demás.
Mi gran conclusión es que estoy bastante entusiasmado con Algolia para los casos de uso adecuados. Pero tienes que estar seguro de que va a satisfacer tus necesidades. Espero que esto te haya convertido en un comprador más informado.