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.
