Jeste me napadlo: pokud bych chtel pouzivat pevnou delku zaznamu, to bych klidne mohl pouzivat staticky soubor a lseek(). Co takhle udelat test s velmi ruznymi delkami zaznamu (klice i hodnoty) - predstavuju si treba neco jako 90% do 1 KB, 9% do 100KB, 1% do 10MB. DB pouzivam prave proto, ze se o takoveto veci nemusim starat a klidne muzu do databaze ulozit image CDcka vedle stovek nekolikabajtovych informaci.
Nevim, co autor chysta pod heslem "prace s posk. soubory", ale pokud by se snad na zaklade clanku nekdy nekdo chtel rozhodovat, kterou db pro svuj projekt pouzije, doporucil bych doplnit tabulku jakou transakcni semantiku ten ktery engine poskytuje, a napr. jak se vyporada s KILL -9 behem dlouhe transakce, protoze dobre chovani v techto ohledech bude seriozni/vetsi projekt vyzadovat. Mozna se pak ukaze, ze pouzit ten (zdanlive) nejrychlejsi by nebyla ta spravna volba...
Nevim co ocekavate ohledne chovani pri kill -9 a soucasne mluvite o "velkych" aplikacich. Myslim ze totalni ztrata dat je spravedlivym trestem za takovouto hloupost.
Je to stejne jako kdybyste od maleho fiatka chteli aby tahnul nakladni vlak a pozadoval bezpecnost pro pasazery kdyz projedete zdi.
Mne to nepripada zbytecne testovani, ono ve chvili kdy treba aplikace pracujici s databazi dostane v druhem threadu treba SIGSEGV a nema ho osetren, tak je efekt vpodstate stejny jako kill -9.
Obdobna situace muze treba nastat, pokud se odrizne databaze od souboru (soubor je na AFS/NFS a spadlo spojeni, byl na vymennem mediu...)
Je jesny, ze prijdu o nejaky data (minimalne ty nezapsany), otazkou ale je, jestli z toho souboru pak pujdou precist aspon ty stara data, nebo jestli bude vice ci mene znicen.
I kdyz je to tak trochu test o nahode, ono to pujde blbe nacasovat kdy presne se ma ten kill pustit aby to byly rovny podminky .... treba muzu mit 50x stesti a po 51. se trefit nekam, kde si databazi znicim.
A i male auto by melo dbat na bezpecnost cestujicich pri narazu (je jasny, ze celni naraz do zdi ve 200 km/h neprezije asi nikdo, ale u 50 km/h uz by mohlo byt nejake srovnani vypovidajici ... proto se asi delaj crash testy s figurinama :o)
Jo, taky bych se zkusil pidit po tom, proc je BerkeleyDB 4 tak pomala - treba je to proto, ze poctive dela f[data]sync() tam kde ma. Mereni by mohlo zahrnovat pocet diskovych operaci, spotrebovany strojovy cas (nejen realny, ale i user+system), a samozrejme tolerantnost k vypadku. Delal bych to treba tak, ze bych vytvoril DB s nejakou minimalni mnozinou dat, a pak bych tam ukladal a rusil nejake "overitelne" klice s "overitelnymi" hodnotami (treba posledni bajt by byl kontrolni soucet). No a takovemu to procesu bych nahodne zasilal SIGKILL a pak bych se dival, jestli v DB jeste porad je tam "minimalni mnozina dat" a jestli vse ostatni (klice i hodnoty) ma spravny kontrolni soucet. No a tohle vsechno bych poustel v cyklu treba 24 hodin.
Ne, je to o stesti, me se widle sesypou v prumeru za pul hodiny prace a je jedno co v nich delam a ve kterych (3, 3.1x, 9x, NT, 2k, XP, 2003). Mam na ne proste smulu, stejne jako znam cloveka, ktery bez znalosti root hesla sunda linux do 12 hodin kancelarskym pouzivanim. Informatika neni exaktni veda.