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

Reply via email to