Bosszantó apróságok
Nyugodtan kezdhetjük a rossz hírekkel, nem lesznek nagyon rosszak, inkább csak bosszantó apróságok.
Az egyik ilyen az, hogy 32-bites rendszeren a mongodb behúzza a kéziféket és max 2 GB méretű adatbázist enged. Ez lófüffy, fogalmazzuk talán inkáb úgy, hogy 32-bites rendszereken a mongodb röpképtelen.
A másik apróság, amibe belefutottam még az elején, az az hogy a OpenVZ virtuális gépeken valami okból memóriaszivárgás van a MongoDB szerverben és ettől teljesen használhatatlan. Bevallom nem néztem igazán utánna, de itt került fel az OpenVZ a ganajlistára. Miféle virtualizációs technológia az, amivel egy adott szoftver a vendég operációs rendszerben behal? Gubancos, gondolom.
Sokkal inkáb bosszantó a MongoDB hanyag viselkedése a tárhellyel. Az alapbeállításokkal folyamatosan logolja az összes adatmódosítást, ami rettenetes méretű logokat eredményez nálam. Kicsit kellett keresgetnem hogy hogyan lehet kikapcsolni.
A másik tárhely-kellemetlenség 3 GB-os journal, amit az adatbázis inicializálásakor létrehoz. Bár a memóriafogyasztása egyébként nagyon frankó lenne, ez a 3 GB journal kicsi adatbázisokhoz nagyjábol diszkvalifikálja. Ki lehet kapcsolni, akkor kicsit visszavesz a sebességből és egy esetleges crash teljesen hazavágja. Akkor most gondolkozzunk el rajta hogy mit szeretnénk inkáb.
Klassz dolgok
Szóval az egyik klassz dolog amit igazán kedvelek a MongoDB-ben, az UPSERT, ami az "insert or update"-re egy rövidítés. Ez pl log feldolgozáskor marha gyors tud lenni és az alkalmazáson is nagyon sokat egyszerűsíthet. Az upsert egyszerűen úgy működik, hogy megmondod a keresőfeltételt és egy dokumentumot. Ha talál a keresőfeltételnek megfelelő dokumentumot, akkor ahhoz hozzávágja az új dokumentumot, tehát azokat a kulcsokat, amik a régiben voltak, azokat felülírja (itt lehet trükközni), ha nincs ilyen kulcs, akkor hozzáteszi a dokumentumhoz. Amennyiben nem talált ilyen dokumentumot, akkor csinál egyet, ami megfelel ennek a keresésnek, azaz benne lesz a keresett kulcs és a bedobott dokumentum.
Nézzük a fent említett okosítást: például nekem hasznos az, hogy egy dokumentumban egy tömbhöz fűzök hozzá értékeket illetve érték párokat. Erre jó a PUSH, amivel a régi doksiban nem írja felül a régi értéket, hanem csak hozzáappendel. Ez upsert esetében is teljesen jól muzsikál.
Az marha sokat segít, hogy nem kell csekkolni, hogy egy dokumentum létezik-e már a feldolgozás során.
A sebesség a másik baró dolog. Eleinte voltak olyan tévhiteim, hogy az adatmennyiséggel egy beágyazott derby is el fog boldogulni. A derby hozta is a formáját az első pár órában, amikor azonban a memória méreténél nagyobbra nött az adatbázis mérete, beleállt a földbe a teljesítménye.
Trükkök
Relációs adatbázishoz szokott barátaim: egy pár dolgot át kell gondoljunk, amikor mongodb országba települünk.
Például relációs adatbázisokban nagyjából magánügy, hogy hogy nevezed a tábláidat és az oszlopokat, a teljesítményre aligha van hatással, mert nem kerül bele minden rekordba, legfeljebb amikor lekérdezést küldünk az adatbáziszervernek akkor kicsit több byte-ot küldünk. Nem nagy ár, ezért inkáb érthetőre próbáljuk faragni a relációs sémát szép oszlopnevekkel. A különbség egy dokumentum-alapú, séma-nélküli adatbázisnál az, hogy minden dokumentumban benne vannak a kulcs-nevek, így a rövidebbet jobb sebességgel jutalmazza az adatbázis szerver.
Én pofátlanul mindent egy-két betűsre rövidítettem. Ezt a dolgot ha valaki átvenné tőlem, nagyon gyűlölne.
Ezzel kapcsolatban jut eszembe az _id kérdése. A mongoDB minden dokumentumba beletesz egy _id nek nevezett, 12-byte hosszú azonosítót, amiben a szerver azonosítója, egy random szám, valami sorszám, a heti lottó nyerőszámok és ilyesmi tlálható. Az én alkalmazásomhoz nem volt igazán hasznos, de egy databig nem jöttem rá erre:
A dokumentumodnak amúgy is kell valami, ami amolyan elsődleges kulcs. Egyszerűen ezt a dolgot hívd _id-nak. Még akkor is, ha az "id", az "azon", és a "customerid" elsőre jobban tetszik. Az _id ugyanis nem kell, hogy a fenti szám legyen. Lehet szöveg, szám, akármi. Értelmesnek tűnik saját ID-t csinálni.
Emellett persze az _id az a dolog, ami mindig indexelve van, nem is kell kérni és nem is lehet kikapcsolni.
Indexek: meg tudom erősíteni, hogy amit nem indexelsz, arra a lekérdezés egészen lassú lesz. Ezt gondolom gondoltad :) Az indexek viszont rendesen meglendítik a memóriahasználatot, szóval okosan azzal az indexel.
Még egy trükk, amiért lehet hogy máglyára küldenétek. Olyanra is volt szükségem, hogy egy dátumokhoz számértékeket rendeljek. Eleinte így csináltam:
[{k: Date(), v: 1}, {k: Date(), v: 3}, {k: Date(), v: 4}]
Ez kicsit terjengős dolog, úgyhogy azt találtam ki, hogy a dátumot szöveggé alakítom, mégpedig egy nagyon tömör szöveggé (amire összeütöttem egy 75 vagy 76 digitből álló számrendszert, az még könnyen olvasható) és az így adott dátumokhoz simán csak a számot rendelem. Ilyen lett:
[{"8V3": 1}, {"8V4": 3}, {"8V5": 4}]
Ennél én sajnos nem tudok tovább egyszerűsíteni, de ha egy dátum csak egyszer fordulhat elő, akkor csinálhatnám így is:
{"8V3": 1, "8V4": 3, "8V5": 4}
Ez ocsmány trükknek tűnhet, de nagyon sokat segített az adatbázis méretének redukálásában. Illetve vehetek nagyobb gépet is persze. Vagy kérhetek karácsonyra.
DAO kérdések
No utolsó beteg design patternem következik így vasárnap este...
Relációs adatbázisoknál a resultset-eket tipikusan egy listává alakították át a DAO-k, ehhez az egész resultsetet elösször végigolvasták és objektumokká formálták. Na ez nagy adathalmazokhoz soha nem volt jó ötlet, de olyan ritkán kellett ilyesmit csinálni. És most mintha mást se kellene.
Szóval én meg akartam tartani a listát mert olyan egyszerűen lehet vele bánni, viszont eszem ágában sem volta teljes eredményhalmazt berángatni a memóriába. Szóval a megoldás egy olyan lista lett, ami Closable is. Így viszont a DAO metódosukat hívó kódnak be kell zárnia a listát. Ez a része szokatlan és kicsit bizonytalan vagyok a kérdésben. A problémát azért megoldotta.
Kotlin nyelven azért egészen egyszerű a dolog a (szerényen dokumentált) use funkció segítségével.
dao.getBlaList().use { it.each{ ... } }
Ezt nyugodtan fikázzátok le, nem garantálom hogy átírom de garntáltan érdekel a véleményetek! No ennyi mára, boldog hétfőt!
Tartozom még egy beszámolóval a linux konferenciáról, nem éppen java de volt java is.
