Migracije i velike baze podataka

Do tell.... Zivo me zanima kako to prodas nekome ko ima bazu od 1TB pa mu alter table traje 2-3h.... (podatak iz prakse, masina sa 4xNVMe u RAID 10, Xeon, 128GB RAM)? Kazes mu "e, bice ti lockovana baza, sajt ti nece raditi 6 sati, ali to je super za konzistentnost!" ? :D

Nemam nista protiv migracija, super su mi za pravljenje pipeline-a u gitlabu, testove, rad na developerovoj masini.... ali onog trenutka kad dodjes do test servera (to je onaj sto ima live datu, samo indemnifikovanu - ali u punoj kolicini), onda imas problem. Takodje, taj pristup podrazumeva u 99% slucajeva i neki ORM, pa to zavrsi sa programerima koji se drze istog "k'o pijan plota", sto tek ume da napravi problem.... Banalno, zbog samog koncepta horizontalnog skaliranja i logike u kodu a ne u bazi, kad ti treba da dodjes do nek date iz vise tabela svaki ORM koji sam ja video ce povuci podatke pojedinacno i onda odraditi to u memoriji. Razmisli kako bi izgledala implementacija EAV modela na tome, za ecommerce sajt sa par miliona artikala? A onda razmisli kako to radi kroz jedan ili dva JOIN-a, kad baza sve to sama uradi, a jedino imas JOIN po primarnom kljucu.

Vidi se da mrzim ORM-ove, a? :)

<sub>[Ovu poruku je menjao Nemanja Avramović dana 26.09.2019. u 09:43 GMT+1]

[Ovu poruku je menjao Nemanja Avramović dana 26.09.2019. u 09:43 GMT+1]</sub>

---

Voleo bih da ovde nastavimo diskusiju koja se povela na drugoj temi, pa sam izdvojio poruku u novu temu.

Skoro sam radio neki alter na tabeli od 9+M redova i deploy - kad se ugl. ispucavaju migracije je trajao dobrih 45 min. Brine me sta ce biti u buducnosti kad jos poraste tabela, sta bi ti predlozio za ovako velike izmene na live (ili dev ali podjednako velikim) bazama?

ORM-ovi su cool za CRUD, za bilo sta sto ukljucuje vise tabela samo custom SQL, naucio na svojim greskama

---

Glupo pitanje: Pošto dolazim iz Oracle okruženja, na kojoj to bazi podataka dužina izvršavanja ALTER TABLE zavisi od broja redova u toj tabeli?

Oracle ALTER TABLE samo menja JEDAN slog u SYS šemi u tabeli objekata, a ne sve redove u tabeli.

Prvo, ja bi gledao da mi dizajn bude kako treba. To je osnovno. Baze podataka se dizajniraju u skladu sa normalnim formama. 3./BC minimum 4. izuzetno pozeljno. Denormalizacija se radi, ali, posto prvo uradis normalnu bazu. Po meni, tako treba poceti, znam da je agile reci samo YAGNI i ici sa ORM-om, ali, po meni, ako projekat ima ikakve sanse da naraste, tj. ako baza nije samo storage - treba odvojiti vreme.

Drugo, Bogdan mi je jednom ovo rekao, sto sam mnogo dobro zapamtio "Denormalizaciju radis kad si siguran i obavezno zapises STA si uradio i ZASTO jer ce ti trebati to za par godina"... parafraziram. :) Nadam se da ce on da se ukljuci, zna mnogo vise o bazi od mene. :)

Trece, kad su baze pocele da se koriste, nije bilo clustera. Zato su isle dinamicke forme, kao EAV model. Ti u EAV modelu, kad hoces da dodas cipele ne dodajes u tabelu "predmet" kolonu "broj cipela" alterom, ti samo dodas atribut "broj cipela" u tabelu atributa, "46" u tabelu vrednosi i srucis za cieple broj 46 par slogova u vezne tabele. Ova sema, osim sto smanjuje kolicinu date i normalizuje podatke ima i prednosta da omogucava dodavanje osobina bez altera.

Kad si sve sto mozes iscrpeo, a moras da imas alter, onda gledas resenja specificna za bazu. Ja cu sad preci na MySQL njega najvise koristim za ovakve stvari:

MySQL replikacija ima zgodnu foru da, ako uradis alter na slave-u, tako da alterom dodajes kolonu NA KRAJ tabele (obavezno vodis racuna kad pises alter) replikacija ce nastaviti da radi. U bilo kom slozenom sistemu, gde imas master i bar dva slave-a, ti mozes bez problema da napravis alter na slave-ovima, proglasiss jedan od njih za novi master, i onda uradis alter na preostaloj masini. Malo je igranka i radi se u krug, ali tako mozes da radis alter tabele i od 100GB bez da ista pukne ili lockuje. Sve dok ne pises nista u te kolone (a ne pises, jer ti je master na starom do poslednjeg trenutka), imaces neki mali downtime jedne od masina, imaces dosta posla - ali sama aplikacija ce videti konzistentnu bazu sve vreme.

Ovo je inace i jako dobra fora po pitanju index-a. Neki indexi ti ne trebaju na masteru, vec npr. samo na slave-u na koji pustas npr. upite za OLAP (obicno je ovo dedicated slave). Da bi ustedeo I/O, ti mozes da imas taj index samo na tom slave-u. Mozda ce on malo da kasni u replikaciji, ali ako imas up i down periode sajta mozes da obezbedis da nikad ne kasni previse - posebno za OLAP koji relano nikad nema problem dok su podaci tu do npr. jucerasnjih.

Ja jako volim devops metodologiju, zato se i bunim kad tako zovu radno mesto. Ovakve stvari su na primer nesto sto se tesko automatizuje i zahteva malo vise manuelnog rada. Proceduru je, sto ja najbitnije, moguce imati vrlo lepo definisanu, kao neki playbook (ne ansible, vec onaj starinski... dokument u nekom wikiju), ali neke stvari je jako tesko napraviti kroz kod.

Nisam pristalica toga da alter znaci da je baza lose projektovana, najcesce to vidjam kad klijent, posle 6 meseci, shvati da on zapravo ne zeli blog o angus govecetu, vec da to treba da bude prodavnica elektricnih trotineta, jer to je samo par izmena, vi cete sve to kompijuterski.... :D. Ono sto mislim je da relacione baze nisu sustinski pogodne za microservices model rada i nece biti dok se ne obezbedi kompletan decouple same baze na microservices, dok se persistent storage ne decouple-uje od api-ja, i dok storage ne postane, kao sto je za sve ostalo, beskonacno brz. (U praksi sve ispod 1ms je beskonacno brzo... ako trosim maximalno 10,000 IOPS-a u piku, meni je storage od 100,000 IOPS-a beskonacno brz... ).. Kako se to realno nece desiti, jer baza nikad nece biti stateless (ne moze, posao joj je da cuva state - zato je baza), plus ce data uvek biti mnogo, mislim da cemo jos dugo vremena ziveti sa relacionim bazama i njihovim osobinama.....

Naravno, imas uvek alternative, tipa prave big data sisteme, gde sve drzis u fajlovima, sve je schemaless, decoupled... ali ti sistemi imaju brdo svojih problema, jednostavno ne mozes da imas finansijske podatke u parquet formatu fajlova i da radis upite kroz HBase ili Hive - trebaju ti odgovori brzo, trebaju ti indexi, trebaju ti transakcije i lockovanje, to su sve stvari direktno vezane za state - i to je glavni razlog zasto ne mozes da imas sve "moderno".

---

Entity Framework radi join-ove u sql-u. Mislim da i Linq2sql takodje, ali se ne secam vise.

---

Pa recimo dodas polje mora da prodje kroz sve redove recimo da postavi default vrednost? Ili Oracle to radi drugacije?

OK, ja to posmatram sa stanovišta DBA i DevOpsa. Ne bi meni taj projektant dugo ostao u firmi da se seti kako mu je u tabeli od nekoliko miliona slogova potrebno da doda not null polje koje bi u 99.9999% slučajeva imalo default vrednost.
Sa druge strane, to se radi tako što se doda null polje koje ima default vrednost, pa da se onda radi BULK UPDATE, recimo po hiljadu slogova, a na svakih hiljadu slogova da ide COMMIT. Kada se prođe kroz sve slogove, onda se ponovo promeni polje, da bude not null.

Sve to se lepo začini sa time da se nad tabelom napravi view koji null nad poljem pretvara u default vrednost ( funkciojom nvl - nvl(ime_polja, default_vrednost) ), a nad pogledom se postavi instead of trigger koji hendluje pokušaj upisa null u to polje.

Nije ti se nikad desilo da korisnik posle nekog vremena kada je već odavno baza u upotebi i napunjena je traži neku dodatnu funkcionalnost koja se rešava dodavanjem nekih kolona u tabelu?

---

Opet ti kažem, ja to gledam kao DBA.
Šta dobijaš time što si dodao NAKNADNO polje za koje si smislio da treba da bude not null? Dobijaš samo da ti baza radi proveru, a to lepo možeš da delegiraš i na aplikaciju.
Recimo, ja vrlo retko koristim FOREIGN KEY constraint. On ti samo usporava upis i brisanje, a ne ubrzava ništa. Više smeta nego što koristi.
Sa druge strane, gomila "developera" i "programera" očekuju da im neki alat automatski generiše šemu baze, SQL, generiše aplikaciju na osnovu toga koje su ti tabele povezane FK relacijama. Ja takve loše programere zovem "Windows" programeri, mada sam čuo za dvojicu koji to rade i na Linuxu.

Ma ne treba ni indekse da koristiš, ni normalizaciju, sve to može aplikacija da uradi. Tako rade pravi programeri :)

Posao baze podataka je da obezbedi integritet baze podataka. Ako je not null pravilo nad bazom onda se baza time mora i baviti.

---

Toliko muke oko jednog polja. Vise vremena ces utrositi baveci se tom gimanstikom nego pustiti jedan alter. Mislim cemu baza? Sve moze da se odradi sa fajlovima...

Potpuno se slazem. Baza je tu da se sacuvaju $$$ inzenjerskog vremena.

Sreca nasa pa se ti ne pitas ko ostaje u "firmi". Mozes sad na bis da objasnis i kako je Web Application Firewall gubljenje vremena, sto glupi i lenji programeri ne garantuju da nece imati nijedan SQL Injection u kodu? :)

Ajmo polako :

- DevOps kao metodologija proistice iz Agile-a i Lean Manufacturing-a, tj. iz automobilske industruje, tamo, koliko se secam, kraja sezdesetih godina proslog veka. Cilj metodologije je bas veliki broj promena :). Samim tim, ovo sto ti pricas nema veze sa metodologijom - jedino ako si ti od onih koji sami sebe zovu tako... ;)

- Poslovni zahtevi se menjaju. Na zahtev klijenta, zbog compliance-a, jer se promeni neki propis.... Treba li programer da zna kako ce se menjati zakon? Ko treba da predvidi ako klijent hoce da od bloga o leopardima napravi prodavnicu mobilnih telefona? :)

- Constraint, Foreign key i sve ostale metode dodatne provere i te kako imaju svoje mesto u produkciji. Je'l ti stvarno mislis da si najpametniji, a da su svi koji rade dev u Oracle-u, IBM-u i gde vec glupi - pa to prave? Cekaju da im objasnis ? :) Zapravo, od dobrog DBA se ocekuje da on radi na proverama paralelno sa proverama iz koda, za neke, kriticne, podatke.

- U zavisnosti od aplikacije, nekad je provera u kodu dovoljna. Nekad, kao npr sa finansijskim podacima, imas proveru i u kodu i na nivou baze, i jos po koji put. Da, trosi resurse. I dalje kosta manje nego da izgubis pare ili popijes kaznu od poreske. Ako zafali IOPS-a, odes i trazis jos. Nikad mi se nije desilo da kazem "nemamo resursa da obradjujemo protok novca, jer to radimo pazljivo" i da odgovor bude "radite to malo vise ofrlje, sta proveravate dvaput", ili da bude "pa onda smanjite kolicinu novca koja nam dolazi u preduzece". Nadje se novac za to.

- Alter table u MySQL-u i da je polje null ce presloziti celu tabelu. To je sad sredjivano u MySQL 8 koliko se secam, ali na verzijama do 5.7 je prepakivalo sve i to nisi mogao da izbegnes. Imale su forice tipa pt-online-schema-change, ali si morao da preslozis tabelu. Again, nije se neko "dosetuo da doda polje", nego je promenjen zahtev kako treba da radi softver.

---

I kako odrzavas konzistentnost podataka ?

Kako održavati konzistentnost?

Evo primera koji ne može da reši foreign key. Imaš tabelu u kojoj jedno polje može da ima vrednost samo ako postoji u drugoj tabeli. I onda ti neko kaže, u drugoj tabeli su vrednosti 1,2 i 3 do 30. septembra, ali posle tog datuma treba da bude 2,3 i 4. Zbog istorijskih podataka ne smeš da brišeš vrednost 1, a moraš da dodaš vrednost 4 u tabelu posle 30. septembra.

Ako ti imaš alat koji ti pravi listu vrednosti "automatski" na osnovu FK relacije, nemaš kontrolu vremenske dimenzije. Aplikacija mora da dozvoli da se, ako se unosi podatak "unazad" dozvoli unos 1 do 30. septembra, a ne dozvoli unos broja 4. Posle 30. septembra dozvoljeni unosi su 2, 3 i 4.

Uslovi mogu da budu i "višedimenzioni" ne tako prosti kao jedan datum. Onda FK postaje više smetnja nego korist. To treba da reši aplikaciona logika.

Imam jako loše iskustvo sa time kako programeri rešavaju exception. Neko bi rekao, ok, neka baza digne exception pa će onda "neko" da reši problem - što je primer tipa programiranja koje ja zovem "brigo moja pređi na drugoga".

Primer iz prakse: dobijam stek greške od stotinak linija - razlog, programer nije napravio validaciju da li polje na ekranu sadrži samo cifre. Poslao je jednom servisu ono što piše u polju, pozvana je druga metoda u kojoj prva nije proverila ulazni parametear, onda treća, ... , desta i onda jedanesta metoda pozove bibliotečku funkciju koja radi konverziju u int i sve pukne. Ili pukne na upisu u bazu zato što je polje number. Lepo što je baza odradila validaciju, ali je greška morala da bude uhvaćena mnogo ranije i bolje hendlovana...

I koliko je takvih primera u celoj bazi, ja bih rekao 1 %.
A ostalih 99 % ces da ostavis na milost i nemilost backend i frontend programera...

Inace, za taj slucaj sto si naveo, ako sam dobro razumeo, se koristi check constraint a ne FK.
A u check constarintu se koristi f-ja u koju teorijski (i prakticno) mozes da stavis logiku za n redova velicine komplikovaniju od te sto si naveo...

Daj nemoj da budeš bukvalista. To što sam ja napisao primer sa tri vrednosti može i drugačije da se napiše.
Šta ako FK pokazuje na tabelu od milon rekorda u kojoj je milion računa. Pa se onda zbog raznih razloga napravi preknjiženje na drugih petsto hiljada računa, pa onda FK pokazuje na tabelu od 1.5 miliona zapisa od kojih milion bolje da nisu tu.

Ne znam da li ste videli ovo na linkedin, komentar na video je: kako junior specialist radi hotfix na produkciju:

Nisam te razumeo ovo za racune, racuni su ovde child strana relacije, mozes s njima da radis sta hoces (dok god ima neki parent rekord, a mora da ima !!!, inace su podaci djubre), ali ajde neka si u pravu, nek su ovde fk smetnja.

A kontraprimeri:
- faktura i stavke fakture
- organizacione jedinice
- currency
- faktura i customer
.....

I u tvojim bazama koliko procentualno imas ovih prvih a koliko drugih primera ?

Ako bi se radilo preko ORM-a... i da ne bude "zagusljivo" a vec pricamo o migracijama koje su sastavni deo Laravela.

Kakve su sanse da se napravi novi kontroler/servis koji bi to radio i ubacio kao job, da ne radi sve odjednom? Figurativno pitam.

Licno imam jedan core PHP projekat koji ima bazu sa trenutno preko 70 miliona slogova. Ako ikad pozelim to da prebacim na Laravel, bice problema.

---

Nemoj mešati aplikativna pravila sa integritetom baze.

Osnovni zadatak baze je da obezbedi integritet baze podataka. To znači da ona treba da obezbedi da se ne mogu uneti neispravni podaci. Da li su oni netačni nije bitno.

Tek ako se odluči da se i tačnost podataka proverava na nivou baze onda se i to realizuje u bazi.




Generalno je loša praksa na više mesta raditi istu stvar.

Ako se odluči da proveru tačnosti podataka radi baza onda to treba da radi baza.

Ako se odliči da se provera tačnosti radi na nekom višem sloju, onda to radi taj viši sloj.

Ako radiš istu proveru na dva (ili više mesta) onda si se osudio na probleme koji će te zadesiti pre ili kasnije, zato što su pravila sklona izmenama (naročito u knjigovodstvenim aplikacijama).

U savremenoj praksi, tačnost podataka se najčešće proverava na nekom sloju iznad baze (ili čak na više slojeva zavisno o kakvim proverama se radi). Razlog je praktičnost. Savremeni zahtevi su često takvi da se pravila tačnosti često menjaju, dinamična su i čak ih često korisnik može i sam podešavati. Sve to je mnogo komplikovanije realizovati na samoj bazi i mnogo je lakše uraditi u aplikaciji.

---