> The writer application must be failsafe, as much as possible (acoustic > emission recording devices); I simply can not afford that a reader makes a > select and because of a programming error the acquisition be blocked. I had > this just by opening sqliteman. > > The recording rate is variable; using a test structure (~14 fields in 1 > table, all integers 32/64bit) I was able to achieve ~90000 records /sec > with > sqlite API, which was not really good enough (there are is no jurnal; I > don't need any rollback / consistency check). >
If you still prefer sqlite for some reasons, how about three-parts approach. You have raw data writer working with the speed of I/O system and making segmented output in very simple format, lazy writer that consumes non-active (passed) segments writing them to the sqlite base, and general reader doing necessary reads. In this case reader and write don't have strict requirements about locking (at least the reader can be more important in this case). You can tune their relationship in a way when raw writer and sqlite writer are usually synchronized, but if the reader is more active there are temporary more non-consumed segments than before. Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
