Créeme, nosotros en LectureNotes.in fuimos en esa ruta, “pero construir tu propia funcionalidad de búsqueda es gratis” es donde te equivocas.
TL; DR Es más costoso en costos de desarrollo, operaciones y mantenimiento, que pagar unos pocos dólares por mes.
La primera vez que implementamos una funcionalidad de búsqueda de cualquier tipo fue una simple búsqueda “% LIKE%” en las tablas de MySQL [1]. Fue horriblemente lento y falló terriblemente por errores tipográficos triviales y faltas de ortografía.
- ¿Cuándo está lista una aplicación en la nube?
- ¿Cuáles son las principales diferencias entre las principales ofertas basadas en la nube en la administración de nóminas?
- ¿Qué seguridad necesitamos en la computación en la nube?
- ¿Por qué uno diseña e implementa soluciones distribuidas a gran escala en la nube? ¿Puedo usar un servicio en la nube para uso personal en lugar de para negocios?
- ¿Cuáles pueden ser algunos proyectos únicos en IoT en los que también tengo que usar la nube?
Recibimos muchas quejas sobre que la búsqueda es terriblemente inexacta. Los usuarios tienen altas expectativas de búsqueda, por razones que explicaré más adelante en esta respuesta.
Segundo intento, probamos la búsqueda de texto completo de MySQL. [2] Funcionó mejor. Pero todavía no puede coincidir con nombres alternativos. Agregamos más campos al índice. Los usuarios luego exigieron poder buscar las descripciones, también las agregamos. Pero esto degradó la calidad de búsqueda en su conjunto. La relevancia de los resultados estaba bajando. Para calcular el “puntaje” adecuado de cada resultado, se nos ocurrió una consulta de cálculo de puntaje de búsqueda compleja. Muy pronto, nos obligó a unir (suspirar) en eso. Esto se desplomó el rendimiento de la consulta.
Hubo otra demanda creciente: “Autocompletar”. Implementamos el autocompletado usando el enfoque% LIKE%, pero no fue efectivo. Los análisis mostraron que a los usuarios no les gustaban los resultados provenientes de la base de datos. La mayoría de los usuarios usaban Internet móvil lento y la latencia arruinó su experiencia. Además, muchos de nuestros términos de búsqueda comenzaron con 2 caracteres, pero no pudimos repararlo porque da como resultado un rendimiento y relevancia más degradados.
Comenzamos a ganar tráfico y experimentamos sobretensiones que causaron la sobrecarga de los servidores. También recibíamos un número cada vez mayor de consultas de búsqueda. Y la mayoría de nuestro público objetivo no tenía el inglés como primer idioma. Recordamos habernos reído al ver las diversas consultas de búsqueda (anónimas), nuestros usuarios ingresan, inician sesión en nuestros registros.
Nos dirigimos a Algolia. Como dicen, son muy confiables y fantásticos. No hubo problemas notables de latencia en sus sugerencias automáticas, y fueron muy relevantes. Proporcionaron búsqueda facetada fuera de la caja, una cosa que era demasiado difícil de implementar. Agregar la integración de Algolia a nuestra aplicación basada en Symfony fue muy fácil. Todo fue sencillo: interfaz de usuario, correcciones ortográficas, sugerencias. Pero simplemente no estábamos dispuestos a pagar $ 100 por mes en ese momento.
Y ese fue nuestro error.
Tenemos codificadores realmente apasionados en nuestro equipo, listos para enfrentar cualquier desafío. Planeamos construir nuestro propio servidor de búsqueda ejecutando Solr, asignamos 3 personas (incluido yo mismo) y 3 meses de tiempo para crear un prototipo que funcione. Y pronto aprendimos que ejecutar Solr sin problemas era una pesadilla. (ElasticSearch es nada menos que una pesadilla, ya lo sabíamos). Desde configuraciones extrañas basadas en XML hasta problemas realmente difíciles de escalar. Mis lecciones de PNL fueron útiles mientras diseñaba los filtros para la búsqueda, pero aún así requería mucha experimentación para lograr una configuración decente.
Nunca lo desplegamos a producción, todavía.
Implica escribir una gran cantidad de código para integrarlo adecuadamente con la aplicación Symfony que ejecutamos. Asegure adecuadamente el servidor de búsqueda para evitar cualquier tipo de ataques DoS en nosotros. Prepárese adecuadamente para manejar multitudes de 50,000 visitantes. Eso es demasiado para un equipo de operaciones de 2 hombres.
No pudimos interactuar con Solr directamente, tuvimos que construir una API de envoltura alrededor para limpiar y validar las cosas adecuadamente. Se pusieron en cola nuevos elementos y se agregaron lentamente al índice. Todo esto requirió una gran cantidad de inversión que aún no ha dado ningún rendimiento.
Como estimación, escribir el código tomó alrededor de ~ $ 3000, el costo del servidor se estima en $ 200 – $ 400, los costos de mantenimiento al menos $ 500.
~ $ 1000 para su propio servidor frente a $ 59 para los planes más económicos de Algolia: su elección.
PD: Esto supone que desea crear algo que coincida con la calidad de la búsqueda en la nube de Algolia o AWS. Si simplemente está proporcionando una búsqueda de etiquetas, está bien con el enfoque de MySQL.
Una nota sobre por qué los usuarios tienen tantas expectativas en el cuadro de búsqueda. Porque Google. Tiene el cuadro de búsqueda más inteligente del planeta. Sabe todo lo que sabes. La mayoría de las personas asume que cualquier cuadro de búsqueda tiene un don similar para saber mágicamente lo que quieren encontrar.
Notas al pie
[1] 3.3.4.7 Coincidencia de patrones
[2] 12.9 Funciones de búsqueda de texto completo
