OFF ötlet

Gondoltam összeírnám, hogy mivel rúghatná tökön felhasználóit a google, de aztán mégsem... Kétségtelenül lekapcsolhatnak ezt is azt is, meg le is fognak, de a leghatékonyabb terheléscsökkentést szerintem azzal lehetne elérni, ha googlplus regisztrációhoz kötnék a gmail használatát. Akkor indulna csak meg a fejvesztett menekülés :)

Gyárlátogatás: az adatbázis

Rég voltunk gyárlátogatáson, gondoltam ismét belerúgok a műfajba, ezúttal az adatbázisok és használatuk területéről írok pár személyes élményemet. Mint mindig, nem arról lesz szó, hogy hogyan kellene, hanem arról, hogy mit csinálnak a szakik a gyárban.

Fellegvár

97 Dolog, amit minden Architektnek tudnia köllene (és mégse tudják), 23. bejegyzés: Legyen erőd az adatbázisod!
Ezt a sírjára vésném azoknak, akik nem tartják be :-) Az adatbázist nem bíznám az izgága programozókra. A DBA egy külön szakma, más mentalítást és más egyéniséget igényel, mint a szoftverfejlesztés. A legjobb tapasztalatom adatbázisokkal annál a munkahelyemnél volt, ahol külön DBA csapat volt. Ezek a csákók vágták az adatbázis minden paraméterét és rendesen lecsesztek mindenkit, akinek az alkalmazása nagy mennyiségű hülyeséget csinált. Persze nem klassz, amikor az embert lecseszik, de néha hasznos.

Az profi üzemeltető csapatból következik még egy dolog: nem akarnak sokféle adatbázis szervert üzemeltetni. Ha elöjössz azzal, hogy neked KakukkSQL kellene, mert a hétvégén kipróbáltad és most az a kedvenced, őseid legkevésbé sem magasztaló kontextusban kerülnek megemlegetésre.
Többnyire 1 cég 1 adatbázishoz ragaszkodik, de legalább abból az egyből elég jó szolgáltatást kapsz.

Ha így nézed a dolgot, marha fontos, hogy az alkalmazásod több adatbázissal is jól szaladjon, amennyiben nem csak 1 ügyfélnek akarod eladni, illetve nagy ügyfeleket is szeretnél célozgatni, akik nem akarnak holmi közös felhőben lakni. Oké, talán ez egyre kevésbé tényező...

Szamócából fellegvár

Egy régi főnökömtől származik a mondás, ami mindig eszembe jut, amikor egy adatbázist rendesen tökön rúg egy alkalmazás:
"Ne aggódj, az Oracle végtelenül skálázható." Én meg kérdeztem mint egy hülyegyerek hogy "Tééélleg? És mennyiért?"

Ezt általában el lehet mondani, hogy kevés elképzelése volt az embereknek eleinte arról, hogy mennyit bír egy adatbázis szerver és a hardver mérettel ez hogyan változik, illetve az adatbázis mérete hogyan befolyásolja a teljesítményt. A fenti dologgal ma már nem hiszem, hogy bárki előjönne, de nekem úgy tűnik továbbra is kevesen tudnak arról bármit is, hogy az adatbázisuk miből mennyit bír. Konkrétan számszerűen, mert az akármennyi az nyilván baromság.

Indexelés és optimizálás

Sajnos nagyon kevés java fejlesztő néz bele akármikor is, hogy a lekérdezései mit is csinálnak konkrétan, pedig minden adatbázisban van valami query debugger funkció, többnyire explain-nek hívják. Ez azért lenne fontos, mert az adatbázis a munka nagy részét elvégzi, amit a hétköznapi ügyviteli rendszereink csinálnak, az valójában csak minimális feldolgozás rajta. Ha kicsit jobban bánunk az adatbázissal, az valószinűleg kategóriákkal többet fog javítani az alkalmazás teljesítményén, mintha felűberelnél a JLophas AS legeslegújabb verziójára, vagy mint ha a teljes alkalmazásban levadásznád a hülye "ez" += "az" konkatenációkat, a temp objektumokat, satöbbi. Sajnos ez van.

 

JPA&Co

Sajnos a perzisztencia frameworkok csak tovább növelik ezt a távolságot a fejlesztők és az adatbázis között. Annyi azért viszont biztos, hogy a JPA implementációk nem generálnak olyan idióta lekérdezéseket, mint egyes alkalmazások JPA nélkül. Most inkáb kihagynám a példát :-D de biztosan találsz a házad táján.

Kétségtelenül nagy előnye a portolhatósága és a gyors fejlesztés, de néhány dolgot néha optimalizálni kell, különben agyonveri az alkalmazásodat. Erre javasolnék egy patternt: csinálj egy általános JPA DAO-t, ebből származtass le szükség esetén DB-specifikus implementációkat és bíráld felül (gyakorlom a magyar nyelvet, az override-ra gondoltam) azokat a lekérdezéseket futtató metódusokat, amiket optimalizálni akarsz. A DAO-kat egy factory-val gyártsd le, ami az adatbázis típusától függően ad vissza egy implementációt.

Mégegy dolog: az automatikus séma generálás nem jó, mert az említett "erődítmény" tétellel ellentétes. Prototypinghoz természetesen kiválló, de az adatbázis adminisztrátorod megöl érte. Talán érdemes írni egy listát, hogy mit kell tenni amikor már komolyan gondolod az alkalmazás fejlesztését, és mondjuk így kezdeni: automatikus séma generálás kikapcs.

 

Cache vagy MQ

Egy gyakori probléma, amivel találkoztam, hogy az adatbázist cache-ként vagy üzenetek küldésére használták. Ennek az oka valahol az egyéb infrastruktúra hiánya és az ismeretek hiánya között volt általában, kicsit mindkettő.
Talán ida tartozik, hogy a Quartz is használ relációs adatbázist Job storeként és elosztott lockoláshoz. Határeset...
Mondjuk a Quartz-ról ma hajlamos vagyok azt gondolni, hogy antipatternek gyüjteménye.

 

Tárolt eljárások

Ez egy rettenetesen vitás téma az adatbázis adminisztátorok és a fejlesztők között. Több DBA-val találkoztam, akik megkövetelték vagy elvárták a tárolt eljárások használatát.
A java fronton ellenben a tárolt eljárásoknak nem igazán népszerűek. Illetve igazán nem népszerűek. Ennek több oka is lehet: elösször is egyetlen egy tárolt eljárás nyelv sem portolható. A java tárolt eljárások inkáb az előző évtized közepe tájám volt egy próbálkozás, csak a DB2 és az Oracle támogatta, PostgreSQL-re ketten írtunk rá támogatást, de őszintén egyikünk sem lett nagyon népszerű vele, évek óta leálltunk a fejlesztéssel.
Portolhatóság szempontjából a tárolt eljárás inkább akadály, mint segítség, a legtöbb persistence framework nem tud velük mit kezdeni.
A népszerűtlenség nagyobbik oka viszont nem a portolhatóság hiánya, hanem egyszerűen az, hogy a tárolt eljárásoknak az esetek nagy részében egyszerűen nincsen semmi előnyük, de nehezeben áttekinthetővé teszik a rendszert. Példának sajnos az oVirt-et fel tudom hozni, a legegyszerűbb lekérdezést is bele kell csomagolnunk egy tárolt eljárásba.

Igazából én egy csomó lehetőséget látnék tárolt eljárásoknak olyan téren, mint az interakciók számának csökkentése az adatbázis és az alkalmazás között. Pl insertOrUpdate, insertAndReturnId. Ilyesmi használatát nem emlékszem hogy láttam volna valakitől.

Tranzakciók

A tranzakciókkal is láttam pár buherát. Egyes rendszerek (pl ovirt is sajnos) egyenesen problémaként élik át a tranzakciók létét és bonyolult, bizonytalan kimenetű dolgokat csinál a kicselezésére.
A kedvenc trükk, amit láttam, mégis az volt, hogy az app egy bizonyos lekérdezésre nyitva hagyta a tranzakciót és a kapcsolatot, meg egy ResultSet-et is, és a következő http requestre tolta ki az eredményt html-be. Néha, amikor a második http request mégsem ütött be, akkor kicsit elakadtak a dolgok. Erre adta a rendszergazda azt a diagnózist, hogy "A program egyébként jó, de a tomcat egy rakás sz.., naponta újra kell indítani"
Ezek a trükközések elég hajmeresztőek, de nem ritkák.

A NoSQL forradalom

Nincs antipattern tapasztalatom a NoSQL adatbázisokkal, mert sajnos munkában még soha nem használtam őket, de alig várom. Talán oda jutott a dolog a tradícionális RDBMS modellel, hogy néhány dolgot, például a tranzakciókat (lásd fent) egyáltalán nem találunk hasznosnak egy olyan alkalmazásban, mint egy chat, alkalmazás logok, vagy szociális háló. Egy évtized kellett hozzá, hogy az internet ipar saját ötlettel áljon elő és elrugaszkodjon az inkáb a pénzintézetek igényeihez igazodott modelltől. Jelenleg annyi NoSQL adatbázis van, hogy nem tudom felsorolni őket és nem tudok mindegyikkel lépést tartani. Azt hiszem még évekbe fog telleni, amig letisztul a terep, pár kellemetlen élmény keletkezik elötte. Például a mongodb-ről hallottam pár forrásból, hogy végül felhagytak vele. Én még mindig hajtom, persze nem atomreaktort vezérlek vele. Egyébként nem hiszem hogy a mongo végül a kiesők között lenne, de pár másik ott lesz.

pubsub humbug

A Google pubsubhubbub szolgáltatásához 2011 óta senki sem nyúlt, látszólag megint egy frontvonal, amiről a google visszavonta a harcoló alakulatait. Ez viszont nem jelenti azt, hogy nincs semmi változás a szolgáltatásban. Ez talán bug volt, de olyan RSS csatornára is fel lehetett íratkozni, ami egyébként nem küldött a pubsubhubbub-nak értesítést, azaz nem publikált megfelelően. Ebben az esetben a pubsubhubbub csak pollozta. Ez egy nagyon kellemes kis bug volt, mert nem kellett pollozni az RSS csatornát, elég volt, hogy a google pollozza, és tovább küldte. Nos február elejétől kezdve nem küldi tovább.

Egyébként a pububsubbub tipikus félbehagyott forradalom, a legtöbb RSS csatorna egyszerűen még mindig a gúgli pubsubhubbub szerverét használja, a wordpress az egyetlen legnagyobb kivétel, ők szép sajátot csináltak és működtetnek.

Lásd még:

• előző bejegyzésem a pubsubhubbub protokolról.
• egy mérésem a pubsubhubbub hubok használatáról

6

Teljesen OFF, csak eszembe jutott, hogy 6 éve kezdtem írni ezt a blogot. Köszi mindenkinenkinek a kommentjeit!


6 év alatt marha sok minden változott. Közben írogatok néha a Dummy Warhead-re, valamint idén (igérem) el fogok kezdeni egy az Example Driven Development-be is írogatni.

Emellett akad időm néha a magyar wikipédia cikkeiben javítgatni. Sajnos bőven van mit, szóval ha van egy kis időtök fussátok át, küldjetek pár megjegyzést vagy akár írjatok bele a cikkekbe, ne legyen a cloud computing téma ilyen rettenetes állapotban!

[szerintem nem] elszállt ötletek: a VM scheduler

Szóval arra gondoltam az óév pár utolsó napján felrázlak titeket pár ötletemmel, talán pár hasznos dolog is kisül belőle. Kicsit többre gondoltam eredetileg, mint amennyi összejött, de egy hétig otthon voltam, mászkáltam erre-arra.
A legutóbbi ötlet végén utaltam egy megintcsak meló-kategóriás ötletemre az oVirt-tel kapcsolatban: szeretném kicsit okosabbá fejleszteni az oVirt VM-schedulerét. Valamennyire megvan rá a jóváhagyás is és erről a témáról beszéltem idén Barcelonában a Linux confba beágyazott oVirt workshopon.

Mi az a VM-scheduler?

A scheduler az a dolog, ami a vason kiosztja a vason, hogy mi és hol fusson. Egy ilyen nyilván minden operációs rendszer kerneljében fut nagyon frekventáltan, hogy eldöntse hogy melyik processznek adjuk oda egy kicsi időre a CPU-t. Ezek az algoritmusok egészen bonyolultak is tudnak lenni (pl gondolj csak a NUMA architektúrára) ahhoz képest, hogy nagyon gyorsan kell futniuk, tudományos cikkeket írnak róluk, satöbbi-satöbbi. Szerencsére van rá az ember, mert én ezzel nagyon nem akarnék foglalkozni.
A VM scheduler egy kicsit más kategória:

• a feladata a virtuális gép számára egy fizikai szerver kijelölése
• plusz esetenként (kellemetlen esetenként) migrációk ütemezése
• ritkábban fut: minden alkalommal, amikor Vm indul, illetve ha egy szerver terhelése túl nagy
• több erőforrás áll rendelkezésre
• viszont a teljes szerverfarm teljesítménye nagyban függ a döntés minőségétől
• a cefet-nagy sebességgel szemben én többre értékelném a skálázhatóságot és az értelmes eredményeket, persze a sebesség is szép

Mit tud ma az oVirt schedulere:  erről már írtam egy nagyon bosszús pillanatban, ugyanakkor amit írtam fentartom: a scheduler lassú, a kód zavaros és a döntései néha egészen hülyék.

Szóval mi történik ezen a fronton: egy ideje semmi, mert más (tökunalmas marhaság) feladaton kellett dolgoznom, de egyébként elkezdtem írni egy specifikációt és egy patch-et, ami a drools plannert használja fel optimalizációra. Ebből osztanék meg veletek pár alapötletet:

• A drools planner úgy dolgozik, hogy egy bizonyos felálláshoz kiszámítja a pontokat, aztán keresőalgoritmussal nekilát jobb felállást keresni. Szóval a pontszámítás a lényeges pont. A pontszámításra azt találtam ki, hogy külön kiszámítjuk minden esetleges tervhez:
• a szituáció költségeit: ide tartozik az, hogy mennyire fáj a jelenlegi helyzet, olyanok mint CPU-túlallokáció egy kis bünti, memória túlallokáció egy kicsit nagyobb bünti. A tényleges CPU és memória használat is ide kerül, csak azokra sokkal nagyobb böntit szabunk ki.
• az esetleges migráció költségeit: a migrációnak kell legyen egy alapköltsége, hogy ne dobáljuk idiótán pillanatnyi ötletek alapján a virtuális gépeket egyik gépről a másikra. Ezen kívül egyes erőforrásokat is megadóztatunk a migráció során, például a lefoglalt memóriát teljesen át kell másolni a másik gépre, ami idő persze.
  Itt üthetnek be a hard constraint-ek, pl a cél gépnek egyáltalán nincs annyi memóriája, mint amennyire a VM-nek minimum szüksége van.
• a migráció előnyeit (kompenzáció): miután megadóztattuk rendesen az aktuális helyzetet, és mindent ami esetleg kivezet innen, kell egy dolog, amit a kereső megtalálhat esetleg jobb megoldásként. Itt ilyen dolgokat lehet fdelsorolni, mint pl a CPU-overallocation a migráció után kisebb lesz. Illetve ha nagyobb akkor még arra is büntetést teszünk ki a kompenzáció helyett.

•  A schedulernek bizonyos időn belül válaszolnia kell. Egy cluster áttervezésnél én el tudnék viselni akár 4-5 másodpercet is, de kifejezetten értékelném, ha folyamatosan és inkrementálisan tervezne. A VM startnál kicsit izgágább a kedves felhasználó, általában szeretnék, ha a VM felstartolna vagy legalábbis valami választ kapnának egy másodpercen belül.
• Több VM indításakor rettenetes lenne egyenként végigmenni a VMeken és mindegyikre kiválasztani egy szervert, elindítani. Talán 2-3 VM-mel elmegy, de 50-100 VM-mel idegesítő és lassú. Egy terv kell az összes startolt VM-hez, azok szükségleteinek és a hostok képességeinek megfelelően.

Hát ennyi röviden, szóval remélem az újévben erre lesz majd időm. Lenne utánna pár további ötletem, de olyan lépésben haladunk, hogy az már tényleg scifi kategóriába tartozna.

Hát szóval ennyit erre az évre, remélem tetszett ez a pár évvégi ötlet, esetleg megihlet pár sajátot.

A tömörítéssel kapcsolatos dologba belerúgtam egyet, ha érdekel mérések a dummy warhead-en. (tudátok, a "hibás-de-sebaj" angol blogom)

Akkor legyen ennyi erre az évre :)
Boldog újévet!

elszállt ötletek: cloud storage

Nem ittam semmit esküszöm.

Mese: szóval a melóban az oVirt-tel amikor éppen akadt szabadidőm, a virtuális gépeimen a I/O sebességet teszteltem. Az oVirt támogat egy halom tárolótípust (nagyjából ugyanazt mint a libvirt). Sokmindenen múlik az I/O sebesség a tárhelyen kívül is, például egész sokat lassít rajta amikor thin provission, de hát valamit valamiért :-) Szóval kipróbáltam az NFS-t és az iSCSI tárolókat, mindkettő csalódás volt. Oké az olvasási sebességgel nem volt különösebb probléma, hozta azt a sebességet amit a merevlemezeken és a gigabites etherneten kifért. Az írás viszont botrány volt. Thin provision vagy nem, az NFS pocsék sebességet produkált és semmivel nem tudtam jobb sebességre rávenni. A fanok mondták, hogy a netapp storage-gel az NFS is egész gyors, de nem vagyok csilliárdos és éppen most nincs netapp szerverem. A munkatársak mondták hogy az iSCSI sokkal jobb lesz. Tényleg sokkal volt jobb, kereken kétszer jobb írási sebességet tudott, de ilyen kis számoknál a kétszer nagyobb még mindig kevés. Marhára kezdett érdekelni a GlusterFS, de még nem volt időm foglalkozni vele. A képzési keretemet szivesen beleölném :-) A tesztelő srácok, akiknek viszont van idejük nagyon sokat játszani, azt mondták hogy a glustertől se várjak sokkal többet, mert egyelőre egy disk az egy file, egy file az egy bricken és egy brick az egy szerveren van. Logikus, de demotiváló.
És persze a storage csapatnak se vagyok tagja. Nem is tudom van-e köztük java hegesztőmunkás. (és nem tudom kik azok, bajok vannak a nevekkel)
Szóval a kutatás teljesen befejezetlen, de pár saját pofátlan elvárással előálltam magamnak.

Ezen gondolkodtam: Mondjuk van egy szervered, benne egy sata vinyó, van egy gigabites hálózati kapcsolat, a hálózaton van még pár hasonló szerver. Mennyit lehetne kihozni ebből? Szerintem jobbat ki lehetne hozni, mint 200 MB/sec sustained R/W. A helyi sata vinyó elvisz 100-at, a gigabites etherneten keresztül a többo majdnem 100-at, és kicsit kombinálva a múltkori "talán gzip" dologgal, 200 fölé lehetne lökni, "csak" kombinálni kell az erőforrásokat. Olcsó gépen, egész jó teljesítmény. Szintén marha jól tudná javítani a random R/W sebességet, mert nem csak egy merevlemez fejét rázod, hanem amennyi van. Egy ilyet szeretnék a VM alatt. Éppen úgyis karácsony lesz mindjárt.

A másik fontos dolog: a lehetőleg VM fusson ott, ahol az adatai vannak. Nem érdemes átcipelni máshova azért, hogy aztán majd visszacipeljük. Konkrétan ilyesmiken dolgoztam is, mégpedig munkaidőben. Ki hinné hogy néha értelmes dologra is sor kerül :) Hamar le is álltunk...

Ez publikus cloud-ba nem igazán passzoló elképzelés, egy publikus cloud provider nem érdekelt abban, hogy a SLA-ban leírtaknál jobb teljesítményt adjon ha van rá lehetőség. Egy privát cloud-ban simán mehetne, had villogjanabbak vadabbul a ledek.

Ez a terület egyike azoknak, ami baromira érdekelne, ha találnék rá időt hogy foglalkozzak vele.

Legközelebb valami épkézlábabb dologgal jövök, addig megyek megmászok pár hegyet. Igen, talán a vm scheduler, bár azt a poént az elöbb lőttem le.

elszállt ötletek: peer to peer apps

Mindig jön valami legújabb webes dolog, amire rákattan mindenki. Aztán vagy a birkanyáj szellem, vagy a szakmai érdeklődés odavisz minket is. Egy ilyen szolgáltatáshoz egyre több szerverre van szükség, egyre több embert kell foglalkoztassanak, egyre magasabb hierarchiák alakulnak ki a cégben és ezek kiadásokat generálnak. A kiadásokat pedig bevételekkel kell fedezni. Ez természetes egyébként is hozzá vagyunk szokva, de sajnos ezen a ponton kezd a dolog elkurvulni:

• egyre több reklám jelenik meg (pl iwiw, index, origo)
  Aki kicsit is ért hozzá, az adblockert használ, de ez az összes felhasználó alig néhány százalékát teheti ki. Kérdezz körbe a családodban, a legtöbb ember még nem is hallott róla, hogy böngészőkbe pluginokat lehet rakni. Pedig van egy hegesztőmunkás a családban!
• privacy visszaélések jelennek meg, spamelnek (freemail tipikusan)
• a felhasználói felületen megjelennek a dark pattern-ek (kedvenc példám a go daddy)
• A fizető fél tartalmának előretolása (youtube, facebook, twitter, linkedin)
• Földrajzi régiók kizárása a free domainből (last.fm) vagy egyes tartalomból (youtube)
  Persze szerezhetsz egy proxyt, de a nagyközönségnek ez sem megoldás.
• Talán a legkevésbé elcseszett eset az, amikor a nagy felhasználóktól kérnek pénzt. (twitter firehose)

Az eleinte jól kezdődő szolgáltatás használhatósága zuhanórepülésbe kezd, a korai felhasználók menekülnek, 1-2 éven belül követi őket a nagyobb közönség. Az egész csak a pénz miatt, amit a cég és az infrastruktúra fentartására be kell szedniük.

...hogy mi lenne akkor,
na jó, ez csak elmélet...

Mi lenne akkor, ha a probléma alól megpróbálnánk kirúgni a széket úgy, ahogy a bittorrent teszi a filemegosztással. A dologba kicsit belekevernénk egy aszimetrikus titkosítást is, mindenki a rekordját egy saját kulccsal írná alá, egy publikus kulccsal lehetne olvasni, de írni nyilván nem. A hálózathoz csatlakozhatna tetszőleges node, attól függően hogy publikus vagy nem, de mindenki hostolná a saját adatait és valamennyit valaki máséból, csak hogy a redundancia is meglegyen. Az egész annyiban különbözne az elosztott adatbázistól, hogy nem csak az adatok repülnek a dróton, hanem néhány feldolgozásra vonatkozó kérés is: keresések, funkcióhívások, stb.
Nyilvánvaló előnyök:

• Az adat köztulajdon, nincs központi hivatal, ami elveheti, még az állam sem
• A felhasználók számával együtt nő a kapacítás
• A gyakran használt adatokhoz baró gyors hozzáférés
• Nincs központi szerver, ami kieshet. Ha néhány gép kiesik, csak azok az adatok vállnak elérhetetlenné, amik csak azokon a gépeken voltak meg.

Előre látható kihívások és kellemetlenségek:

• Trollok, spam és rongálók. Akár pornó is, mármint kéretlenül
• Hogy a feszegetőkről ne is beszéljünk...

Ezekre valamennyire van megoldás, spamfilterek, felhasználói interakciók a trollok jelölésére és blokkolására, satöbbi... persze a hülyeségre nincs orvosság. Milyen alkalmazásokra gondoltam tipikusan:

• social network akár - amennyiben még mindig meg akarod osztani a barátaid listáját
• akár hirdetési rendszerek is
• akár kereskedelmi rendszerek is
• tulajdonképpen akár csoportmunka jellegű szoftverek is, pl egy prezi-féle dolog, vagy egy , amin a szerver igazán csak púp

Nem fogok egyébként minden nap egy elszállt ötlettel előállni, ez csak ilyen év végi nagytakarítás :-)