Interesante. El tema de los algoritmos de ordenamiento, máximo y minimo. son faciles cuando los datos estan ordenados.
Cuando los datos están desordenados. Bueno es otra cosa. cuando ordenas. el primer dato es el min y el ultimo max. (simple eh). ahora sobre la media es un poco más complejo dado que tiene que recorrer todos los datos. como el archivo tiene 1B de registros y las maquinas tienen 8 core. ( puede que tengan 16 threads ). en C cuando compilaba el Kernel ( tiempos muy viejos ) CPU * 2 + 1 = Workers…. how ignoro si esta regla se aplica de esta forma o no. Las CPU tienen registros especiales para operaciones matemáticas. por lo que usarlas ayudara mucho me imagino. ASM ( assembler ) es mi preferido a la hora de hacer cosas raw con la CPU, pero dice en Java…. Si quieres hacer algo como esto en postgresql. Supongo que meter los datos. crear indices DESC y ASC ayuda mucho al calculo. Tablas particionadas por estaciones y la base se podrá a hacer cosas en paralelo. super rápido. Para no tener mucha RAM pipe lines serían interesantes a la hora de Implementar esto con PGSQL. ( solo tengo experiencia con Oracle no postgresql haciendo pipelines ). o Stream Le voy a dar una vuelta. > On 8/01/2024, at 11:59 PM, Jairo Graterón <jgrate...@gmail.com> wrote: > > Saludos lista > > Hay un reto para crear un algoritmo en java para para recuperar valores de > medición de temperatura de un archivo de texto y calcular la temperatura > mínima, media y máxima por estación meteorológica > https://www.morling.dev/blog/one-billion-row-challenge/ > <https://www.morling.dev/blog/one-billion-row-challenge/> > > Pero se están haciendo implementaciones en otros lenguajes y por supuesto en > bases de datos por ejemplo https://ftisiot.net/posts/1brows/ > <https://ftisiot.net/posts/1brows/> y > https://rmoff.net/2024/01/03/1%EF%B8%8F%E2%83%A3%EF%B8%8F-1brc-in-sql-with-duckdb/ > > <https://rmoff.net/2024/01/03/1%EF%B8%8F%E2%83%A3%EF%B8%8F-1brc-in-sql-with-duckdb/> > > Ya inserté los mil millones de registros en mi máquina y al realizar la > consulta > <image.png> > Tarda casi 2 minutos, así que seguí investigando como mejorar el tiempo y al > encontrar estas otras pruebas > https://gist.github.com/FranckPachot/50a6a491b85b0ddb3da6399d54653085 > <https://gist.github.com/FranckPachot/50a6a491b85b0ddb3da6399d54653085> me > llamó la atención ésta línea > select /*+ parallel(8) gather_plan_statistics*/ > > Revisando postgres tiene un parámetro para aumentar el número de workers en > paralelo si la consulta lo necesita max_parallel_workers_per_gather > > > <image.png> > Mejoró bastante, 40 segundos menos. > > ¿Qué otras optimizaciones se podrían realizar en postgres para disminuir el > tiempo? > > Con Apache Pinot tarda aprox 1.9s > https://hubertdulay.substack.com/p/1-billion-row-challenge-in-apache?r=46sqk&utm_campaign=post&utm_medium=web > > <https://hubertdulay.substack.com/p/1-billion-row-challenge-in-apache?r=46sqk&utm_campaign=post&utm_medium=web> > > Otro tardó 20 segundos > https://twitter.com/_TylerHillery/status/1742971310123487429 > <https://twitter.com/_TylerHillery/status/1742971310123487429> > > > Por supuesto eso depende de las especificaciones del equipo pero es > interesante que compartan sus experiencias. > > Las especificaciones de mi máquina son: > Ryzen 5 6 cores/12 Threads a 3.0ghz > Disco nvme KINGSTON > Ubuntu 22.04 > Postgresql 14 > > > >
