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.
