Hace aproximadamente 1 año estoy liderando un proyecto de migración de APIS para un Front end de Facturación.
Las APIs al principio fuimos contra la Base, y cuando vimos que los tiempos claramente no eran los esperados ( luego supimos que unos de los requerimientos de las APIS era que su performance por request no deberían superar los 0.1 seg) tuvimos que implementar una solución de Elastic Search.
Partimos de un esquema de arquitectura que nos permitiese no solo la carga Online de manera escalable, si no que ademas pudiesemos hacer cargas de datos históricos, nosotros los llamamos "Cargas Iniciales", para que el usuario pueda ver su histórico de Facturación.
En ese tiempo descubrimos una serie de cuestiones y experiencias con ES que me pareció interesante compartirlo con uds.
* El modelado de ES a nivel de cluster es simplemente caprichoso. No existe una receta que nos indique cuál es el mejor modelado. Si podemos saber que los indices , cuando son muy grandes, requieren una gran cantidad de Yardas para que performe ( una yarda se desempeña de manera optima con hasta 10G de información. Nosotros llegamos a un esquema de más de 100 yardas).
El modelado iterativo sucederá inevitablemente ; para ello tener en claro los modelos de Procesos de Cargas, ya que lo tendremos que rehacer varias veces a nuestro cluster hasta que la performance sea la esperada.
* Rootear es fundamental. Los tiempos se mejoran mucho si se agrega este parámetro. Puede haber indicio de como armemos nuestros indices no lo necesitan. Pero si necesitan velocidad en cientos de gigas, esto es necesario
* El Scroll es una herramienta que no debemos olvidar.Para hacer consultas paginadas donde se necesita recolectar cientos de datos , pero no queremos penalizar la performance, hay que usarlo.
* Programar OO y TDD ayuda, y mucho. Code Reviews tambien. ES es una herramienta poderosa. Pero Armar las consultas pueden ser por demás engorrosas y muchas veces poco elegantes. El esquema de builders que utiliza no es el mas bello. Por lo que conviene ser prolijo a la hora de diseñar, y conocer claramente que escenarios queremos soportar.
* Las modificaciones no son baratas: tratemos siempre de entender claramente los escenarios funcionales. Si bien un modelo iterativo es el que mas me agrada, una falla de concepción del requerimiento del usuario impacta muchas veces en rehacer el indice, o por que no todo el elastic. Tener claro los conceptos ( para tener claros los test ) tendrá un claro impacto en nuestro ES. Saber cuantos usuarios lo usaran , cuanto volumen aproximado, cual es la consulta que mas nos importa son "hints" importantísimos para poder hacer un modelo en el cual las modificaciones no nos peguen de lleno y nos hagan re hacer la infraestructura.
* Juniors... con cuidado!. Parece tan simple usar elastic, parece fácil, pero no. Requiere idealmente que los desarrolladores sean maduros para encarar el uso de la herramienta. Desde la concepción Funcional del problema hasta donde implementar la solución es fundamental tener a alguien que pueda entender desde la infraestructura hasta los vericuetos funcionales del problema. Esto que menciono, tan abstracto, es lo que realmente lo hace facil y escalable. Cualquier falla en esto implicará que los diseños no sean los mejores, que los refactors sean en extremo costosos. Creo igualmente que esto en un punto aplica a cualquier proyecto. Tener un buen "counselor" en esto es casi menester. Si no, deberemos saber que haremos multiples refactors hasta lograr la implementación que responda a nuestros requerimientos siempre será cuestión de varias iteraciones.
* Migrar de Elastic , de versiones , sobre todo en productivos; con mucho cuidado. Es factible migrar datos de un Elastic a otro ( nos toco hacerlo de una versión 1.4 a una versión 1.7 ) . Hay que tener mucho cuidado con la situación de datos que vienen online y el pisado de datos que vienen desde el "otro" Elastic. Concurrencia es un gran Issue y riesgo a tener en cuenta.
Este es el enfoque desde un equipo que se luchó/lucha para lograr tener productivo un esquema con ES como motor de datos.
Si alguien tiene otras experiencias , con gusto escuchare. Si me acuerdo mas diatribas sobre lo mismo , Tambien lo volcaré.
Gracias por Pasar.
No hay comentarios:
Publicar un comentario