¿Polyglot Persistence, te suena? No hemos querido traducir el término por algo como persistencia políglota, porque no suena demasiado bien … ¡ni siquiera en inglés!
Es un término que cada vez se escucha más y que resume muy bien el estado del arte a la hora de diseñar soluciones de negocio en un mundo cada vez más digitalizado y a escala de Internet.
¿Y lo de los zapatos? Pues que creo que es una buena manera de decir lo mismo, voy a explicarme:
¿Qué es Polyglot Persistence?
¿Correrías una maratón con este zapato? ¿Verdad que no? Pero si sirve para andar … ¿por qué no puedo usarlo para correr?
Bien, hasta ahora hemos tenido un tipo de zapato más o menos estándar, que servía más o menos para todo: las Bases de Datos Relacionales. Estas bases de datos han sido el corazón de miles de aplicaciones durante muchísimos años.
Se han usado para soluciones de todo tipo, tanto aplicaciones transaccionales como analíticas, y ciertamente han tenido un éxito que será difícil de igualar. De hecho, los fabricantes de este tipo de soluciones se han convertido en auténticos gigantes del software.
Pero esto ha cambiado los últimos años con internet … o casi podría decir con Google. Esta plataforma ha sido pionera a la hora de inventar artefactos que dan servicios de valor añadido muy alto y que responden a las necesidades del usuario en milisegundos.
Los más mayores podremos recordar cómo antes no era raro esperar bastantes segundos, o incluso minutos, para que un sistema devolviera una respuesta. Ahora eso es impensable. Google nos da la mejor ruta entre París y una pequeña calle del último pueblo de Alemania en milisegundos usando su Google Maps.
Eso no se consigue usando una BD relacional. Tampoco se consigue hacer un motor de búsqueda gestionando los datos en una BD relacional. Esto es precisamente el concepto de Polyglot Persistence, usar el mejor sistema gestor de datos para cada caso de uso particular.
Cuando tenemos necesidades de búsqueda, usaremos una BD orientada a esta necesidad, como Solr o Elastic Search, y cuando tengamos necesidad de gestionar los datos de los productos, seguramente será más eficaz usar una BD de tipo documental, como Mongo DB o Couch DB.
Ejemplo de Polyglot Persistence
La mejor manera de entender esto es con un ejemplo. Esto es aplicable a cualquier eCommerce, así que usaremos uno bastante conocido, zara.com.
Lo primero que ve el usuario es un sistema que tal como va escribiendo va sacando resultados. Por ejemplo, ponemos “zapatos” y el propio buscador nos da opciones “zapatos mujer”, “zapatos hombre”, … incluso nos ayuda en caso de que nos equivoquemos al escribir ¿qué rabia da verdad? Esa sensación que el sistema sabe escribir mejor que nosotros …
Vamos a lo importante. ¿qué tipo de tecnología está detrás de este buscador? Seguro que habéis adivinado que no es una BD relacional. Efectivamente, es una BD pero orientada a búsquedas, un sistema de indexación de datos potente como Elastic Search.
Cuando escogemos una categoría, como “zapatos de mujer” nos aparecen en milisegundos unos cuantos zapatos, con su foto, toda la información correspondiente, … y ¿de dónde vienen estos datos? De nuevo, seguro que habéis adivinado que no están guardados en un relacional. Es muy probable que estén en una BD documental como MongoDB.
En cuanto pinchamos sobre uno que nos guste, en la parte de abajo, existe un “completa tu look”, que no es más que una recomendación de productos relacionados con el que estamos comprando.
De nuevo este motor de recomendación no está funcionando sobre un relacional, sino que en este caso es un grafo, como Neo4j. Esta recomendación es una consulta compleja que está adaptada a cada usuario según su perfil, compras realizadas por las personas que conoce, …
Y ¿dónde está la BD relacional? ¿acaso ha desaparecido? La respuesta es NO, en absoluto. La BD relacional sigue teniendo un papel importante en nuestro eCommerce, y es en toda la gestión de la transacción, es quien guarda de manera eficiente nuestro proceso de compra, la gestión del carro de la compra y del proceso de pago en particular.
Conclusión
Las bases de datos de grafos como Neo4j, así como las de búsqueda como Elastic Search, no han venido para eliminar las BD relacionales tradicionales.
Lo que han permitido es generar soluciones novedosas que no se podían llevar a cabo hasta ahora, y sí que van a sustituirlas en algunas aplicaciones en las que su resultado era ineficiente.
