I'm in 100% agreement with that. ________________________________________ From: Campbell, Rob [rob_campb...@centraltechnology.net] Sent: Thursday, May 07, 2009 8:56 AM To: MS-Exchange Admin Issues Subject: RE: Exchange archiving
My biggest complaint with using it as data storage isn't performance, but management and access. The access methods and permission model of an Exchange database make programmatic access of the data unnecessarily complicated for bulk data storage and retrieval. IMHO. -----Original Message----- From: Michael B. Smith [mailto:mich...@owa.smithcons.com] Sent: Wednesday, May 06, 2009 7:23 PM To: MS-Exchange Admin Issues Subject: RE: Exchange archiving Not intending to delve into the vagaries of the ESE implementation; however, it is worthwhile to note that Exchange 2007 changed database internals to flatten the database and increase table performance; Exchange 2010 has made a large number of changes that continue to flatten the database structure and improve table performance.As such, in 2010, the number of items in a folder that provide good performance has increased by a couple orders of magnitude. Also, there used to be message-store level tables that contained all attachments and message bodies; these have been moved to be per-mailbox tables and that also allows for significantly improved per-mailbox performance (and subsequently larger mailboxes). Each "block" in a message store has overhead associated with it, thus the larger number of blocks, the higher amount of overhead consumed. In Exchange 2003, the blocksize was 4K. In Exchange 2007, it was 8K. In Exchange 2010, it is 32K. Thus, the overhead as a percentage of storage is significantly reduced. I would argue that ESE is a filesystem; albeit a specialized one. Unlike SQL, it is not a RDBMS. Most original database systems (and I think Oracle and DB2 still do on certain operating systems) allocated an entire "volume unit" and managed the storage in raw mode; obviating the need for a filesystem - this was to eek the maximal performance from the device especially when a filesystem provided no services that they needed. SQL Server, in its early versions, allocated fixed files and managed them for the same reason (I don't know whether that is still an option or not). ________________________________________ From: Ben Scott [mailvor...@gmail.com] Sent: Wednesday, May 06, 2009 7:28 PM To: MS-Exchange Admin Issues Subject: Re: Exchange archiving On Wed, May 6, 2009 at 2:11 PM, John Cook <john.c...@pfsf.org> wrote: >> But why isn't an e-mail system a file transfer and storage system? > > Because it's a database app with performance limits as opposed to a file > server. [This message is somewhat vague theory, somewhat devil's advocate, and somewhat philosophy, but I think this is a discussion worth having.] Fundamentally, and from a high level, a database and a filesystem are not all that dissimilar. Indeed, in a lot of the historical literature I've read from the 1940s and 1950s, there isn't a clear distinction between the two. That idea came later. It's not like a filesystem doesn't magically not have performance lists. Do a directory of a folder with tens of thousands of files in it sometime. Slow. Databases and filesystems generally have different optimization goals and feature sets, of course. And that's some of the reason why trying to move large files out of Exchange is a good idea. ESE doesn't do well at that, and NTFS does. But there's more to it than that. As many have said, having more than a few thousand items in a single folder slows Outlook and Exchange way down. See above about large NTFS directories. Both are slow, so going to NTFS simple moves the problem around. One could point to the performance wins that fixed sized records give you in a contiguous file, and that's a reason why databases are good at that. But ESE (Exchange^W Extensible Storage Engine) doesn't use that model, as far as I know. More importantly, I would argue that a mail system has more in common with a filesystem than a traditional database anyway. Message body lengths vary hugely. That's more like files than fixed-length records. Ultimately, computers should be a tool that serves the needs of people. Telling people not to use email they way they *want* to use email is not an ideal situation. Sometimes one has to adapt to the limitation of a system, but when possible, it's better to adapt the system to better do the job. -- Ben ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~ ************************************************************************************************** Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. ************************************************************************************************** ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
