>>>>> "SJS" == Steven J Sobol <sjsobol@nstc.com> writes:
SJS> I have checked and have not seen much of anything about serving
SJS> Majordomo mailing lists using database tables instead of flat
SJS> files.
Well, Majordomo2 already has everything in "databases", but they're just
key/data pairs implemented in flat text files. There has been quite some
discussion about moving to something better, and I am about 1/4 done with
my BerkeleyBD-based implementation. A relational database backend will be
more difficult because:
1) We only ever have one indexed column (well, it doesn't make it harder,
only less useful).
2) You _cannot_ use fixed-length fields. (We take lists and join them
together and stuff them in the database. Their size may not be
reasonably limited.)
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.
SJS> It seems to me that placing a Majordomo list in a database
SJS> table may make some administrative tasks easier, but there are
SJS> probably going to be performance issues too.
I don't see how it would change administrative tasks in the slightest,
since you still need to do everything from the blessed Majordomo interfaces
(either email, command line, or through the library) and it's been trivial
to write code that uses the library interface for some time now. (I've
done it in more than one instance and there are examples in the
distribution. I doubt anyone else has played with it, though.)
There are quite a few performance gains to be had, going from my
preliminary data. These come from two things:
Incidental database access - databases are used for things like holding all
message-ID's seen and such. My test lists show significant time going
over the flat-file versions of these.
Membership checking/data retrieval - often times we need to get the data
for a single list member (or to just check that they're one a list).
Caching is done internally on an address, but the initial lookup is not
really quick. Since we do it once per address appearing in the To: and
CC: headers when sending a list message, this gets important and
databases can help.
In addition, BerkeleyBD can iterate over the database in a sorted order
(with the B+Tree backend). This lets us do domain-clustering for free
(i.e. without an additional sort step) which can help some MTAs deliver
faster.
Of course, I'm talking about Majordomo2 here. I know some have given some
thought to doing this with Majordomo1 but I haven't.
- J<
Follow-Ups:
References:
|
|
