MySql nakon Postgresql-a (rant)

[ bogdan.kecman @ 26.11.2020. 20:59 ] @

fts, sta mu fali? (uvek mozes da koristis externa resenja kao sto nidza
rece ali u odnosu na psql ne vidim da je mysql-ov fts nesto znacajno
gori, bice da samo mozda nisi savladao sintaksu?)

sp - kako mislis ne moze ? i kakve veze ima stored procedura sa select
sintaksom?!

> select * from (select * from tp1 limit 3) x join tp2 using (s1);
+--------+
| s1 |
+--------+
| 100005 |
| 100029 |
| 100036 |
+--------+
3 rows in set (0.00 sec)

fje ne mogu da vrate tabelu, to je limit koji mislim da nikad nece biti
uklonjen, kao sto nece najverovatnije nikad biti dodat "array" tip

temp tabele, nisam siguran da kapiram o kom limitu pricas, o
materijalizovanim intermediate temp tabelama ili o obicnim temp tabelama
posto obicu temp tabelu u toku sesije mozes da referenciras koliko puta
hoces kako hoces kao bilo koju drugu tabelu

CTE - da, tek od 8, ali kakve to veze ima, pa neces u 2020 godini da
koristis 5.x ?! koristis 8.x ... nema pre 8 mnogo toga, metadata se pre
8.0 cuva u frm fajlovima sto znaci da operacije nad tabelama nisu acid i
slicno .. mozemo da pricamo i o tome kako 3.23 nema left join l kako 4.0
nema ni proper karakter setove, kolacije ... kako myisam nije acid ...
kakve to veze ima ..

pazi, ja radim za mysql ali privatno koristim i psql i mysql podjednako
(cak stavise malo vise psql) i isto tako mogu da ti kazem da

- psql - kolacije i karakter setovi - neupotrebljivo (na mysql 5.x to
radi vrhunski)

- psql - replikacija - neupotrebljivo (na mysql-u to radi vrhunski od
uvek)

- psql - bilo kakav realan HA - neupotrebljivo (za mysql imas group
replication, innodb cluster, mysql ndbcluster, galera ... resenja koja
koriste telekomi, banke, sistemi koji u slucaju pada sistema gube
milione na minut)

- psql - biz analitika - neupotrebljivo (za mysql na resenje postoji
sa RAPID engine-om koji je na zalost dostupan samo na oracle cloud
verziji mysql-a)

tako da .. svaki ima svoje prednosti i mane, a ako ce vadimo stare
verzije nijedan nije ni za .!. :D

ono sto je ozbiljan mysql drawback list u poredjenju sa psql danas je

- optimizer je i dalje losiji nego psql-ov (na ovome se intenzivno radi )

- stored procedure su rudimentarne (na ovome se ne radi uopste jer je
ideja da mysql ne treba da bude app server vec rdbms, ako oces app
server uzmes oracle db)

i to je "big deal" .. sve ostalo je vise manje sio mi ga djura

[ BuzzLightyear @ 26.11.2020. 21:20 ] @

Citat:

CTE - da, tek od 8, ali kakve to veze ima, pa neces u 2020 godini da koristis 5.x ?!

Da mogu da biram ne bih ni pokrenuo rant :) Radi se o izveštaju iz nekog starog sistema.

Citat:

sp - kako mislis ne moze ? i kakve veze ima stored procedura sa select sintaksom?!

Ne može select * from call moja_procedura(p1,p2)

Dovoljno je bilo da sam samo napisao funkcije ne mogu da vrate tabelu. Da li postoji elegantno rešenje za ovo? Ja sam rešio procedurama koje kreiraju privremene tabele.

Citat:

temp tabele, nisam siguran da kapiram o kom limitu pricas, o

Code:
mysql> SELECT * FROM temp_table, temp_table AS t2;
ERROR 1137: Can't reopen table: 'temp_table'

Dodao bih i poruke o greškama. Uglavnom su neinformativne i besmislene.

[ bogdan.kecman @ 26.11.2020. 22:08 ] @

da svasta na 5.x fali .. jbg .. sto vise unazad ides, fali vise stvari
.. ali relativno je lako odraditi upgrade :D

elem,

> select * from repeat('moze', 1);
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near 'repeat('moze', 1)' at line 1
> select * from (select repeat('moze', 1)) x;
+-------------------+
| repeat('moze', 1) |
+-------------------+
| moze |
+-------------------+
1 row in set (0.00 sec)

tako da rezultat funkcije mozes da iskoristis relativno lako, no problem
je sto rezultat funkcije ne moze da bude tabela

ah ovo sa temp_table je pos@#$%%^@$^ni limit koji nikako da se resi :(
... vec 10 godina slusam kako ce "biti uskoro" :(

https://dev.mysql.com/doc/refm.../temporary-table-problems.html

na ovom linku imas workaround ali radi samo na 8.0 :(

ja imam to reseno na jednom mestu na "glup" nacin, probacu da iskopam da
dignem ovde source, ali ako se dobro secam sp proveri da li postoji
tabela (prava), ako postoji throwne gresku, ako ne postoji napravi je,
napuni je i izadje i app posle koriscenja te tabele istu brise, znaci ne
brise se sama od sebe ako se diskonektujes... meni to radi posao zato
sto tu proceduru radim jednom u par meseci i uvek se radi iz jednog
treda i nema sanse da se desi da se duplicira a samim tim sto proveravam
dal tabela postoji sprecavam slucaj da u slucaju da neko ko ne zna oce
mu se radi proba da odradi stvar dok je proces u toku ne bude nista...
ne znam dal tako nesto mozes da implementiras ili ne..

e sada, na osmici mozes da zaobidjes problem sa JSON-om posto funkcija
moze da vrati json

EDIT: pojeo ES mail pa moram da izeditujem kroz web interface

Code:

DELIMITER $$

CREATE FUNCTION fja(
    a char(10),
    b int(8)
)
RETURNS json
DETERMINISTIC
BEGIN
    DECLARE counter INT DEFAULT 1;

    WHILE counter <= b DO
        -- ovde napunis json
        SET counter = counter + 1;

    END WHILE;
    RETURN '[{"a":"3"},{"a":2},{"b":1},{"a":0},{"a":[1,2]}]';

END $$

DELIMITER ;

SELECT * FROM JSON_TABLE(
  fja('a',1),
  "$[*]" COLUMNS(
  rowid FOR ORDINALITY,
  ac VARCHAR(100) PATH "$.a" DEFAULT '111' ON EMPTY DEFAULT '999' ON ERROR,
  aj JSON PATH "$.a" DEFAULT '{"x": 333}' ON EMPTY,
  bx INT EXISTS PATH "$.b"
)) AS tt;

na primer

Code:

> SELECT * FROM JSON_TABLE(
    ->   fja('a',1),
    ->   "$[*]" COLUMNS(
    ->   rowid FOR ORDINALITY,
    ->   ac VARCHAR(100) PATH "$.a" DEFAULT '111' ON EMPTY DEFAULT '999' ON ERROR,
    ->   aj JSON PATH "$.a" DEFAULT '{"x": 333}' ON EMPTY,
    ->   bx INT EXISTS PATH "$.b"
    -> )) AS tt;
+-------+------+------------+------+
| rowid | ac   | aj         | bx   |
+-------+------+------------+------+
|     1 | 3    | "3"        |    0 |
|     2 | 2    | 2          |    0 |
|     3 | 111  | {"x": 333} |    1 |
|     4 | 0    | 0          |    0 |
|     5 | 999  | [1, 2]     |    0 |
+-------+------+------------+------+
5 rows in set (0.00 sec)

[ bogdan.kecman @ 26.11.2020. 23:18 ] @

evo ti primer kako tu majmu... da izvedes da zaobidjes mysql issue

Code:

CREATE TABLE `t` (
  `a` varchar(10) DEFAULT NULL,
  `b` varchar(10) DEFAULT NULL,
  `i` int DEFAULT NULL
);

INSERT INTO t VALUES ('ddas','das', 3), ('das','dsa', 4), ('das','das', 5);
INSERT INTO t VALUES ('ddas','das', 6), ('das','dsa', 7), ('das','das', 8);

DROP FUNCTION IF EXISTS f2;
DELIMITER $$
CREATE FUNCTION f2()
RETURNS json
DETERMINISTIC
BEGIN
    DECLARE done TINYINT DEFAULT FALSE;
    DECLARE keetah json;
    DECLARE j json;

    DECLARE c1 CURSOR FOR SELECT JSON_OBJECT('a', a, 'b', b, 'i', i)  FROM t;
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

    SET keetah = '[{"a": null, "b": null, "i": null}]';

    OPEN c1;

l:
    LOOP
      FETCH NEXT FROM c1 INTO j;

      IF done THEN
        LEAVE l;
      ELSE

        SELECT JSON_ARRAY_APPEND(keetah, '$[0]', j) INTO keetah;

      END IF;
    END LOOP;
    CLOSE c1;

    RETURN keetah;
END $$
DELIMITER ;

SELECT * FROM JSON_TABLE(f2(),
  '$[*]' COLUMNS (
    NESTED PATH '$[*]' COLUMNS ( a varchar(10) PATH "$.a", b varchar(10) PATH "$.b", i int PATH "$.i")
  )
) yyy;

npr:

Code:

> SELECT * FROM JSON_TABLE(f2(),
    ->   '$[*]' COLUMNS (
    ->     NESTED PATH '$[*]' COLUMNS ( a varchar(10) PATH "$.a", b varchar(10) PATH "$.b", i int PATH "$.i")
    ->   )
    -> ) yyy;
+------+------+------+
| a    | b    | i    |
+------+------+------+
| NULL | NULL | NULL |
| ddas | das  |    3 |
| das  | dsa  |    4 |
| das  | das  |    5 |
| ddas | das  |    6 |
| das  | dsa  |    7 |
| das  | das  |    8 |
+------+------+------+
7 rows in set (0.00 sec)

(mozes umesto da inicijalizujes ono sa null da bi izbegao taj null row viska da inicijalizujes sa "prvim" pa da dopunis json dalje ali generalno kontas ideju .. )

[ nkrgovic @ 27.11.2020. 09:00 ] @

Ja sam stekao utisak da je covek navikao na PL/SQL-like sisteme ... nek me ispravi ako gresim. Bukvalno su mu pitanja koja sam vec cuo da se ljudi zale koji su radili na slican nacin. Znam bar za jedan slucaj da su na kraju, za web projekat, ipak isli na Oracle bazu (Oracle XE, tad im je bilo dosta 1GB date), jer im je bilo lakse nego da promene developere (bilo promene kao zaposle nove ili promene tipa nauce ih nove stvari), a znam nekoliko njih koji su isli na PostgreSQL jer su navikli na taj nacin pravljenja arhitekture (DB heavy, in-database logika...).

[ BuzzLightyear @ 27.11.2020. 09:23 ] @

Citat:

Ja sam stekao utisak da je covek navikao na PL/SQL-like sisteme

U pravu si, napisao sam to i u naslovu teme.

Hvala Bogdane na detaljnom odgovoru.

[ bogdan.kecman @ 27.11.2020. 09:32 ] @

a vidi, meni je interesantno bilo da vidim kako bi izgledalo ovo sa
tabela -> json -> tabela pa sam napravio primer .. a ko sto rekoh mysql
nikad nije zamisljen kao app server, oracle ima svoj app server i
sigurno nece od mysql-a praviti app server, ako ti treba app server i
biznis logika u bazi oracle ima svoje resenje(a), foss nudi svoja
resenja .. mysql to nije niti ce ikad biti

[ djoka_l @ 27.11.2020. 10:49 ] @

Uvek je bolno kada logiku rada na jednoj bazi pokušaš da dobiješ sa drugom bazom.
Meni je uvek bilo neshvatljivo da neko kao prednost softvera navodi da je portabilan na više baza.
To je možda zgodno kada kupuješ aplikaciju sa bazom i samo ta aplikacija ide na bazu.
Onako kako ja čitam, to mi znači "naš softver radi podjednako loše sa svakom bazom".

Recimo, moja firma je bila dovoljno blesava da kaže da softver radi i na Standard Edition i na Enterprise Edition Oracle bazi.
Onda nam je najveći klijenta rekao, to je super, ali mi smo dali velike pare na Enterprise i želimo da radi bolje nego na Standard.
Sva sreća, bar kod Oracle baze, sa developerske strane se više te dve edicije (skoro) ne razlikuju. Razlika dolazi do izražaja tek na DBA nivou.

Sada, međutim, imam situaciju da imam heterogeno okruženje, SQL Server i Oracle DB i stalno uviđam koliko loših odluka je tim koji je razvijao aplikaciju doneo kada je logiku SQL Servera hteo da primeni na Oracle strani.

EDIT: Uzgred, pošto je SQL Server strana rađena, pa skoro da bude portabilna na više baza, na SQL Server strani aplikacije imam 3 puta više hardverskih resursa sa 10 puta manjom bazom, ali zato 5 puta slabije performanse.

[ bogdan.kecman @ 27.11.2020. 10:57 ] @

@djoka, vidi, kada neko kaze da sw radi dobro sa svakom bazom to u 99%
slucajeva znaci da se biz lokiga nalazi u aplikaciji a ne u bazi. Ja sam
inace pobornik toga, od uvek, da biz logika bude u aplikaciji a ne u
bazi... baza treba da cuva/isporucuje datu i treba da cuva
ref.integritet .. i to danas skoro svi rdbms mogu da obezbede.... a
razlike u sintaksi su toliko minimalne danas da nije problem da podrzis
sve njih u istom kodu.. problem nastaje samo ako zelis da gurnes biz
logiku u bazu i koristis u stvari application server a ne rdbms ... u
tom slucaju mysql prosto nije resenje, mysql nije appserver ... psql
jeste, oracledb jeste, m$sql jeste ..

[ djoka_l @ 27.11.2020. 11:18 ] @

Nije samo do stored procedura, problem je i ako samo koristiš SQL.
Recimo, gomila upita ima hintove, koje pomažu Oraclu da izabere execution plan.
Sada, hintovi ne smetaju drugoj bazi, oni su pod komentarom, ali to definitvno znači da moraš da prođeš kroz svaki upit koji je napravi ORM i da ručno dodaješ hintove, pa prilikom sledeće iteracije te hintove izgubiš.
A da ne pričam da se gomila funkcija ne nalazi na jednoj ili drugoj bazi.

Drugo, SQL Server programeri mnoooogo vole da koriste temporary tabele. Potupuno nepotrebno na Oracle strani.

Treće SQL Server programeri mnogo vole da im procedura vrati record set, a to Oracle procedure ne rade. Ono, mogu da rade sa PIPE ROW, ali ubija performanse.

Sa druge strane, Oracle voli da vrati REF CURSOR, a SQL Server programeri se samo češu na to.

Onda, neko je smislio da je dobra ideja da se Oracle baza gađa preko JDBC/ODBC, ali Oracle mnogo više voli da se gađa preko SQL*Net-a i da za pristup bazi koristiš OCI pozive, a ne kilavi JDBC/ODBC

[ BuzzLightyear @ 27.11.2020. 11:27 ] @

U mom konkretnom slučaju cela baza je u jednoj tabeli. Pošto su podaci nenenormalizovani cilj mi je bio da napravim funkcije i poglede koje bih prezentovao aplikaciji. Nisam ja projektovao bazu, ne nalazi se na mom serveru, dobijam samo parametre za pristup. Rešio sam problem preko privremenih tabela, samo sve mi je nekako sklepano. Moj utisak je da je Postgresql mnogo više "developer friendly", mada znam da i Postgresql ima svojih problema.

[ bogdan.kecman @ 27.11.2020. 11:48 ] @

@djoka sa previse stvari u ovome sto si napisao se ne slazem da bi imalo
smisla komentarisati detaljno ali neki generalni odgovor...

- ako koristis ORM (fuj, bljak, $^%#%#$^$#) pustis orm da hendla
razlicite upite ka razlicitim bazama na razliciti nacin

- sve ovo ostalo opet pricas o app serveru, ako koristis app server tu
"portability" ne postoji ... prebacivanje sa jedne na drugu bazu je pita
i uvek ce biti pita uz sve alate i kompatibilnosti koje postoje .. psql
se mega trudi da omoguci "lakse" prelazenje sa oracledb na psql (i ne
ide im lose), marija se cima do jaja da omoguci prelazenje sa oracledb i
m$sql na mariju (smeh i tuga) ... mysql je skroz u fazonu - mi ovo sto
radimo radimo do jaja, ako vam to treba bolje nema, ako vam treba nesto
drugo imamo mi i druge proizvode koji nisu mysql .. ali realno svi
veliki igraci se trude da te zakljucaju sto vise mogu (oracledb, db2,
informix...) da ne mozes tako lako da predjes nigde .. tj. da te
prelazak na drugi sistem kosta vise nego licenca za postojeci

u slucaju op-a nije pitanje generalno dal nesto radi ili ne radi i dal
se nesto prebacuje sa X na Y nego je dosao covek koji radi na jedan
nacin na jednom sistemu i dali su mu da odradi nesto na drugom sistemu
gde se stvari rade drugacije, ono na sta je navikao ne radi a ono kako
bi se to uradilo drugacije ne ume jer nikad nije morao tako da radi i
sad je problem kako vozaca mega do jaja nadrkanog kamiona tipa Navistar
LoneStar gurnuti u nascar vozilo tipa toyota camry .. jeste ima i volan
i tockove (14 komada manje nego sto je navikao) i menjac (sa manje
brzina nego sto je navikao) i fali mnogo dugmica i prekidaca na koje je
navikao .. oba idu preko 200km/h ...

[ bogdan.kecman @ 27.11.2020. 12:02 ] @

@buzz, u tvom slucaju bazu je pravio neki demon cije ime ne smemo
izgovoriti ne vratio se nikad :D ... ti si na123 abitno dal ti je ta
"baza" u mysql-u, psql-u, oracledb, db2 ili mongo/kasandra/flat text
file formatu ... na zalost ne postoji pravilan nacin da se resi taj
problem :( osim da se sistem redizajnira kako treba... ja sam imao par
puta priliku da me zovu da vadim iz.. takve projekte ali "bez redizajna"
nego bas to sto sad ti radis ali, fala .!., ja sam mogao da dozvolim
sebi da im pokazem srednji i kazem necu igram igru koja je unapred
izgubljena... opet, da nisam imao u tom trenutku posla jbg radio bi sta
se mora kinta je kinta, racuni dolaze svaki mesec ne pitaju dal je bilo
posla...

psql/mysql iskreno, dev friendly, nije nijedan :( .. oba su retar... i
fali im puno toga .. mysql ima mnogo veci community te je do nekih
odgovora lakse doci ali opet taj veci community generise mnoooogo suma
tako da je potrebno vreme iskopati pravi odgovor u sumi sra... takodje
mysql support od orakla kida milu majku a kosta relativno smesno para,
tako nesto za psql ne postoji ni za 10x vise kinte .. mysql ima mnogo
vise free i mnogo vise paid alata dostupnih .. sad ono, uglavnom ti
treba jedan tako da to sto postoji milion za mysql i 100k za psql i nije
neko veliko m000do al opet ..

a rad u njima ... totalni uzas i jedan i drugi .. ono gde psql sija su
stored procedure, na zalost ni on nema valjani nacin za debagovanje
istih, i optimizer za orm generisanje kilobajtne upite ... ovo prvo je
velika stvar (razlog zasto ja brdo mojih projekata radim u psql, evo
upravo smo poceli novi projekat kao bad-team, nesto sto smo pre 6 godina
pravili u kombo mysql+mongo sada pravimo sa psql-om, preturio sam ovih
dana par stotina tabela i par giga date iz mysql-a u psql, sad pisem
neki app da ovo #$^^%#^ iz monga isto prebacim u psql) tako da .. sp,
baratanje json-om .. psql ftw ... mysql u v8 navodno podrzava vise
stvari od sql standarda (neke cte stvari) i vise funkcija sa jsonom nego
psql, ali meni je psql tu i dalje "logicniji" .... sto se ove druge
prednosti psql-a tice, bolje hendlanje %^#$^% upita, iskreno, ko koristi
te upite ni bog ne moze da mu pomogne tako da ... nebitno :D ... ono sto
mogu da kazem je da moje iskustvo sa dba/dbd koji su odrasli sa psql-om
kaze da isti znaju mnogo manje o dizajniranju baza nego dba/dbd koji su
odrasli uz mysql ... a i jedni i drugi su mala deca u odnosu na one koji
su odrasli uz oracledb i db2 ... no strasna stvar je sto kad pogledas
dobar deo psql baza indexi fale svuda :( ...

elem, tebi nek je bog upomoc .. ti izgleda ne treba da uradis jedan
report iz tog smeca vec moras da napravis neki paralelni sistem koji ce
da radi sa tim smecem .. uzas, ne bi ti bio u kozi :(

[ djoka_l @ 27.11.2020. 12:25 ] @

Da se ne shvati pogrešno, ja volim da radim u MySql-u. Jbg, nema gomilu stvari na koje sam navikao na Oracle ili pg, ali kad prihvatiš ograničenja, lepo vozi.
Još kad uzmeš koliko si para platio, radi i više nego dobro.

Međutim, insistiranje da logika treba da bude na strani app ne u bazi, u mnogo slučajeva ne pije vodu.
Banalan primer, uzmi slučaj da treba da napraviš neku statističku analizu, razlika je da li ćeš da prebaciš preko mreže 100.000 slogova sa baze na app server, ili ćeš tih 100.000 slogova da odradiš u stored proceduri i vratiti 10 linija rezultata.

Ono što je klasična boljka je da se ne radi, u praksi, dovoljna separacija slojeva.
Realan slučaj, pukne ti insert u Oracle bazu, insert pokuša upis null u not null polje. Uzmeš da debaguješ, nađeš da ti je prethodni sloj poslao slog koji sadrži u svim poljima null. Vratiš se još jedan korak i nađeš roman od exception stacka da je neuspela konverzija u int. Vratiš se još jedan sloj i vidiš da je idiot od programera stavio na formu input polje, gde se očekuje numeric a jbn korisnik je uneo slovo.

Programer nije napravio kontrolu unosa po tipu podatka. Bezvezni podatak je prosledio sledećem sloju, koji, takođe, nije proverio ulaz, on sledećoj proceduri ... pa tako 50 nivoa dok neko nije pozvao konverziju u int. Onda je lepo bibliotečka procedura pukla, programer je uredno uneo u log exception stack, a zatim potpuno ignorisao exception, nego je slog sa neinicijalizovanim varijablama poslao dalje.

Zato ja volim da svoju Oracle bazu "ogradim" gomilom stored procedura, zato što znam da imam programere koji nisu bolji od treniranih majmuna.

[ bogdan.kecman @ 27.11.2020. 12:36 ] @

@djoka, ne kazem ja da nikad ne valja da se kroisti biznis logika na
strani baze, samo kazem da kad je to potrebno (ili cak i ako je
nepotrebno ali je tako odluceno iz bilo kog razloga), mysql nije idealan
alat za rad

"velika separacija slojeva" je kao i "agile sistem" i mnogo sta moderna
buda...stina... da ne ulazimo sada u detalje ima vise nego dovoljno
analiza toga zadnje dve tri godine kada se dovoljno ljudi opeklo, raditi
bilo sta na silu zato sto "tako pise u nekoj knjizi" je .... primer koji
si dao nije problem separacija slojeva nego lenstine koje ne rade
kontrolu greske i kontrolu date ... vec je "u apiju pise da uvek vraca i
ja ocekujem da UVEK vraca" .. i slicni junoski stavovi koji se onda u
manjku kvalitetnog kadra promovisu u seniore bez realnog znanja i
iskustva i onda imamo "seniore" koji pisu takav kod ... nikakva
separacija tu ne pomaze vec 10% pa 20% pa otkaz jbg ..

[ Shadowed @ 27.11.2020. 12:53 ] @

@djoka_l, mozda je vreme da menjas programere :)

[ nkrgovic @ 27.11.2020. 12:54 ] @

Citat:

djoka_l:
Međutim, insistiranje da logika treba da bude na strani app ne u bazi, u mnogo slučajeva ne pije vodu.
Banalan primer, uzmi slučaj da treba da napraviš neku statističku analizu, razlika je da li ćeš da prebaciš preko mreže 100.000 slogova sa baze na app server, ili ćeš tih 100.000 slogova da odradiš u stored proceduri i vratiti 10 linija rezultata.

Imao bukvalno ovaj slucaj: PHP, Laravel framework, Eloquent ORM. Djubre. Treba da napravi upit koji je realno JOIN, on umesto 10 redova vrati dva puta po 100,000 jer ucita obe table u aplikaciju i onda radi in-app join. :)

Resenje: Izmeni se ta jedna klasa, napise se jedan upit rucno, kroz PDO. Jedan dan posla, senior developer i ja, imali smo vremena i za rucak i za 2h u workbenchu da odradimo optimizaciju join-a, pregledamo explainove, sve.... Smanjilo zauzece memorije sa, u tom trenutku doslo do 400MB na pristojnih 30MB, ubrzalo izvrsavanje sa 40s na 0,3s.

Alternativa: Napise se view, koji sadrzi taj join i ucita to kroz ORM. Ovo sam pravio sa neki Yii projekat pre par godina, kad je, zbog prirode radne snage, moralo da se to radi kroz ORM. Bio je deo koji samo cita, nista ne pise.

U oba slucaja je i dalje in-applicaiton logika, ali se ne drzis toga kao pijan plota vec koristis mozak i, tamo gde treba, optimizujes. Nije in-application logika isto sto i "koristi ORM", stavise.

[ djoka_l @ 27.11.2020. 13:23 ] @

https://www.youtube.com/watch?v=ecIWPzGEbFc&t=51m00s

Pa sada vidi šta da radiš sa radnog snagom u kojoj 50% ima manje od 5 godina iskustva...

[ nkrgovic @ 27.11.2020. 14:01 ] @

Imas dva izbora:

- Da nadjes bar nekoliko matoraca koji znaju sta rade i debelo ih platis
- Da gledas kako se desava ovo sto je Bogi opisao i sve se raspada....

[ bogdan.kecman @ 27.11.2020. 14:11 ] @

ne mora nesto specijalno da ih plati, ali mora necim da ih privoli da
rade na tom projektu :D

[ Branimir Maksimovic @ 27.11.2020. 15:30 ] @

Citat:

djoka_l:
Da se ne shvati pogrešno, ja volim da radim u MySql-u. Jbg, nema gomilu stvari na koje sam navikao na Oracle ili pg, ali kad prihvatiš ograničenja, lepo vozi.
Još kad uzmeš koliko si para platio, radi i više nego dobro.

Međutim, insistiranje da logika treba da bude na strani app ne u bazi, u mnogo slučajeva ne pije vodu.
Banalan primer, uzmi slučaj da treba da napraviš neku statističku analizu, razlika je da li ćeš da prebaciš preko mreže 100.000 slogova sa baze na app server, ili ćeš tih 100.000 slogova da odradiš u stored proceduri i vratiti 10 linija rezultata.

Ono što je klasična boljka je da se ne radi, u praksi, dovoljna separacija slojeva.
Realan slučaj, pukne ti insert u Oracle bazu, insert pokuša upis null u not null polje. Uzmeš da debaguješ, nađeš da ti je prethodni sloj poslao slog koji sadrži u svim poljima null. Vratiš se još jedan korak i nađeš roman od exception stacka da je neuspela konverzija u int. Vratiš se još jedan sloj i vidiš da je idiot od programera stavio na formu input polje, gde se očekuje numeric a jbn korisnik je uneo slovo.

Programer nije napravio kontrolu unosa po tipu podatka. Bezvezni podatak je prosledio sledećem sloju, koji, takođe, nije proverio ulaz, on sledećoj proceduri ... pa tako 50 nivoa dok neko nije pozvao konverziju u int. Onda je lepo bibliotečka procedura pukla, programer je uredno uneo u log exception stack, a zatim potpuno ignorisao exception, nego je slog sa neinicijalizovanim varijablama poslao dalje.

Zato ja volim da svoju Oracle bazu "ogradim" gomilom stored procedura, zato što znam da imam programere koji nisu bolji od treniranih majmuna.

Znas kako ja do sada nikada nisam izlagao bazu mrezi, nego je logika u middleware aplikaciji koja cuci ispred baze, pa onda komunicira sa klijentima.
No sad baze mogu da se nose sa 1000+ klijenata pa mogu da razumem ;)

[ bogdan.kecman @ 27.11.2020. 15:36 ] @

@branimir, ja mogu da ti potpisem da, ma koliko mozda mogu da rade sa
1000+ klijenata nijedna nije sigurna da bude vidljiva direkt sa mreze
... za mysql i psql mogu dam ruku, a za ostale ti je dovoljno da
pogledas javne cve-ve pa ce ti bude jasno :D ..

[ bogdan.kecman @ 27.11.2020. 15:48 ] @

btw vezano za one lose programere, plate etc... savetujem svima da procitaju

http://remaster.ff.uns.ac.rs/m...d_20201109_psi_320029_2017.pdf

bez obzira sto nije vezano za temu direkt... obavezno procitati

[ nkrgovic @ 27.11.2020. 16:22 ] @

Citat:

Branimir Maksimovic:
Znas kako ja do sada nikada nisam izlagao bazu mrezi, nego je logika u middleware aplikaciji koja cuci ispred baze, pa onda komunicira sa klijentima.
No sad baze mogu da se nose sa 1000+ klijenata pa mogu da razumem ;)

Gledaj, sve i da imas komlpetnu in-database logiku, imaces ispred neki API koji je mnogo lakse obezbediti, a DB server i API server pricaju u privatnoj mrezi, iza firewall-a (switch ili cloud VPC, sve jedno je).

[ djoka_l @ 27.11.2020. 21:24 ] @

Ne znam kakve to aplikacije prave oni koji misle da logika u bazi nije potrebna.
Recimo, ako imaš 200 db jobova koji hendluju asihrnone događaje preko AQ mehanizma, zašto tome nije mesto u bazi?
Ako događaj u bazi (commit) treba da okine 20 asinhronih događaja, zašto kod da ne bude u bazi?
Ako treba da sinhronizuješ 50 baza podataka, a da to bude malo "pametnije" od replikacije, zašto ne kod u bazi?

Ne radimo svi forume i on line prodavnice, da bi nam kod u bazi bio luksuz.

[ djoka_l @ 27.11.2020. 21:39 ] @

Primer: za jedan posao moraš da obezbediš end-to-end odgovor u roku od 3 sekunde. A takvih poslova imaš 10.000 dnevno.
Za drugi posao moraš da obezbediš 10s end-to-end response, a i njih ima 10.000 dnevno.
Sve to dok ti baza od 3TB ima 100-200 commita u sekundi, 500 aktivnih sesija (od kojih je 50 prema "spolja", webu i drugim eksternim kanalima).

Sada, da šetaš podatke između DB servera i srednjeg sloja, zavisiš od latencije i opterećenja mreže...
Zato sve lepo odradiš u bazi, ono što moraš, uradiš odmah, ono što može kasnije upucaš na AQ BUS pa pozadinski poslovi odrade ostatak posla (koji ne bi stao u one 3s).

[ bogdan.kecman @ 27.11.2020. 22:36 ] @

@djoka, postoji veliki broj aplikacija gde ti je app server neophodan...
npr skoro svaki ERP ali iako postoji neki broj ERP resenja koja koriste
MySQL ja bi rekao da je MySQL tu pogresno odabran rdbms.

e sad, sve ovo o cemu pricas je "princip" od pre hrista (ili kako sad
kazu Before Corona i After Corona) i ako pogledas "moderna" SAS resenja
istih sistema koji rade upravo tako (sve je u bazi, van baze je bukvalno
samo shell) can i ERP-ovi nemaju u bazi nikakvu logiku vec je logika
potpuno detached od baze i od fronta i vrlo cesto je cak "serverless" ..
tako da, ne radimo svi webshopove ali ne zivimo svi ni u 20. veku ... a
kada smo prinudjeni da koristimo sistem 20. veka onda za app server ne
biramo MySQL vec nesto drugo :D

potpuno je cudno da sam ja kao neko ko radi za mysql taj koji ovde
govori da mysql nije pravo resenje za sve probleme i da u nekim
slucajevima mysql prosto ne pije vodu

[ nkrgovic @ 27.11.2020. 23:01 ] @

OK, I'll bite:

Job nije u bazi i ne inicira se u bazi - job (skoro uvek) inicira user. Samim tim, ne mozes logiku posmatrati data-centric, kad je aplikacija user-centric. Jednom kad promenis paradigmu, shvatis da je baza ono sto ti je Bogi rekao: state storage koji cuva datu (state) i obezbedjuje mu integritet. Ako razmisljas, ajde da malo parafraziram, na unix nacin, to znaci "do one thing and do it well". MySQL je olicenje toga.

E sad, ako imas trista izmena nad datom koje sve idu odjednom i zajedno, normalno, to je posao nad datom - i radis ga u bazi. Ali, ako imas trista izmena nad trista data, koje nisu (relaciono) vezane - onda nema razloga zasto tu datu ne bi razbio na trista baza (schema, bar za pocetak). Ako imas job queue njemu je mesto u queue softveru (zeroMQ, AMQ, stagod) a ne u bazi. Sta je prednost ovoga: Skaliranje. Ako imas jednu, monolitnu bazu ti po pravilu mozes pisanje u nju da skaliras samo vertikalno. Ako imas mnogo baza i obradu koja je stateless (jer je state u bazi, a obrada uvek radi samo na osnovu inputa) ti obradu mozes da skaliras horiznotalno, a baze su pojedinacno mnogo rasterecenije. Pazi, ovo je potpuno druga paradigma, ali cesto ima dosta prednosti.

Redductio ad absurdum ovog principa je nestruktuirana data. Kao takva, ona je mnogo teza za obradu, ali, ako obradu vrsis na nacin koji je paralelabilan, map-reduce ce ti omoguciti da krajnji rezultat dobijes mnogo brze i mnogo jevtinije. Jednostavno, manje kosta trista masina po 256GB RAM-a i 64 core-a, nego jedna sa 32TB RAM-a 640 core-ova, ako je ova druga manje od trista puta veca (odokoativno 10/100 puta) - posebno ako znas da ove prve mozes, kao commodity, da iznajmis na minut, samo koliko ti treba, a ova druga, ako i ima da se kupi, kosta milione.

Ne kazem da su velike baze zastarele. Ima primena gde imaju smisla, gde sva data jeste povezana i tu nemas puno izbora. Ako porastes dovoljno, javice se neko da ti proda Exadata za to, za lepe pare i Oracle stvarno radi vrhunski te sisteme. Stavise, to sad cak ima i kao cloud. Ali, ako mozes da skaliras horiznotalno, uvek ces biti u prednosti, zato treba razmisljati o tome na vreme.

BTW, mysql bez problema ima desetine hiljada insert/update upita u sekundi na masini koja kosta par stotina EUR mesecno. E, ali taj mysql (konkretan, sad ga nesto gledam) nema trigere, nema stored procedure, sve to je prebaceno na aplikativnu logiku. Biznis logika je u aplikaciji. Baza radi svoj deo i radi ga fantasticno brzo, a sporiji i zahtevniji deo posla je na aplikaciji koja moze da se - paralelizuje.

Opet, kazem, slazem se da ima primena gde je database-centric prava mera, ali, ako mozes, uvek je bolje to izbeci.

[ djoka_l @ 28.11.2020. 02:07 ] @

Radio sam sa kontejnerima i mikroservisima.
Kada aplikaciju razbiješ na 100 mikroservisa, a uptime svakog od njih je 99%, znaš kolika je raspoloživost sistema?
36%

Ako napraviš monolitnu aplikaciju, db centric, a raspoloživost baze je 99% dobiješ raspoloživost sistema od 99%
Osim toga, gubi se gomila vremena kad se sistem razbije na puno mikroservisa na komunikaciju između njih, ne samo zbog konačnog truputa mreže i latencije mreže, nego i zbog konstatnog konvertovanja podataka kojima se komuniciraju poruke između servisa (ono, imaš int podatak, konvertuješ u JSON, pa JSON na drugoj strani konvertuješ u int).

[ Branimir Maksimovic @ 28.11.2020. 05:52 ] @

Citat:

djoka_l:
Primer: za jedan posao moraš da obezbediš end-to-end odgovor u roku od 3 sekunde. A takvih poslova imaš 10.000 dnevno.
Za drugi posao moraš da obezbediš 10s end-to-end response, a i njih ima 10.000 dnevno.
Sve to dok ti baza od 3TB ima 100-200 commita u sekundi, 500 aktivnih sesija (od kojih je 50 prema "spolja", webu i drugim eksternim kanalima).

Sada, da šetaš podatke između DB servera i srednjeg sloja, zavisiš od latencije i opterećenja mreže...
Zato sve lepo odradiš u bazi, ono što moraš, uradiš odmah, ono što može kasnije upucaš na AQ BUS pa pozadinski poslovi odrade ostatak posla (koji ne bi stao u one 3s).

Ne znam, ja sam do sada radio srednji sloj da bi zastitio bazu od downtime-a, naime baza nije mogla da opsluzi...

[ dejanet @ 28.11.2020. 09:02 ] @

Citat:

bogdan.kecman : "velika separacija slojeva" je kao i "agile sistem" i mnogo sta moderna
buda...stina... da ne ulazimo sada u detalje ima vise nego dovoljno
analiza toga zadnje dve tri godine kada se dovoljno ljudi opeklo, raditi
bilo sta na silu zato sto "tako pise u nekoj knjizi" je .... primer koji
si dao nije problem separacija slojeva nego lenstine koje ne rade
kontrolu greske i kontrolu date ... vec je "u apiju pise da uvek vraca i
ja ocekujem da UVEK vraca" .. i slicni junoski stavovi koji se onda u
manjku kvalitetnog kadra promovisu u seniore bez realnog znanja i
iskustva i onda imamo "seniore" koji pisu takav kod

Citat:

djoka_l: Kada aplikaciju razbiješ na 100 mikroservisa, a uptime svakog od njih je 99%, znaš kolika je raspoloživost sistema?
36%

Izvinjavam se ako sam izvukao iz konteksta, posto bolje ne mogu da napisem od ovoga gore

[ nkrgovic @ 28.11.2020. 10:19 ] @

Citat:

djoka_l: Radio sam sa kontejnerima i mikroservisima.
Kada aplikaciju razbiješ na 100 mikroservisa, a uptime svakog od njih je 99%, znaš kolika je raspoloživost sistema?
36%

Ako napraviš monolitnu aplikaciju, db centric, a raspoloživost baze je 99% dobiješ raspoloživost sistema od 99%

Ima ovde dve stvari:

- Ako je uptime svakog od 100 servisa 99% i AKO SVAKI IMA DOWNTIME U RAZLICITO VREME uptime celog sistema je 36%
- Uptime od 99% je mozda OK za jedan kompleksan sistem, uptime od 99% je katastrofalno lose za mikroservis koji ima jedan prost task. :) Vreme da restarujes kompleksnu bazu, tipa prost update-and-reboot za DB server ti oduzme pola sata. Vreme da uradis redeploy mikroservisa koij samo radi login (cita iz baze, vrati token) ti napravi downtime od oko 30s, plus ako imas vise od jedne instance servisa, realni downtime pri deploy/udpate je nula.

OK ti je matematika, samo mnogo pretpostavljas. Vecina sisetema ima mnogo bolji uptime od 99% - posebno prostih.

Citat:

Osim toga, gubi se gomila vremena kad se sistem razbije na puno mikroservisa na komunikaciju između njih, ne samo zbog konačnog truputa mreže i latencije mreže, nego i zbog konstatnog konvertovanja podataka kojima se komuniciraju poruke između servisa (ono, imaš int podatak, konvertuješ u JSON, pa JSON na drugoj strani konvertuješ u int).

Ovo je zapravo mnogo bolji argument. Apsolutno si u pravu. Ja i ne kazem da je sve dobra meta za mikroservise - stavise ja tvrdim da mnogo toga NIJE dobra meta za mikroservise. Layered monolit je super model, laksi je za rad, bolje funkcionise. Ali :

- Monoliti lose skaliraju. DB centric monolit katastrofa skalira - jer skalira samo vertikalno.
- Monolit koji ima logiku u aplikaciji i dalje bolje skalira jer, ako je aplikacija stateless, a state drzi u bazi (koja samo obezbedjuje data storage i referencijalni integritet, kao sto je gore Bogi lepo rekao), ti bar mozes da skaliras aplikativni sloj horizontalno.

Cak i izuzimajuci mikroservisknu arhutekturu (koji sam naveo kao svodjenje na apsurd, tj. ekstremni slucaj), i dalje se logikom u bazi gubi skalabilnost sistema. Monolit sa logikom u aplikaciji skalira bolje od monolita sa logikom u bazi. Dodatno, ako je domenska logika u aplikaciji, a aplikacija je takva da je vecina obrade podataka citanje, izmestanje logike u aplikaciju ti omogucava da iz aplikacije kesiras podatke kad se koriste samo za citanje (prezentaciju korisniku) i time dodatno ubras celu stvar. Dalje, ako je aplikaciaj stateless, ili cak ima shared state storage, ti mozes da imas vise od jedne instance u startu - i da imas tako implementiran high availability. Implementirati multi-master high-availability na bazi i sistemu koji je db-centric jeste moguce, ali je jako, jako skupo.

Moj argument protiv db centric sistema nije vezan za to da li je to "dobar" sistem - samo da je skup u startu i da jos skuplje skalira. Ti pricas o sistemima koji imaju 50 transakcija u sekundi, ja pricam o sistemima koji imaju 5000 ili 50,000.

[ Branimir Maksimovic @ 28.11.2020. 10:41 ] @

Nikola:"izmestanje logike u aplikaciju ti omogucava da iz aplikacije kesiras podatke kad se koriste samo za citanje (prezentaciju korisniku) i time dodatno ubras celu stvar."

Pa to recimo imas izvlacenje mesecnih/godisnjih izvestaja koji uzimaju po 15 minuta do pola sata po queriju. I ono 10-20 klikova i baza je neupotrebljiva.
Lepo sam stavio da kesira, moze kolko hoce klikova jer onda treba samo jedan query na n klikova ;)

[ bogdan.kecman @ 28.11.2020. 10:50 ] @

@djoka, moz bidne a ne mora da znaci :) .... ti pricas o sporom
glomaznom inertnom sistemu poput nekog erp-a u nekoj delti... ja vec 15
godina zivim od sistema gde minuti downtime-a znace milione gubitka i
99.0% se ne smatra u prihvatljivu cifru, prihvatljivost krece od 5
devetki na gore i tu se racuna i "planned maintenance" .. znaci sve sa
planiranim downtimeom moras da imas 5 devetki, dakle stvari poput online
upgrade i online backup su stvarnost a sistemi nisu tromi poput nekog
erp-a vec vrlo dinamicni i obradjuju u minuti vise date nego jedan erp
za godinu dana :D .... sve ima svoje, TOC je vrlo kompleksna stvar,
koliko kosta sw, koliko kosta hw, koliko kosta odrzavanje, koliko kosta
razvoj sto u ljudstvu sto u vremenu ... tu je nekad cena samog rdbms-a
ili apps-a potpuno nevazna (iako je u milionima npr) ... ali zato ultra
fancy support za mysql bez ndbcluster-a kosta 5000$ godisnje sto je
priznaces pateticno obzirom na benefit koji dobijas (to ti je jedna
mesecna plata prosecnog dba) dok recimo ista firma za mysql ndbcluster
support naplacuje isti OD 40,000$ godisnje (startna cifra je 40k i ne
ukljucuje mnogo toga) .. a mogu ti kazem da je prosecna cifra koju moji
klijenti placaju za support (tj da imaju pristup meni i par mojih
kolega) oko 10,000,000 godisnje :) ... nemam ideju koje su cifre za
oracledb, exadata, db2...

takodje sve i da pricamo o 99% a ne o bar 99.999% opet ti je matis za
36% los :D posto opet zavisi od toga kako si dizajnirao sistem :) ...
100*95% moze da bude 100.00% a moze da bude 10% zavisi kako je sistem
dizajniran

% su statistika, realnost je da je recimo jedan klijent imao 100% uptime
10 godina i onda je, ljudskom greskom, imao downtime 3.5h ... steta oko
15 miliona evra, i to im je poje4$#@$ uptime na 99.996% ... tako da je
sad pitanje kako to racunas, dal samo tu godinu, ili svih 10 godina
koliko sam ja zaduzen za njih, ili racunamo 15M stetu ili ne racunamo
uopste posto je sistem ok nego je doso tenkre i zas123 motku ili ...
kako racunas uptime % kada teroristicki napad u usa ugasi 10 data
centara od ukupno 20 na celom kontinentu (bilo davno) ili kada jedini
kabl izmedju usa i evrope bude presecen?.... tako da .. je...es
procente, gledas sta ti je SPOF, DPOF, gledas kako da se zastitis od
seniora iz kine, indije, srbije .. uplatis jednom godisnje neki dinar
pravoslavnoj, katolickoj, budistickoj, islamskoj, jevrejskog i svim
ostalim crkvama koje nadjes zlu netrebalo ako se desi da je neka od njih
ipak u pravu ko zna mozda pomogne, i to je to .. i pre svega dobro
dokumentujes ceo sistem ukljucujuci sve procedure i nadas se najboljem
:) ..

[ bogdan.kecman @ 28.11.2020. 11:02 ] @

> Pa to recimo imas izvlacenje mesecnih/godisnjih izvestaja
> koji uzimaju po 15 minuta do pola sata po queriju.
> I ono 10-20 klikova i baza je neupotrebljiva.

napravis lepo read only repliku koja je uvek up2date a nad kojom vrsis takve smaracke upite i bole te uvo sto si zabo tu instancu baze na X sati ... to je jedan od glavnih razloga zasto neke aplikacije koje bi imale ozbiljan benefit od psql-a ipak koriste mysql jer psql replikacija tek zadnjih godinu dana "donekle radi" a i to je pateticno a neke ozbiljnije stvari poput group replication, innodb cluster, galera i slicno psql jos uvek moze samo da sanja ..

dodatno, na zalost samo na cloud verziji mysql-a, postoji rapid engine koji radi kao shadow engine iza innodb-a i optimizer bira da li da izvrsi upid nad jednim ili drugim se te olap i slicni reporting upiti rade gzilion puta brze na petabajtnim podacima... nesto sto bi normalno gurao u redshift ili neki map reduce sada mozes direkt iz mysql-a ... no, ko sto rekoh, na zalost samo na oracle cloudu... no cena je takva da ima smisla... imas za mariju columnar se koji pokazuje da ce mozda biti iskusan u buducnosti no glavni developer je zapalio u prijatniji tim za rad pitanje sta ce biti sa tim.. a ko zna, mozda rapid dodje na on-prem, jednom, ako ne foss onda bar za $$

[ Branimir Maksimovic @ 28.11.2020. 11:13 ] @

Bogdan:"napravis lepo read only repliku"

Da al, i nad tom replikom ce da potraje ;)
Mislim da je cache u ovom slucaju bolje resenje zato sto prakticno dobija iluziju da to traje na nivou milisekunde..

[ bogdan.kecman @ 28.11.2020. 11:15 ] @

vezano za procente, evo jedan primer iz realnog zivota

mysql cluster ima

- management nodove

- data nodove

- api nodove

management nodovi su bitni u slucaju starta sistema, sistem ne moze da
startuje bez njih i novi nod ne moze da se prikljuci klasteru ako mgm
nodovi (bar jedan) nije prisutan, oni rade i logovanje ali realno ako
bar jedan mgm nod radi sve je ok, ako svi nodovi crknu novi "ne mgm" nod
ne moze da se prikljuci klasteru i nemamo logovanje

data nodovi cuvaju i isporucuju datu, u grupama su po dva znaci uvek ih
je paran broj i dokle god je grupe od dva jedan radi klaster je
dostupan, ako umru 2 iz iste grupe cluster je down ... znaci ako imamo
100 data nodova moze 50 da crkne i da sistem bude up a moze 2 da crkne i
da sistem bude down, zavisi "koja 2" crknu ...

api nodovi su tvoja aplikacija

i sad, imamo americki nosac aviona koji koristi mysql cluster u sistemu
navigacije, ne radi mysql cluster i nosac gubi navigaciju i upravljanje,
recimo da je to bitna stvar za jedan nosac aviona, meni zvoni telefon u
neko nevreme, umro je klaster na nosacu aviona i sve je otislo u .!.

resimo problem, ne bude nista strasno, steta nula, radimo postmortem

0. imaju setup sa 4 mgm noda, 4 data noda i brdo api nodova

1. crko im je jedan mgm nod pre 6 meseci, jedan mgm nod pre 3 meseca i 1
mgm nod pre mesec dana, rade sa samo jednim mgm nodom - ok za sistem ali
admin ignorise mrtve nodove mesecima!!!

2. crko im je jedan data nod pre 6 meseci, admin ignorise to da mu jedan
data nod mrtav 6 meseci!!!!

3. sad im je crko drugi data nod u istoj grupi i klaster je down

koji je planirani uptime ovog sistema i ko je kriv? onaj ko je
dizajnirao sistem ili pajser koji je trebao da pazi na njega al je
navikao da "to radi sta god da mu se desi" pa ga je ignorisao do
"sledeceg revampa u portu"