Jump to content

SUBIECTE NOI
« 1 / 5 »
RSS
Transferuri instant intre bancile...

player video

Carefur Act for good

Parcare gratis in Bucuresti pentr...
 Rovinieta prin SMS pentru masina ...

Viteza mica Usb 3.2 gen.1 header

Cerificat atestare fiscala pentru...

Schimbare destinatie imobil din l...
 Dorsalgie

Recomandare brand cheie dinamomet...

Divorț la notar

Vechime vs km reali
 Android 12 : "Yahoo Mail s-a ...

Bloc Favorit cu RS2

Ce extractor audio (analogic) pen...

Cine suporta cheltuielile de jude...
 

Teorie penibila

- - - - -
  • Please log in to reply
12 replies to this topic

#1
MartinAdelberg

MartinAdelberg

    Member

  • Grup: Members
  • Posts: 866
  • Înscris: 23.08.2019
Daca solutia ofertita este pentru teme de casa, atunci solutia este ok.
Daca solutia oferita este cod spre productie atunci solutia propusa nu este ok.
Mai exact prezenta lui CROSS JOIN din
FROM dates
								 CROSS JOIN (SELECT DISTINCT articol FROM articole) a
		 ),

si prezenta lui SELECT * din
[SELECT *
				 FROM (SELECT data, articol, cantitate,


Exemplu: la noi in corporatie, am pus filtre ca sa nu-i las pe juniori sa ruleze CROSS JOIN si SELECT * , fortandu-i sa scrie SQL calumea optimizat in mod profesionist.
De asemeni pe echipele de juniori care scriu SQL-ul pt BigData, ii fortam sa optimizeze tot SQL-ul si acolo sa incerce sa formuleze intai cod SQL fara JOINURI daca se poate,
ci sa le folosesca doar daca sectiunea de cod respectiva chiar nu se poate rezolva altfel.
Chiar si atunci cand folosesc JOINURI automat, juniorii nu trebuie sa foloseseasca SELECT * ci sa scrie coloanele respective de manuta.
De asemenea trebuie sa fie atenti cum clusterizeaza fiecare JOIN  si cum isi partitioneaza datele inainte de a intra in JOIN-ul respectv.

De aemenea acest criterii de mai sus, sunt criteriile minimaliste atunci cand trebuie sa scrii cod SQL care ruleaza pe o infrastructura moderna gen  GCP. Acolo orice query SQL neoptimizat genereaza
shufflle suplimentar  de date care costa la buzunar. Adica din cauza unor joinuri  se poate ca 70% din cod sa  doar plimbe datele pe disc prin ram si prin CPU , fara a procesa efectiv informatia utila.
Ori , procesarea pe RAM, CPU si pe disc costa foarte mult bani de acea programatorii sunt obligatii sa scrie cod SQL profesionist si optimizat inainte de a-si rula queriurile  SQL in mediul Big Query din GCP.

CROSS JOIN-uri si SELECT * , in functie de dimensiunea datelor si datorita shuflle-ului de date pe care il implica, pot genera mii de euro cheltuiala degeaba per query in mediul GCP.
De aceea noi am pus filtre pe astfel de chestii si nu numai, iar pentru cei care vin la interviu pt senior Big Data Developer sau  senior GCP developer le dam un test in care bagam soparlele astea sa vedem  daca se prind.

Edited by MartinAdelberg, 27 December 2019 - 10:07.


#2
MartinAdelberg

MartinAdelberg

    Member

  • Grup: Members
  • Posts: 866
  • Înscris: 23.08.2019
primele reguli de optimizare ar fi:
  • 1.intotdeauna daca ai operatii pe o singura tabela, nu folosi SELF-JOIN ci rescrie algortimul folosind functii analtice, doare nu creaza suffjle suplimentar de date.
  • 2.daca ai de facut o filtrare a tabela A in functie de tabela B, nu folosi LEFT JOIN ci foloseste un LEFT-SEMI JOIN sau RIGHT SEMI-JOIN doarece nu creaza shuffle suplimentar de date
  • 3.daca se poate rescrie tot codul SQL fara joinuri, reducand enorm shuffle de date.
  • 4.daca totusi trebuie facute joinuri partitineaza si clusterizeaza cele doua seturi de date inainte de a intra in join, dupa coloanele de join,pt a mentine la minim sufflle-ul de date suplimentar ce poate fi generat de joinuri.
  • 5.niciodata nu folosi cross-join-uri si select *.
cu cat ai mai putin shufflle cu atat plimbi mai putin datele prin cpu, ram si disc si scazi timpii morti de procesare, crescand randamentul query-ului  in functie de resursele utilizate si platesti bani mai putin pt timpul de procesare.


Deja companiile cauta programatori care pot scrie SQL optimizat, astfel incat in loc sa te coste 3000 de euro rularea unui query in GCP,  sa te coste 500 de euro, doar prin aplicarea celor 5 principii de mai sus (acolo unde se poate bineinteles)

Edited by MartinAdelberg, 27 December 2019 - 10:22.


#3
dani.user

dani.user

    Guru Member

  • Grup: Senior Members
  • Posts: 30,114
  • Înscris: 24.02.2007
Postul la care se refera MartinAdelberg: https://forum.softpe.../#entry25628167

Edited by dani.user, 27 December 2019 - 12:34.


#4
MarianG

MarianG

    be that as it may

  • Grup: Moderators
  • Posts: 31,295
  • Înscris: 10.08.2005

View PostMartinAdelberg, on 27 decembrie 2019 - 10:00, said:

Exemplu: la noi in corporatie, am pus filtre ca sa nu-i las pe juniori sa ruleze CROSS JOIN si SELECT * , fortandu-i sa scrie SQL calumea optimizat in mod profesionist.

View PostMartinAdelberg, on 27 decembrie 2019 - 10:17, said:

Deja companiile cauta programatori care pot scrie SQL optimizat, astfel incat in loc sa te coste 3000 de euro rularea unui query in GCP,  sa te coste 500 de euro, doar prin aplicarea celor 5 principii de mai sus (acolo unde se poate bineinteles)

Ne vedem la anu'.

#5
Augustus1978

Augustus1978

    Member

  • Grup: Members
  • Posts: 923
  • Înscris: 01.02.2019
Da' te-ai gandit ca sclavii de pe plantatie sunt dezinteresati. Cu siguranta stiu dar nu vor. Ofera-le un bonus sa vezi ca o sa scrie cum trebuie, adica cei care scrieti cum vreau eu primiti in plus la salar.

#6
_Smiley_

_Smiley_

    Guru Member

  • Grup: Senior Members
  • Posts: 19,927
  • Înscris: 24.02.2006

View PostMartinAdelberg, on 27 decembrie 2019 - 10:00, said:

.........pe echipele de juniori care scriu SQL-ul pt BigData, ii fortam sa optimizeze tot SQL-ul ..........

s-a gandit vreunul din voi ca "juniori" si "optimizat" sunt niste chestii un pic paralele?
am mai vazut firme d'astea, unde sareau imediat cu "esti inca junior" cand era vorba de salarii, dar uitau de asta cand era vorba de ce li se cerea respectivilor.

#7
sticksaint

sticksaint

    Junior Member

  • Grup: Junior Members
  • Posts: 46
  • Înscris: 03.04.2017
junior si optimizat merg mana in mana, indiferent de salar. Un junior cu cap care o sa devina un senior briliant ceva mai incolo o sa invete si o sa optimizeze pt el. Cand o sa vina vremea o sa plece pe x5 salariu de cacao pe care il are la firma x unde a stat cat sa-si faca mana.

#8
_Smiley_

_Smiley_

    Guru Member

  • Grup: Senior Members
  • Posts: 19,927
  • Înscris: 24.02.2006
daca reusesti sa pleci la o alta firma pe "x5 salariu", asta inseamna un singur lucru: firma anterioara te muncea ca pe un sclav.

#9
dani.user

dani.user

    Guru Member

  • Grup: Senior Members
  • Posts: 30,114
  • Înscris: 24.02.2007
Daca initiatorul ar mai si citi cate ceva in loc sa scrie romane de teorie cand vrea sa ofere o critica, ar fi observat ca:
  • Beneficiaul interogarii respective a confirmat ca functioneaza rapid si ok.
  • Platforma in cauza nu era GCP
  • SELECT * nu era folosit pe un tabel, ci pe o subinterograre specifica


#10
sticksaint

sticksaint

    Junior Member

  • Grup: Junior Members
  • Posts: 46
  • Înscris: 03.04.2017

View Post_Smiley_, on 29 decembrie 2019 - 12:27, said:

daca reusesti sa pleci la o alta firma pe "x5 salariu", asta inseamna un singur lucru: firma anterioara te muncea ca pe un sclav.
cand esti muncit ca un sclav inveti o gramada de chestii, ceea ce iti va permite mai incolo sa pleci pe x5 salariu. Una n-o exclude pe alta.

#11
_Smiley_

_Smiley_

    Guru Member

  • Grup: Senior Members
  • Posts: 19,927
  • Înscris: 24.02.2006
adevarul e ca cei platiti normal nu ajung niciodata sa plece pe "x5 salariu", pentru ca salariul lor creste constant :)
tu ce ai prefera, sa lucrezi 5 ani pe X salariu si apoi sa treci la X5 salariu, sau sa ai in primul an X salariu, in al doilea X2 salariu si tot asa, pana in al cincilea an cand o sa ai tot X5 salariu? rezultatul final e acelasi (X5 salariu), dar unul a incasat in perioada asta doar 5*X salarii pe cand celalalt a primit 15*X salarii.

nemaivorbind ca cei care-s munciti ca sclavi pe bani putini rareori ajung sa vada acel "x5 salariu", sau chiar daca-l primesc vor descoperi ca e tot sub media industriei. vezi tu, daca ar fi in stare sa obtina un salariu decent, l-ar fi obtinut si la inceput.

#12
sticksaint

sticksaint

    Junior Member

  • Grup: Junior Members
  • Posts: 46
  • Înscris: 03.04.2017
Tu pleci de la premisa ca toata lumea ajunge la fiecare sfarsit de an la acelasi nivel din punct de vedere profesional. Teoretic vorbind 2 developeri care au acelasi nivel de skill nu vor progresa uniform daca unul munceste ca nebunul, iar celalalt relaxat. Ala care munceste ca un sclav va avansa mai repede. Dupa 2 ani va avea un salt salarial mai mare decat cineva care creste constant de la an la an, iar dupa 5 diferenta se va accentua. (5 ani nu e interval realist de muncit ca sclav pt ca dai in burn-out, insa).
Si mai e o chestie, unul obisnuit sa munceasca ca un sclav pana la urma isi va da seama care e piata si va pleca sa munceasca ca un sclav pe un salariu mult mai mare decat media pietei, chiar si decat cel care evolueaza constant de la an la an.

#13
_Smiley_

_Smiley_

    Guru Member

  • Grup: Senior Members
  • Posts: 19,927
  • Înscris: 24.02.2006
ce refuzi tu sa intelegi e ca o astfel de crestere a salariului (de 5 ori) este aberanta, daca discutam de pastrarea domeniului de lucru si a locatiei geografice (relative). si asta nu doar in IT, ci cam in orice domeniu.

Anunturi

Chirurgia spinală minim invazivă Chirurgia spinală minim invazivă

Chirurgia spinală minim invazivă oferă pacienților oportunitatea unui tratament eficient, permițându-le o recuperare ultra rapidă și nu în ultimul rând minimizând leziunile induse chirurgical.

Echipa noastră utilizează un spectru larg de tehnici minim invazive, din care enumerăm câteva: endoscopia cu variantele ei (transnazală, transtoracică, transmusculară, etc), microscopul operator, abordurile trans tubulare și nu în ultimul rând infiltrațiile la toate nivelurile coloanei vertebrale.

www.neurohope.ro

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Forumul Softpedia foloseste "cookies" pentru a imbunatati experienta utilizatorilor Accept
Pentru detalii si optiuni legate de cookies si datele personale, consultati Politica de utilizare cookies si Politica de confidentialitate