2016-02-25 9:05 GMT+02:00 Florin Popovici <[email protected]>: > 2016-02-25 7:24 GMT+02:00 Mihai Badici <[email protected]>: > [...] > >> Mysql introduce un overhead pentru ca >> "externalizezi" toate aceste procese de coordonare, nu le elimini. Sau >> gresesc? > > Ma mir ca n-a zis nimeni de sqlite. A fost creat tocmai pentru cazul asta, > cand overheadul mysql-ului este, uh, overkill, dar nu vrei sa-ti crosetezi > arbitrajul lucrului direct cu fisiere. > > Chiar daca ai un singur "producator" si un singur "consumator", daca tii > totul intr-un singur fisier "chior" (in care citesti/scrii direct), poti sa > dai in edge-case-ul de acces simultan nearbitrat. Poate consumatorul se > nimereste sa citeasca fix in milisecunda in care producatorul a inceput sa > scrie, si n-a apucat sa termine sau sa faca flush la buffers. In cazul > asta, consumatorul o sa vada un fisier trunchiat (0 bytes or more). > > Si eu m-am lovit de cazul asta: o interfata web in care teoretic lucra o > singura persoana (deci "single-threaded"), care scrie niste date undeva, si > niste cronuri care citesc datele alea. Dupa cateva luni, s-a intamplat ca > persoana a dat "save" fix cand rula un cron, care a avut "placerea" sa > citeasca din fisier niste gunoaie splendide. > Am trecut atunci la sqlite, si de 6 ani n-am mai avut data corruption.
Ajută mult, dar de ținut în minte că nu rezolvă toate cazurile-limită: https://www.sqlite.org/howtocorrupt.html
signature.asc
Description: OpenPGP digital signature
_______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
