On Mon, 2005-12-19 at 00:08 +0100, Henrik Stoerner wrote:
On Sun, Dec 18, 2005 at 10:28:17AM -0500, Scott Walters wrote:
Ahhh the BB/Hobbit, "How about a DB backend question ;)"
I've always been amazed that BB and Hobbit could use a filesystem as
a database and not kill a server much *sooner*. hobbits use of
memory for bbvar/logs is a huge win . . . .Ideally the backend for most, if not all, of the state/history
information for events would be a database. Problem is, that
introduces a dependency of the product (hobbit) an another tool
(Database). This can very easily become a nightmare from a support/ integration point of view. Not to mention you raise the bar for
entry level admins ability to 'tinker' with the product.Unless the entire hobbit tool were re-architected to have DB back- end, I don't think it would be worth the overall effort for keeping
the histlogs area small.That in itself would not gain you much, I agree. There has to be some other benefit besides the space-win to justify moving to a DB backend. E.g. if there were some fancy backend pulling data from Hobbit which could benefit from having the Hobbit data in a DB.
Well, the other option is to simply use a filesystem that doesn't incur a penalty for having large numbers of files in a directory, or on the filesystem. My favourite is of course ReiserFS, where multiple files can share the same block (no space wastage from allocating whole blocks to a single file), as well as no limited inodes for the filesystem etc...
On the other hand, for the interested individual, I've been told that there is some way to basically embed mysql into a product, thereby allowing you to 'contain' the entire system, rather than relying on the administrator to configure mysql/etc properly. In fact, this might be helpful initially, and for the larger sites, then they would simply reconfig hobbit to point to a external mysql server that they can customise themselves.
Regards, Adam