Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Migracije i velike baze podataka

[es] :: PHP :: Migracije i velike baze podataka

Strane: 1 2

[ Pregleda: 6484 | Odgovora: 38 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 08:14 - pre 54 meseci
Citat:
Zlatni_bg:
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.

Ako imas samo jedan database server, nekako je moguce. Ako imas slozenu replikacionu semu, onda moras da imas alat koji upravlja replikacijom, koji ima API sa kojim mozes da se povezes sa kontrolera... Verovatno je moguce, ali ja to nisam radio. Iskreno, dovoljno je retko da ne moras da radis.

U svakom slucaju, ti mozes da napravis servis koji ce da uradi alter table i prebaci sve kako valja, ali da taj servis to radi koristeci migracije mislim da ne mozes. Bukvalno bi morao da override-ujes ceo mehanizam migracija da bi ga naterao da to tako radi... Ne znam da li ti se isplati, bukvalno ces prepraviti pola eloquent-a. :) Po meni onda lakse da batalis eloquent i predjes na cist PDO - neki moji developeri tako rade.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 08:17 - pre 54 meseci
Citat:
Predrag Supurovic: Generalno je loša praksa na više mesta raditi istu stvar.

Generalno si u pravu, ja sam naveo primer koji sam imao u praksi da se proverava na dva mesta. Ne bas ista stvar, baza je proveravala integritet i konzistentnost, a aplikacija neku biznis logiku. Nije bila racunovodstvena aplikacija, ali recimo da je baza proveravala, ajde najblizi analog, kao da ne mozes da upises izmenu na kartici, ako nisi prvo uneo fakturu ... tako nesto.

Poenta je da provera na nivou baze nije, i ne treba da bude smatrana losom, posebno ne za kriticne poslove.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 11:47 - pre 54 meseci
Citat:
nkrgovic: Generalno si u pravu, ja sam naveo primer koji sam imao u praksi da se proverava na dva mesta. Ne bas ista stvar, baza je proveravala integritet i konzistentnost, a aplikacija neku biznis logiku. Nije bila racunovodstvena aplikacija, ali recimo da je baza proveravala, ajde najblizi analog, kao da ne mozes da upises izmenu na kartici, ako nisi prvo uneo fakturu ... tako nesto.


To su različite provere i rade se na mestima gde je to logično. Ono što ne valja je raditi istu proveru na dva mesta.

Citat:

Poenta je da provera na nivou baze nije, i ne treba da bude smatrana losom, posebno ne za kriticne poslove.


Daleko bilo da je loše.
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 12:22 - pre 54 meseci
Ni ja ne smatram da je provera na nivou baze loša.
Poenta je, da između toga da mi 24/7 aplikacija bude 12 sati ugašena zato što treba da se doda not null polje lošija opcija od toga da se to polje doda kao null. A da se kontrola da li je polje popunjeno radi u aplikaciji.
Više volim da mi aplikacija vrati grešku PRE nego što baza vrati exception.
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 12:34 - pre 54 meseci
Uvek možeš da napraviš novu tabelu u koju ćeš da staviš dodatno polje i zatim napraviš 1:1 vezu sa osnovnom tabelom.

 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 12:45 - pre 54 meseci
Ali ne mozes da na primer dodas index bez altera, a mysql 5.7 (i stariji) ce ti i za to lockovati tabelu....

Da se razumemo, kapiram ja sve. Naravno da je bolje nova tabela. Naravno da je alter generalno losa ideja. Ali to je teorija, ja nekad samo dobijem task "pusti alter", pa sta sad? Nekad taj alter menja dve nedelje programiranja, a nekad resava problem performansi - i bolje da odvojim dan da ga pustim, nego da resavamo drugacije. Niko ih ne trazi "eto tako" ili iz dosade, svi koji rade 10+ godina znaju sve ovo... (a task za alter necu, naravno, da primim od juniora, bez da mu ga neko odobri, je'l) . Ali opet, nekad mora.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
109.72.51.23



+1064 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 16:36 - pre 54 meseci
Citat:
djoka_l:
Ni ja ne smatram da je provera na nivou baze loša.
Poenta je, da između toga da mi 24/7 aplikacija bude 12 sati ugašena zato što treba da se doda not null polje lošija opcija od toga da se to polje doda kao null. A da se kontrola da li je polje popunjeno radi u aplikaciji.
Više volim da mi aplikacija vrati grešku PRE nego što baza vrati exception.


Primer sa poljem je banalan, obicno se dosta toga izmeni, sto ne mozes sve pokriti u aplikaciji a da ne napravis jos bagova... inace baza koja ne restruktuira rekorde nakonm izmene mora
da splituje, pa onda dolazi do slabiojih performansi zbog toga, samo razmisljam...
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 20:23 - pre 54 meseci
@Bane:

To kako radi storage engine unutra, kako odrzava strukturu i indexe... to je prica za sebe. InnoDB source je uglavnom javan (bar dobar deo istog), ti znas da ga analiziras ako te ne mrzi. Cela ta BTree zavrzlama, pa jos spustena na konkretnnu implementaciju matematike je previse za mene. :) Znam da je dr. Tuuri expert za te stvari, znam da bi InnoDB trebalo da bude jezivo dobra implementacija teoretski gledano. Takodje znam da Postgre radi neke stvari bolje, i da ima neke specificnosti koje MySQL nema, par puta sam probao i Toku engine u MySQL-u, za neke stvari.... ali sve je to previse slozeno za mene. :D Vodi racuna, baza nije samo storage engine, ima mnogo u optimizeru, nacinu na koji se bira execution path, kako se koriste indexi.... Oracle koji spominju je tek show, oni imaju neke columnar storage fore direktno, da se koriste paralelno.... ali sa njim nemam puno iskustva.

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Migracije i velike baze podataka27.09.2019. u 21:02 - pre 54 meseci
Pazi sta je jos problem :

- Dodam na tabelu jos jedno polje, recimo CHAR(64). Kratko neko polje, recimo za neki text...
- Baza to doda samo u opis tabele, ne menja strukturu na disku
- Svaki sledeci insert mora da promeni nacin upisa tih npr. 1000 polja koje si radio bulk update. Realno, da ih procita i onda upise negde drugde na disku.

Na kraju imas haos po disku... OK, SSD-ovi nisu toliko osetljivi na fragmentaciju kao ovi od rdje, ali ja nemam blage kako BTree strukture trpe te vrste fragmentacije, kako sve to radi... Jeste, dobices na kraju isto i izbegao si lock, ali me zanima kakve su posle performanse. Dok su bili spinning rust diskovi, ovo deluje da nije bilo srecno resenje....

Takodje, ako se ja secam, Oracle RAC je shared storage arhitektura, sta se desava sa MS SQL-om ili nekom drugom shared nothing bazom, koja ima replikaciju master-slave? Kako se to na njima radi? Deluje mi da tu tek imas problem....

I sta se desava kad pustis ALTER da doda index? To isto ide bez lockovanja? Kad index postaje dostupan? Koliko ti dodavanje indexa na tabeli od 50M ili 500M slogova kosta? Sve i da nemas nominalan lock tabele, kako ti se ponasa DB engine? Pojede li sve postoje iops-e dok podigne index?

Alter nikad nije bezbolno i lako resenje.... ajde se ne lazemo. :D
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Zlatni_bg
Nikola S
Beograd

Član broj: 65708
Poruke: 4420
*.dynamic.sbb.rs.



+498 Profil

icon Re: Migracije i velike baze podataka28.09.2019. u 02:20 - pre 54 meseci
A kako bi bilo na dev/staging serveru da se odradi kloniranje baze, ista da se alteruje, potom da se lupi kratak downtime gde ce se proveriti timestampovi (nadam se da se koriste u ozbiljnijim stvarima) i gde god postoji izmena posle kloniranja baze da se radi update? Downtime bi trebalo da je DRASTICNO kraci od kompletnog alterovanja jer se ne radi u deployment fazi vec se samo "preveze" baza i potom sa malim downtime-om aplikacije sinhronizuju podaci? Tada realno bilo koga boli q za IOPSe jer u delu kada se najveci deo baze klonira bice 90-95% posla, posle ostaje samo kratak deo.

DB server sa onih mojih 70mil slogova ne moze da radi na HDD normalno, najcesce zbog konstantih SELECT i UPDATE, mislim da imam neku temu od ranije gde sam pitao za savet za to jer sam razmisljao o prelasku na MSSQL. SSD u mom slucaju je obavezan. Mada mislim da se radi i mnogo, mnogo kesiranja pa se SSDovi i ne akaju preterano.
THE ONLY EASY DAY WAS YESTERDAY
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
109.72.51.23



+1064 Profil

icon Re: Migracije i velike baze podataka28.09.2019. u 04:03 - pre 54 meseci
"mislim da imam neku temu od ranije gde sam pitao za savet za to jer sam razmisljao o prelasku na MSSQL"

To sam i ja pitao, i ispalo je da se ne isplati :P
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
109.72.51.23



+1064 Profil

icon Re: Migracije i velike baze podataka28.09.2019. u 04:07 - pre 54 meseci
"Onda uradiš još jedan query gde setuješ default ali tada se tabela ne zaključava."

To moze samo ako ti to polje ne treba, sto nece biti slucaj... ako aplikacija podrazumeva da je setovana
defaultna vrednost puci ce, a ako ne nego proverava dal je NULL, onda i ne moras da setujes. No ovo
je banalni primer kao sto sam rekao...
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
109.72.51.23



+1064 Profil

icon Re: Migracije i velike baze podataka28.09.2019. u 04:13 - pre 54 meseci
"ali ja nemam blage kako BTree strukture trpe te vrste fragmentacije, kako sve to radi."

btree se koristi za indeks disk strukture bas zbog toga sto je cache friendly. No rekordi ako nisu sekvencijalni
tu ce da bude jurenja po disku sto ce svakako dosta usporiti citanje. SSD takodje trpi ako nisu sekvencijalni.
Recimo imas ociglednu razliku kod random i sekvencijalnog citanja i u RAM-u, kamoli SSD-u ;)

evo ti razlike u performansama kod btree-a i razlicitih binarnih stabala u RAM-u
Code:

verage op 5327
t insert time 1.490256647
true
height 20
weight (612044,387955)
average op 5900
t1 insert time 1.649772982
true
height 26
weight (671914,328085)
average op 4452
t2 insert time 1.247223759
true
height 20
weight (315716,684283)
average op 4771
t3 insert time 1.335650463
true
height 21
weight (612044,387955)
counter 17015
average op 3374
bt insert time 0.948487987
true size 1000000
t find time 1.049569006
true
sum 1783293664
t1 find time 1.552935806
true
sum 1783293664
t2 find time 1.089489937
true
sum 1783293664
t3 find time 1.266148225
true
sum 1783293664
bt find time 0.969915444
true
sum 1783293664
average op 369
t iter time 0.102758823
true
sum 1783293664
average op 386
t1 iter time 0.10724529
true
sum 1783293664
average op 371
t2 iter time 0.103247368
true
sum 1783293664
average op 384
t3 iter time 0.106687776
true
sum 1783293664
average op 58
bt iter time 0.016124994
true
sum 1783293664
t delete time 1.652509492
true size 0
empty tree
t1 delete time 1.677476289
true size 0
empty tree
t2 delete time 1.36569463
true size 0
empty tree
t3 delete time 2.868176166
true size 0
counter 19
empty tree
bt delete time 0.92497502
true


Znaci smo iteracija kroz btree je 10 puta brza od binarnog stabla.
 
Odgovor na temu

dejanet
Beograd

Član broj: 19240
Poruke: 1181



+835 Profil

icon Re: Migracije i velike baze podataka28.09.2019. u 08:56 - pre 54 meseci
Milione redova treba ocekivati u "transakcionim" tabelama, zar ne, koje bi po nekom ps-u trebalo da imaju fk ka drugim tabelama, znaci nekoliko INT-ova. Mislim da su tu promene strukture relativno retke u odnosu na ostale tabele, gde se nalaze stvarni podaci. Eventualne promene seta atributa treba ocekivati nad tim "drugim" tabelama i one su bezbolne.

EAV model koji je spomenut, mozda sam video u MS CRM/Dynamics, bem li ga, taj model sam primenjivao na deo ERP baze, ako se secam na dodatne atribute za Proizvod i Komitenta, ali nikako kao resenje za celu db. Kada su promene ceste, a relacioni model moze da se izbegne, vredi razmisliti o document bazi, npr Mongo DB. Ipak moje skromno misljenje je da je rdbms nadmocno resenje za vecinu data poslova .

Da, na MySql-u 5.x, alter lock-uje Master, a zatim i Slave kada krenu event-i za replikaciju. E sad mi smo u nasoj glavnoj app roknuli MSMQ sistem, konkretno MS Mesaging Queue, njega umetnuli pre crud akcije, sto nam je nebrojeno puta spasilo dan. To je bilo krpljenje zvakom, koje drzi vodu vec godinama, ali pravo resenje jeste neki krsteni Cache sistem na osnovu Redis-a. Ako ima dovoljno RAM-a da drzi crud operacije u queue par sati do jednog dana, onda je alter ok.
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Migracije i velike baze podataka28.09.2019. u 20:21 - pre 54 meseci
Citat:
Zlatni_bg:
A kako bi bilo na dev/staging serveru da se odradi kloniranje baze, ista da se alteruje, potom da se lupi kratak downtime gde ce se proveriti timestampovi (nadam se da se koriste u ozbiljnijim stvarima) i gde god postoji izmena posle kloniranja baze da se radi update? Downtime bi trebalo da je DRASTICNO kraci od kompletnog alterovanja jer se ne radi u deployment fazi vec se samo "preveze" baza i potom sa malim downtime-om aplikacije sinhronizuju podaci? Tada realno bilo koga boli q za IOPSe jer u delu kada se najveci deo baze klonira bice 90-95% posla, posle ostaje samo kratak deo.

DB server sa onih mojih 70mil slogova ne moze da radi na HDD normalno, najcesce zbog konstantih SELECT i UPDATE, mislim da imam neku temu od ranije gde sam pitao za savet za to jer sam razmisljao o prelasku na MSSQL. SSD u mom slucaju je obavezan. Mada mislim da se radi i mnogo, mnogo kesiranja pa se SSDovi i ne akaju preterano.

Ja sam vec pisao, bas na ovoj temi: Produkciona baza ima 3+ servera, uradi se prvo ALTER na slave-ovima, pa se proglasi slave za master i onda pusti i na njemu. :) Slicna logika.

Poenta nije da ne moze da se pusti alter u produkciji (moze), poenta je da ne moze kroz migraciju. Nije RDBMS vnogo, nego ORM :)
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Migracije i velike baze podataka28.09.2019. u 20:25 - pre 54 meseci
Citat:
dejanet:
Milione redova treba ocekivati u "transakcionim" tabelama, zar ne, koje bi po nekom ps-u trebalo da imaju fk ka drugim tabelama, znaci nekoliko INT-ova. Mislim da su tu promene strukture relativno retke u odnosu na ostale tabele, gde se nalaze stvarni podaci. Eventualne promene seta atributa treba ocekivati nad tim "drugim" tabelama i one su bezbolne.

EAV model koji je spomenut, mozda sam video u MS CRM/Dynamics, bem li ga, taj model sam primenjivao na deo ERP baze, ako se secam na dodatne atribute za Proizvod i Komitenta, ali nikako kao resenje za celu db. Kada su promene ceste, a relacioni model moze da se izbegne, vredi razmisliti o document bazi, npr Mongo DB. Ipak moje skromno misljenje je da je rdbms nadmocno resenje za vecinu data poslova .

Da, na MySql-u 5.x, alter lock-uje Master, a zatim i Slave kada krenu event-i za replikaciju. E sad mi smo u nasoj glavnoj app roknuli MSMQ sistem, konkretno MS Mesaging Queue, njega umetnuli pre crud akcije, sto nam je nebrojeno puta spasilo dan. To je bilo krpljenje zvakom, koje drzi vodu vec godinama, ali pravo resenje jeste neki krsteni Cache sistem na osnovu Redis-a. Ako ima dovoljno RAM-a da drzi crud operacije u queue par sati do jednog dana, onda je alter ok.

Skoro smo pricali na drugoj temi: Kupindo, ako odes na sajt, pise da ima 2 miliona predmeta. To nije 2 miliona redova u transakcionim tabelama, to je dva miliona u tabeli koja drzi predmete, a relacione tabele koje drze veze izmedju atributa i vrednosti imaju, logicno, vise.... ne ulazim u detalje jer ih znam, a poslovna su tajna, ali ako otvoris cipele videces da imaju broj cipela, duzinu gazista, materijal i boju na primer.

A imam sad klijenta cija MySQL baza je veca desetak puta od one na kupindu. :)
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

dejanet
Beograd

Član broj: 19240
Poruke: 1181



+835 Profil

icon Re: Migracije i velike baze podataka28.09.2019. u 21:57 - pre 54 meseci
Ok, mozda sam terminoloski neprecizan, mislim da su predmeti(ili oglasi) transakciona tabela i imas n:m relationship sa proizvodima ili sta vec a one sa atributima i vrednostima, sto je EAV model, ako razumem. Osim ako se ne radi alter nad predmetima i/ili veznim tabelama, mislim da nemas problem.
Moje zapazanje se odnosilo na jednostavan slucaj da proizvodi sve atribute drze u svojoj tabeli, znaci nemas tabelu atributi, tako ce tokom vremena biti ceste potrebe da se dodaju nove kolone u tabeli proizvodi. Tu se ne radi alter nad milionima redova ?
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Migracije i velike baze podataka29.09.2019. u 10:45 - pre 54 meseci
Ne radi se tu, radi se na nekim drugim tabelama. :D Nije sve EAV, ima mesta gde je nasledjen los kod, gde je nasledjen los dizajn, gde je vise podatak u jednoj tabeli... Na primer :

https://blog.limundograd.com/2...undo-porodica-400-000-clanova/

To je 2013, ako pretpostavis da je tabela koja drzi korisnike sa autoincrement ID-em, zakljucices da tabela ima preko nekoliko clanova vise. :D
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

[es] :: PHP :: Migracije i velike baze podataka

Strane: 1 2

[ Pregleda: 6484 | Odgovora: 38 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.