Az évekkel ezelőtt néhány ember által alapított cég - amelyet később felvásárolt az eBay - folyamatosan növekszik. 2006-ban 37.6 milliárd dollárnyi tranzakciót bonyolított, míg ez a szám idén már az 50 milliárdhoz közelít. Ha a növekedést mainframe rendszerekkel kellene követnie az online fizetéssel foglalkozó cégnek, az fejlesztési lépcsőnként dollár tízmilliókba kerülne. Ehelyett néhány éjszaka leforgása alatt csatasorba állítanak néhány száz szervert, ami ezrekbe és nem milliókba kerül.
A teljes cikk itt.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Valahol vérfagyasztó, hogy ezeket a méreteket itthon elképzelni sem tudjuk. Mint a google, amelyik egy vízierőmű mellé költözött, hogy ötödannyiért kapja az áramot mint másutt mert egy paksnyi az áramfelvétele.
- A hozzászóláshoz be kell jelentkezni
A PayPal szerint. Feladata válogatja. Itt bejött a dolog, máshol nem biztos. Szerintem a mainframek soha nem fognak teljesen eltűnni, legfeljebb néhány területen visszaszorulnak, de úgy látom, lesz ahol még terjedni is fognak.
Eszközt a feladathoz. És nem fordítva. Akkor túl nagy baj nem lehet :)
- A hozzászóláshoz be kell jelentkezni
Kifejtenéd bővebben, melyek azok a területek, ahol szerinted a mainframek terjedni fognak?
- A hozzászóláshoz be kell jelentkezni
Vastelep, színesfém-nagykereskedelem, nemesfém-újrahasznosítás, veszélyeshulladék-megsemmisités?
Hirtelen ezek jutnak eszembe.
Egyébként nekem van egy olyan érzésem, hogy ha jobban belenéznénk a paypal belső működésébe, rájönnénk, hogy sok rejtett hardver és szoftverhiba van, amely akár hibás tranzakciókhoz is vezethet.
- A hozzászóláshoz be kell jelentkezni
ha már a vasiparnál vagyunk, a dunaferr nemrég dobta ki a mainframejeit, és itaniumos gépeket állított a helyükre.
a mainframek újrahasznosítását pedig házon belül megoldhatták :)
- A hozzászóláshoz be kell jelentkezni
Oh, gigalol. :)
Olvastam róla, de ez eszembe sem jutott.
- A hozzászóláshoz be kell jelentkezni
Engem mondjuk megnyugtatna, ha az olyan környezeteket, ahol a számítástechnika hibája emberéleteket sodorhat veszélybe, nemhogy nem linux, de nem is unix-os gépek vezérelnék. Például:
repülés-, vasút- és közútirányítás, atomerőművezérlés, interkontinentális rakéták vezérlése...
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Nyugi azokon Windows fut ;)
Egyébként miért lennél jobban megnyugodva ha nem Linux vagy UNIX futna rajtuk? Megnyugtat hogy nem tudhatod/ismerheted mennyire megbízható az oprendszerük?
Nincs szoftver garantáltan bug nélkül. Még akkor sem, ha egy nukleáris rakéta pontos célbajuttatása a feladata.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.
- A hozzászóláshoz be kell jelentkezni
Tudod, ha nem ismerem milyen OS irányítja ezeket a rendszereket, akkor még bízhatok abban, hogy valami valóban működő. Ha tudom, hogy *NIX - vagy Win* -, akkor minden remény odavész. Jó esetben csak a remény.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
"...akkor még bízhatok abban, hogy valami valóban működő. "
Hát ha ez neked nyugodt éjszakákat jelent, akkor OK. Én nem a reménykedésre és talánokra építem az életem, mert ennyi erővel templomba is járhatnék.
Amit te vázolsz azzal szerintem analóg a security by obscurity hozzáállás. Ha nem tudsz a bugokról, akkor ezek szerint neked megbízhatóbb egy rendszer. Tudomásulvéve.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.
- A hozzászóláshoz be kell jelentkezni
"Hány éves vagy kiskirályfi?"
Hagyd, a kérdés szónoki, kurvára nem érdekel amúgy. Én idővel rájöttem, hogy minden bennem felmerült kérdésnek utána járni reménytelen elhatározás, ezért erről letettem. Inkább az általánosítás elítélendő és megvetendő gyakorlatát űzöm. Ismerve ennek minden hátrányát és buktatóját.
A fentiek és tapasztalataim alapján alakítottam ki azt a véleményem, hogy unix, linux és windows alapokon jelentős mértékben reménytelen vállalkozás megbízható környezetet kialakítani. Nem száz százalékban reménytelen, de azért eléggé.
Ennek folyományaként, ha egy környezetben nem használnak unixot, linuxot vagy windows-t, akkor nagyobb valószínüsége van egy megbízható környezet kialakításának, mintha a jelzett eszközöket használatba vennék.
Persze pénzt és energiát nem sajnálva a jelzett operációs rendszerekből is kialakíthatő megbízható környezet, de én mégis jobban bízom egy olyan operációs rendszerben, mely ipari - hogy azt ne írjam, enterprise és nem iskolai vagy kutatóintézeti - igények figyelembevételével került megvalósításra.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
- 24, szeretek költői kérdésekre válaszolni :)
- Hatalmas csapdába estél véleményem szerint. Remélem te döntéshozó vagy szoftverbeszállítás tekintetében, mert akkor megyek hozzátok és eladom a saját oprendszeremet, amit vagy 6 éve kezdtem el írni. :) Garantáltan nem ismered, soha egyetlen bug nem volt benne (mivel soha nem tettem egyet sem nyilvánossá, sőt a szoftvert nem publikáltam, de egyedi klienseknek már értékesítettem) és azt is garantálom neked hogy enterspájz. A cégem teljes testhosszan áll mellette üzleti támogatáshoz (ugyanis emiatt hívnak egy szoftvert enterprise ready-nek).
A kód ugyanis Prologban készült (oké, sokadik nekifutásra, de komplett újraírtam :), kövire megpróbálom Erlangban, úgyis meg akartam tanulni alaposan - csak tudnám mikor lesz rá időm :S), így mondhatni matematikailag önigazoló maga a kód. Sőt, még doksit is írtam róla, ami alapján megérthető a működés. Sőtsőtsőt, ezt a doksit a _létező_ tervezési szakasz alatt írtam, még mielőtt egy kódsort is leírtam volna.
Ui.: Affene! Elindítottam egy Core2 Duo-n és hardlockolt az ütemezőm. Azt hiszem fogtam egy bugot. Nem baj, nem tudja meg úgyse senki, majd valamilyen feature patch-be rejtve disztributálom és remélem senki nem veszi észre, főleg saabi ne :S
Ui2.: A fenti leírás erős metaforikus túlzás akar lenni. Sosem sikerült befejeznem sem a C-ben és Assembly-ben írt OS-emet(kb 8 éve kezdődött), sem a revízionált Prolog verziót, amely egy mikrokernel lett volna és a taszkokat implementáltam volna Prologban, a core-t C-ben. De shellem már volt, meg Prolog schedulerem :D Ettől függetlenül mindenkinek ajánlom hogy ha ideje engedi és érdekli csináljon ilyesmit, baromi sokat lehet belőle tanulni ;)
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.
- A hozzászóláshoz be kell jelentkezni
Mellélőttél. Supportos vagyok, tudod, akinek a OS-ek hibái a szakmája. :-P
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Így már világossá vált számomra a szélsőséges nézőpontod ;) Nem lőttem mellé, példát szerettem volna állítani eléd, hogy érzékeltessem a hozzáállásodból fakadó logikai problémákat.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.
- A hozzászóláshoz be kell jelentkezni
Csak azért látsz logikai problémákat, mert egy fórum keretein belül nem írok egy komplett értekezést az operációs rendszerekről és azok hibáiról. Meg valószínüleg arra sem fektettem elég hangsúlyt, hogy kristálytisztán kivonatoljam a gondolataimat.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Mindketten láttunk már Tandem Himalayat saját nyálában forogni. És azt is tudjuk, hogy mennyivel kerül többe mint az ugyan azt a teljesítményt nyújtó x86. Nem állítom, hogy a végső igazság birtokosa lennék, de a világ mintha arra menne, hogy rakd össze relative olcsó vasakból, és ha adatbiztonság kell, akkor duplázd/triplázd meg az egészet, és checkpointoknál ellenőrizd, hogy a párhuzamosan elindított számításoknál mindenhol ugyan az az eredmény jött-e ki. Árban még mindig csak a töredékénél leszel, mint ha mainframe-et használnál, és számítási biztonságban sem leszel gyengébb. A bővíthetőségről nem is ejtenék szót....
- A hozzászóláshoz be kell jelentkezni
Azért a Tandem rendelkezésreállása ettől függetlenül is az, amiről a *NIX világban csak nyálcsorgatva álmodoznak.
Értem én, hogy az ingyenes Linux kernel és a köré kókányolt ingyenes GNU utility-k alkotta operenciás rendszernek jobb az ár/érték aránya, mint bármi másnak, de talán vannak helyzetek, amikor nem csak gazdasági szempontokat kell figyelembe venni. Én igyekeztem ilyeneket felsorolni.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Ezt kifejtenéd? Nem ismerem a Tandem-et, de elég sok *nix cég vállal 6 9-es rendelkezésreállást.
- A hozzászóláshoz be kell jelentkezni
Öt kilences lesz az, nem? Vagy már sikerült lefaragni az évi öt percből?
Sajnos a Tandemekről én se tudok túl sokat, de engem meggyőzött, amikor egy Tandem-es mérnök mesélt róla. Elmesélte például, hogy ezekben minden redundáns. Nem csak a táp - az triviális -, hanem MINDEN alkotóeleme (CPU, memória, buszok, interface-ek, stb...). Azt is elmesélte, hogy valamilyen hardware-es megoldás figyeli, hogy a redundáns CPU-k ugyanazt az eredményt adják-e, így ellenőrizve hogy melyik jó és melyik hibás. (technikai részleteket nem ismerem, hiába is kérdezi bárki)
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Ez innentől eléggé vallási téma - nem láttál még egy rendszert, de valaki azt mondta hogy jó, és ezt Te egy az egyben átvetted.
---
;-(
- A hozzászóláshoz be kell jelentkezni
Azért az nagyon nem mindegy, hogy ki az aki mondja. Vannak ugye megbízható források és...
Amúgy nekem tökmindegy, ki mit hisz.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Én láttam ilyen rendszert, és kb. ez így van.
- A hozzászóláshoz be kell jelentkezni
És pont ez az, amit a megfelelő szoftverrel egy unix griden is el tudsz érni. Párhuzamosan elindítod 2 szálon a számításokat, és ha egy-egy checkpointon nem egyezik az eredmény, akkor rollbackelsz egyet és nekifutsz megint.
Amíg ezt nem tudtad megcsinálni gazdaságosan, mert a belső busz sebessége sok nagyságrendel magasabb volt, mint bármilyen megoldás, ami két különálló szervert összeköt, addig volt a Tandemeknek létjogosultsága, mert a redundanciát 1 dobozon belülre kellett építeni. Mostanában viszont 10GB/s- es hálókártyák vannak, gazdaságosabb ugyan azt a funkcionalítást apróbb építőelemekből összerakni.
- A hozzászóláshoz be kell jelentkezni
MINDEN nem lehet redundans egy gepben. Pl. mi tortenik ha az osszehasonlito elektronika romlik el? :)
- A hozzászóláshoz be kell jelentkezni
Mittudom én? Nem vagyok NonStop support-os. De szerencsére ezeket a gépeket nálam - s gondolom nálad is - okosabb emberek tervezték, akik remélhetőleg gondoltak erre is. Ha meg nem, hát nem.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
ahol a számítástechnika hibája emberéleteket sodorhat veszélybe, nemhogy nem linux, de nem is unix-os gépek vezérelnék
Megnyugtatlak, nem az fut. A lélegeztetőgépeken pl. Windows2000 megy...
- A hozzászóláshoz be kell jelentkezni
A szívultrahangon is.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Na jó, de ha a szívultrahangon fagy le a windows, attól közvetlenül nem halhat meg a beteg. De ha a lélegeztetőgéppel lesz valami, az már probléma...
- A hozzászóláshoz be kell jelentkezni
[evil]Hát elvileg 2-3 percet kibír az ember anélkül, annyi idő alatt csak észreveszi valaki. :-)[/evil]
Viccet félretéve: gondolom, ez valami speciális cucc.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
A legújabb csilivili több10milliós Siemens altatógépekről van szó.
- A hozzászóláshoz be kell jelentkezni
Szerinted nem tudom? :-)
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Nekem is ez jutott eszembe. Az a szívás, hogy mikor lefagy, nem csak kézi lélegeztetésre kell kapcsolni, de elmegy a monitor is. Az ócska régi gépeknél legalább ilyen nem volt.
- A hozzászóláshoz be kell jelentkezni
Ezennel elszomorítalak, a légitársaságoknál is erőteljes tendencia a mainframe-ek kidobálása.
Egyébként azokon is emberek által írt szoftverek futnak, és a szoftverhiba sokkalsokkal gyakoribb mint a hardverhiba. Akkor meg mindegy, min fut a rossz szoftver. Egyébként Linuxszal+pcvel is lehet remek rendelkezésreállást csinálni, igazából szoftver kérdése.
--
Gabriel Akos
- A hozzászóláshoz be kell jelentkezni
No igen PayPal vs. hazai viszonyok... Legutobb 1 ora alatt regisztraltam az eBayra majd PayPalra es meg is rendeltem kinabol a memoriakartyat ami Sanghaibol szallitasi koltseggel olcsobb volt mint kishazankbol (akkorri edigital ar alapjan). Na en hulye tegnap regisztraltam a magyar vatera meg teszvesz oldalakra... Aszongya vatera: utaljak mar nekik 100 hufot na jo en osbizalmatlan nem vagyok hajlando netbankot hasznalni azaz majd hetfon utalok es majd egyszer lesz elo accountom... Ekkor mar sejtettem nem fogom sosem eladni azt a ket alaplapot. Sebaj mellette regisztralni probalkoztam teszvesz nevu formedvenyre is. Anno gyerekkoromban imadtam a Tesz-vesz konyvet es regota szurta a szememet ez a nevhasznalat de sebaj uccu neki... Amig ki nemd erult kuldenek ugy masfel het alatt egy levelet (ertsd csigaposta) de ha ket hetig sem kapok akkor modositsam a regisztraciomat mert tuti vmit rosszul adtam meg csak errol ok engem ugye nem ertesitenek...
Bocs ha offtopic mert tudom PayPal-rol volt szo ez meg eBay de egy tulaj es hat az ugymenetet ha hasonlitjuk "picit" mas...
- A hozzászóláshoz be kell jelentkezni
paypalon is kell utalni pénzt hogy verified legyél
- A hozzászóláshoz be kell jelentkezni
Vagy kártya. Nálunk nincs kártya.
- A hozzászóláshoz be kell jelentkezni
hol rendeltél?
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Ez a 4000 gep csak a tranzakciokat kezeli ?
Még külön vannak webserverek .. etc. -k ?
- A hozzászóláshoz be kell jelentkezni
Ago hozzaszolasa alapjan pont forditva
--
Bow down and admit defeat. | Old, weak and obsolete.
- A hozzászóláshoz be kell jelentkezni
Megbizhato SSD diskek ugy latom ilyen helyeken nagyon jol jonne.
- A hozzászóláshoz be kell jelentkezni
Betonstabil kártyavár? Kőkemény szappanbuborék?
- A hozzászóláshoz be kell jelentkezni
Az SSD garantálja, hogy a CPU által kiírt (tételezzük fel, hogy korrekt) adat a visszaolvasáskor ugyanaz lesz?
- A hozzászóláshoz be kell jelentkezni
Egy darabig igen.
De tudható, hogy meddig tart az a darabig, (törlések száma / blokk)
így tudható mikor érdemes cserélni.
- A hozzászóláshoz be kell jelentkezni
egyáltalán nem tudható. sejthető. akkor már inkább valami raid5
- A hozzászóláshoz be kell jelentkezni
PL. itt egy
Access time: <0.04 ms
BER (Bit Error Rate) <10^-20
Warranty
5 years
Flash eszkozok adatlapjaban fel szoktak tuntetni egy garantalt torlesi ciklus szamot.
Ha ebbe csak 1Gb flash lenne es csak 100k szor torolheto , akkor ~115 napig dd-hetsz -ra random adatott elejetol vegeg irva, hogy ez lejarjon.
- A hozzászóláshoz be kell jelentkezni
Nem minden am a marketing... Melyik komoly vendor tamogatja pl. a jffs2 filerendszert? SZVSZ blade szerverekbe alacsony fogyasztasu OS diszknek elmennek.
- A hozzászóláshoz be kell jelentkezni
TrueFFS -cucc miatt tehetsz ra barmilyen FS -t a HW gondoskodik rola, hogy jo legyen.
Tudod, hogy leszarom Vendorokat :).
(Alacsonyabb szinten oldanám mág tranzakció kezlést, de gondolom egy teljesen új megoldás senkinek sem eladható, mert vevők adnak marketingre )
- A hozzászóláshoz be kell jelentkezni
Meg az SLC NAND Flash miatt. Majd ha az olcsóság kedvéért MLC-t (Multi Level Cell - ld. http://www.micron.com ) fognak használni, mint az MP3 lejátszókban, akkor jönnek a néhány év múlva eldobható vinyók.
- A hozzászóláshoz be kell jelentkezni
SSD-t nem lehet raidbe kötni?
- A hozzászóláshoz be kell jelentkezni
Lehet.
- A hozzászóláshoz be kell jelentkezni
Maradhatunk annyiban, hogy az SSD (mint technológia) semmi ilyet nem garantál? Egyes implementációi esetleg tudhatnak olyat, hogy az interfészükön beérkezett bitet több-kevesebb sikerrel rögzítik és ha az a háttértárban módosulna, még akár észre is vehetik, vagy javíthatják.
De ez sem garantálja a lánc minden elemének védelmét.
- A hozzászóláshoz be kell jelentkezni
BER (Bit Error Rate) mennyi hagyomanyos cuccoknal ?
- A hozzászóláshoz be kell jelentkezni
Mintha rossz hozzászólásra válaszoltál volna. Mi köze a BER-nek ahhoz, amit írtam?
- A hozzászóláshoz be kell jelentkezni
"CPU által kiírt (tételezzük fel, hogy korrekt) adat a visszaolvasáskor ugyanaz lesz?"
Merem remelni, hogy ez a szam azt jelemzi, es nem az SCSI bus-t :)
- A hozzászóláshoz be kell jelentkezni
Arra akartam célozni, hogy egy PC-ben számos pont van, ahol az átvitt adat védtelenül utazik, így annak módosulása akár észrevétlen is maradhat, jobb esetben lerohad az egész.
A BER-nek ehhez annyiban lehet köze, hogy valamilyen valószínűséget mutat az egyes komponensek hibázási arányára, de ennek alacsony volta semmiben sem befolyásolja azt, hogy a kiírt adat szar lesz, ha az nincs védve mindenhol.
(RAS témakör, ha úgy tetszik, amit az Intel is csak nemrég kezdett el kóstolgatni az Itaniummal)
- A hozzászóláshoz be kell jelentkezni
Van ez a könyv: http://www.foundersatwork.com/
Az egyik interjú az elején a Paypal kezdeti időszakáról szól, és bennem nagyon mély nyomokat hagyott. Gyakorlatilag ők sem tudták, hogy mivel kellene foglalkozniuk egyetem után - egyszerűen pár tehetséges srác csinált egy közös céget bármilyen komolyabb üzleti terv nélkül. A Paypal kb az ötödik ötletük volt, de először handheld eszközök közötti biztonságos fizetési tranzakciót lebonyolító szoftverként fejlesztették ki azt hiszem Palmra - a webes fizetési tranzakció dolog csak a demója volt az eredeti ötletnek. Aztán mégis ez jött be.
--
The reason that half of us are in computing at all is that we see computers as things that we can make beautiful things out of..
- A hozzászóláshoz be kell jelentkezni
Tavaly már olvastam ezt a cikket, kicsit hosszabban. Abban elmondták, hogy ezek a frontendeket intézik, az átutalási megbízások fogadását, kezelését stb. De akkor az volt a mondás, hogy a háttérben ott van pár nehézsúlyú SUN vas, Solarissal + Oracle db-vel. Érdemes lehet rákeresni annak akit érdekel. Én egy windows-nyálverőnek küldtem el bosszantásként, hogy "na, hát vannak ilyen hobbi rendszerek is", hogy reagáljak arra a kijelentésére, hogy a Linux mögött nem áll cég, meg hobbi rendszer az egész... nem baj, az élet azóta büntette hiúságáért.
Megvan:
"On the back end, these thousands of systems communicate with just a few large Sun Solaris boxes, which run an Oracle database that stores all customer data. A custom-made database connection-management system links Web processes from the Linux-based Web and middleware tiers of the PayPal site to the Sun/Oracle back end."
- A hozzászóláshoz be kell jelentkezni
Azért 4000 linux szerverre elég nehéz lenne lerakni egy elosztott adatbázist a számla és tranzakció adatokkal....
Erre a célra mindig is nagy gépek lesznek használatban.
- A hozzászóláshoz be kell jelentkezni
Dehogy. Csak megfelelő alkalmazás kérdése.
- A hozzászóláshoz be kell jelentkezni
Nem alkalmazas kerdese, hanem a feladattol fugg, hogy meg lehet-e csinalni. Zwei-nek igaza van abban, hogy peldaul egy nagy teljesitmenyu tranzakcios rendszert nem lehet megcsinalni ilyen szintu elosztassal, mert a feladatot (a tranzakciok tarolasat) nem lehet parhuzamositani egykonnyen, maximum nehany gep kozott.
Azt meg lehet csinalni, hogy a 4000 kiszolgalo gep mogott van egy 2-3-4 gepbol allo adatbazis cluster. De 4000 gepbol nem lehet adatbazis clustert epiteni. Vagyis lehet, de az mar nem a szo hagyomanyos ertelmeben vett adatbazis lesz, hanem inkabb egyfajta elosztott tar. Az ilyen tar pedig nem fogja ugyanazokat a garanciakat adni mint egy adatbazis (nem lesz tranzakcionalitas, nem lesz globalis kepe senkinek a rendszerrol, stb.)
- A hozzászóláshoz be kell jelentkezni
De miért? Én ezt nem tudom elfogadni.
Egyszerűsítsük le a rendszert: a feladat az, hogy mindenkinek nyilvántartsuk a számlaegyenlegét. Kétféle feladat van: számlaegyenleg növelése x-szel, vagy csökkentése y-nal.
Tranzakcióból egyféle lehetséges: a tranzakció indítójának csökkentjük a számlaegyenlegét, míg a kedvezményezettnek ugyanezzel az összeggel növeljük.
Ezt az adatbázist elosztani 2-3-4 gép helyett 4000-re annyiból áll (ez is leegyszerűsítve), hogy a teljes számlaszámteret elosztjuk 1000 felé, az adott számlaszámhoz tartozó adatok pedig konzisztensen mindig négy gépen megtalálhatók.
Azaz amikor az egyféle tranzakció elindul, a tranzakciót indító gép a forrás és a célszámlaszámból tudja, hogy melyik négy gépben kell azt elvégeznie. Azt, hogy ki végezze ezt a feladatot (négy gép konzisztens állapotban tartása) és hogyan (osztott háttértár, dupla-tripla-négyszeres commit) lényegtelen.
Tehát miért nem működhet ez, miért nem lesz tranzakcionális, miért nem rendelkezhet ugyanazokkal a garanciákkal, miért nem lesz globális képe senkinek a rendszerről?
- A hozzászóláshoz be kell jelentkezni
2ms nagyságrendű a vinyó elérése. Ha garantálni akarod, hogy tranzakcó lezajlik pl. 200 ms alatt, kialakulhat olyan szerencsétlen állapot, hogy mindig ugyan arra vinyora és klonjaira kell írni.
Hagyományos felépítésnél is leginkább egy olyan gépre van szükséged (+ redundancia) ahol bele fér mindenki számla adata. (1Tb memoriába 1 Milliárd 1k-s rekord férhet el.
- A hozzászóláshoz be kell jelentkezni
He?
- A hozzászóláshoz be kell jelentkezni
Bocs write only-ban vagyok :)
Csak azt akartam mondani, hogy fel kell lenni készülve extérm helyzetekre, pl. hogy az összes tranzakcio ugyan azt gepet baszogatná.
Diskek maximum seek time -ja meg elég rossz, ezért arra nem nagyon lehet épiteni.
- A hozzászóláshoz be kell jelentkezni
Az igaz, hogy a maximális terhelésre kell felkészülni, de ha 1 gép csinálja akkor 1 egységnyi számla kezelésére kell felkészíteni, viszont ha 4000 gép végzi a feladatot akkor egy gépre csak 1/4000 egységnyi számla juthat maximális terheltség mellett is!
Szerintem a feladat eben az esetben jól párhuzamosítható, hiszen egy művelet végrehajtásához nem kell a teljes adatbázisra rálátással rendelkeznünk. Persze azért még adódik a kérdés, hogy milyen gép fogja a műveleteket szétosztani. Pl. két eltérő gépen lévő számla közötti pénz mozgatás esetén, mi van ha csak az egyiken sikeres a commit, mert akkor a másikról is vissza kell hívni a tranzakciót. Erre viszont jó megoldás lehet ha területi alapon vannak csoportosítva számlák, az országon belüli tranzakciók valószínűbbek mint az országon túliak, így ritkábban fordul elő, hogy gépek között keljen tranzakciót végrehajtani.
Szóval, szerintem csak tervezés kérdése a dolog, a DNS kiszolgálás is hasonló, szét van osztva rendesen és mégis működik (persze azért az más).
- A hozzászóláshoz be kell jelentkezni
Az ilyen jellegu feladatok eseten az szokott a gond lenni, ha ket szamla kozott kell atvezetni egy osszeget, tehat nem egy, hanem altalaban ket szamlat nyilvantarto gep kozott kell tranzakciot fenntartani.
Ekkor ket problema is adodik:
1. Deadlockok lehetosege, de legalabbis tranzakciok kozti contention point (egymast utjaba kerulnek a kulonbozo szalak) kialakulasa.
2. Elosztott tranzakcio lemenedzselese lassitja a rendszert, es igazan nincs ra teljesen megbizhato megoldas (mindenkepp fennall annak a lehetosege, hogy kommunikacios hiba fellepesekor az egyik eroforras commitolt a masik meg rollback-elt, ami csak kezzel kijavithato problema).
Amennyiben nem kell ket szamla kozt atvezetni a tranzakciot, akkor teljesen jol skalazhato vizszintesen a feladat szamla id-k szerint teljesen melysegben particionalt rendszerrel (plusz gep berakasa kozel linearisan noveli a rendszer teljesitmenyet).
Udv,
Finrod
- A hozzászóláshoz be kell jelentkezni
szerintem reiserfs-sel lehetseges
--
Bow down and admit defeat. | Old, weak and obsolete.
- A hozzászóláshoz be kell jelentkezni
> szerintem reiserfs-sel lehetseges
1 TiB memória? Reisefs-sel? Lehetséges?
Én kérek elnézést ...
- A hozzászóláshoz be kell jelentkezni
úgy érti kubuntun
- A hozzászóláshoz be kell jelentkezni
Amennyiben nem feltetel az adatbiztonsag :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
> Egyszerűsítsük le a rendszert: a feladat az, hogy mindenkinek nyilvántartsuk a számlaegyenlegét.
Egyszerűsítsük le a rendszert: a feladat az, hogy megbízhatóan nyilvántartsunk egy eseménynaplót.
Az összes számlaegyenleg, számlaforgalom, stb., ebből a naplóból származtatható, adatvesztés esetén a naplóból minden újragenerálható.
Az eseménynapló nem adatbázis, hanem csak egy folyamatosan növekedő, de egyébként adattartalmát tekintve változatlan lista. A 4000 gépnek az az elsődleges dolga, hogy ennek a listának a lekérdezéseit minimalizálja (gyorstárazza).
Az adatvesztés csak annyiban számít, hogy nyilván jobb, ha minél kevesebbszer következik be, és nyilván rossz, ha az adatvesztés nem érzékelhető. Egyébiránt az adatvesztés a gyorstárazó gépeken nem bír jelentőséggel.
Elegendő a napló adatvesztésének a megakadályozására koncentrálni.
Szerintem.
- A hozzászóláshoz be kell jelentkezni
kicsit leegyszerűsíted a képet. Ha csak olyan tranzakciókról lenne szó, amik mindig 2 számla között zajlanak, még talán megoldható a dolog.
Viszont általában egy-egy számlaszámhoz tartoznak még technikai számlák, illetve globális technikai számlák is, amiket ilyenkor is módosítani kell.
Vannak olyan műveletek, amiket a teljes aktív számlatartományon kell elvégezni. Pl. időszaki zárási folyamatok, statisztika, stb.
Ezeket ezres nagysgágú szerver esetén baromi nehéz kopnzisztensen összehangolni. Főleg azért, mert ezek nagy része adott időn belül kell, hogy megtörténjen.
Pl. bankközi utalásoknál az esti zárási folyamat után le kell generálni azokat a tételeket a teljes adatbázisból, amik az éjszakai giro küldéskor kimennek a bankközi elszámoló rendszer felé, majd pár órán belül az elszámoló rendszerből érkező tételek fogadásakor ismét update-elni kell a teljes adatbázist, szintén egy adott időn belül.
Ha bármelyik adatbázisszerver kiesik egy-egy ilyen műveletkor, akkor legjobb esetben is kicsúszol az időből, rossz esetben meg totál szétcsúszik a teljes adatbázis.
Egy ilyen több száz node ból álló rendszer üzemeltetése egy rémálom, mert ha bármilyen hiba miatt vissza kell görgetni az adabázist, vagy mentésből visszatölteni 1-1 szervert több száz szerveren kell elvégezni a rolback-ot, vagy kihámozni, hogy 1 elem kiesése milyen más szerverek adatállományát érintette.
Nem azt mondom, hogy lehetetlen megcsinálni egy ilyen elosztott rendszert, de jóval egyszerűbben és olcsóbban kijön az ember, ha beállít 1-2 nagy vasat 80-100 processzorral, meg 2-300 GB memóriával.
- A hozzászóláshoz be kell jelentkezni
Erre is van koncepciom.
Ugy latom sokakt erdekel a tema..
Kicsit nagyobb lelekzet vetelu iras 0. kozelitesben leirni mire gondoltam, amikor legutobb szoba jott ez tema, talan mejd ezt is leirom, de mar sokmindenre mondtam ezt, az ido meg keves.
- A hozzászóláshoz be kell jelentkezni
"De 4000 gepbol nem lehet adatbazis clustert epiteni. Vagyis lehet, de az mar nem a szo hagyomanyos ertelmeben vett adatbazis lesz, hanem inkabb egyfajta elosztott tar."
Azert ez igy nem egeszen igaz. Nezd meg a Mysql Cluster vagy az Oracle TimesTen nevu cuccost, meg fogsz lepodni :-)
- A hozzászóláshoz be kell jelentkezni
Mifelenk manapsag HP DL585-osok vannak terjedoben adatbazisszervernek, szepen szorulnak vissza a korabbi "nagy" vasak. Persze semmifele lokalis diszket nem hasznalunk adattarolasra, kizarolag SAN diszkekre dolgozik.
- A hozzászóláshoz be kell jelentkezni
Azt ugye tudod, hogy a HP DL585 teljesítményének megfelelő "nagy vasak" kb. 10 éve számítottak nagy vasnak. Nézd meg pl. az IBM p595-t (64 cpu, max 2T RAM), vagy a Sun Fire 20K (38 cpu, 576Gb RAM).
Itt nem csak a memória és a cpu darab szám ami sok, hanem a belső busz sebessége , illetve I/O sávszélessége is elég jó. (A p595 pl. 196Gbps max io peak-ot bír.)
Ezek a nagy vasak, és igen, van olyan hely, ahol ezek kellenek.
- A hozzászóláshoz be kell jelentkezni
A PC architektura I/O tekinteteben ugy vacak, ahogy van, ebben egyetertunk... Mellesleg en is sokkal szivesebben latnek itt PPC-s gepeket mint x86-ot, de nem vallalja fel a ceg a harmadik architekturat. Nekem mar az OpenPower 7xx is tetszett, pedig az meg csak a beleposzint. A nagy vasakat probaljuk izmos PC-kbol epitett cluster-ekkel helyettesiteni, mert meg a meregdraga PC cluster is olcsobb. Van ahol megy, van ahol nem.
- A hozzászóláshoz be kell jelentkezni
Erre szolgál az Oracle Grid technológiája, több száz(ezer) gépet össze tudsz kötni...
- A hozzászóláshoz be kell jelentkezni
Hat, azert az Oracle nem mindegyik Grid technologiajaval tudsz tobb szaz, tobb ezer gepet osszekotni.
Az Oracle RDBMS grid-je pl. nem igazan jol skalazhato.
Az Oracle Coherence, az igen... azt viszont igazan csak vette az Oracle iden aprilisban. Elozoleg ugy hivtak, hogy Tangosol Coherence.
- A hozzászóláshoz be kell jelentkezni