I am an embedded guy, not really a database guy. I have been requested to redesign a current system that has bottlenecks in a number of places.
The embedded set up is based on a leg 9 processor running at 220mHz.
There must be a database of 50k records (may increase to 250k) each with 1k of information (max 8 filed). That's approximate - I'm able to try to obtain more precise figures if required.
They're presently using SqlLite 2 and likely to proceed to SqlLite 3.
Without beginning a flame war - I'm a complete d/b newbie just seeking advice - would be that the "best" decision? I recognize that this can be a "how lengthy is a bit of string?" question, but any pointers woudl be greatly welcomed. I do not mind doing lots of reading through &lifier research, but simply wished you could get me off and away to a flying start. Thanks.
p.s Again, an overall total rewrite, may not even stay with embedded Linux, but change to eCos, don't be concerned an excessive amount of about once conversion between d/b formats. Oh, and accesses ought to be infrequent, for the most part one every couple of seconds.
edit: ok, it appears they've 30k records (may achieve 100k or even more) of just five to six fields each, but a minimum of 3 of these could be a search key for any record. They're toying with "getting no d/b whatsoever, because the data are extremely simple", however it appears in my experience by using multiple secrets, we could not use fancy things like a quicksort() type search (recursive, binary search). Any ideas on "no d/b", just data-structures?
Btw, one secret is 800k - unsure how good SqlLite handles that (maybe with "no d/b" I must hash that 800k to something more compact?)
I'd stay with SQLite, it's broadly supported and pretty wealthy in features.
Also SQLite may be the Database selected by almost all mobile os's. Android, Apple iphone OS and Symbian ship with SQLite making me believe that manpower was spent to optimize it for that processor in individuals phones (usually ARM).
Firebird (formerly Interbase) claims to be effective embedded.
HypersonicQL (HQL) is small , fast as well as states be appropriate for embedded use.
Alas, I've no personal expertise to support either claim.
SQLite is most likely quite a safe wager. However, if performance is actually essential for the application and you don't need a relational database, I recommend you have a look at Berkeley DB link text . Berkeley DB isn't a relational database though. Quite simply, in case your information is arranged in various tables and also you constantly have to query result sets that need relevant data from several table, you most likely require a relational database. Berkeley DB is much better suited to something similar to lookup tables (i.e., the information is organized inside a couple of tables and you don't have to query data from several of these to be able to make the result sets you would like). Berkeley DB becomes manifest pretty quickly but it may need more focus on your finish to be able to get the most from it.
I'll suggest sqlite3 too. It's used by lots of famous application.
i'm not acquainted with embed system, but apple iphone use arm9, and sqlite as DB
The 01-11-10 Embedded.com E-newsletter does a pleasant job of covering this subject. The e-newsletter are available at Embedded.com.
if you would like an alternate, then berkeleydb may be worth searching at. it was once possessed by sleepycat software, but has become offered by oracle. it is a barebones database engine is directly prrr-rrrglable (as opposed to a sql) frontend. it's included in the core engine in lots of major databases, and because the database in lots of embedded products - it was once particularly popular for controlling routing tables in hubs. it has a tendency to get overlooked nowadays for additional fashionable configurations, but i have found it decent, solid but for the amounts you're speaking about it may be lightning fast.