[es] - Baze podataka i konkurentnost rada

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Baze podataka i konkurentnost rada

^{06.02.2009. u 16:22 - pre 185 meseci}

Konkretno, koja banka ima stotinak ekspozitura u jednom gradu? Koliko znam nisu sve ekspoziture uvek povezane na glavni server. Neke od njih povremeno vrše usklađivanje stanja. Iz bankarskog sektora znam samo Poštansku štedionicu da je stalno na vezi. I nema neke velike konkurentnosti. Uglavnom se ažurira samo jedan mali skup podataka (jedan do dva tekuća računa). Više sam mislio na pravu konkurentnost gde imamo neku vrsu magacina i komercijaliste koji popunjavaju porudžbine, vrše rezervaciju robe, ... Nešto slično veleprodaji hrane. Znači banke, barem ja tako mislim , i nemaju neku konkurentnost u radu sa bazom.

cume
Menadzer za visoko frekventnu naplatu u
maloprodajnom objektu

Član broj: 26038
Poruke: 315
91.148.77.*

+1 Profil

Re: Baze podataka i konkurentnost rada

^{06.02.2009. u 18:07 - pre 185 meseci}

bilo koji telco

cume
Menadzer za visoko frekventnu naplatu u
maloprodajnom objektu

Član broj: 26038
Poruke: 315
91.148.77.*

+1 Profil

Re: Baze podataka i konkurentnost rada

^{06.02.2009. u 18:09 - pre 185 meseci}

I kako ne banke??? Ekspoziture + centrala + eBanking + ATM ..... razmisli malo.

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Baze podataka i konkurentnost rada

^{06.02.2009. u 19:33 - pre 185 meseci}

Nisam ubeđen da isti skup podataka ažuriraju veći broj klijenata bilo kog programa za bankarsko poslovanje. Nisam siguran da su ekspoziture iz više gradova povezane u jedan centralni sistem. eBanking uglavnom barata sa jednim ili dva računa i nikada podatke vezane za jedan račun ne obrađuju dva, a kamo li više klijenata. Kod ATM-a ubaciš karticu i jedini si koji dižeš pare. Razmislio sam malo više i, za sada, jedino sam u Telekomu video aplikaciju koja ima veliki broj klijenata. Zato se i raspitujem za još neki sistem.

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Baze podataka i konkurentnost rada

^{11.02.2009. u 13:30 - pre 185 meseci}

Na forumu ima dosta postova na temu baza podataka. Neki diskutanti su koristili, da bi pokazali svoju merodavnost i stručnost, tvrdnju da su radili na izradi baze (aplikacije) koju koriste više stotina pa i više hiljada korisnika. Očekivao sam da se jave i iznesu svoja iskustva. Diskusija malo zamrla pa moram da proširim pitanje koje sada glasi: koja firma bilo gde u svetu koristi bazu podataka i aplikaciju sa više stotina konkurentnih klijenata? Pod konkurentnim klijentima podrazumevam klijente koji aktivno učestvuju u ažuriranju baze na serveru (serverima).

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 10:15 - pre 184 meseci}

Citat:

Diskusija je zamrla jer su okviri diskusije koje se postavio ireleavntni i pokazuju tvoje elementarno nepoznavanje problematike i nacina
na koji radi lockovanje. Nisu samo klijenti koji aktivno azuriraju bazu smetnja, zapravo oni su retko kad smetnja jedni drugima jer obicno
manjaju razlicite redove u tabelama i ne-eskalirani RID lock je sasvim dovoljan da ih razgranici i da im omoguci konkurentan rad.
Ono sto je mnogo veci problem su svi ostali korisnici sistema koji imaju potrebu da cesto citaju te tabele i redove, a citanje (SELECT)
nije potpuno pasivna operacija narocito kad je SERIALIZABLE izolacija u pitanju. Da bi select vratio redove mora da uspostavi IS, S
(intended share pa share) lock nad SVIM redovima koje vraca, i ako neki drugi proces(i) drze U, IX, X (update, intended exclusive,
exclusive) lockove nad tim redovima select mora da ode u WAIT za SVAKI od njih (ili da eskalira lock u PAGE/TAB i opet da ceka na
WAITu) i za svaki mora da se izlakta drzeci IS lock nad njima tako zaustavljajuci IU, U, IX, X pokusaje iz nadolazecih update operacija
koje sad moraju da cekaju na U locku da se select kompletira. Ako usput naidju i drugi select-i i oni se ubace u zajednicko cekanje na S
lock. Dakle sad ne govorimo o 100 korisnika koji rade paraleleni update, vec o 100 korisnika koji rade select nad opsegom u kome se
nalaze X lockovi koje drze drugi procesi, a ti korisnici vise nisu samo pera, mika i zika, to su i automatski servisi i procesi koji rade
pozadinske poslove, stampu, validaciju, itd, itd.

Jel sad jasnije zasto ne treba produzavati X lock duze nego sto je apsolutno neophodno i zasto se pesimistic lockovanje ne skalira lepo i
zasto ga ne treba koristiti bez preke potrebe?

@mmix
Pitanje je glasilo : Koja firma u Srbiji koristi bazu podataka i aplikaciju sa više stotina konkurentnih klijenata? Molio bih te da se držiš teme i da, ako imaš odgovor na temu , onda to i kaži, kratko i jasno. Znači : koja firma? Samo to je bilo pitanje. Hvala

_{[Ovu poruku je menjao mkaras dana 12.02.2009. u 15:23 GMT+1]}

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 12:56 - pre 184 meseci}

U pravu si, evo sad cu da reorganizujem svoje odgovore. A sto se tice firmi u srbiji, to ne mogu da tvrdim 100% ali su velike banke sigurno medju njima, narocito postanska stedionica. Banka koja je bila moj klijent napolju je imala oko 120 direktnih korisnika core-banking baze i oko 60-ak automatskih procesa u pozadini, kako kontinualnih tako i periodicnih, plus oko stotinak sekundarnih korisnika i sistema koji su se oslanjali na core banking (loans, investments, merchants, itd). A to je banka osrednje velicine sa 5 ekspozitura i oko 100,000 depodenata, nasa prosecna banka je veca od ove. Od kapitalnih korisnika vece su reinsurance kompanije, imaju manje ljudskih korisnika sistema ali drasticno mnogo vise automatizovanih sistema, narocito oko risk managment-a i sracunavanja modela rizika. Samo npr surety reinsurance sa 100 klijenata i milion iteracija generise oko 100 miliona sirovih simulacija koje potom razliciti modeli (po 300+ paralelno) tweakuju i konsoliduju u procene rizika. Itd, kao sto sam rekao u ovoj poruci koju pomeram, nisu samo oni koji rade update/insert predmet concurrency-a, moras da posmatras SVE korisnike.

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić

djoka_l
Beograd

Član broj: 56075
Poruke: 3453

Jabber: djoka_l

+1462 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 13:10 - pre 184 meseci}

Aplikaciju moje firme u bankama koriste isključivo u on-line režimu 24/7. Naš najveći klijent ima 125 ekspozitura koje su sve zakačene na jedan centralni server (dobro, ne jedan nego klaster od dva) koji je u Beogradu. Aplikacioni serveri su takođe u Beogradu. Aplikacija je three-tier, znači na 125 lokacija samo brauzer. Prosečno opterećenje oko 1200 on line usera i oko 2000 e-banking usera. Da ne pričam o on-line autorizaciji sa ATM i POS-ova. Baza - za sada 3TB ali i dalje raste...

Dodatak:
U leto 2006. godine radili smo neka merenja performansi, rekord po broju transakcija u sekundi (u radno vreme) je bio 178. Merene su performanse na pravim podacima, na produkcionoj mašini u banci, doduše u letnjim uslovima kada je manje posla.

U prilogu je statistika slučajnog uzorka u septembru iste godine.

_{[Ovu poruku je menjao djoka_l dana 12.02.2009. u 15:00 GMT+1]}

_{[Ovu poruku je menjao djoka_l dana 12.02.2009. u 15:22 GMT+1]}

Prikačeni fajlovi

transakcije.PNG - 31.07k

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 14:46 - pre 184 meseci}

@djoka_l

Da li aplikacija omogućava da dva učesnika menjaju isti skup podataka? Recimo da je Pera Perić vaš štediša i da trenutno važeće podatke učitaju dva učesnika. Jedan promeni naziv ulice, a drugi kućni broj. Šta se dešava kada drugi učesnik želi da snimi svoje izmene posle već upisanih izmena prvog učesnika? Kako se razrešava šta će konačno pisati kao adresa Pere Perića?

momsab
Momčilo
Beograd, R.Srbija

Član broj: 2804
Poruke: 3041
*.dynamic.sbb.rs.

Jabber: pitati@PP
Sajt: www.momsab.com

+1 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 15:28 - pre 184 meseci}

ako se ne varam, tako nesto nije dozvoljeno samim slucajem koriscenja, narem na primeru banaka
uplate i isplate se snimaju kao posebni redovi pri cemu ne mogu da se menjaju ne racunajuci storniranje (nemam uvid u ovu aplikaciju nego tako kontam da je napravljeno)

Žena u krevetu i vino na stolu nikako ne smeju da čekaju. Jer, vino se greje a žena hladi.

-vinolog

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 16:42 - pre 184 meseci}

Citat:

momsab: ako se ne varam, tako nesto nije dozvoljeno samim slucajem koriscenja, narem na primeru banaka
uplate i isplate se snimaju kao posebni redovi pri cemu ne mogu da se menjaju ne racunajuci storniranje (nemam uvid u ovu aplikaciju nego tako kontam da je napravljeno)

obicno nije tako. Ima vise implementacija obradi naloga ali uglavnom se trazi da nalozi mogu da se menjaju dok god se ne proknjize. Meni se u principu najvise svidja mehanizam sa radnim tabelama gde unosis i menjas naloge koliko hoces, onog trenutka kad se nalog upucava u glavnu knjigu uradi se server side validacija naloga i transakcioni insert u glavnu knjigu. Pored toga sto ne blokira glavnu knjigu tokom rada takodje i omogucava da se prenos obavi u server-side insert-u cime se minimizuje trajanje X lockova.

U principu najcesci concurrency mehanizam koji se koristi za nekriticne podatke (kao sto je adresa u gornjem primeru) je tzv "Last write wins", sto zapravo i nije concurrency kontrola vec njen nedostatak

. Preduslov je naravno da dva korisnika zaista i nece u isto vreme menjati neki podatak (kao sto je adresa) i da concurrency ni ne postoji i da cak iako postoji ne dovede do opasnih posledica. Sa adresom je takav slucaj, adresa ce se menjati na zahtev korisnika koji je u jednom primerku i obradjuje ga jedan zaposleni, cak iako dva korisnika u isto vreme obradjuju zahtev, posledica ce biti ne-kriticna.

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 16:55 - pre 184 meseci}

Adresa je samo primer. Šta se dešava kada se istovremeno menjaju kritični podaci? Kako se tu rešava pitanje konkurencije.

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 17:22 - pre 184 meseci}

Onda ti treba neki concurrency mehanizam, a ima ih podosta. Ono sto ja forsiram je neki od optimistic modela, a koji tacno zavisi od okolnosti, s tim da naginjem ka timestamp-u (kao malo brzoj alterantivi u odnosu na proveru svih polja). Ono sto sad srecem u praksi uglavnom je polu-zavrseni optimistic metod iz ado.net-a. Wizardi u .net-u (dataadapteri i ceo DLINQ) su sad omogucili da se kreira back-validating optimistic mehanizam, ali ta implementacija je samo pola puta

i zavrsi se time da korisniku sevne nehandlovani concurrency exception. Kad radis optimistic concurrency onda moras da osmislis i "conflict resolution" deo koji se obicno preskoci. U svakom slucaju sa stanovista konzistentnosti podataka problema nema, dal ti handlova exception ili ne podatak nece biti upisan ako je neko vec promenio red.

djoka_l
Beograd

Član broj: 56075
Poruke: 3453

Jabber: djoka_l

+1462 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 18:27 - pre 184 meseci}

Svaka izmena matičnih podataka se čuva - znači čuva se slika komitenta nakon svake izmene. Takođem čuva se timestamp i oznaka referenta koji je nešto menjao.
Osim toga - koliko je moguće da Pera Perić stoji istovremeno na dva šaltera, sa dve lične karte i nešto traži. Primer ti nije relevantan.

_{[Ovu poruku je menjao Gojko Vujovic dana 12.02.2009. u 21:21 GMT+1]}

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 21:12 - pre 184 meseci}

Citat:

djoka_l:
...
Osim toga - koliko je moguće da Pera Perić stoji istovremeno na dva šaltera, sa dve lične karte i nešto traži. Primer ti nije relevantan.
...

Koristim eBanking pa i ja i knjigovođa imamo pravo pristupa računima. Desi se nekada da se sudarimo i da ja ili on dobijemo obaveštenje da neko drugi pristupa računu. Znači primer je veoma relevantan. Naravno ne menjamo adrese i slično, ali istovremeno pristupamo računu i menjamo stanje na računu. Ne dešava se to baš tako često ali se dešava. Isto tako ćerkama sam dao ovlašćenje na upotrebu sredstava na mom privatnom tekućem računu. Znači i tu se može desiti da svo troje istovremeno pristupimo računu. To su stvari koje mene interesuju. Zato i pokušavam da dobijem informacije od onih koji su radili na projektovanju ili implementaciji sistema.
Što se tiče timestamp-a: zamislimo da se menja više polja. Prvi učesnik izmeni prvo polje, malo posle njega to uradi i drugi korisnik. Prvi korisnik se javi na telefon pa drugi korisnik popuni drugo polje koje se menja pre prvog korisnika. Kako iskoristiti timestamp? I čija izmena će biti konačno upisana kao validna?

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 21:44 - pre 184 meseci}

eBanking je uglavno web ili webServices based. Ako ti eBanking resenje ne dozvoljava konkurentan SELECT na racunu onda je to lose uradjen sistem.

U odgovoru na tvoje pitanje o timestamp optimistickom locku, nevazno je ko je pre krenuo sa izmenom, proci ce onaj koji prvi uradi write. Svaki row update ce promeniti timestamp reda i svaki buduci pokusaj da se optimisticki locira red sa starim timestampom za izmenu nece uspeti jer taj timestamp vise ne postoji. Ali takve situacije u eBankingu nisam skoro nigde video, eBanking se obicno svodi na atomicne INSERT transakcije (uplate, isplate, i slicno) i 'last write wins' operacije (izmena adrese, nick-a, itd), nisam jos video nista sto bi podlegalo pod konkurentni UPDATE.

slacker

Član broj: 14720
Poruke: 1049
*.adsl.net.t-com.hr.

+1 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 22:41 - pre 184 meseci}

Citat:

Na forumu ima dosta postova na temu baza podataka. Neki diskutanti su koristili, da bi pokazali svoju merodavnost i stručnost, tvrdnju da su radili na izradi baze (aplikacije) koju koriste više stotina pa i više hiljada korisnika. Očekivao sam da se jave i iznesu svoja iskustva. Diskusija malo zamrla pa moram da proširim pitanje koje sada glasi: koja firma bilo gde u svetu koristi bazu podataka i aplikaciju sa više stotina konkurentnih klijenata? Pod konkurentnim klijentima podrazumevam klijente koji aktivno učestvuju u ažuriranju baze na serveru (serverima).

Bilo koja firma mora u obzir uzeti takav slučaj, bez obzira koliko je realno da se on dogodi. Financijske institucije pogotovo. Tamo su stvari zaista centralizirane i vrte se obično na mainframe-u, AIX mašinama, klasteru linux strojeva ili nečem sličnom, ovisno o broju klijenata. Sama baza ima svoje mehanizme koji sprečavaju anomalije u slučaju konkurentnih transakcija.

Što se tiče konkurentnog UPDATE-a:
Sama baza po dizajnu ne dopušta takav slučaj, bar znam da je tako kod DB2. Laički, transakcija koja prva pristupi će "zaključati" slog (kaže se da trx "drži lock"), a druga koja istovremeno pokušava napraviti update neće u tome uspjeti, dogodit će se rollback.

Postoji cijeli mehanizam isolation level-a ugrađenih u samu bazu koji se koriste ovisno o situaciji. Znači postoji više razina lock-ova koje baza može koristiti u slučaju konkurentnih transakcija. Cilj je koristiti onu razinu koja će najmanje smetati, a neće dovesti do neželjenih rezultata, odnosno slučajeva da se transakcije "gaze" međusobno ili dohvaćaju stvari koje nebi trebale.

Ima nekoliko dobrih članaka koji laički na konkretnim primjerima objašnjavaju problematiku kod DB2:
http://www.ibmdatabasemag.com/...icle.jhtml?articleID=180206444
http://www.ibmdatabasemag.com/...icle.jhtml?articleID=186500771

Vjerujem da sve baze imaju slične mehanizme.

_{[Ovu poruku je menjao slacker dana 13.02.2009. u 00:28 GMT+1]}

djoka_l
Beograd

Član broj: 56075
Poruke: 3453

Jabber: djoka_l

+1462 Profil

Re: Baze podataka i konkurentnost rada

^{12.02.2009. u 23:28 - pre 184 meseci}

Citat:

Opet loš primer, pristupanje računu ne sme da zaključa slog stanja računa. Stanje se pročita (samo informativno), formira se stavka knjiženja, pa onda potvrda naloga menja stanje (koje pre započinjanja potvrde zaključa stanje). Potvrda naloga prouzrokuje update stanja. Dok jedna transakcija ne završi commit, druga ne može da se potvrdi, ali ta potvrda traje vrlo kratko (reda 1-10ms od momenta kada se zaključa stanje do završetka update).