
www.Usenet.com
| <-- __Chronological__ --> | <-- __Thread__ --> |
Martha Stewart called it a Good Thing when "Marshall Spight" <[EMAIL PROTECTED]> wrote:
> "Paul" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>>
>> 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('@'),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.
| <-- __Chronological__ --> | <-- __Thread__ --> |