TMADOC -
I have a slightly different opinion for TempDB than does Eugene - although I will stress that he is quite right (as he is in essentially all things NetApp) in the general case.
The specific use case where I found AFF with inline dedupe and inline compression on TempDB to be useful was for a large scale data warehousing application. Total TempDB allocation was 5TB total spread across 6 database instances. This application supported significant multi-table joins and other actions that chewed up a lot of temporary space.
AFF did not address write performance, since writes are acknowledged from NVRAM of course. So SSD as the write target is not a big deal. CPU use was higher as expected to process the inline efficiency but not a concern as it was an AFF8080 with CPU cycles to burn. Disk usage typically held to 50% of actual size through efficiency. Of course all instances never managed to use their max temp space together either, but at scale I could easily rely on a 2.5TB committed storage size required for the TempDBs during allocation and sizing planning.
At higher scale, if you have the CPU, the cost of the flash (along with the storage tax) can be higher than not using the efficiencies - the difference between hardware for AFF8080 vs AFF8040 was much smaller than would be the cost of the SSD for TempDB as this grows further to storage it native size. Application is currently limited in that we can't make use of non-NSE disks, so 3.8TB SSDs are not an option and the smaller ones were way higher cost per GB.
In this same use case if I were limited to AFF8040 as the controllers I likely would not have used inline efficiencies on the TempDBs because CPU wasn't as plentiful. It's a "soft" cost that can be considered but hard to quantify during purchase cycles without a really good idea of exactly how your applications and databases behave.
Hope this helps.
Bob Greenwald
Senior Systems Engineer | cStor
NCIE SAN Clustered, Data Protection
Kudos and accepted solutions are always appreciated.
