On 28 Oct 2018, at 2:06pm, Gerlando Falauto <gerlando.fala...@gmail.com> wrote:
> There are two (apparently) opposing requirements: > - in case of a power outage, all data collected up to at most N seconds > prior to the power failure should be readable. Ideally N=0, but what's > important is that the database never gets corrupted. Unless you really know what you're doing, leave SQLite settings and PRAGMAs at their defaults. This gives you the safest, least corruptable, settings. WAL mode is fine. > - the SSD's wear due to continuous writes should be reduced to a minimum I assume your App generates items for the log one by one. There's not much you can do to reduce wear if you want each one logged as soon as possible. In terms of deleting rows, if you want the least wear on your SSD, do the deletes seldomly. Definitely no more than once a day. > There's just too many layers which will affect the end result: Correct. And remember that pretty much every hardware driver lies to the OS to make the hardware seem faster. > For instance, one crazy idea might be to put the WAL file on a ramdisk I understand why you're raise that but, as you suspect, it's not going to help. > I found the "Total_Erase_Count" reported by smartmontools to be an > interesting end-to-end metric in the long run If you care about that level of detail, using SQLite is the wrong approach. You should be logging by appending each entry to a text file. Or maybe to a new textfile every day/week/month. Then, to prune the log just delete one old textfile each time you start a new one. Convert a text file to a database only if you want to query the log, which is presumably a rare operation because you're such a good programmer/admin that stuff rarely goes wrong. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
