Re: alguna base de datos abierta

El 09-08-23 a las 12:44, Fernando Romo escribió:
> Estimado Enrique,
>
> Creo que el acercamiento debe ser pro-procesar información para llevar
> a cabo la consolidación de datos estratégicos
>
> El termino de esto se le llama “PermaComputation”, que en términos
> sencillos es almacenar los resultados de datos previamente calculados
> para evitar uso de recursos repetidamente.
>
> En mi caso hice un algoritmo que le llamo “Cache diferencial”, que
> consiste en procesar por ventanas una muestra de la información, si no
> existe un registro previo, insertarlo y si existe, leerlo y actualizarlo.
>
> He usado esto para el manejo de 650 sucursales de una conocida
> pizzería y con esto damos los datos de manera rápida a todas las áreas
> gerenciales, resaltando los llamados “kpi” (key performance indicator)
>
> La técnica de Cache diferencial se puede usar en cualquier BD y
> lenguaje, consiste en generar tablas  de cache (por hora, día, més,
> etc) que te permite acceder a los resultados previamente calculados
>
> Por ejemplo:
>
> Tomando en cuenta que tengo una tabla con inmformacieon de actividad
> telefónica con unos 228,272,901 registros, el tiempo que tarda en
> consultar la info base en un querrá puede ser de muy alto vs el cache
>
> queue_log , que es la tabla base, si hago un query  y le pongo
> “explain analyze” para ver los tiempos de ejecucieontenemos estos
> resultados:
>
> Tabla           registros          tiempo
> cache_year      2,711 Execution Time:         3.580 ms (      1x) */
> ache_month      24,804 Execution Time:        28.971 ms (      8x)
> cache_day     731,909 Execution Time:       342.648 ms (   96x)
> cache_hour  8,715,863 Execution Time:     2,014.931 ms (    563x) */
> Queue_log   228,272,901 Execution Time: 2,099,358.675 ms (586,413x)
>
> Si te fijas, si hiciera un query de todos los indicadores de llamadas
> anuales, desde la tabla base, tardo 586,413 veces mas que usando el
> cache.
>
> Las tablas de cache dan los mismo resultados que haciendo en la tabla
> base, pero los tiempos de ejecución son muy bajos en los caches.
>
> Esto tiene mucho sentido cuando tienes a mucha gente viendo los
> indicadores constantemente, si tienes a 50 personas ejecutando un
> querrá que tarda mas de 34 minutos por persona, pues colapsaras la BD
> de manera terrible.
>
> Con gusto te muestro como lo hago, siéntete libre de preguntar y si
> está en mis manos, ayudarte.
>
> Saludos…. Fernando “El Pop” Romo
>
>
eso es conociendo la base, recién estoy definiendo a cual base le
hincare el diente (son dos o tres que se demoran sus dias en
procesarse), para de acuerdo eso ver si la estrategia que propones me
servirá

mi idea es la siguiente:

definida la base , extraer un 10% de la base ( con la sugerencia de
alvaro podre volcar a una base "victima", osea que podre romperla sin
preocupación )

luego sobre la base victima, aplicar todas las opciones de mejoras:

mejora de consultas

revisión de indices,

estrategia de almacenamiento,

etc.

hacer tuning , etc.

>
>
>> On 9 Aug 2023, at 8:54, Enrique Herrera Noya
>> <enrique(dot)herreranoya(at)gmail(dot)com> wrote:
>>
>> Colegas:
>>
>> Estoy desarrollando mi proyecto de titulo
>>
>> el cual versa sobre :
>>
>>
>> En la empresa se procesa un gran volumen de datos (TeraBytes), con
>> los cuales se crean determinados productos y/o servicios que se
>> ofrecen a los clientes. Dado esto es importante la seguridad de los
>> datos, en los aspectos de*disponibilidad*,*accesibilidad*, y sobre
>> todo*integridad*de la información.
>> Actualmente el procesamiento de algunos conjuntos de datos, mediante
>> programas propios desarrollados en*Java*y utilizando*Postgresql*como
>> base de datos, se demora alrededor de unos dos a tres días, cada vez
>> que se/_precisa realizar el análisis mensual_//de ellos,/para lo cual
>> se utiliza en forma intensiva los recursos informáticos asignados,
>> dicho proceso se realizar en paralelo con otros procesos diarios.
>> Este uso intensivo surge porque el estado de ciertos registros van
>> variando cada mes, y es necesario llevar un registro histórico*.*
>>
>> Se necesita realizar mejoras para optimizar el uso de los recursos
>> informáticos y también mejorar el código desarrollado, para disminuir
>> el tiempo necesario para el procesamientos de los datos.
>>
>> me tope con un tema practico , como son varios teras desde el cual
>> debo seleccionar la muestra, me demorare mas tiempo que el plazo de
>> entrega de la maqueta,
>>
>> entonces, para armar la maqueta se me ocurrió que podría utilizar una
>> bbdd abierta de algunos gigas, para utilizarla como insumo para
>> mostrar los pasos que
>>
>>  realizare con la bbdd  a analizar.
>>
>> atentos de sus comentarios.
>>
>>
>>
>>
>> Enrique Herrera Noya
>> --
>> +56 992303151
>> Red Hat Certified Engineer RHCE Nº100223072 (RH6.0)
>> Red Hat Certified System Administrato RHCSA Nº100223072 (RH6.0)
>> Red Hat Certified Technician (RHCT) Nº605010753835478 (RH5.0)
>> Novell Certified Linux Professional CLP 10
>> Red Hat Delivery Specialist -Container Platform Application Deployment I
>> Red Hat Delivery Specialist - Container Platform Administration I
>> RED HAT SPECIALIST
>> How to Sell Red Hat OpenShift for Infrastructure
>> How to Sell Red Hat OpenShift for Developers
>> Red Hat Sales Engineer Specialist - Container Platform
>> Red Hat Sales Engineer Specialist – Automation
>

Enrique Herrera Noya
--
+56 992303151
Red Hat Certified Engineer RHCE Nº100223072 (RH6.0)
Red Hat Certified System Administrato RHCSA Nº100223072 (RH6.0)
Red Hat Certified Technician (RHCT) Nº605010753835478 (RH5.0)
Novell Certified Linux Professional CLP 10
Red Hat Delivery Specialist -Container Platform Application Deployment I
Red Hat Delivery Specialist - Container Platform Administration I
RED HAT SPECIALIST
How to Sell Red Hat OpenShift for Infrastructure
How to Sell Red Hat OpenShift for Developers
Red Hat Sales Engineer Specialist - Container Platform
Red Hat Sales Engineer Specialist – Automation