There’s a mystery about early Exchange 2010 deployments: despite the much-publicized removal of single instance storage, sizes of Exchange 2010 databases have not increased. The same message has trickling back from all quarters, as businesses go live: after moving mailboxes, database sizes in Exchange 2010 are roughly the same as they were in Exchange 2007.
How is this possible? Could it be that single instance storage never really had real benefits? Or maybe because it had been weakened in 2007 (so that only attachments within a storage group were single-instanced), we already paid the tax?
Well, the mystery has been solved: in Exchange 2010, MS introduced compression. In more detail,
“As a result of the new architecture and the other changes to the store and ESE, we had to deal with an unintended side effect. While these changes greatly improved our IO efficiency, they made our space efficiency worse. In fact, on average they increased the size of the Exchange database by about 20% over Exchange 2007. To overcome this bloating effect, we implemented a targeted compression mechanism (using either 7-bit or XPRESS, which is the Microsoft implementation of the LZ77 algorithm) that specifically compresses message headers and bodies that are either text or HTML-based (attachments are not compressed as typically they exist in their most compressed state already). The result of this work is that we see database sizes on par with Exchange 2007.”
So! It seems that Microsoft has not been as off-hand with our storage as it seemed. The message from Redmond has mostly been, ‘Ah, storage is cheap – and even cheaper for Exchange 2010 – so losing SIS isn’t a big deal.’
But, heart-warmingly, they were looking out for our storage needs all along.… which makes me wonder, why the shyness about the compression? Yes, there will be a performance tax, but most Exchange servers are not performance-limited by the processor.
Is there some other disadvantage to compressing messages in the Exchange database? I can’t think of one.