> Someone else has been working on a MySQL backend but I can't recall his
> name at the moment. I'm not sure how he intended to work around the
> variable-length field problem unless he's using BLOBs or some VARSTRING
> extension.
That's me. I've been struggling with more pressing issues for a few
months, and so it hasn't gotten very far. I'd be delighted to collaborate
with someone on it though. Or even help someone get up to speed if they
want to take ownership.
Actually, I have two ideas. The simple one is basically just two fields,
one varchar for the keys and one blob for the data. That should be
adequate for an initial implementation, and for the most part it would work
just fine. It would perform poorly for searches on non-key fields.
The other is more complex and would scale better, and should have
reasonable performance for searches on other fields than the key. It's
essentially an implementation of associative arrays using four tables. It
would also rely on using mysql's regex functions instead of perl's.
My big reason for wanting to do it in the first place was to avoid locking
issues. Locking in mj1 is horrible. Avoidance of locking issues,
especially if also addressed in the mj2 daemon's queueing would let mj2
scale to multiple machines.
Using berkeley db is essentially the same as idea one. It should be
sufficient in all but the most demanding applications.
Brian
Follow-Ups:
References:
|
|
