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:

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:

Limitaciones:

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:

Por contra:

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:

Aunque encontramos ciertas limitaciones y carencias:

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:

Por contra, encontramos diferentes factores a tener en cuenta:

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.

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.