Delphix and Flash
I started working with flash in 2006 -- fortunate timing as flash was just starting to take hold in the enterprise. I started asking customers I'd visit about flash. I'll always remember the response from an early adopter when I asked about how he planned on using the new, expensive storage, "We just bought it, and we have no idea." It was a solution in search of a problem -- the garbage can model at play.
Flash has evolved significantly since then from a raw material used on its own to a component in systems of increasing complexity. I wrote recently about the various techniques being employed to get the most out of flash; all share the basic idea of trading compute and IOPS (abundant commodities) for capacity (still more expensive for flash than hard drives). The ideal use cases are the ones that benefit most from that trade-off, ones where compression and dedup consume cheap compute cycles rather than expensive space on the NAND flash. Flash storage is best with data that contains high degrees of redundancy that clever software can squeeze out. With those loose criteria, it's been amazing to me how flash storage vendors have flocked to the VDI use case. It's certainly well-suited -- big on IOPS with nearly identical data from different Windows installs that's easily compressed and deduped -- but seemingly every flash vendor has decided that it's one part -- if not the part -- of the market they want to address. Take a look at the information on VDI from various flash storage vendors: Fusion, Nimble, Pure Storage, Tegile, Tintri, Violin, Virident, Whiptail -- the list goes on and on.
I worked extensively with flash until leaving Oracle in 2010 when I decided to leave for a start up. I ended up not sticking with flash precisely because it was -- and is -- such a crowded space. I'd happily bet on the space, but it was harder to pick one winner. One of the things that drew me to Delphix though was precisely its compatibility with flash. At Delphix we create virtual database copies by sharing blocks; think of it as dedup before the fact, or dedup but without the runtime tax. Creating a virtual copy happens almost instantaneously saving tremendous amounts of administration time, unblocking developers, and accelerating projects -- hence our credo of agile data. Unlike storage-based snapshots, Delphix virtual copies are database aware, provisioning is fully integrated and automated. Those virtual copies also take up much less physical space, but with as many or more IOPS hitting the aggregate of those virtual copies. Sound familiar yet? One tenth the capacity with the same workload -- let's call it 10x greater IOPS intensity -- is ideally suited for flash storage.
Flash storage is best when clever software can squeeze out redundancies; Delphix is that clever software for databases. Delphix customers are starting to combine our product with their flash storage purchases. An all-flash array that's 5x the $/TB as disk storage suddenly becomes half the price of disk storage when combined with Delphix -- with substantially better performance. We as an industry still haven't realized the full potential of flash storage. Agile data through Delphix fills in another big piece of the flash picture.
- ← Previous
On Systems Software - Next →
Topics in post-mortem debugging