Hi, Without knowing the details of sqlite implementation on indexing, I would imagine if you do some benchmarking runs, and collect systrace like log, and see if # of writes and reads are exceeding you requirement.
Regards, - Kun On Sun, May 4, 2008 at 11:59 PM, John Passaniti <[EMAIL PROTECTED]> wrote: > I am trying to decide if sqlite is appropriate for my system. > > The target is an embedded system. It's an ARM9 processor running > under Linux 2.6. The system's primary storage is NAND flash, using > jffs2. The system is essentially a datalogger, where at regular > intervals (typically once per minute) sensor data is written. The > table schema would be very simple-- each row would have a timestamp, > and one column for each sensor. The table would be indexed on the > timestamp. Also, as time marches forward, old data (more than a year) > will be periodically deleted. > > My concern is this: I gather sqlite keeps data in an indexed tree > structure. As I write new rows to the table, I would imagine the data > has the potential to move around in the tree. That is, as I add > entries, the tree will rebalance, possibly shuffling data around. > > I guess my question is in the situation I just described, how often > will data be shuffled around? I'm not looking for some absolute > number here, but rather a sense of if a sqlite database on a jffs2 > filesystem would be spending a lot of time rebalancing trees and thus, > wearing out the flash faster. Or if such is just inherent with > sqlite, are there programming pointers people can provide that would > minimize this? > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users