banke koje imaju nekoliko stotina ekspozitura, npr

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.

bilo koji telco

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

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.

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).

@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]}

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.

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.
[att_img]
<sub>[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]</sub>

@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?

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.

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

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.

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]}

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?

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.

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]}

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).

Ako hoćeš tačan mehanizam kako naše banke rade e-banking:

Unos naloga za plaćanje formira slog naloga za plaćanje na bazi podataka koja je u demilitarizovanoj zoni (između neta i tog servera je prvi firewall). Zatim ebanking server šalje DB serveru poruku plaćanja kao rpc (db server je iza drugog firewalla) i time samo upisuje kopiju naloga plaćanja sa ebankig servera na produkcioni server. Na db serveru se vrti job koji proverava da li su pristigle nove poruke plaćanja i kada je nađe onda poziva proceduru koja radi knjiženje (ili rezervaciju, zavisno od toga da li je plaćanje između računa u istoj banci ili na eksterni račun).
Ova procedura proverava da li postoje sredstva na računu i ako ne postoje, stavlja nalog u stanje čekanja na pokriće na kojem može da ostane, u zavisnosti od politike banke i toga šta je komitent stavio kao krajnji rok plaćanja do 5 dana.
Ako je nalog za plaćanje za drugu banku i postoje sredstva na računu platioca, ne radi se knjiženje nego rezervacija. Raspoloživo stanje se računa kao trenutno stanje + dozvoljeni minus - rezervacije. Formira se poruka plaćanja (SWIFT poruka MT103) koja se šalje na SWIFT server, pa dalje u kliring centar. Knjiženje se radi kada se dobije konfirmacija od kliring centra da je nalog izvršen, te se u tom momentu ažurira stanje na računu i stanje rezervisanih sredstava.

Upravo tako. Postoji klijentski dio aplikacije, zatim neki midleware koji sadrži poslovnu logiku (transakcije) i komunicira sa DB, te vraća rezultat klijentu (ili više njih najčešće). Klijenti nikad ne šaraju direktno po bazi, bar ne kod tako velikih sistema.

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

Potpuno se slazem sa tobom, i onda je sva ova diskusija gore samo teoretisanje. Isti slog moze da cita vise transakcija, ali samo jedna moze da ga menja, ali cak i pri toj izmeni bi staro stanje sloga moralo biti dostupno drugim transakcijama. Svaka ozbiljna baza to podrzava.
U tom duhu, dobro dizajnirana baza i jos bitnije aplikacija bi morali imati konflikte azuriranja izuzetno retko.

A sto se tice broj konkurentnih korisnika i konkurentnih transakcija, to bi trebalo naglasiti o cemu pricamo, jer kao sto je receno, par korisnika (konekcija) moze imati i vise desetina aktivnih transakcija, te bi onda 100-tinak realnih korisnika lako moglo imati oko 1000 aktivnih transakcija, opet u zavisnosti od dizajna aplikacije.

Bez obzira da li se radi o bazama podataka ili o generalnom programiranju, pri programiranju konkurentnih procesa se mora voditi računa o upotrebi zajedničkih resursa.

Bitno je identikovati kritične sekcije, tj. delove programa koji nesmeju paralelno da koriste iste resurse. Pre ulaska u kritičnu sekciju sporni resursi se moraju ekskluzivno prisvojiti, i osloboditi nakon izvršavanja kritične sekcije.

U mkarasovom primeru 3 platne kartice nad jednim računom, moguća kritična sekcija je momenat kada se vrši skidanje novca sa računa. Rekao sam "moguća kritična sekcija" jer to zavisi od dizajna baze - midlweara aplikacije - klijentske aplikacije. U svakom slučaju, ako se utvrdi da je skidanje novca kritična sekcija neke od aplikacija, tabele koje učestvuju u formiranju stanja računa se moraju pesimistički zaključati do obavljanja transakcije skidanja!

Konačno. Do sada se više puta pojavila tvrdnja da je pesimističko (eXlusivno) zaključavanje glupost koja uništava perfomanse aplikacije. Čini mi se da smo ipak došli do spoznaje da je u nekim situacijama neophodno. Naravno, projektanti baze i aplikacije moraju da povedu računa i da ga svedu na najmanju moguću meru i po učestalosti upotrebe i po trajanju, ali ne smeju i ne mogu ga izbaciti iz upotrebe kao što su zagovarali neki od diskutanata.
Na forumu se nekada pojave tekstovi koje pišu diskutanti koji nisu učestvovali u rešavanju konkretnih problema pa samim tim i ne primećuju sve skrivene zamke koje problem nosi sa sobom. Drago mi je da su se javili i oni koji su čestvovali u sličnim projektima. Hvala.

Sasvim sigurno se neće zaključavati čitava tabele zbog jednog korisnika već samo pojedini slogovi koji se tiču tog korisnika. Drugo, sama baza će voditi računa o tome, ako dve transakcije pretenduju da izmene isti slog, baza će shodno podešavanjima transkacije razrešiti situaciju i po potrebi sprečiti jednu transakciju da promeni stanje. Kao što je neko rekao ranije, tako nešto se u bankarskim aplikacijama nikada neće desiti, nalozi za plaćanje se upisuju u red za čekanje i redom se obrađuju tako da nikada ne utiču na isti slog istovremeno.
Ekskluzivno zaključavanje na nivou čitave tabele jeste loše u tavkim velikim sistemima jer bi ih učinilo neupotrebljivim, ako postoji potreba zaključavaju se samo pojedini slogovi.

Ma nije u tome problem, njegov problem sam od pocetka bio ja kao "diskutanti koji nisu učestvovali u rešavanju konkretnih problema pa samim tim i ne primećuju sve skrivene zamke koje problem nosi sa sobom" . Svojevremeno sam mu rekao da je izrekao neke totalne gluposti oko pesimistickog zakljucavanja u ado.net aplikacionom layer-u i posto nije dobio odgovarajucu satisfakciju u zalbi mojim kolegama na moje ponasanje sad pokusava posto poto da dokaze da nisam u pravu, makar usput iskrivljujuci cinjenice, deleci tu temu na nekoliko nekompletnih tema koje moze da navodi ka svom zakljucku, pozivajuci se na svoje vaskoliko Access i FoxPro iskustvo i citirajuci populisticku literaturu, dok ne uspe da ubedi bar jos nekog da se slozi sa njim, pri tom pokazajuci sopstveno elementarno nepoznavanje materije o kojoj iznosi tvrdjenja. Retko ko je pratio sve te teme, pa cisto da ubrazmo upoznavanje.

Ovu njegovu poslednju poruku bih trebao da obrisem jer nije odgovor na pitanje zbog kojeg je meni tako samouvereno nadrljao nos pri pocetku teme, secas se mkaras? "@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"

Al nema veze, znao sam da ces pre ili kasnije da sam navedes vodu na tu vodenicu sa pesimistickim zakljucavanjem i mojom 'nesposobnoscu', pa sad mogu slobodno da uputim ljude na tu drugu temu, pa koga interesuje nek isprati: ES: Pesimisticko zakljucavanje - razlozi za i protiv da ne bi ovde ponovo to ponavljali. I ja i dalje stojim protiv drzanja pesimistickih lockova duze nego sto je apsolutno minimalno neophodno i da nisu najbolji lek za sve moguce concurrency probleme i stojim iza toga da su pesimisticki lockovi i njihova zloupotreba glavni uzrocnici neskalabilnosti aplikacija a te tvrdnje su u toj drugoj temi potkrepljene primerima.

Došli smo do zaključka da veliki broj finansijskih organizacija koristi bazu podataka sa velikim brojem klijenata. Prilikom plaćanja karticom na izveštaju se, osim datuma, iznosa i broja terminala nalaze još neki podaci. Na jednom od njih imam stavke: broj prometa, broj potvrde i broj odobrenja i još po nešto. Gde se generišu ti podaci?

Između POS-a ili ATM-a i banke se nalazi procesor. Banka i sama može da radi procesiranje ukoliko ima opremu i softver. E sad, imaš tri scenarija, bančina kartica u bančinoj mreži, tuđa kartica u bančinoj mreži i bančina kartica u tuđoj mreži.

U principu, te dodatne podatke generiše procesor, osim broja autorizacije. Ako banka ima on-line autorizaciju, tada ona generiše broj autorizacije. Ako nema, ona pravi balance file za procesora, pa onda procesor na osnovu podataka iz tog fajla (stanja na računima) generiše i autorizaciju.

Uzimajući u obzir prvu rečenicu, tada te podatke mogu generisati procesor, procesor u banci, procesor u drugoj banci ili banka.

Sve te dodatne informacije su brojevi. Pitanje je da li ti brojevi moraju da budu poređani po nekom određenom pravilu i da li su dozvoljene "rupe u nizu?

Ova tema ide u nekim cudnim pravcima i mislim da na je na pocetno pitanje odgovoreno. Pitanja koja autor postavlja naknadno nisu toliko vezana za temu. Zatvoricu je sad, a ako autor misli da pita neke druge stvari slobodan je da otvori novu temu.