Re: Desafío 1brc

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 <jgrateron(at)gmail(dot)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
>
>
>
>