procesare fisiere de tip .log eficient si corect

Salut. Am o problema: am 1000 de fisiere de tip log din care trebuie sa scot anumite campuri si sa le inserez intr o baza de date. Citirea fisierelor merge ok si extragerea datelor cu BufferedReader. Dar vreau sa le fac in paralel. Asa ca: am creat o clasa Procesare, folosita pentru un singur fisier. La un momentat dat inserarea o fac cu un PreparedStatement primit dintr o clasa Connection, deci am o singura conexiune, si pentru fiecare fisier procesat creez un PreparedStatement. In clasa cu main() am folosit o lista pentru Procesare si parallel & lambda, dar merge extrem extrem de greu....cum se poate face citirea din fisier, insert-ul cat mai corect in paralel?

Salut.
Cauti info despre connection pool si batch insert.

Pai folosesc deja batch insert. Fiecare fisier are cam 2000 de insert uri la final si le execut cu batch cand termin de citit fisierul

Nu am codul la indemana, doar oare sa fac Procesare de tip Runnable si sa folososc ExecutorService ar merge mai bine? Cam 1000 de threaduri ar fi...

1000 de thread-uri?
Oarecum offtopic, am facut odata niste teste pt numere Armstrong, observatia mea a fost ca numarul de threaduri tre' sa fie cam nr de core - 2 pt eficienta maxima. Cand depaseam numarul de core-uri, rezultatele erau praf.
Nu stiu daca se aplica in orice situatie observatia mea, dar totusi.. 1000th.. ce masina ai?

Cand creezi batchul, opreste autoCommit si reporneste-l la sfarsit.
Batchul, in functie de cat de multe date trimiti, nu-l lasa foarte mare, trimite-l in calupuri de 500-1000 de inregistrari.

Corect, asa se face batch-ul de jdbc

Depinde de cerințe și de datele de intrare și de ieșire, dar

eu aș citi în paralel doar câte x fișiere, probabil cu x=n, n nr de threads din CPU, și fișierele memory-mapped.

Trebuie să experimentezi puțin, deci util ar fi să faci x un parametru. Depinde dacă ce faci e IO bound sau CPU bound.

Și la ieșire trebuie să experimentezi. În mod ideal, ai avea un singur thread de scriere în DB. Dar din nou, depinde de date. Dacă datele sunt sharduibile, poate merită câte un thread per shard.

Trebuie să te gândești la performanța întregului sistem și să o măsori. Dacă paralelizezi prea mult scrierea, dar baza de date nu face față, tot degeaba, că te alegi cu contention.

Deci parametrizează cu un int paralelismul de intrare și cu un alt int pe cel de ieșire, și măsoară. Paralelism de 1 e secvențial, include-l și pe el în măsurători, s-ar putea să ai surprize plăcute.

Quote

Noi java developerii am experimentat ani de-a randul si cum zice @sorin147 aceasta este cea mai buna metodologie de abordate in java care este stabila.

Daca vrei sa faci batch insertion la date foarte mari,  iti faci prorpiul server de batching , ii pui memoria de lucru mare, si apoi maresti numarul de inregistrari chiar si la 500.000 /batch insertion operation.
Idee e ca insertia  trebuie sa fie tranzactionala, fie reusesc toate cele 500.000 de linii /operatie fie nici una si se  intra in bucla de retry pana reuseste sau pana iese cu o eroare generica, caz in care
se scrie in log-ul de iesire care este ultima valoare PKID comisa  cu succes in baza de date.

Si apoi se reia jobul cu parametrul de intrare acel PKID, de unde a ramas, asta daca vrei sa faci jobul de batch insertion cu cap si sa nu ai inconsistente in RDBMS daca se intampla fie erori de networking, fie erori la baza de date , fie erori la aplicatie, fie erori I/O.

Edited by Iulius-Foyas, 22 July 2019 - 11:42.

Ar fi util sa ne spui ce baza de date este si daca toate inserturile sunt intr-o singura tabela sau in mai multe.
Ar mai ajuta sa pui niste timere in cod sa vezi ce dureaza mult - partea de citire de fisier sau partea de scriere in baza de date.
As zice ca problema e la managementul tranzactiilor pe baza de date dar ... trebuie mai multe informatii.

Ma, eu ma deprim aici...citesc si nu inteleg, nu stiu de unde invatati voi...deci eu log uri pentru diferite componente cu diferite campuri. Cred ca rescriu altfel: citesc fisierul, fac un list de hashmap, iau cheile si fac tabela unde inserez datele(bine , fac si insertul folosind string.format). La final voi avea un batch cu aprox 2000 de inserturi pe fisier. Poate impart fisierele cumva intre 4 thread uri nu stiu, ceva...
Oricum voi sunteti prea avansati! Bravo voua!

mcelbmag, on 22 iulie 2019 - 15:06, said:

quote la pasajele pe care nu le intelegi, cuvintele cheie pe care nu le intelegi, sau unde nu esti sigur ca intelegi, spune ce intelegi ca sa ne asiguram ca intelegi ce vrem sa spunem.

Doar "nu inteleg" nu e de ajutor nimanui. Trebuie sa scrii ca un om ajutabil, ca in general oamenii vor sa ajute daca inteleg cum pot ajuta.

In loc sa te deprimi:
- ia un (1) fisier, parseaza-l (sau ce-i faci tu acolo), baga datele in baza. Afiseaza undeva (console/logfile), timpul de parsare, timpul de insert.
- la acelasi fisier, in loc de 2000 de inserturi, fa cate un batch de 500. Verifica timpii cu ce ai obtinut mai devreme.
- incearca si cu batch de 1000 ...
treci la 2 fisiere, ce am scris mai inainte: 1 si 2 fire de executie, eventual 2 conexiuni (ma gandesc ca are sens.. am scris mai sus de connection pool, caci toate firele tale pe o singura conexiune..)
treci la 4 fisiere + test de 1, 2 si 4 fire de executie..
Si vezi ce si unde se misca greu. Citirea? Parsarea? Constructia batch-ului, sau executia batch-ului.

Cu acele informatii, poti sa pui intrebari mai la subiect.
De asemenea, poti scoate un schelet de program, sa vedem ce si cum... n-om sti toti sa-ti raspundem (uite, eu nu stiu lambda si stream-uri), dar s-o gasi cineva. Asa ca nu merge, sau ca merge greu..

cheers si rabdare.

Quote

In paralel sa le faci dupa ce stapanesti bine procesul de batching in java, stii cum sa modifici performantele driverului jdbc, esti la curent cu toate bugurile driverului jdbc atunci cand este accesat
concurential si stii cum se comporta engine-ul de RDBMS atuncin cand este accesat concurential.

Pentru asta trebuie sa stii bine  Java Concurency(aka multi-threading): https://pdfs.semanti...5d403cc8edd.pdf

Decoamdata suntem la nivelul in care inca nu ti-ai dat seama ca viteza ta procesare este limitata de:

probleme legate la  partea de aplicatie

• setarile JVm-ului
  
• limitariile versiunii drvierului jdbc
  
• necunosterea(din nestudierea) bunele practici privind procesul de batch-insertions
  
• prelucrarea defectoasa a stringurilor care iti incarca mult memoria si iti creste timpul de prelucrare mult de tot.
  
• clase structurate gresit care fac comunicarea in interiorul aplicatiei greoaie
  
• metadate al containerelor de tip Integer/Double daca le folosesti(mai exact duci date de pomana in spate)-> utilizeaza primitve cum ar fi double, int.
  
• folosirea de liste pt stocare datelor in loc sa folosesti array-urile primitive, mai ales ca stii in avans cate date o sa prelucrezi per batch

probleme legate la partea de baza de date:

• chei primare puse gresit sau chei de business puse gresit
  
• probleme generate de indecsii de tabela asupra operatiunii de insert : https://use-the-inde.../sql/dml/insert, de care nu se tine seama
  
• etc

Dupa ce stapanesti toate chestiile de mai sus, de abia atunci poti sa treci sa-ti faci "multithreading batch insertion jobs" in java, pana atunci ramai la metoda clasica secventiala de batch insertion
si optimieaza fiecare chestie pe care ti-am spus-o mai sus.

Edited by Iulius-Foyas, 22 July 2019 - 15:56.

Cat de incet merge acum? Cat de mari sunt fisierele? Cam cati MB/secunda reusesesti sa inserezi? Ce sistem de baza de date folosesti?

Cele mai rapide moduri de a insera date multe intr-o baza de date implica facilitati specifice serverului, nici nu trec prin JVM. De exemplu: https://www.postgres...t/sql-copy.html

Daca nu-i secret, ataseaza un exemplu de rand din log si structura tabelului destinatie.

Edited by dani.user, 22 July 2019 - 18:28.

Probabil el si proceseaza datele din acele fisiere care nu sunt in format standardizat si apoi unde a zis ca  foloseste ca backend postgresql ?

Omul a dat un exemplu, în lipsa comunicației lui @OP.

Iulius-Foyas, on 22 iulie 2019 - 11:40, said:

Nu stiu ce ai experimentat tu, dar ce ai debitat acolo sunt pur si simplu elucubratii. Orice problema de optimizare ar trebui sa inceapa cu o faza de ANALIZA, ca sa vedem ce merge defapt greu si unde trebuie sa ne concentram eforturile, ca avem pretentia sa fim "noi, programatorii", nu din aia care "tuneaza" masini cu un spoiler si o toba de esapament care suna bineee fratica. Colegii au sugerat deja elemente care ar trebui analizate.

Edited by andrei_0, 22 July 2019 - 23:23.

pentru noi programatorii de java problema este clasica arhicunoscuta si rezolvata de ani de zile, pt voi este o enigma.

Edited by Iulius-Foyas, 23 July 2019 - 00:44.