Database administrators (DBAs) spend a large portion of their day optimizing databases. Do all-flash arrays eliminate that need? While in most cases, the answer to any IT question is “it depends”, in this instance the answer is an emphatic NO!. While all-flash arrays do take some of the pressure off they don’t eliminate the value of database optimization.
The Anatomy of a Performance Complaint
When there is a complaint about database performance, it most often is the result of lack of response time. Users request information and the system is not able to provide the answers fast enough. In most cases too many requests coming in at the same time causes this issue. Once the complaint is lodged, almost all fingers point toward storage. The response to the finger pointing is often to the throw hardware at the problem and in most cases an all-flash array seems to fix the issue. And an all-flash array, if the organization can afford it, is an excellent first step.
Is All-Flash Really the Fix?
Most, if not all databases, do experience a performance improvement when moving to an all-flash array. But how much of an improvement depends on other environmental factors. Clearly the all-flash array is the catalyst for performance. But it also exposes latency elsewhere. For example, if the application is poorly written, if indexes and/or the network are not optimized, then the flash array can’t live up to its full potential. A design flaw elsewhere bottlenecks the data flow.
A Case for Database Optimization
A poorly optimized database is one of the elements in the environment that will keep a flash investment from running to its full potential, and at some point IT will need to address it. It is OK to invest in the flash array first but use the flash array to buy time while database optimization is performed.
Using Flash for Database Optimization
First, make sure the flash array can provide copy on write snapshots. Some vendors call this copy data services. Then make a production copy of the database and perform some of the best practice optimization steps like index and query optimization. Once the impact of these optimizations is realized and tested, then the actual production database can be scheduled for this optimization.
The ability to make writable copies also helps with the bigger task of actual code optimization. Code optimization is a longer but necessary process. The ability to test these code changes against near-production copies of data, that don’t take up any additional capacity, is of huge benefit. Code optimization comes in two forms. First, fixing legacy inefficiencies in the code that may have always been there. And second, changing code to take advantage of an all-flash reality. Often there are coding decisions made to work around hard disk based arrays, with flash those workarounds may no longer be needed and in fact add latency to the process.
In a perfect world database optimization should happen before buying a flash array. But the world is hardly perfect, especially when it comes to IT. Database optimization is often a time consuming task that may require application downtime, inserting a flash array into the environment can often be done with only the smallest amount of downtime as the system is cut over. Investing in the flash array first also enables the more involved process of database optimization through the use of technologies like copy on write snapshots.
Sponsored by Tegile