[geeks] SQL Performance

[Jonathan C. Patschke]

On Tue, 22 Jul 2008, James Fogg wrote:

>>> If you need direct access to a RDBMS via the network on an embedded
>>> platform, you have Other Problems.
>>
>> Why?
>>
>> I've worked on a couple and have seen a lot use remote services of
>> various kinds, databases included.
>
> Same here, I work with an application that is a huge DB client (50G
> database, up to 150 TPS).

Network access to an RDBMS is inherently about as far from a real-time
facility as you can get.  If you're designing something that requires a
real-time OS, building in such a requirement can very quickly make things
a gigantic mess.  Also, my limited understanding of the DB2 and Oracle
protocols reveals them to not be neither very lean nor predictably
bounded, in terms of processing or memory requirements.

It just all seems to be a very nasty fit for the sorts of things one would
want to do with VxWorks or QNX.

At least, that's just been my experience so far with implementing a system
that uses an RDBMS (over the network) to gate/support semiconductor
testing without increasing verification latency.  To keep performance
acceptably regular, I've had to implement a high-performance write-back
cache closer to the IC tester that presents a subset of the data as a
hash.  This isn't even a hard real-time system, and the latency very
quickly adds up.  Granted, this is also a much larger database (> 300GB,
constant access from multiple clients beating it up).

If you're designing a hard real-time system (ie: you actually -need- an
operating system like QNX or VxWorks, and aren't just trying to show off
how obtuse you can be), that lack of predictability might, quite
literally, be destructive.

-- 
Jonathan Patschke | "There is more to life than increasing its speed."
Elgin, TX         |                                   --Mahatma Gandhi
USA               |