Aside from the obvious benefits of reducing the database size and de-duplicating attachments, another point raised was that mail attachments are typically quite static and are usually not accessed all that often. Therefore, by spinning them out to separate files on the disk, it's more cost effective to place the repository on Tier 2 storage, saving your faster disks for the databases.
It's also worth noting that DAOS is not just for mailboxes - it will work with ANY notes database. That includes mail.box, by the way, so once a message with an attachment hits the server, it's written to the disk once and once only, and the pointer stub gets routed through the server. They've seen about a 13% reduction in disk I/O, as well as a 10.5% decrease in CPU usage from this.
Of course, it's not all sunshine and roses. There are a few caveats to be aware of. These include:
- The size of the attachment still counts towards the user's quota size, even though it's not stored within the nsf file.
- The attachment size does NOT count towards the 64Gb size limit for an NSF file. In one case, a client has created an NSF file which is logically storing 2TB of data, but thanks to DAOS the NSF is still less than 64Gb. However, this database cannot be replicated to any non-DAOS server, because the replica would then be over the limit
- Copying/duplicating an NSF file file at the OS level, or deleting an attachment file will cause the DAOS system to go out of sync. Things will still work, but files will not be deleted off the file system when the documents are deleted until after resync/verification is done. This can be automated, however.
- Transaction logging must be enabled on the server, and the available space in the logs must be large enough to buffer the largest file you might want to pull out.
- You need to create/upgrade the database format to 8.5 format.
So, there's a few things to note but they're fairly minor, compared to the significant savings that can be made.
No comments:
Post a Comment