[MUD-Dev] TECH: AmigaMud DB questions

[Bruce]

Chris Gray wrote:

> Sure. No response on my offer yet, and I don't seriously expect
> one. My code is all pretty vanilla stuff. My main drives have been
> efficiency (having crammed things onto 56K 1MHz CP/M boxes helps
> with that) and generality. Ask away! There is a fair amount
> discussed in the documentation on the web pages, too. And, in the
> mud-dev archives from the early days.

Is your description of your DB in:

  http://www.kanga.nu/archives/MUD-Dev-L/1998Q2/msg00018.php

still accurate?  How has that worked out for you?

The DB is something that I've been experimenting with a lot lately
inside of Cold.  One of the first things to go was the use of DBM for
maintaining the index because it simply didn't scale.  I'm still not
entirely thrilled with Berkeley DB, which I used to replace it and
will probably end up moving over to something simple and similar to
what you described.  Relying on other libs where speed is critical
hasn't worked well for us.

Do you still maintain refcounts for objects external to them in a
mapping?  Does the user have to write code that correctly manages the
refcounts on objects, or is that handled as part of the scripting
language?

Does your LRU cache have multiple buckets or just a single linked
list? (I'd like to understand what DGD does here at some point as
well.) Do you really flush the whole cache to disk when you have no
empty cache slots available? (If so, why the whole cache?)

How do you handle backups?  I'm not entirely happy with the amount of
time they take in Cold ... although, I think that with some tuning,
they could definitely perform better than they do now by copying more
blocks at once (Cold's DB has a minimal block size, defaulting to 256
bytes). The asynch part of our backup is pretty nice though, although
it had a data-corrupting bug in it that was hard enough to tickle that
it wasn't noticed for about 4-5 years.  Of course, it only corrupted
the backup DB, not the running one. It'd also be nice to have a way to
provide transactional capability .. but that's not happening within
Cold anytime soon.  Transactional stuff is the only reason that I'm
jealous of DGD. :)

Another interesting topic is the conversion of your in-memory objects
to the buffer that you store on disk .. that's kinda slow in Cold at
the moment, but I'm too tired to ask questions about that yet. :)

Are there good open source/free software lightweight OODBs around,
preferably with a C API?  I've not seen one and I keep getting tempted
to rip that layer out of Cold and package it up separately as a
lib. It'd be nice if any suggestions were actively developed as
well. :)

  - Bruce

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev