On 3/17/2012 12:36 PM, Sven Hartge wrote:
Storing mails inside SQL? Not supported by dovecot and not very wise, IMHO. DBmail does this, but to be honest, I never heard any good feedback from admins using that product. From what I have been told, you need quite the beefy server to get a decent performance out of DBmail, compared to the needs of a "traditional" setup like with dovecot or courier-mail, but I digress.
Ugh, I've tried the product. It works pretty well, until you move more than a small handful of users and email hives to it, and you hit some hard walls pretty fast with how many inbound emails/second it can handle for even burly server configurations.
Those hard walls occur at too low a threshold for me. The product's mailing list is supportive and there are many dedicated DBMail users who step in an answer questions, but be prepared for "BUY MORE RAM" as the answer to concerns about performance. When 128GB of RAM is needed for a small organisation's email setup to perform well, I am strongly inclined to move on to the next product.
Best practices for it seem to revolve around being able to have your ENTIRE email + index content resident in RAM. Well, gosh. Why didn't I think of that before instead of wasting all of this time worrying about design and efficiency?
And if you're hoping that it will make text searches "automagically" fast, think again.
Timo's FTS_SQUAT blows it out of the water by orders of magnitude, even with mailbox sizes of around 300K emails (20GB), let alone something like Lucene or Solr.
I understand why it seems like a great idea to store email this way, but realise that the bulk of email is NOT structured or inherently relational.
=R=