Q: Embedded Database Recommendations?

...but you do not mention what these requirements are so how can be offer advice?

-- Regards, Richard.

• formatting link
  &
  formatting link

17 official architecture ports, more than 6000 downloads per month.

• formatting link
  Certified by TÜV as meeting the requirements for safety related systems.

"Peter K." schreef in bericht news: snipped-for-privacy@remove.ieee.org...

MySQL is not an embedded database IMHO, way too big. The licensing is also very commercial since you're only really entitled to use it if for free you are an open-source programmer.

I'm using SQLite in many projects and the performance is excellent and the memory footprint very, very small (several KBytes). There's also an in-memory version of the database in development (or maybe already available).

** Posted from **

If an 'in memory' database is satisfactory, take a look at my GPLd hashlib. It is written in pure standard C, so extremely portable. I own it, so arrangements can be made if the GPL requirement to release your code is a problem. See:

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

Repeated from my original post:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ciao,

Peter K.

--
"And he sees the vision splendid 
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."

Dale, thanks for the comments!

-- "And he sees the vision splendid of the sunlit plains extended And at night the wondrous glory of the everlasting stars."

Well the SELECT speed and memory footprint of mySQL are both superb.

[caveat - you need a 2GHz Pentium and 1GByte of RAM]

--
Regards,
Richard.

+ http://www.FreeRTOS.org & http://www.FreeRTOS.org/shop
17 official architecture ports, more than 6000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.

Thanks, Chuck, I'll take a look.

Ciao,

Peter K.

--
"And he sees the vision splendid 
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."

Hmm my working gateway email server uses mySQL, originally on a sub GHz processor and 256MB of RAM, Got upgraded to a newer nano-ATX board

1GHz and 1GB RAM. System runs Apache and email server and several other apps, some of them using the half dozen databases.

However the system is so lightly loaded, the real question on SELECT speeds and memory footprint depends on

Size and complexity of database Number of concurrent users (access to database) Number of SELECT requests per min/per hour... What forms of caching are being used etc....

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

Thanks, all good information.

The database will be large (e.g. tables of 1,000,000 or more entries), but not particularly complex.

There weill only be one application accessing the database at a time (or at all).

Assuming only one (concurrent) connection, I wonder why the number of select requests per time period is a factor (it clearly will be for multiple connections).

I suppose what I'm looking for is how long it takes to do:

SELECT * FROM SomeTable WHERE SomeField = 'SomeValue'

and SomeField is the primary key. By "how long" I mean mean, standard deviation, and [if possible] worst case times.

Ciao,

Peter K.

--
"And he sees the vision splendid 
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."

This is an embedded newsgroup. How can 1Gbyte of RAM be considered "superb"?

The caveat doesn't seem like much of an endorsement. It seems more a statement that a brick can be made to fly if enough brute force is applied.

This will determine how much data is moving around, so determines how fast a storage unit (and interface), how much needs to be buffered in memory, to keep up. Could the serving be better served by being done from a RAM copy. Can the processor/OS/database software keep up with the expected number of requests. Are the vast majority of database operations ONLY Read, and the database updated once a day/hour/week/etc...

What sort of response time is a MUST have, would be nice, or would be great! In other words how fast *must* the data be returned.

If you only make 1 request a second, there are a hell of a lot of solutions, whereby cost of processor/RAM and size become more of the issue in determining what software to use.

If you make 10,000 requests a second, you better have a really fast processor with lots of RAM, possibly with RAM copy (or RAMdisk) for the database in live use. Here the software becomes more of an issue that determines the host hardware/software.

So simple requests, but what is the dataset size? Number of fields in a record? Fixed or variable length length fields in the records?

To read a 10 byte or 10MB record? (yes some people have fields in the SAME database that is a large picture or other document!)

Standard deviation on a system doing NOTHING else?

What type of system are you using to benchmark this on?

The other important issue is

What else is running How much processor time available How much storage access time available? (i.e. does this application have near total allocation of storage unit or is somebody streaming video to/from the storage unit at the same time!)

There is NO simple answer to questions like this.

Consider this analogy

Take a deck of cards

Shuffle the deck (our database)

Now consider these requests Find the 15th card down - very fast and easy to find

Find a heart of any size - slower but easy.

Find All the Three's - More complicated

Find the 5 of hearts - more complicated

A lot depends on how your data is organised and normalised and many other issues, you have not given the details on.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

It was pure sarcasm (its a British thing) and not meant to be taken literally or in any way as fact. The OP had a 'requirement' for an embedded database, but without giving any clue what that requirement was wants advice about memory footprint. I don't know if it is to run on an 8bit device or a dual core Pentium - hence the sarcasm.

--
Regards,
Richard.

+ http://www.FreeRTOS.org & http://www.FreeRTOS.org/shop
17 official architecture ports, more than 6000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.

Paul, thanks for the pointers. I realize it's a "how long is a piece of string?" type question. Yours (and other) responses have been interesting.

Ciao,

Peter K.

--
"And he sees the vision splendid 
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."

Richard,

It came across to me that you hadn't read the question. Your 'sarcasm' comes across as something quite else.

Thankfully there have been more useful, and thoughtful, responses from others.

Ciao,

Peter K.

--
"And he sees the vision splendid 
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."

Apart from RAM data bases, on a virtual memory machine, the most primitive data base would be just mapping the tables into virtual memory and let the OS do the data loading with page faults as well as the caching of frequently used data.

If you are only interested in accessing through the primary (and even secondary keys) any COBOL style ISAM (Indexed Sequential Access Method) file system should do. With current amount of memory and only a very small (one million) amount of records, the whole key tree could be in memory, so the SELECT time is not an issue. Retrieving the actual data from disk will of course cost some extra. Unfortunately, none of the popular (Windows and Unix variants) operating systems support ISAMs at the OS level, so some drivers are required.

Paul

Paul, thanks for the good comments!

Ciao,

Peter K.

-- "And he sees the vision splendid of the sunlit plains extended And at night the wondrous glory of the everlasting stars."

Datadraw looks interesting.

--

John Devereux

fer

^^^^

^^^^

You need nothing like that. A recent poster on c.d.mysql is approaching a 45MB memory footprint after basic tuning achieved a footprint of 80MB. Certainly it will run just fine on a 486/66 with

256MB or less. But I am speaking about modern versions of the full networked server; the embedded version or 3.23.x are probably less demanding. .

That it does! Thanks, John.

Ciao,

Peter K.

-- "And he sees the vision splendid of the sunlit plains extended And at night the wondrous glory of the everlasting stars."