Búsqueda semántica en NoSQL, ¿qué herramienta usar en cada caso?

Hasta hace poco, se tendía a utilizar el mismo tipo de tecnología de almacenamiento sin tener en cuenta el uso que se le fuera a dar a la información guardada. En los últimos años estamos viviendo un cambio radical de pensamiento en el que el uso de la información cobra importancia y no paran de aparecer soluciones centradas en solventar problemas muy específicos (cache, datos fuertemente relacionados, búsquedas textuales...).

Todo ello sin dejar de lado los problemas clásicos a los que ya se enfrentaban: gran capacidad de almacenamiento y procesamiento, tiempos de respuesta ínfimos, escalabilidad, flexibilidad...

Resumiendo, venimos de una situación en la que, en muchos casos, se usaba un único gestor de bases de datos, Oracle, SQL Server, DB2, MySQL… a un escenario en el que pueden convivir Redis, Elastic, MongoDB, Neo4j o Cassandra, por citar algunos ejemplos.

Cada una de estas tecnologías resuelve de manera sobresaliente casos de uso concretos y es por ello que en proyectos con grandes exigencias de rendimiento y funcionalidad, se ha hecho uso de ellas, pero… ¿qué ocurriría si con una sola tecnología pudiéramos cubrir razonablemente todas las necesidades de nuestra aplicación en cuanto al acceso y almacenamiento del dato?

Simplificar la arquitectura del dato de nuestro producto y aprovechar plenamente los componentes ya existentes puede ser beneficioso en términos de costes, complejidad y mantenibilidad. No obstante, habrá situaciones en las que el coste de esta especialización esté más que justificado.

Muchos productos se han separado sutilmente del camino de la especialización para convertirse en herramientas que resuelven con éxito un mayor número de casos de uso, lo que facilita, en caso de necesitarse, que reduzcamos el número de elementos de nuestra arquitectura de almacenamiento.

En esta ocasión, hablaremos de la capacidad de hacer búsquedas textuales, pero extenderemos este razonamiento a otras funcionalidades interesantes como el uso de grafos o caches.

Si hablamos de búsquedas semánticas, el rey indiscutible es ElasticSearch. Han sabido desarrollar un producto completo, de alto rendimiento y con multitud de funcionalidades y características que facilitan la labor de desarrolladores y administradores de sistemas y nos acercan a las necesidades reales del producto. Además, Elastic, ha creado todo un ecosistema de aplicaciones a su alrededor completando su oferta.

Las principales características que reúne ElasticSearch son:

• Simple. Tanto en configuración e instalación, cómo desarrollo.
• Alta disponibilidad y tolerante a fallos. Detecta fallos en el cluster y garantiza que no afecten a pérdida del servicio.
• Rápido y escalable horizontalment****e. Gracias a estructuras de árboles binarios y protocolos de comunicación entre nodos.
• Potente y versátil. Cubre la mayor parte de casos de uso de manera óptima.

En cuanto a funcionalidad y características, son el rival a batir, por tanto si el núcleo de tu negocio gira en torno a esta funcionalidad, lo más adecuado es decantarse por Elastic.

No obstante, hay un amplio espectro de situaciones en las que se pueden requerir ciertas capacidades de búsqueda sin que supongan el centro de nuestro producto o aplicación y por tanto podamos explorar otras alternativas que simplifiquen nuestra arquitectura del dato.

Couchbase, MongoDB, OrientDB o PostgreSQL son bases de datos NoSQL que han ampliado sus funcionalidades para, una vez resuelto el problema de la escalabilidad horizontal y los diferentes retos de NoSQL, abordar características avanzadas y que les permita posicionarse como opción en un mayor número de situaciones. Aún siendo esta su tendencia, no todas ellas están en el mismo punto.

MongoDB

MongoDB es probablemente la más conocida de las cuatro tecnologías que comentamos, pero ello no la convierte necesariamente en la mejor alternativa en este escenario. Veamos qué nos ofrece:

• Índices de texto.
• Soporta 21 lenguajes ordenando en función del lenguaje elegido.
• Tokenización y Stemming.
• Permite ordenación por relevancia semántica.
• Se pueden atribuir pesos a los campos del documento.
• Facetado y búsqueda geoespacial a través del framework de agregación.

Limitaciones:

• Sólo podemos tener un índice de texto por colección.
• No se pueden personalizar el Tokenizado ni el Stemming, se aplica uno asociado al lenguaje elegido en el índice.
• Los índices de texto ocupan más almacenamiento que los índices normales.

Couchbase

Couchbase es el producto que más está creciendo y más acogida ha experimentado en los últimos meses. Ofrece un gran rendimiento y diferentes facilidades para desarrolladores y administradores. El servicio de Full Text Search (FTS) está basado en Bleve, una librería para la búsqueda y el análisis de texto escrita en Go.

Algunas de sus características son:

• Se integra con N1QL a la perfección.
• Podemos crear índices de texto sobre múltiples campos.
• Soporta 18 lenguajes, entre ellos el chino.
• Tokenización y Stemming personalizado. Además de incluir algunos por defecto, podemos definir nuevos.
• Diferentes tipos de búsqueda: facetados, geoespacial, con expresiones regulares, conjunciones, disyunciones...
• Ordenación por diferentes campos.
• La relevancia de la búsqueda, se calcula no sólo sobre campos sencillos, también sobre Arrays.
• Boosting, podemos modificar la relevancia de los campos en la propia query.

Por contra:

• La interfaz de administración no es muy amigable.
• No soporta por defecto búsquedas textuales en japonés o chino, entre otros.
• La construcción de índices puede consumir mucho tiempo en función de los campos. Por defecto indexa todos los campos.

PostgreSQL

PostgreSQL se ha visto siempre como una base de datos relacional, pero lo cierto es que también puede ser utilizada como NoSQL almacenando otro tipo de información (por ejemplo JSON), y escalando horizontalmente gracias a soluciones distribuidas. En el ámbito de las búsquedas semánticas puede ser otra alternativa.

Nos ofrece:

• Soporte para 15 lenguajes.
• Asignación de pesos a campos y ordenación de la búsqueda en base a los mismos.
• Stemming y Tokenizado en base al idioma elegido.

Aunque encontramos ciertas limitaciones y carencias:

• No soporta lenguajes asiáticos como el japonés o el chino.
• Asignación de pesos limitadas, solo hay 4 valores posibles. Por lo que las opciones de Boosting son limitadas.
• Añade complejidad a nuestro modelo de datos.
• No se pueden personalizar el Stemming ni el Tokenizado de los textos.
• La forma de trabajar con búsquedas semánticas no es intuitiva.

OrientDB

OrientDB es otra de las opciones que tenemos cuando entramos en el ámbito de las bases de datos NoSQL multimodelo. Su solución de búsqueda semántica se basa en Lucene Engine, incorporado desde la versión 2.0 y que nos permite entre otras cosas:

• Creación de índices sobre múltiples atributos.
• Parametrización de analizadores para el índice y la consulta.
• Se puede personalizar el analizador a nivel de campo tanto para índice como para consultas.
• Optimización de Lucene Engine en la creación de índices.
• Uso de Lucene Spatial vía plugin para búsquedas geométricas: puntos, líneas, polígonos, etc.
• Uso de un lenguaje SQL-like para el manejo de este tipo de datos.

Por contra, encontramos diferentes factores a tener en cuenta:

• Muy ligado a la implementación de Lucene Engine.
• Sintaxis compleja y poco intuitiva.
• No facilita búsquedas facetadas.

Conclusiones

Teniendo todo esto en cuenta, la próxima vez que vayamos a plantearnos una arquitectura para nuestros datos o que necesitemos incluir funcionalidades nuevas a un producto ya existente, podremos elegir la mejor solución sin tener que incurrir en componentes adicionales.

No obstante, por el momento, todas ellas se encuentran lejos de alcanzar a Elastic en versatilidad, funcionalidad y flexibilidad. Por lo que si contamos con un equipo experto, que reduzca la curva de aprendizaje y maneje adecuadamente la mantenibilidad de la solución, a la vez que los costes no son una variable a tener en cuenta, no lo pensemos dos veces: Elastic se hará un hueco propio en nuestra arquitectura.