A kozponti DB-t is vissza kell vegul valahogy mindig irni diskre (mikozben masok hasznalgatjak). Es teny, hogy amugy sokkal kisebb, mint egy atlagos szerver oldali rdbms, kevesebb process is hasznalja, de meggyozodesem, hogy messze nem is annyira optimalis. 100x ekkora rdbms-t ledumpolok annyi ido alatt, amennyi ido alatt a resitry-ben megtalalok egy erteket szekvencialisan olvasva. Oke, hogy "nem erre van optimalizalva", de az a parszaz mega nem annyira big data, hogy ennyire ne menjen ez nekik. Szoval ez a tipikus "not by this margin" esete.
Mellesleg operacios rendszer feature-rol beszelunk. Ezek azok a feature-ok, amiket olyan surun hasznalunk, hogy inkabb megirjuk C-ben, meg ha eleve tovabb is tart, meg 10x annyit is kell figyelni arra, hogy pl. biztonsagos maradjon, mindezt egy minimalis sebessegnovekedesert. Ennel a feature-nel mondod azt, hogy "tok normalis, hogy kivarjuk mig 4 olvasas es ket iras befejzodik mielott mi odairhatnank". Az rdbms-hez valo csatlakozasod szerver oldalon az meg mar egy erosen user space valami, ott mar nem az oprendszered sokmilliard usere erez lassulast amiatt, hogy nem lett optimalis egy update query-d. De valahogy megis ez utobbi bizonyul lenyegesen gyorsabbnak. Mindemellett nem veletlen szokas az is, hogy az rdbms-nek van egy kulon dedikalt eroforraskeszlete (alapesetben hardvere). Mert ami ezt a lockolgatos irogatast szamolgatja, az ne szamoljon mast. Mert hat ahogy irtad: megoldott. De ennek a megoldasnak azert ara van a hardver kihasznaltsagaban.