No hace mucho, trabajando en un proyecto para una empresa, tuvimos un problema de performance con el tiempo de respuesta al momento de realizar queries sobre la base de datos Oracle. Luego de varias mediciones del tiempo de respuesta y estadísticas sobre queries que mayor tiempo de respuesta consumían y no consiguiendo mejorar ostensiblemente con la optimización de los queries, decidimos, a sugerencia del gurú Pablo “Calé” Santa Cruz, investigar y llevar a la práctica la utilización de SQLite como cache de datos. De aquí en adelante hablaremos de que se hizo y como se hizo para lograr la optimización, especialmente cuando se trata con volúmenes interesantes de datos.
Para la implementación de esta mejora recurrimos a un driver jdbc nativo de java para SQLite y la versión que utilizamos es sqlitejdbc-v056.jar.
Antes del inicio del proceso, primeramente realizamos un volcado completo de los datos de la tabla en donde los queries arrojaban tiempos moderadamente altos, a nuestra base de datos SQLite que actuará de cache, y que al tratarse de consultas iterativas, representaban un tiempo total considerablemente costoso en todo el proceso. Es importante destacar en este punto que la replicación de los datos se realizó en un tiempo bastante menor del que esperábamos para sorpresa nuestra, primera buena impresión.
Ya con los datos enteramente replicados en una tabla temporal de nuestra base de datos SQLite nos detuvimos a medir los tiempos de respuesta de los queries sobre nuestro cache y arrojaron resultados sorprendentes, por cada proceso iterativo, hemos ahorrado aprox. 86% del tiempo de respuesta o lo que equivale a 1/6 del tiempo de procesamiento cuando la consulta se realizaba puramente sobre la base de datos Oracle.
En conclusión, cuando se trata de manejar volúmenes grandes de datos y el tiempo de respuesta de la base de datos es crítico en procesos iterativos y por sobre todo elevado, es conveniente recurrir a este tipo de implementación que nos permita mejorar ostensiblemente el tiempo de procesamiento.
Buenisimo!
ReplyDeleteUna consulta como manejan la coherencia de los datos?
Pueden dar un poco mas de detalles de la implementacion?
Me imagino que ha de ser una cache LRU con tamano fijo, pero lo que me gustaria saber es como invalidan la cache cuando se actualiza la BD
Saludos y que grande Roshka siempre innovando!
Javier, realmente no es una política LRU, sino más bien es un reemplazo total de los datos del cache cada vez que corre el proceso, es decir con un criterio de búsqueda obtenemos los datos de la base de datos Oracle y hacemos un drop sobre la tabla SQLite que actúa de cache para llenarlo de vuelta.
DeleteAsí mismo. Además, hay que destacar que es un Cache puntual para una aplicación específica, cuya lógica de negocios permite que se tenga este cache específico de datos. No es una solución genérica, pero definitivamente fue un CACHE que hizo bajar tremendamente los tiempos de un proceso muy complejo.
DeleteEntiendo, cada aplicacion tiene un use case distinto que permite utilizar una u otra tecnica de optimizacion.
ReplyDeleteMuy interesante, gracias por tomarse el tiempo para responder.
Out of topic: Existe algun lugar fisico o virtual para poder discutir este tipo de cosas? Soy un seguidor del blog de Roshka dev team y veo que siempre tienen algo interesante que contar, como se podrian llevar estas discusiones a un publico mas general? Creo que hace falta esto en PY
Saludos!
Una opción valida al SQLite, para consultas iterativas es usar el feature de Result Cache de Oracle 11gR2 (si es el caso). Lo he utilizado y el tiempo de respuesta llega a los ordenes tambien mencionados. Ya que la sentencia SQL se parsea y ejecuta una única vez. Los resultados son cacheados y la consulta no se reejecuta hasta que los bloques de BD sufran alguna modificación. A modo de ejemplo puedo dar fe que una consulta bastante grosa no se reejecuta desde hace meses, debido a que los bloques afectados no sufrieron cambios. Ademas con este feature el problema de la consistencia no se presenta dado que todo esta bajo el control de DBMS. Obviamente la selección de un consulta candidata al Result Cache no es a libre albedrío.
ReplyDeleteEsa definitivamente es una alternativa. El único tema acá es que, por cómo está definida la lógica de negocios, se hacen muchísimos queries a la base de datos a lo largo de un gran procedimiento. Esto hace que hayan muchos "round-trips" a la base de datos, que con el SQLite por lo menos te librás del I/O de red. Hay que aclarar que el query no tenía baja performance en el Oracle. De hecho la performance era totalmente aceptable. El problema fue justamente la cantidad enorme de queries que se hacían.
Delete