Re: [Dbmail] Query on Database Stability in DB Mail

[Chris Nolan]

Microsoft's highend SMTP product uses MSSQL? What's the name of the product?
When you say "Novell's highend system" are you talking about Groupwise? 
If so, you might find it uses PervasiveSQL. Novell have had a long 
association with it and I doubt they've pulled it out of Groupwise just 
yet. Their adoption of MySQL happened way after Groupwise 6.0 was 
released, and Groupwise 6.5 is really just a client-side upgrade. 
Remember, they've also ported PostgreSQL to NetWare.

Exchange Server 2003 (aptly named "Titanium") doesn't seem to use MS SQL 
on the backend. It achieves it's hot backup through Volume Shadow Copy - 
an old trick that Windows 2000 and above have built in and is used by 
the built-in backup utility.

I totally agree about MySQL outclassing Oracle in the file size 
argument, but the ease of configuration of MySQL cannot be understated 
when you're comparing the two. Even though Oracle comes with a graphical 
configuration front end and a bunch of chunky books, I'd rather set up a 
mission-critical cluster using MySQL (single-master replication of 
course, as it doesn't currently to it any other way) than set up an MP3 
database using Oracle. It's that damned hard to get the thing to work!

If I had to go with a commercial DB though, I'd probably pick DB2 as 
it's the only commercial one with the platform support to match the big 
2 in the open space. That and the fact that DB2 loves Linux and is 
heavily standards compliant, not to mention that it's coming to the 
almighty Hammer very soon. Now if only they'd port it to BSD so my 
friends would shut up....

As for Postfix+SpamAssassin etc, e-mail me if you'd like. I've had it 
happening for over a year now. I used to be a Sendmail admin, but as 
soon as I got a hold of Postfix, I moved all of my installations over to 
it. It wins in every area, except maybe number of features (of which 
Sendmail has too many in my opinion). There are still a few gotchas with 
DBMail, but I've logged all of mine in the bug tracking database and 
hope to learn a bit more about DBMail's structure with a view to fixing 
them.

Regardless, off to bed. I have an SRS to hand in at uni tomorrow 
morning, and it's 3:30am!

Chris
www.itoperations.com.au/dbmail.html

Curtis Maurand wrote:

Let us not forget that the really highend email systems such as Openwave Email 
Kx uses Oracle (AT&T Broadband, RoadRunner, Bell Canada and a host of other 
very large systems use the Openwave product), Microsofts highend smtp product 
uses MSSQL server, Novell's highend system (which outperforms most but is 
expensive) has a database at the backend.  They're not saying what it is.  I 
suspect its similar to the one they are using for eDirectory.  they used to 
use Btrieve for everything, but they just recently started shipping MySQL 
with netware and dropped btrieve support.  That leads me to believe that 
MySQL may be at the heart of a lot of their services.  The next version of 
*cough* exchange server will have MSSQL at the backend.  IBM mainframes use 
DB2 for the message store.  A database makes a lot of sense for a mail 
server.  The database folks have spent a lot of time developing techniques 
for finding information in files rapidly.  There is also the issue of scaling 
to large files.  Some databases are better than others with that.  At the top 
of the heap are MySQL, Oracle and DB2.  If you talk to the folks MySQL, 
namely Monty, he'll explain it, but has found that MySQL scales to large 
files better than Oracle does.

I could go on, but I like the idea of dbmail and I'm looking to implement it 
in my hosting business.  It makes sense on  a lot of different levels.  The 
lack of documentation is a hinderance plus the fact that I've been working 
with Sendmail for years and now I'm learning postfix in addition to finding 
ways to implement spamassassin and anti-virus prior to dropping the message 
in the database.  I've looked into all of the solutions and there is a good 
commercial product from the folks that wrote dnews and even it will use MySQL 
at the backend.

I've gone on long enough, now back to your regularly scheduled discussion.

Curtis

On Tuesday 22 April 2003 10:38, Chris Nolan wrote:
 

Kiran N S wrote:
   

Hi All,
I am not an out and out techie, but would still like to know more about
the stability of the PostgreSQL / MySQL database used in case of say, 10
/ 25 / 50 / 100 / 500 / 1000 users. What are the db restoration processes
executed and how, in case of PostgreSQL or say, McKoi / MySQL? Somebody,
pls shed light on the issue. Can a stabler db like Oracle be used?
     

PostgreSQL has pg_dump.  MySQL has  mysqldump. In both cases, you can
use 'em while the DB is running. pg_dump gives you a point-in-time
snapshot of the entire DB. If you're using the InnoDB table type in
MySQL, you can use the --single-transaction switch with mysqldump for
the same effect (make sure that you've got your isolation level set to
READ_COMMITED in your my.cnf file though).

Resotration is easily handled with the command-line clients for each.

   

Another thing with the usage of MySQL is that it is not an RDBMS, leading
to code complexities when you need to incorporate more effective
productivity-oriented features along with the vanilla e-mail. Even a
simple thing like, say, generating a report on number of e-mails sent to
a particular account with timestamps can be a problem. What is the way
out?
     

Umm...errr...how exactly is MySQL *not* a relational database!?!?


From a business strategy point of view, will the introduction of
database-centric e-mail servers with/without messaging and groupware
functionalities result in a non-competitive offering in the market as
better flexibilities are offered through a file storage mechanism? Have
other players in the same space already analyzed the database route,
discovered it to be full of complexities and opted for a stabler file
storage model? Does a database approach speak of unsound strategy and fuzzy
R&D or is there light at the end of the tunnel?


There is definitely light at the end of the tunnel.

Are you familiar with the reasons why database systems are such big
business? Basically, a RDBMS solves many of the problems associated with
storing stuff in lots of different files through it's fundamental
design. Problems of change control, syncronisation and versioning that
can cause headaches with distributed files are all solved through
database usage.

If you're looking for a commercial implementation of "mail in a
database" check out Oracle's Collaboration Suite. It's built on top of
Oracle 9i and speaks IMAP4, POP3 and MAPI (sort of, enough to be Outlook
compatible).

Additionally, the massive benefits available when your mail storage
backend is a database include, but are not in any way limited to:

* Adding more storage becomes trivial and instantaneous - Just add
another partition to your database
* Backups can happen online, without interrupting anything
* Redundancy can be added without bringing down an already existing system
* The data store can be accessed concurrently by any app,  without
needing to worry about file locking or low-level storage mechanisms
* Performance, performance, performance
* Filesystem limitations (file size limits, filename length limits, max
number of directory entries) all become basically null and void.
* Data safety! Even though we have XFS, JFS, EXT3 and the almighty
ReiserFS in the Linux world (with JFS coming to the BSD world real soon
and the other Unixes already having journaling...except that poor joke
excuse for a Unix SCO OpenServer), I'll take a transaction-based DB in
addition to those thanks!
* Security - As the FS is never touched, that's one less part of the OS
we (even though indirectly) expose to the world - security flaws in apps
can be rectified with less downtime than OS flaws in many cases.

The list goes on. Storing stuff in a bunch of files is a simpler
concept, but unlike the simple concept that is the Unix paradigm storing
stuff in files can cause a lot of problems as you start wanting to do
more complex things. Of course, there is a blur between FS and DB
storage thanks to those idiots at Microsoft (with Access/Jet and that
pile of crap called FoxPro that the other pile of crap ACT! is built on
top of).

I hope this helps somewhat!

Chris

   

Look forward to hear from all you guys out there...

Best regards,

NS Kiran
India.
Cell Phone: +91-98861-12210
Land Phone: +91-80-333-6173 x-270

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

"Sometimes you have to take the leap, and build your wings on the way
down." - Kobi Yamada

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
     

_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
   

_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail