Augusztus 9-én három éves lesz a Miner. Erre a dátumra jelentős szolgáltatásbeli bővülést, és technikai megújulást tűztünk ki célul. Három év alatt immáron 40 GB-osra nőtt a rendszer adatbázisa, 15 millió blogbejegyzéssel, hasonló nagyságrendű videó mennyiséggel őrizzük az elmúlt három év történéseit. Ez az adatmennyiség számos üzemeltetési, fejlesztési problémát is felvetett, ezeket szeretnénk most orvosolni a tudomány és technika újdonságait segítségül hívva. Ebben a bejegyzésben most pár problémáról írok, legközelebb pedig remélhetőleg már arról, hogy hogyan sikerült megoldani ezeket.

Egyik gond a MySQL adatbázis backupja, melyet megoldottunk ugyan egy slave adatbázis beállításával, a napi backup alatt a replikáció leállításával, rsync-kel történő backupolásával, de rengeteg erőforrást emészt fel így is a történet. A régi blogbejegyzéseket persze törölhetnénk, rengeteg helyet felszabadítva, hiszen ki kiváncsi vajon egy két évvel ezelőtt született blogbejegyzésre, de szeretnénk a Miner ezen lehetőségét megtartani. Másik lehetőség az lenne, hogy szétdaraboljuk az adatbázist, és a régebbi tartalmakat csak olvasható formában tároljuk, ezzel az a gond, hogy akár igen régi bejegyzésekhez is hozzá kell nyúlnunk néha, mert a szerző kéri, hogy blogját töröljük adatbázisunkból (ilyen igen ritkán van, de nem mondhatjuk hogy nem tudjuk megoldani). Az irány valószínűleg valamilyen elosztott adatbázisba mentés lesz, mely nem csak a tárolást, hanem egyben a backupot is biztosítani tudja.

Másik gond a lekérdezések sebessége. Itt például a mellékletek friss bejegyzéseiről van szó, itt a gyors megjelenítés a követelmény. A probléma itt abból adódik, hogy egyes mellékleteknél (mint például a film) vannak olyan blogok (pl. sorozatjunkie, comment.com), melyekben nagyon-nagyon sok bejegyzés van. Ilyenkor egy olyan SQL lekérdezés, mely dátum szerint rendez, és több tucat kategóriára szűr, elég sokáig tarthat. Ugyanitt probléma a megfelelő képek, videók kiszűrése is a tartalomból. Már korábban továbbléptünk egy külön indexelésre, illetve keresőszerverünk bevetésére (mely meglepő módon gyorsabb tud lenni, mint a MySQL), további lépés várhatóan az lesz, hogy az egészet felturbózzuk az egy-az-egyben a memóriába pakolással.

Végül, de nem utolsó sorban a robotok működését sem mondanám a legkiforrottabbnak, bár az utóbbi években bizonyított ez a felállás, a további skálázhatóság, és a jobb áttekinthetőség érdekében tovább kell lépnünk. Jelenleg pár PHP-ben írt robot fut párhuzamosan, lekérdezve a MySQL adatbázisból hogy mely blogok RSS-ének letöltése következik, s párhuzamosan elindítanak 100 kérést, az eredményt pedig memóriába pakolják. További robotok a memóriából felolvassák az RSS tartalmát, megnézik van-e új blogbejegyzés, módosult-e már régi, s ha igen, akkor letárolják azokat, s gondoskodnak a mellékletekbe történő “címkézésről” is. Ezt a felállást a MySQL lehetőség szerinti teljes kiiktatásával, s erre kitalált jobszerverek, queue-k összerakásával szeretnénk kiváltani, mely azt is kényelmesen lehetővé teszi, hogy a hamarosan beállítandó új szerverekre osszuk szét a jelenlegi terhelést (az indexelés jelenleg a legerőforrásigényesebb feladatunk).

Persze ez csak az előttünk álló technikai változtatások egy (a jelentősebb) része, s az új szolgáltatásokról még nem is ejtettem szót. A megoldásokról igyekszem majd részletes blogbejegyzésben, blogbejegyzésekben, továbbá ha lehetőségem adódik rá, akkor egy newtech meetup keretében is beszámolni.