En un e-commerce, las b\u00fasquedas se realizan sobre el cat\u00e1logo de productos, mientras que en una web de contenidos esta b\u00fasqueda se realiza sobre noticias, eventos, informaci\u00f3n corporativa, etc. En ambos casos, por lo que al motor de b\u00fasqueda se refiere, se est\u00e1n incluyendo (indexando) en los \u00edndices de b\u00fasqueda documentos compuestos por un conjunto de campos (nombre, t\u00edtulo, descripci\u00f3n, etc.).<\/p>\n
El grado de fiabilidad de las b\u00fasquedas realizadas por los usuarios, y su grado de satisfacci\u00f3n con los resultados obtenidos van a ser determinantes en el \u00e9xito de nuestro e-commerce o de nuestra web. Por lo tanto, es fundamental elegir el motor de b\u00fasqueda e indexaci\u00f3n<\/strong> de forma adecuada. Dependiendo del motor de b\u00fasqueda elegido, hay una serie de aspectos a tener en cuenta y decisiones a tomar.<\/p>\n En el art\u00edculo Apache Solr vs ElasticSearch<\/a><\/strong>\u00a0se habl\u00f3 de los dos motores de b\u00fasqueda open source m\u00e1s utilizados, y de las diferencias entre ellos.<\/p>\n En este art\u00edculo nos centraremos en Elasticsearch<\/strong> y en los factores determinantes en el dise\u00f1o y contrucci\u00f3n de nuestro buscador basado en el motor de Elastic.<\/p>\n \u00a0<\/strong><\/p>\n Una de las primeras decisiones a tomar es c\u00f3mo vamos a almacenar y estructurar la informaci\u00f3n en el \u00edndice, es decir, qu\u00e9 campos contendr\u00e1n los documentos a almacenar en el \u00edndice, de qu\u00e9 tipo (texto, num\u00e9rico, booleano, etc.) y si los campos se analizar\u00e1n al indexarse o no. Esta definici\u00f3n es lo que se denomina mapping en Elasticsearch.<\/strong><\/p>\n En primer lugar, debemos decidir si el mapping ser\u00e1 din\u00e1mico<\/strong>, es decir, no existir\u00e1 una estructura fija para los documentos en el \u00edndice (se ir\u00e1n a\u00f1adiendo nuevos campos al mapping autom\u00e1ticamente seg\u00fan lleguen documentos que incluyan nuevos campos), o si por el contrario ser\u00e1 estricto<\/strong>, es decir, la estructura de los documentos ser\u00e1 fija y cualquier documento deber\u00e1 ce\u00f1irse a esta estructura para poder ser insertado en el \u00edndice. Cada una de las dos opciones es m\u00e1s adecuada para un tipo de situaciones y la decisi\u00f3n no debe tomarse a la ligera, si bien a nivel general podemos decir que el mapping estricto suele ser m\u00e1s adecuado<\/strong> salvo en los casos en los que la estructura de la informaci\u00f3n a indexar no es conocida a priori.<\/p>\n <\/p>\n Otro punto fundamental en un motor de b\u00fasqueda, relacionado con el anterior, es tener claro qu\u00e9 campos se usar\u00e1n en b\u00fasquedas full-text y cu\u00e1les se usar\u00e1n en facetas (para agrupar los resultados y permitir navegaci\u00f3n guiada). Esto determinar\u00e1 la forma en la que debe indexarse cada campo.<\/p>\n Los campos que vayan a utilizarse para b\u00fasquedas de texto deben ser analizados en indexaci\u00f3n<\/strong>, de forma que se transformen y se almacenen en el \u00edndice de la forma m\u00e1s adecuada. Las transformaciones (separar palabras, eliminar sufijos y plurales, pasara a min\u00fasculas, etc.) realizadas depender\u00e1n del analizador que utilicemos, y son las que permiten que un texto pueda ser encontrado independientemente de si lo buscamos en may\u00fasculas o min\u00fasculas, en singular o plural, etc.<\/p>\n Elasticsearch viene con un gran n\u00famero de analizadores disponibles, cada uno de los cuales realiza ciertas transformaciones. Cada analizador est\u00e1 compuesto por una cadena de filtros, que se ejecutan en secuencia sobre los textos a indexar, de forma que las transformaciones que realiza cada analizador dependen de los filtros que utiliza. Adem\u00e1s, podemos crear nuevos analizadores combinando los filtros ya existentes en Elasticsearch o creando nuevos filtros.<\/p>\n Ejemplos de campos de un documento (producto o contenido) que suelen indexarse de esta manera suelen ser el nombre, el t\u00edtulo o la descripci\u00f3n.<\/p>\n A continuaci\u00f3n, se presenta un ejemplo de la definici\u00f3n de un analizador<\/strong>:<\/p>\n <\/p>\n \u00a0<\/strong><\/p>\n Los campos que vayamos a utilizar como facetas<\/strong> para agrupar los resultados (por ejemplo, agrupar los resultados por color, por rangos de edad, por g\u00e9nero\u2026 y permitir ir refinando la b\u00fasqueda en base a estos grupos) deber\u00e1n indexarse sin ser analizados<\/strong>, es decir, sin ninguna transformaci\u00f3n. Campos t\u00edpicos que suelen indexarse de esta forma son campos con un n\u00famero limitado de valores posibles (color, g\u00e9nero, origen, \u2026) o campos num\u00e9ricos o de tipo fecha, para poder agrupar por rangos de precios, de edad, de fechas, etc.<\/p>\n En Elasticsearch los campos que queremos indexar de esta forma los indexaremos como tipo keyword<\/em>, o con el tipo num\u00e9rico adecuado en el caso de que vayan a utilizarse para agrupar por rangos.<\/p>\n En algunos casos, un mismo campo necesitamos utilizarlo para b\u00fasquedas de texto pero tambi\u00e9n vamos a utilizarlo para agrupar los resultados. Por ejemplo, la marca la utilizaremos para agrupar resultados, pero tambi\u00e9n queremos utilizarla en las b\u00fasquedas de texto, para que si el usuario teclea la marca los productos de esa marca aparezcan entre los primeros resultados de b\u00fasqueda. Para estos casos, Elasticsearch nos permite indexar un mismo campo de las 2 maneras, de forma que seg\u00fan vayamos a utilizarlo en b\u00fasqueda de texto o como faceta lo referenciaremos de una forma u otra. Por ejemplo, en el caso de la marca el mapping ser\u00eda<\/p>\n <\/p>\n <\/p><\/blockquote>\n <\/p>\n En b\u00fasquedas full-text usar\u00edamos el campo brand<\/em>, y agrupar\u00edamos los resultados por por brand.raw<\/em><\/p>\n <\/p>\n El n\u00famero de \u00edndices que utilicemos para indexar la informaci\u00f3n es tambi\u00e9n importante. Versiones anteriores a la 6.x de Elasticsearch permit\u00edan crear diferentes tipos de documento dentro de un mismo \u00edndice, pero a partir de esta versi\u00f3n desaparece el concepto de tipos de documento, por lo que todos los documentos almacenados dentro de un mismo \u00edndice deben tener un mismo mapping. Por lo tanto, si tenemos varios tipos de documento con una estructura totalmente diferente, deber\u00edamos utilizar \u00edndices diferentes para almacenarlos.<\/p>\n Sin embargo, a mayor n\u00famero de \u00edndices mayor consumo de memoria, por lo que hay que buscar un equilibrio entre el n\u00famero de \u00edndices y el tama\u00f1o del mapping (n\u00famero de campos diferentes) de cada \u00edndice, ya que un mapping demasiado grande puede derivar en problemas de rendimiento.<\/p>\n <\/p>\n Si la informaci\u00f3n a indexar va a estar disponible en varios idiomas, deberemos decidir entre dos alternativas:<\/p>\n <\/p>\n A la hora de optar por una u otra soluci\u00f3n debemos tener en cuenta factores como el n\u00famero de idiomas, el porcentaje de campos traducibles frente a campos no traducibles, si se van a lanzar b\u00fasquedas contra varios idiomas a la vez y el n\u00famero total de campos a indexar.<\/p>\n Es importante destacar que Elasticsearch ofrece analizadores para multitud de idiomas<\/strong>, que analizan los textos teniendo en cuenta las reglas propias de ese idioma, y por tanto es recomendable utilizar para cada campo el analizador correspondiente al idioma de ese campo o \u00edndice, para conseguir unos resultados de b\u00fasqueda m\u00e1s refinados.<\/p>\n <\/p>\n Elasticsearch est\u00e1 especialmente preparado para la configuraci\u00f3n en cluster<\/strong>. En base a unas propiedades b\u00e1sicas, cuando los diferentes nodos arrancan el cluster se configura autom\u00e1ticamente, y cuando alguno de los nodos queda inaccesible si el cluster est\u00e1 correctamente dimensionado el resto de nodos asumen las funciones del nodo inaccesible, de manera que el cluster contin\u00faa 100% operativo.<\/p>\n Dependiendo del n\u00famero de documentos a indexar y del tama\u00f1o de estos, del n\u00famero de \u00edndices y del volumen y tipo de queries esperadas deber\u00e1 dimensionarse adecuadamente el cluster, tanto en n\u00famero de nodos como en la configuraci\u00f3n de cada uno de ellos (shards, r\u00e9plicas, memoria dedicada, cu\u00e1ntos de ellos son elegibles como master, si son nodos de datos, etc.).<\/p>\n <\/p>\nMapping o estructura de los datos en el \u00edndice<\/h2>\n
An\u00e1lisis de los campos en tiempo de indexaci\u00f3n<\/h2>\n
\"analysis\": {\r\n \"filter\": {\r\n \"spanish_stop\": {\r\n \"type\": \"stop\",\r\n \"stopwords\": \"_spanish_\" \r\n },\r\n \"spanish_keywords\": {\r\n \"type\": \"keyword_marker\",\r\n \"keywords\": [\"ejemplo\"] \r\n },\r\n \"spanish_stemmer\": {\r\n \"type\": \"stemmer\",\r\n \"language\": \"light_spanish\"\r\n }\r\n },\r\n \"analyzer\": {\r\n \"spanish\": {\r\n \"tokenizer\": \"standard\",\r\n \"filter\": [\r\n \"lowercase\",\r\n \"spanish_stop\",\r\n \"spanish_keywords\",\r\n \"spanish_stemmer\"\r\n ]\r\n }\r\n }\r\n }\r\n<\/pre>\n\n
\"brand\": {\r\n\r\n\"type\": \"text\",\r\n\r\n\"analyzer\": \"simple\",\r\n\r\n\"fields\": {\r\n\r\n\"raw\": {\r\n\r\n\"type\": \"keyword\"\r\n\r\n}\r\n\r\n}\r\n\r\n}<\/pre>\nN\u00famero de \u00edndices<\/h2>\n
Soporte para multiidioma<\/h2>\n
\n
Configuraci\u00f3n del cluster<\/h2>\n
![\"\"](\"https:\/\/www.hiberus.com\/crecemos-contigo\/wp-content\/uploads\/2019\/03\/cluster-300x90.png\")
<\/a>\u00a0<\/strong><\/p>\nTipos de b\u00fasquedas<\/h2>\n