Solr: el servidor de búsqueda de Apache

Solr (pro­nu­n­cia­do “solar”) es un proyecto open source basado en Lucene (software libre de Apache) y escrito en Java. Como servidor de búsqueda, Apache Solr es una de las he­rra­mie­n­tas más populares para integrar motores de búsqueda ve­r­ti­ca­les. Las ventajas de Solr co­m­pre­n­den una amplia gama de funciones (in­clu­ye­n­do, por ejemplo, el facetado de los re­su­l­ta­dos de búsqueda) y la in­de­xa­ción acelerada. Se ejecuta en co­n­te­ne­do­res-servidor como Tomcat (Apache). ¿Cómo funciona Apache Solr? ¿Qué hay que tener en cuenta al utilizar el software por primera vez?

La base de Solr la co­n­s­ti­tu­ye Apache Lucene, software de­sa­rro­lla­do por el diseñador Doug Cutting en 1997, que primero lo ofreció a través del servicio de alo­ja­mie­n­to de archivos Sou­r­ce­Fo­r­ge. En 2001 entra a formar parte del proyecto Jakarta, lanzado en 1999 por parte de la Apache Software Fou­n­da­tion para apoyar y promover el de­sa­rro­llo de software libre de Java, por estar también escrito en Java. Desde 2005, Lucene se incluye entre los pri­n­ci­pa­les proyectos de Apache y se di­s­tri­bu­ye bajo una licencia libre de Apache. De Lucene derivaron varios proyectos se­cu­n­da­rios como Lucy (Lucene escrito en C) y Lucene.NET (escrito en C#). En Lucene también se basa el popular servidor de búsqueda Ela­s­ti­c­sea­r­ch, del cual ha­bla­re­mos más adelante.

Creado en 2004, en aquel entonces Solr todavía se llamaba Solar y era di­s­tri­bui­do por CNET Networks. “Solar” re­pre­se­n­ta­ba las siglas de “Search on Lucene and Resin” (“buscar a Lucene y a Resin”).

En 2006, CNET entregó el proyecto a la Fundación Apache, donde ini­cia­l­me­n­te pasó por otro periodo de de­sa­rro­llo. Cuando Solr se puso a di­s­po­si­ción del público como un proyecto autónomo en 2007, atrajo pronto la atención de la comunidad Apache, que en 2010 integró el servlet en el proyecto Lucene. Este de­sa­rro­llo conjunto es el que garantiza la co­m­pa­ti­bi­li­dad entre ambos. El paquete lo completan SolrCloud y el Tika Parser.

Apache Solr se integra como un servlet en Lucene, co­m­ple­me­n­ta­n­do así a la bi­blio­te­ca de software. Por esto, y dado que algunos de los sitios web de más renombre, como Netflix o eBay, utilizan Solr como base para sus motores de búsqueda ve­r­ti­ca­les, acla­ra­re­mos en los si­guie­n­tes párrafos en qué consiste Apache Lucene.

El software libre Lucene es una bi­blio­te­ca Java de código abierto y gratuita que se puede utilizar en cualquier pla­ta­fo­r­ma. Conocido como una bi­blio­te­ca NoSQL escalable y de gran re­n­di­mie­n­to, Lucene está es­pe­cia­l­me­n­te indicado para im­ple­me­n­tar motores de búsqueda, tanto en Internet como en dominios y consultas locales.

Dado que la bi­blio­te­ca subdivide los do­cu­me­n­tos en campos de texto y los clasifica de forma lógica, la búsqueda de texto completo con Lucene funciona de forma muy precisa, así como también responde bien al encontrar re­su­l­ta­dos re­le­va­n­tes para textos y do­cu­me­n­tos similares. Esto hace que esta bi­blio­te­ca también sea adecuada para páginas como Yelp. Mientras reconozca un texto, el formato (texto plano, PDF, HTML u otros) es lo de menos porque, en lugar de indexar archivos, Lucene trabaja con texto y metadatos, aunque los archivos se han de extraer de la bi­blio­te­ca de todas formas.

Para ello, el equipo de Lucene de­sa­rro­lló el proyecto, ahora in­de­pe­n­die­n­te, Apache Tika. Apache Tika es una he­rra­mie­n­ta para el análisis, la tra­du­c­ción o la in­de­xa­ción de textos. La he­rra­mie­n­ta lee texto y metadatos de más de mil tipos de archivos. A co­n­ti­nua­ción, extrae el texto y lo pone a di­s­po­si­ción para su tra­ta­mie­n­to posterior. Tika consta de un ana­li­za­dor (parser) y un detector. El ana­li­za­dor examina los textos y es­tru­c­tu­ra el contenido en una jerarquía ordenada. El detector tipifica el contenido. Por ejemplo, reconoce el tipo de archivo, pero también el tipo de contenido de los metadatos.

Funciones y ca­ra­c­te­rí­s­ti­cas más im­po­r­ta­n­tes de Lucene:

• In­de­xa­ción rápida, tanto en fases como por lotes (hasta 150 GB por hora según sus de­sa­rro­lla­do­res)
• Uso económico de la memoria RAM
• Escrito por completo en Java y, por lo tanto, mu­l­ti­pla­ta­fo­r­ma (las variantes en lenguajes de pro­gra­ma­ción al­te­r­na­ti­vos son Apache Lucy y Lucene.NET)
• Interfaz para plugins
• Búsqueda por campos de texto (ca­te­go­rías como contenido, título, autor, palabra clave), también para varios al mismo tiempo
• Cla­si­fi­ca­ción por campos de texto
• Listado de los re­su­l­ta­dos de la búsqueda según similitud o re­le­va­n­cia

Lucene divide los do­cu­me­n­tos en áreas como título, autor y texto. Dentro de estos campos, el software realiza la búsqueda uti­li­za­n­do el ana­li­za­dor de consultas (query parser), co­n­si­de­ra­do un in­s­tru­me­n­to es­pe­cia­l­me­n­te eficaz para las consultas de búsqueda in­tro­du­ci­das ma­nua­l­me­n­te. Su simple sintaxis consiste en un término de búsqueda y un mo­di­fi­ca­dor. Los términos de búsqueda pueden ser palabras o grupos de palabras que pueden ajustarse con un mo­di­fi­ca­dor o enlazarse con variables booleanas a una consulta compleja. Los comandos exactos pueden co­n­su­l­tar­se en el manual Apache sobre la sintaxis del query parser.

Lucene también soporta la búsqueda inexacta sobre la base de la distancia de Le­ve­n­sh­tein, que recoge el número de cambios or­to­grá­fi­cos (re­em­pla­zar, insertar o eliminar) necesario para pasar de una cadena si­g­ni­fi­ca­ti­va de ca­ra­c­te­res a otra. Es decir: de “lupa” (sustituye p por n) a “luna” hay una distancia de 1 porque solo fue necesaria una co­n­ve­r­sión.

El usuario puede definir un valor que determine el alcance de las de­s­via­cio­nes del término de búsqueda original para que un término se tenga aún en cuenta en los re­su­l­ta­dos de búsqueda. Este valor se encuentra entre 0 y 1 (cuanto más se acerca a 1, más parecido ha de ser el resultado de la búsqueda a la palabra original). Si no introduce ningún valor, se sitúa por defecto en 0,5. El comando co­rre­s­po­n­die­n­te se parecerá a este:

Para definir un valor con más precisión (0,9, p. ej.) se introduce este comando:

Un esquema similar sigue la búsqueda por entorno, en la cual puede definirse la distancia a la que pueden situarse las palabras en el texto para seguir siendo re­le­va­n­tes. En la búsqueda “Alice in wo­n­de­r­la­nd” puede de­te­r­mi­nar­se que las palabras “alice” y “wo­n­de­r­la­nd” estén en un radio de tres palabras.

Lucene permite realizar búsquedas en Internet y dentro de los dominios. Los motores de búsqueda que cubren un amplio rango de páginas se denominan motores de búsqueda ho­ri­zo­n­ta­les. Entre estos se incluyen conocidos pro­vee­do­res como Google, Bing, Yahoo u otros como Du­c­k­Du­c­k­Go y Startpage. Un motor de búsqueda vertical, en cambio, se limita a un dominio, un tema o un público objetivo. Un motor de búsqueda es­pe­cí­fi­co para un dominio ayuda a los vi­si­ta­n­tes de un sitio web a encontrar textos u ofertas es­pe­cí­fi­cas. Ejemplos de bu­s­ca­do­res temáticos son los portales de re­co­me­n­da­cio­nes como Tri­pA­d­vi­sor o Yelp, pero también los bu­s­ca­do­res de empleo. Los motores de búsqueda es­pe­cí­fi­cos para un público objetivo se dirigen, por ejemplo, a los niños y jóvenes o a los cie­n­tí­fi­cos que buscan fuentes.

A través de crawlers web enfocados (focused crawlers), los motores de búsqueda ve­r­ti­ca­les en­cue­n­tran re­su­l­ta­dos más precisos. Una bi­blio­te­ca como Lucene, que divide su índice en clases según los pri­n­ci­pios de la taxonomía y los conecta ló­gi­ca­me­n­te por ontología, es la primera en permitir esta búsqueda de texto completo. Los bu­s­ca­do­res ve­r­ti­ca­les utilizan, además, filtros temáticos que limitan el número de re­su­l­ta­dos.

El índice de Lucene re­pre­se­n­ta un archivo escalable para búsquedas, si bien hay algunos pasos fu­n­da­me­n­ta­les y ru­ti­na­rios que no se realizan de forma au­to­má­ti­ca. La búsqueda vertical requiere un índice muy ra­mi­fi­ca­do. Es aquí donde entra en juego Apache Solr, que co­m­ple­me­n­ta a las funciones de la bi­blio­te­ca y se configura con comandos de una forma muy sencilla, incluso para pri­n­ci­pia­n­tes, en Java. El servlet ofrece muchas he­rra­mie­n­tas para co­n­fi­gu­rar un motor de búsqueda vertical para una página web y adaptarlo a las ne­ce­si­da­des de las visitas.

Ahora que ya cuentas con alguna in­fo­r­ma­ción básica sobre Lucene y el ámbito de apli­ca­ción de Solr, pasaremos a ver cómo funciona el servidor, cómo co­m­ple­me­n­ta a Lucene y cómo puedes trabajar con él.

El hecho de estar escrito en Java permite, como dijimos arriba, utilizar a Solr en cualquier pla­ta­fo­r­ma. Los comandos se escriben no­r­ma­l­me­n­te en HTTP (Hypertext Transfer Protocol) y para los archivos que se van a guardar se utiliza XML (Ex­te­n­si­ble Markup Language). Apache Solr también ofrece a los de­sa­rro­lla­do­res de Python y Ruby su conocido lenguaje de pro­gra­ma­ción a través de una API. En cambio, para aquellos que no­r­ma­l­me­n­te trabajan con la Notación de Objetos Ja­va­S­cri­pt (JSON), Ela­s­ti­c­Sea­r­ch pro­po­r­cio­na el entorno óptimo. Con una API, Solr también puede trabajar con este formato.

Aunque está basado en Lucene y encaja pe­r­fe­c­ta­me­n­te en su ar­qui­te­c­tu­ra, Solr también trabaja solo. Es co­m­pa­ti­ble con co­n­te­ne­do­res-servidor como Apache Tomcat.

In­de­xa­ción para re­su­l­ta­dos precisos en fra­c­cio­nes de segundo

Es­tru­c­tu­ra­l­me­n­te, el servlet se basa en un archivo invertido (inverted index). Solr utiliza la bi­blio­te­ca de Lucene para ello. Los archivos in­ve­r­ti­dos son un subtipo del índice de la base de datos y tienen la función de acelerar la re­cu­pe­ra­ción de in­fo­r­ma­ción. Dentro de la bi­blio­te­ca, el índice almacena co­n­te­ni­dos, que pueden ser palabras o números. Cuando un usuario busca cierto contenido en un sitio web, suele in­tro­du­cir uno o dos términos de búsqueda re­le­va­n­tes para el tema. En lugar de rastrear estas palabras en todo el sitio web, Solr recurre a la bi­blio­te­ca.

La bi­blio­te­ca indexa todas las palabras clave im­po­r­ta­n­tes casi en tiempo real y las vincula a los do­cu­me­n­tos del sitio web en los que se en­cue­n­tran estas palabras. Pero la búsqueda se limita ex­clu­si­va­me­n­te al índice. La lista de re­su­l­ta­dos muestra entonces todos los do­cu­me­n­tos que según el índice contienen esta palabra al menos una vez. Este tipo de búsqueda se co­rre­s­po­n­de con la búsqueda análoga en un libro: cuando se busca un de­te­r­mi­na­do término en el glosario, se encuentra la página o las páginas donde se encuentra y es ahí a donde se dirige el lector. Siguiendo el mismo principio, la búsqueda vertical muestra una lista de re­su­l­ta­dos con enlaces a los do­cu­me­n­tos.

Para que este proceso funcione sin problemas, cada vez que se añade un nuevo documento al catálogo del sitio web es necesario in­tro­du­cir todas las palabras clave y los metadatos (como autor o año de pu­bli­ca­ción) en la bi­blio­te­ca. Esto hace que el trabajo interno con Lucene resulte algo tedioso. Con Solr estos pasos pueden au­to­ma­ti­zar­se.

Re­le­va­n­cia y filtro

Apache Solr utiliza la ontología y taxonomía de Lucene para ofrecer re­su­l­ta­dos de búsqueda altamente precisos con la ayuda de las variables booleanas y el tru­n­ca­mie­n­to ma­te­má­ti­co, que ya son conocidos por Lucene. A la caché de Lucene, Solr añade una caché de nivel superior. Con esto, el servlet recuerda consultas de búsqueda fre­cue­n­tes, incluso si consisten en variables complejas, op­ti­mi­zá­n­do­se así la velocidad de búsqueda.

De cara a mantener a los usuarios en un sitio web, hay que ofre­ce­r­les una buena ex­pe­rie­n­cia de usuario. Esto incluye, en pa­r­ti­cu­lar, hacer las ofertas adecuadas. Por ejemplo, si tus lectores están buscando in­fo­r­ma­ción sobre api­cu­l­tu­ra, los textos que deberían aparecer entre los primeros re­su­l­ta­dos deberían tratar de los ciclos de vida de las abejas y de los métodos de crianza. Otras cue­s­tio­nes, p. ej., dónde comprar miel ecológica, no deberían formar parte de los re­su­l­ta­dos de la búsqueda o, al menos, no en lugares pro­mi­ne­n­tes.

En cualquier caso, estén los usuarios buscando un término es­pe­cí­fi­co o deban obtener su­ge­re­n­cias con enlaces internos al final de un artículo in­te­re­sa­n­te, es crucial que los re­su­l­ta­dos sean re­le­va­n­tes. Y para ga­ra­n­ti­zar que el usuario obtiene los re­su­l­ta­dos más re­le­va­n­tes a su búsqueda, Solr utiliza la medida “tf-idf”.

Apache Solr recopila e indexa datos (do­cu­me­n­tos) casi en tiempo real con el apoyo de Lucene Core. El documento es la unidad de medida decisiva tanto para la búsqueda como en el índice. El índice consta de varios do­cu­me­n­tos y estos, a su vez, de varios campos de texto. En una base de datos, una fila contiene un documento y una columna, los campos.

Si se acopla a Apache Zookeper a través de una API, Solr cuenta con un ad­mi­ni­s­tra­dor central que pro­po­r­cio­na si­n­cro­ni­za­ción, registros de nombres y di­s­tri­bu­ción de co­n­fi­gu­ra­cio­nes. Aquí se incluye, por ejemplo, un algoritmo en anillo que asigna un coor­di­na­dor (leader) a los procesos dentro de un sistema di­s­tri­bui­do. Este re­co­no­ci­do mediador también reactiva los procesos si se pierden los tokens y encuentra los nodos (or­de­na­do­res en el sistema) uti­li­za­n­do la detección de nodos (node discovery). Todas estas funciones ga­ra­n­ti­zan que tu proyecto pe­r­ma­ne­z­ca escalable.

Esto también significa que el motor de búsqueda funcione incluso bajo las co­n­di­cio­nes más duras. Como se ha me­n­cio­na­do an­te­rio­r­me­n­te, grandes páginas web, que almacenan y gestionan grandes ca­n­ti­da­des de datos, también utilizan Apache Solr a diario.

Si un solo servidor Solr no fuera su­fi­cie­n­te, con SolrCloud pueden co­ne­c­tar­se varios se­r­vi­do­res. Esto permite fra­g­me­n­tar los registros de datos ho­ri­zo­n­ta­l­me­n­te, lo que también se denomina fra­g­me­n­ta­ción (sharding). Para ello, debe dividirse la bi­blio­te­ca en fra­g­me­n­tos enlazados ló­gi­ca­me­n­te. Esto permite ampliar la bi­blio­te­ca más allá del espacio de al­ma­ce­na­mie­n­to di­s­po­ni­ble. Apache también re­co­mie­n­da cargar múltiples copias de su bi­blio­te­ca en di­fe­re­n­tes se­r­vi­do­res. Esto aumenta el factor de re­pli­ca­ción. Si llegan muchas pe­ti­cio­nes al mismo tiempo, éstas se di­s­tri­bu­yen entre los di­fe­re­n­tes se­r­vi­do­res.

La búsqueda de texto completo, que ya soportaba Lucene, Solr la amplía con más funciones, entre otras:

• Reajuste de términos también para grupos de palabras: el sistema detecta errores or­to­grá­fi­cos en la entrada y pro­po­r­cio­na re­su­l­ta­dos para una al­te­r­na­ti­va corregida.
• Joins (uniones): una mezcla entre el producto ca­r­te­siano (en la búsqueda se co­n­si­de­ran varios términos en cualquier orden) y la selección (solo se muestran los términos que cumplen una de­te­r­mi­na­da condición), es decir, una sintaxis compleja de variables booleanas.
• Agru­pa­ción de términos re­la­cio­na­dos te­má­ti­ca­me­n­te.
• Cla­si­fi­ca­ción en facetas: el sistema clasifica cada elemento de in­fo­r­ma­ción in­di­vi­dual según varias di­me­n­sio­nes. Por ejemplo, a un texto lo asocia con palabras clave como el nombre del autor, el idioma y la longitud del texto, junto a los temas de los que trata el texto, así como a una cla­si­fi­ca­ción cro­no­ló­gi­ca. La búsqueda en facetas permite al usuario utilizar varios filtros y obtener así una lista de re­su­l­ta­dos pe­r­so­na­li­za­da.
• Búsqueda con “comodín”: ¿un carácter re­pre­se­n­ta a un elemento in­de­fi­ni­do o a varios de estos elementos en una cadena? Para un carácter se utiliza “?” y para varios “*”. Por ejemplo, si se introduce el fragmento de una palabra más el comodín para varios ca­ra­c­te­res, como prof*, la lista de re­su­l­ta­dos incluirá todos los términos con esta raíz (profesor, pro­fe­so­ra­do, profesión), de modo que el usuario obtiene re­su­l­ta­dos para estos temas. La re­le­va­n­cia resulta de la de­li­mi­ta­ción del tema de su bi­blio­te­ca o de otras de­li­mi­ta­cio­nes de búsqueda. Por ejemplo, si los usuarios buscan "l?na", obtendrán re­su­l­ta­dos como luna, lana o lena, pero no, en cambio, palabras como liana o leona, ya que “?” solo sustituye a una letra.
• Re­co­no­ci­mie­n­to de texto en muchos formatos, desde Microsoft Word hasta PDF y contenido en­ri­que­ci­do indexado, pasando por editores de texto.
• Detección de di­fe­re­n­tes idiomas.

El servlet también puede integrar varios núcleos (core). Estos núcleos están co­m­pue­s­tos por índices de Lucene, de modo que el núcleo recopila toda la in­fo­r­ma­ción en una bi­blio­te­ca, incluidos los archivos de co­n­fi­gu­ra­ción y los esquemas. Con esto se define el co­m­po­r­ta­mie­n­to de Apache Solr. Si deseas utilizar ex­te­n­sio­nes, inserta en el archivo de co­n­fi­gu­ra­ción tus scripts o los plugins aportados por la comunidad.

Los re­qui­si­tos del sistema para Solr no son muy altos. Solo necesitas un entorno de ejecución Java SE a partir de la versión 1.8.0 y un sistema operativo Linux/Unix, macOS o Windows en di­fe­re­n­tes versiones, donde los de­sa­rro­lla­do­res ya probaron el servlet.

Comienza este tutorial de­s­ca­r­ga­n­do el paquete de in­s­ta­la­ción co­rre­s­po­n­die­n­te y ex­tra­ye­n­do el archivo.zip (paquete Windows) o el archivo.tgz (paquete Unix, Linux y OSX) a un di­re­c­to­rio de tu elección.

3. En esta imagen se observan varios paquetes de descarga di­s­po­ni­bles, en este caso, para la versión actual 8.0.0:

• solr-8.0.0-src.tgz es el paquete para de­sa­rro­lla­do­res, porque contiene el código fuente en el cual también se puede trabajar fuera de la comunidad GitHub.
• solr-8.0.0.tgz es la versión para usuarios de Mac y Linux/Unix.
• solr-8.0.0.zip contiene el paquete co­m­pa­ti­ble con Windows.
• En la carpeta changes/ se guarda la do­cu­me­n­ta­ción para esta versión.

Al escoger una de ellas, aparece una ventana de descarga. Deberás guardar el archivo. Cuando la descarga haya fi­na­li­za­do, clica en el botón de descarga de tu navegador y abre la carpeta de la descarga.

4. De­s­co­m­pri­me el archivo .zip o .tgz según sea tu caso. Si por ahora solo quieres conocer el programa, escoge un di­re­c­to­rio cua­l­quie­ra y guarda en él los archivos de­s­co­m­pri­mi­dos. Si, en cambio, ya tienes una idea precisa de cómo vas a emplear Solr, escoge el servidor que has previsto para ello o configura un entorno cloud clu­s­te­ri­za­do si ya sabes que lo vas a escalar hacia arriba (en el siguiente capítulo nos de­te­n­dre­mos en esto).

Introduce “cd //[ruta de al­ma­ce­na­mie­n­to]” en la línea de comandos para abrir el di­re­c­to­rio Solr e iniciar el programa. En nuestro ejemplo:

El servidor Solr corre ahora en el puerto 8983. El co­r­ta­fue­gos podría requerir tu co­n­fi­r­ma­ción (co­n­fí­r­ma­lo).

Si quisieras detener a Solr, introduce este comando:

Si Solr funciona bien, comienza a uti­li­zar­lo para conocerlo. La versión de prueba te permite iniciar el programa en uno de sus cuatro modos:

• SolrCloud (comando: cloud)
• Co­n­tro­la­dor para la im­po­r­ta­ción de datos (da­tai­m­po­rt handler) (comando: dih)
• Sin esquema (comando: sche­ma­le­ss)
• Ejemplo de­mo­s­tra­ti­vo basado en un fregadero de cocina (comando: te­ch­pro­du­cts)

Cada uno de estos cuatro modos cuenta con un esquema propio que se edita en la interfaz de esquemas. Para hacerlo, introduce este comando (el marcador [ejemplo] re­pre­se­n­ta a uno de los cuatro comandos de arriba):

6. Con esto, Solr empieza a eje­cu­tar­se en el modo elegido. Para ase­gu­rar­te, abre el informe de estado así:

7. Estos cuatro modos de muestra contienen ajustes básicos pre­de­fi­ni­dos. Si pones en marcha Solr sin ellos, tienes que definir tú mismo tanto el esquema como el núcleo. El núcleo guarda tus datos y sin él no puedes ni indexar datos ni buscarlos. Con este comando crearás un núcleo:

9. Fi­na­l­me­n­te, utiliza este comando para detener a Solr:

Solr pro­po­r­cio­na una sencilla he­rra­mie­n­ta de comandos llamada Post-Tool que permite cargar contenido, compuesto tanto por do­cu­me­n­tos para el índice como por co­n­fi­gu­ra­cio­nes de esquemas, en el servidor. Para poder hacerlo, la he­rra­mie­n­ta recurre a tu colección. Este es el motivo por el que, antes de empezar a trabajar, hay que pro­po­r­cio­nar siempre el núcleo (la colección).

En nuestro siguiente código de muestra, se­gui­re­mos la forma habitual. En <colección> deberás escribir el nombre de tu núcleo/colección. “–c” es el comando de “create”. Con él podrás crear un núcleo o una colección. Después podrás definir otras opciones o ejecutar comandos. Por ejemplo, con “–p” podrás escoger un puerto y con “*.xml” o “*.csv” cargar en tu colección todos los archivos con este formato (filas 2 y 3). Con el comando “–d” borrarás do­cu­me­n­tos de tu colección (fila 4):

Ahora, ya conoces algunos de los comandos básicos para Solr. Para saber cómo debes proceder en concreto para co­n­fi­gu­rar Apache Solr, uti­li­za­re­mos el ejemplo pre­de­fi­ni­do del fregadero de cocina.

1.Inicia Solr con la versión de prueba. Para se­le­c­cio­nar “kitchen sink demo” introduce el comando “te­ch­pro­du­cts”:

Solr se inicia por defecto en el puerto 8983. La terminal te informará de la creación de un nuevo núcleo para tu colección y el indexado de algunos archivos para tu catálogo. En la demo del “kitchen sink” deberías encontrar esta in­fo­r­ma­ción:

2. Solr ya se está eje­cu­ta­n­do y ha cargado algunos archivos XML en el índice con los que más tarde podrás trabajar. En los pasos que vienen a co­n­ti­nua­ción, deberías intentar guardar algunos archivos en el índice. Esto puede hacerse en la interfaz de usuario del panel de ad­mi­ni­s­tra­ción de Solr que vimos antes. Abre el servidor Solr en tu navegador. En nuestra versión de prueba Solr ha definido ya el servidor y el puerto. Escribe esta dirección en tu navegador: "http://localhost:8983/solr/".

Si ya definiste un nombre de servidor y un puerto, utiliza la siguiente sintaxis: "http://[no­m­bre­de­l­se­r­vi­dor]:[nu­me­ro­de­pue­r­to]/solr/".

Aquí, navega a la carpeta example/exam­ple­do­cs que incluye ya algunos archivos de muestra así como el archivo post.jar. Escoge el archivo que quieras incluir en el catálogo y utiliza a post.jar para incluirlo. Para nuestro ejemplo escogemos more_books.jsonl. Introduce el siguiente código en tu terminal:

Si Solr ha cargado tus archivos en el índice emitirá este mensaje:

3. Cuando se instala el servidor de búsqueda es co­n­ve­nie­n­te instalar también los archivos de co­n­fi­gu­ra­ción y el esquema, que en las versiones de prueba ya están definidos. Si, en cambio, trabajas en un servidor nuevo, tendrás que definir el juego de co­n­fi­gu­ra­cio­nes (Config-Set) y el esquema tú mismo.

El esquema (schema.xml) establece el número, el tipo y la es­tru­c­tu­ra de los campos en los do­cu­me­n­tos. Como se mencionó an­te­rio­r­me­n­te, en Lucene los do­cu­me­n­tos se componen de campos. Esta forma de es­tru­c­tu­ra favorece la búsqueda de texto completo. Solr trabaja con estos campos. Cada tipo de campo acepta cierto contenido (<date>, p. ej., solo acepta fechas en el formato año-mes-día-hora). Con el esquema puedes definir qué tipo de campo re­co­no­ce­rá el índice y cómo lo cla­si­fi­ca­rá. Si no lo haces, los do­cu­me­n­tos de­te­r­mi­na­rán los tipos de campo. Si en la fase de prueba esto puede resultar práctico, porque así puedes comenzar a llenar el catálogo, más adelante podría generar problemas.

Estos son algunos de los tipos de campo básicos de Solr:

• Da­te­Ra­n­ge­Fie­ld (indexa franjas te­m­po­ra­les y momentos exactos hasta el mi­li­se­gu­n­do)
• Ex­te­r­na­l­Fi­le­Fie­ld (extrae valores de una carpeta externa)
• TextField (campo para la entrada de texto)
• Bi­na­r­y­Fie­ld (campo para datos binarios)
• Cu­rre­n­c­y­Fie­ld indexa dos valores por separado, pero los muestra al usuario como uno solo: el campo guarda un valor numérico, p. ej., 4,50, y una moneda, p. ej., €, cada uno en un campo, pero el usuario los verá juntos, es decir, 4,50 €.
• StrField (UTF-8 y Unicode-String en un campo pequeño. Ni se analizan ni se re­em­pla­zan por un token.)

En la wiki de Solr en­co­n­tra­rás una exhau­s­ti­va lista de tipos de campo y otros comandos para ajustes de esquema.

Con el fin de definir tipos de campo, abre schema.xml en 'http://localhost:8983/solr/te­ch­pro­du­cts/schema', donde en­co­n­tra­rás los tipos de campo pre­de­fi­ni­dos en “Te­ch­pro­du­cts”. Una línea de comandos en el archivo XML describe las pro­pie­da­des de un campo a partir de atributos con más exactitud. Según la do­cu­me­n­ta­ción, Apache Solr es co­m­pa­ti­ble con estos atributos:

• field name (No puede estar vacío. Contiene el nombre del campo.)
• type (Introduce un tipo válido de campo. No puede quedar vacío.)
• indexed (Significa que se ha indexado. Si el valor es “true”, puede buscarse por este campo o cla­si­fi­car­lo.)
• stored (Describe si el campo se ha guardado. Si el valor es “true”, puede lo­ca­li­zar­se.)
• mu­l­ti­Va­lued (Si un campo contiene varios valores para un documento, aparece aquí el valor “true”.)
• default (Aquí se introduce un valor por defecto, que aparecerá cuando no se haya definido ningún valor para un documento nuevo).
• co­m­pre­s­sed (Pocas veces está co­n­fi­gu­ra­do como “false”, porque solo puede aplicarse en campos co­m­pri­mi­bles gzip. Para poder comprimir ha de figurar “true”.)
• omitNorms (No­r­ma­l­me­n­te está co­n­fi­gu­ra­do como “true”. Se ahorran normas para un campo y también espacio en disco.)
• te­r­mO­f­f­sets (Necesita más espacio. Guarda vectores junto con datos offset, es decir, co­m­ple­me­n­tos a la dirección de la memoria.)
• te­r­m­Po­si­tio­ns (Requiere más espacio porque guarda la posición de los términos junto con el vector.)
• te­r­m­Ve­c­to­rs (Por defecto está como “false”; si contiene “true”, almacena vectores de término.)

Las pro­pie­da­des de los campos pueden añadirse en el archivo schema.xml o uti­li­za­n­do un comando en la terminal. En el archivo, un tipo simple de campo aparece así:

Si utilizas la terminal de comandos, introduce un comando “curl”, define los atributos del campo y envíalo a través de la interfaz schema indicando la dirección del archivo:

4.Una vez co­n­fi­gu­ra­do el archivo schema, es el turno de la co­n­fi­gu­ra­ción de Solr, con la cual se es­ta­ble­cen los ajustes de la búsqueda. Los co­m­po­ne­n­tes más im­po­r­ta­n­tes son:

• Pa­rá­me­tros de caché de la consulta
• Gestor de la petición (request-handler)
• Lo­ca­li­za­ción del di­re­c­to­rio de los datos
• Co­m­po­ne­n­tes de búsqueda

Los pa­rá­me­tros de la caché de la consulta permiten tres tipos de caching: LRUCache, LFUCache y Fa­stL­RU­Ca­che. LRUCache utiliza un mapa hash enlazado y Fa­stL­RU­Ca­che recoge datos sobre un mapa hash co­n­co­mi­ta­n­te. Estos mapas hash procesan pe­ti­cio­nes si­mu­l­tá­nea­me­n­te, lo que permite al servidor de búsqueda producir re­s­pue­s­tas más ágiles en el caso de que las búsquedas tengan lugar de forma paralela. Fa­stL­RU­Ca­che lee los datos más rápido que el primero pero los añade más despacio.

El gestor de consultas procesa las so­li­ci­tu­des: lee el protocolo HTTP, busca en el índice y emite las re­s­pue­s­tas. La co­n­fi­gu­ra­ción de Te­ch­pro­du­cts contiene el gestor estándar para Solr. Los co­m­po­ne­n­tes de búsqueda se en­cue­n­tran enu­me­ra­dos en el gestor de pe­ti­cio­nes y son los que ejecutan la búsqueda. Por defecto, el gestor contiene lo si­guie­n­tes co­m­po­ne­n­tes:

• query (petición)
• facet (facetado)
• mlt (More Like This)
• highlight (mejores)
• stats (es­ta­dí­s­ti­ca)
• debug (erradicar errores)
• expand (ampliar la búsqueda)

Para el co­m­po­ne­n­te de búsqueda “More Like This” (mlt) escribe el siguiente comando:

Este co­m­po­ne­n­te encuentra do­cu­me­n­tos con contenido y es­tru­c­tu­ra similares. Consta como clase en Lucene. La consulta encuentra co­n­te­ni­dos para los usuarios de una página co­m­pa­ra­n­do la secuencia de ca­ra­c­te­res y los campos indexados.

Para co­n­fi­gu­rar la lista, abre el gestor de consultas:

En esta lista puedes añadir co­m­po­ne­n­tes definidos por ti mismo o cambiar los que contenga. Cuando un usuario que visite tu dominio in­tro­du­z­ca una consulta, la búsqueda asumirá estos co­m­po­ne­n­tes. El siguiente comando añade tu co­m­po­ne­n­te por delante del estándar:

Para añadirlo después:

Para renombrar los co­m­po­ne­n­tes estándar:

El di­re­c­to­rio de datos estándar se encuentra lo­ca­li­za­do en el di­re­c­to­rio de in­s­ta­n­cias del núcleo “in­s­ta­n­ce­Dir” bajo el nombre de “/data”. Si quisieras utilizar otro di­re­c­to­rio diferente, cambia la lo­ca­li­za­ción en so­l­r­co­n­fig.xml. Para hacerlo introduce una ruta de­te­r­mi­na­da o conecta el nombre del di­re­c­to­rio al núcleo (SolrCore) o el di­re­c­to­rio de in­s­ta­n­cias (in­s­ta­n­ce­Dir). Para la conexión al núcleo escribe:

Apache Solr pro­po­r­cio­na una nube de prueba que uti­li­za­re­mos para explicar cómo se configura un clúster en la nube.

1.Inicia la interfaz de usuario de la línea de comandos. Para iniciar Solr en el modo Cloud, escribe lo siguiente:

La demo se inicia.

2.Es­pe­ci­fi­ca cuántos se­r­vi­do­res (aquí: nodos) se han de conectar por medio de la nube. Esta cifra puede situarse entre [1] y [4] (en nuestro ejemplo hemos elegido [2]). La demo trabaja en una máquina, pero utiliza un puerto diferente para cada servidor que se ha de indicar a co­n­ti­nua­ción (la demo prescribe los números de puerto):

Asignados todos los puertos, el script muestra (como se observa arriba) los comandos para iniciar los se­r­vi­do­res.

3.Con los se­r­vi­do­res en marcha, se­le­c­cio­na un nombre para tu colección de datos (los corchetes señalizan comodines y no aparecen en el código).

4.Con SPLITSHA­RD crearás un fragmento a partir de esta colección que después podrás pa­r­ti­cio­nar aún más. De esta forma, se agiliza la búsqueda en los casos en que tengan lugar varias consultas al mismo tiempo.

Una vez fra­g­me­n­ta­da tu colección con SPLITSHA­RD, puedes repartir tus datos con ayuda de un rúter. Por defecto, Solr integra el rúter co­m­po­si­teID (router.key=co­m­po­si­teId).

En la interfaz su­b­di­vi­des el fragmento en dos partes. Estas dos pa­r­ti­cio­nes contienen la misma copia de los datos ori­gi­na­les. El índice las subdivide a lo largo de las áreas se­cu­n­da­rias recién creadas.

5.En el último paso se es­pe­ci­fi­ca el nombre del di­re­c­to­rio de co­n­fi­gu­ra­ción. Puedes escoger entre sample-te­ch­pro­du­cts-configs y _default. Este último no fija ningún esquema, de modo que si lo eliges, tendrás que ajustarlo tú mismo. Con el siguiente comando des­ac­ti­vas la función sin esquema de _default para la interfaz de SolrCloud:

Con él impides que los campos, a la vista de los primeros co­n­te­ni­dos, creen esquemas in­co­m­pa­ti­bles con el resto de archivos. Dado que, para esta co­n­fi­gu­ra­ción, necesitas utilizar el método HTTP POST, no puedes utilizar la barra de di­re­c­cio­nes del navegador. “localhost:8983” equivale al primer servidor. Si has elegido un número de puerto diferente, has de añadirlo aquí. En [_nombre_de_la_colección] escribe tu nombre elegido.

Tu nube Solr ya está co­n­fi­gu­ra­da. Si quieres ver si la nueva colección se muestra co­rre­c­ta­me­n­te consulta el estado de nuevo:

En la interfaz de ad­mi­ni­s­tra­ción obtendrás una vista más precisa sobre la di­s­tri­bu­ción de tus fra­g­me­n­tos. La dirección se compone del nombre de tu servidor junto con el número de puerto y la conexión a SolrCloud de esta forma: "http://no­m­bre­de­l­se­r­vi­dor:nú­me­ro­de­pue­r­to/solr/#/~cloud"

Apache Solr ya cuenta con algunas ex­te­n­sio­nes. Se trata de los llamados “handler” (gestores o co­n­tro­la­do­res). Un poco más arriba ya vimos al gestor de pe­ti­cio­nes. Lucene (y Solr) también soporta algunos scripts nativos como la clase “analyzer” y la clase “si­mi­la­ri­ty”. Los plugins se integran en Solr con un archivo JAR. Si has creado tus propias ex­te­n­sio­nes que in­ter­ac­túan con in­te­r­fa­ces Lucene, deberías añadir los archivos lucene-*.jars de tu bi­blio­te­ca (solr/lib/) en el tipo de clases con el que compilas el código fuente de tu plugin.

Este método funciona si solo utilizas un núcleo. Si usas la SolrCloud, crea una bi­blio­te­ca co­m­pa­r­ti­da para los archivos JAR. Crea para ello un di­re­c­to­rio con el atributo “sharedLib” en el archivo solr.xml en tu servlet. Este es un método simple para cargar plugins en núcleos:

Si has co­n­s­trui­do tu propio núcleo, crea un di­re­c­to­rio para la bi­blio­te­ca con el comando “mkdir” (en Windows, “md”) de esta forma:

Si solo estás probando Solr con alguna de las demos, navega en cambio a “example/solr/lib”. En ambos casos te en­co­n­tra­rás en el di­re­c­to­rio de la bi­blio­te­ca de tu di­re­c­to­rio de in­s­ta­n­cias. Aquí podrás guardar los archivos JAR de tus plugins.

Otra opción, a la que se puede recurrir cuando, por ejemplo, no se tiene éxito en el co­n­te­ne­dor servlet con la primera variante, consiste en utilizar el método de las versiones antiguas de Solr.

• De­s­co­m­pri­me el archivo solr.war.
• Añade al di­re­c­to­rio WEB-INF/lib el archivo JAR con la clase que has creado. El di­re­c­to­rio se encuentra en la web app siguiendo esta ruta: server/solr-webapp/webapp/WEB-INF/lib.
• Vuelve a comprimir el archivo WAR mo­di­fi­ca­do.
• Aplica tu archivo solr.war.

Si amplías la bi­blio­te­ca con una opción “dir”, esta se encarga de añadir todos los archivos dentro de cada di­re­c­to­rio a la ruta de la clase. Con “regex=” se excluyen todos los archivos que no cumplen con las normas “regex”.

Si vas a de­sa­rro­llar el script de tu plugin, para el entorno Java se re­co­mie­n­da entre otros el Lisp-Dialekt Clojure. Este lenguaje de pro­gra­ma­ción soporta también el de­sa­rro­llo in­ter­ac­ti­vo de programas. Otros lenguajes integran sus pro­pie­da­des nativas y Clojure las pone a di­s­po­si­ción en la bi­blio­te­ca. Esta me­to­do­lo­gía de trabajo se ajusta al uso del servlet Solr.

El lenguaje de pro­gra­ma­ción y scripts Groovy es co­m­pa­ti­ble con la ti­pi­fi­ca­ción dinámica y estática en la máquina virtual Java. El lenguaje está basado en Ruby y Pithon y se compila en código Byte Java. Esto hace que pueda eje­cu­tar­se en un script. Groovy contiene algunas ca­ra­c­te­rí­s­ti­cas que amplían las fa­cu­l­ta­des de Java. El lenguaje integra, por ejemplo, una plantilla simple para crear código en SQL o HTML. Groovy Syntax ofrece, asimismo, ex­pre­sio­nes muy fre­cue­n­tes o campos de datos para listas pre­pa­ra­das para usarse. Si editas JSON o XML para tu servidor de búsqueda Solr, Groovy ayudar a mantener la sintaxis limpia e in­te­li­gi­ble.

Cuando se trata de motores de búsqueda de código abierto, Solr y Ela­s­ti­c­sea­r­ch, ambos basados en la bi­blio­te­ca Java de Apache Lucene, están siempre a la cabeza en pruebas y encuestas. Lucene, indexando con fle­xi­bi­li­dad la in­fo­r­ma­ción y pro­po­r­cio­na­n­do respuesta a consultas complejas, co­n­s­ti­tu­ye apa­re­n­te­me­n­te una base estable con la que ambos bu­s­ca­do­res ofrecen servicios co­n­vi­n­ce­n­tes. Cada uno de los proyectos cuenta también con el apoyo de una comunidad activa.

El equipo de de­sa­rro­llo de Ela­s­ti­c­sea­r­ch trabaja con GitHub, mientras que Solr trabaja en la Fundación Apache. En co­m­pa­ra­ción, el proyecto Apache cuenta con una tra­ye­c­to­ria más larga, con una comunidad que ha estado do­cu­me­n­ta­n­do todos los cambios, ca­ra­c­te­rí­s­ti­cas y errores desde 2007. La do­cu­me­n­ta­ción de Ela­s­ti­c­sea­r­ch no es tan completa y por este motivo ha recibido críticas. Sin embargo, Ela­s­ti­c­sea­r­ch no se queda atrás en términos de usa­bi­li­dad.

Con Ela­s­ti­c­sea­r­ch puede co­n­s­trui­r­se una bi­blio­te­ca en pocos pasos. Para las pre­s­ta­cio­nes es­pe­cia­les se necesitan plugins Premium con los que puede ad­mi­ni­s­trar­se la co­n­fi­gu­ra­ción de seguridad, su­pe­r­vi­sar­se el servidor de búsqueda o ana­li­zar­se las métricas. El servidor de búsqueda también reúne una familia bien coor­di­na­da de productos a su alrededor. Bajo la etiqueta Elastic-Stack and X-Pack se obtienen algunas funciones básicas gratis. Sin embargo, los paquetes Premium solo están di­s­po­ni­bles con una su­s­cri­p­ción mensual con una licencia por nodo. Solr, por otro lado, siempre es libre, in­clu­ye­n­do ex­te­n­sio­nes como Tika y Zookeeper.

La mayor di­fe­re­n­cia entre los dos motores de búsqueda radica en su enfoque principal. Puedes utilizar tanto Solr como Ela­s­ti­c­sea­r­ch para pequeños conjuntos de datos, así como para grandes datos que se di­s­tri­bu­yen en múltiples entornos, pero Solr se ha centrado en la búsqueda de texto, mientras que el concepto de Ela­s­ti­c­sea­r­ch combina la búsqueda con el análisis. El servlet procesa métricas y registros desde el principio, manejando estos volúmenes de datos fá­ci­l­me­n­te, pues el servidor integra núcleos y fra­g­me­n­tos di­ná­mi­ca­me­n­te desde la primera versión.

Si Ela­s­ti­c­sea­r­ch superaba con esto en su momento a su principal rival, hace algunos años que la nube de Solr también permite la cla­si­fi­ca­ción de facetas. Con datos dinámicos, Ela­s­ti­c­sea­r­ch sigue estando li­ge­ra­me­n­te por delante. A cambio, el co­m­pe­ti­dor puntúa con datos estáticos. Produce re­su­l­ta­dos es­pe­cí­fi­cos para la búsqueda de texto completo y calcula los datos con exactitud.

Estos dos conceptos di­fe­re­n­tes también se reflejan en el caching. Ambos pro­vee­do­res ofrecen caché de consulta, lo que significa que cuando una consulta utiliza variables booleanas complejas, ambas almacenan los elementos de índice so­li­ci­ta­dos en segmentos. Estos pueden fu­sio­nar­se en segmentos más grandes. Sin embargo, si solo cambia un segmento, Apache Solr debe invalidar toda la caché y re­ca­r­gar­la. Ela­s­ti­c­sea­r­ch limita este proceso al segmento afectado. Esto ahorra espacio de al­ma­ce­na­mie­n­to y tiempo.

Si trabajas re­gu­la­r­me­n­te con XML, HTTP y Ruby, no te será difícil aco­s­tu­m­brar­te a Solr. JSON se añadió más tarde a través de una interfaz. Es por eso que el lenguaje y el servlet no encajan pe­r­fe­c­ta­me­n­te todavía. Ela­s­ti­c­sea­r­ch, en cambio, se comunica de forma nativa a través de JSON. Otros lenguajes como Python, Java,.NET, Ruby y PHP están incluidos en el servidor de búsqueda por medio de una interfaz similar a REST.