Re: [help] main memory db

Martha Stewart called it a Good Thing when "Marshall Spight" <mspight_at_dnai.com> wrote:
> "Paul" <paul_at_not.a.chance.ie> wrote in message news:MPG.1a355f9b53cbbe9f989816_at_news1.eircom.net...
>>
>> I think that in memory dbs will start to become very common in the near
>> future.
>
> I think we'll start to hear a lot more hype about in-memory
> databases, yes. I'm not sure it'll be anything other than
> hype, though. To the best of my knowledge, many existing
> DBMS products use main memory just fine. It's just a question of
> tuning the parameters.
>
> I don't see how failing if your database exceeds main memory
> size is a particular virtue.

Well, there's the _possibility_ (I haven't seen good papers on it, so I rank it only as "possible") that there would be substantially different algorithms that you would use if you know you'll never be hitting disk.

<http://kdb.snu.ac.kr/~tsangbi/papers/TTree86.html>

If the behaviour of T-trees leads to data being accessed in substantially different ways than happens when walking a B-tree cache, then there may be _specific_ merit to "in-memory" as distinct from hooking up lots of cache to a more traditional RDBMS.

The claim of in-memory DBMS vendors is that it _is_ faster to have it all managed in memory than to have buffer caches in the way.

• The paper points to the costs of managing cache, that seem legitimate.
• But perhaps clever RDBMS implementors can, albeit at the cost of some complexity, improve how well they manage cache.

  [There's a significant ongoing effort in that regard right now    with PostgreSQL; improved buffer management code is being    actively worked on...]

I can't tell how much of it is reality, and how much is hype. I daresay I _refuse_ to believe what in-memory vendors tell me, because I know it is in their interests to twist things to look favorable for their position. I don't know of 'objective' work on the matter.

-- 
wm(X,Y):-write(X),write('_at_'),write(Y). wm('cbbrowne','ntlug.org').
http://www.ntlug.org/~cbbrowne/wp.html
As of next Tuesday NCOMPLR will no longer open-code arithmetic statements.
Please update your programs.