MarcStaimer,President&CDSDragonSlayerConsulting W h i t e P A P E R DatabaseFatalFlashFlawsNoOne TalksAbout AndHowtoAvoidThem
WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem DatabaseFatalFlashFlawsNoOneTalksAbout MarcStaimer,President&CDSofDragonSlayerConsulting Introduction Flash storage has been touted for several years now as the answer to inadequate database performance.therearesomeverygoodreasonswhythisisso.flashstorageisgenerallymuchfasterthan hard disk drives (HDD). It has much lower latency, much greater write IOPS, throughput, and read IOPS.ThereforeitmustfixdatabaseperformanceproblemsNotsofast.Sometimesitdoesandsometimesit doesnot.thereareseveralflashissuessuchassteadystateperformance,writeamplification,wearlife,and electronleakagecausedhighbiterrorratesthatcansabotagetheperformancegainswhileoverwhelmingthe budget.theseissues(andseveralothersaswell)arerarelydiscussed,exceptafterthefactwhenperformance isnolongermeetingrequirements. This white paper examines these issues in detail looking at how they specifically affect databases and the structuredapplicationsthatdependonthosedatabases.therewillalsobediscussionabouttheprosandcons of common workarounds. It then examines howtegile s Intelliflash storage systems actually solve those unpleasantdatabasefatalflashflaws. DragonSlayerConsulting Summer2014 2
TableofContents WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem Introduction...2 SQLDatabasePerformanceIssues...4 HowDBAsFrequentlyRespond...4 Tuning...4 ScaleVup...4 ScaleVout...4 WhyFlashStorage...5 GeneralHostBasedFlashStorageDrivesProsandCons...5 GeneralFlashStorageHybridSystemProsandCons...5 GeneralAllFlashArray(AFA)SystemProsandCons...6 FlashStorageSQLDatabaseSurprises...6 DatabaseFatalFlashFlaws...6 HowFlashStorageActuallyWritesandReadsData...6 FlashIdiosyncrasies,Issues,orFlawsThatAreOftenFataltoSQLDatabases...7 HowTegileIntelliFlash StorageArraysSolveSQLDatabaseFlashFatalFlaws...8 EliminatingTheBitsPerCellTradeoffs...9 ReducingWriteAmplificationIncreasingWearLife...9 Eliminating/MitigatingWriteVCliff...9 Steadystateperformance...9 EliminatingReadVDisturb...9 CorrectingHighBER...9 TegileIntelliFlashSQLDatabaseProofPoints...9 GrassValley...9 St.PaulHousingAuthority...9 USVYellowPages...10 UnnamedHedgeFund...10 InSummary...10 ForMoreInformation...10 DragonSlayerConsulting Summer2014 3
WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem SQLDatabasePerformanceIssues SQLdatabasesaretypicallyIOPS(inputsandoutputspersecond)intensive.Meaningthattheyrequirethe computeinfrastructuretodeliverhighamountsofiopstodeliveraconsistentsatisfieduserexperience.sql database IOPS requirements are rapidly increasing because of application proliferation dependent on those databases.thoseiopscanbedeliveredviamemoryorstorage.memoryordramisaveryexpensiveoption although justifiable in some cases. Storage is much less expensive, delivers much fewer IOPS, therefore requiring a lot more of tehm to meet modern database requirements. This puts high stress on the storage infrastructure. HowDBAsFrequentlyRespond Databaseadministrators(DBA)havebeenendeavoringtocopewiththeIOPSperformancegrowthforyearsby delvingintotheirbagofsoftwareperformanceenhancementtricks.mostwilltrytofixtheiopsperformance problembeforeaddingorchangingtheirstoragehardware. Tuning OneofthefirstthingstheyattemptisHDDIOtuning.HDDIOisoptimallysizingSQLdatabasefilesandthen placingthemondifferentlunsandraidgroups.doingthisdeliversthemaximumharddiskdrivesubsystem throughput. But it requires the DBA to possess extensive SQL database as well as storage subsystem knowledge.nextupisapplicationtuning,whichisanotherwayofsayingrecodingthesql.applicationtuning isatimevconsuming,laborvintensivetask.acommondbatuningtrickistopincertaindataintomemoryor cache.doingsowillreducetripstothedisksubsystemanddecreasequerylatencies.anothertoolismemory tuningor rightvsizing thesqldatabasebuffers.although,thisonetendsnottobeusedasoftenbecauseof itshitormissnature.rightvsizingsqldatabasebuffersisasmuchartasscience.itcomesfromexperienceand DBAintuitionbasedon wait events,bufferhitratios,systemswapping,andpaging. EachofthesetoolsisdependentontheDBA sinherentexpertise.allofthemtakeeffort,labor,andtime.and fartoofrequentlythesetuningtricksjustdonotachievethedesiredperformancegains. WhentuningfailstoaddressSQLdatabaseperformanceissues,thenextstepistospendmoney.TheDBAcan scalevupthedatabase,scalevoutthedatabase,orbuyhigheriopsflashstorage. ScaleRup ScalingVupistheprocessofmovingtoabigger,morepowerfulserverfortheSQLdatabasesuchas64,96,128, or256processorswithmorememory,io,bandwidth,pcieslots,etc.it ssimplebutwithahighcostinboth capital expenditures and operating expenditures. Besides more expensive hardware, there s the additional softwarecosts.sqldatabaselicensingescalatesrapidlybecausethey rebasedoncores.scalingvupassumes processingistheperformancebottleneckandthat srarelythecase. ScaleRout ScalingVoutisthenextapproachandhastwodistinctiveoptions.Thefirstoptionisbasedonspreadingqueries acrossmultipleuniquedatabaseinstances.itrequiresmoreinstancesofthecurrentdatabasewithatwist. Thereareseveralvariationsofthistechniqueincluding: Sharding (the process of dividing database data along a specific application boundary among multiple databaseinstances); Readonlyslaves(writesarededicatedtoamasterdatabasethenreplicatedormirroredtothereadVslaves whereallreadsarerouted); PeerRtoRpeerreplication(onlyusedwhendatabaseupdatesareinfrequent,maintainsmultipledatabase copieswherereplicationisrequiredtoupdatetheotherdatabaseengineswhenachangehasbeenmade); Linkedserversanddistributedqueries(localdatabasequeriesremotedatabasesasiftheywerepartof thelocaldatabase); Distributed partitioned views (ideal for update intensive apps, the primary SQL database table data is partitionedamongtablesinnumerousdistributeddatabasesbasedonapartitioningkey); Data dependent routing (partitions the data to multiple databases while placing responsibility on the applicationormiddlewaretoroutethequeriestothecorrectdatabase). SpreadingqueriesacrossmultipleuniquedatabaseinstancesisnotforamateursrequiringwideVrangingDBA knowledge, skill, expertise, as well as continuous adjustments and tuning. The underlying database DragonSlayerConsulting Summer2014 4
WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem performanceproblemassumptionisthatit stheresultofdatabasesizeorscale.sometimesthatisthecase. And whenitis,it can sometimes be solved by spreading queries across multiple unique database instances leveragingtheadditionalcomputenodesanddatabaseinstances. Optiontwoistheimplementationofclusteredordistributeddatabase.Bothutilizemultiplecommoditized servers.clusteredsqldatabasesareasharedeverythingarchitecture.itcreatesabiggerdatabaseviatheuse of clustering. Distributed SQL databases are a shared nothing architecture built on grid technology (the underpinningsofcloudtechnology)forelasticityandscalability.theytendtorequirelessdbaexpertiseand budgetthanmultipleinstancesofstandardsqldatabases;however,it saripvoutandreplacementofthose traditionaldatabases.andonceagain,theunderlyingdatabaseperformanceproblemassumptionisthatthe bottleneckisnotenoughcomputepower.whenthat sthecaseclusteredordistributedsqldatabasescan resolvetheperformanceissue. AlloftheDBAissuesdiscussedupuntilthispointhavebeenmanuallylaborVintensiveoptions.They retime consuming,oftenfrustrating,anddon talwayssolvetheproblem.thisiswhysomanydbashaveturnedto flashstorageastheanswertotheirperformanceissues. WhyFlashStorage Flashstorage(a.k.a.NAND)drivesproducethousandstomillionsofIOPSinasmall package. Flash storage is fast producing as much as 3 orders of magnitude more random IOPS than Enterprise HDDs. It also draws much less power and cooling (reduced operating expenses) than HDDs because there are no moving parts, does not require an entire flash drive to be rebuilt when a block fails, and does not fragment as HDDs do eliminating defragmentation requirements. But it s those incredibleiopsthatmakeflashstorageofallkindssoattractivetothedba.justas importantly,flashstoragedoesnotprecludetheuseofanyoftheotherperformance enhancingeffortsjustdiscussed.flashstorageisinfactsqldatabasemethodologyagnostic.itcananddoes forthemostpartinstantlyincreasethesqldatabaseiops. SQLdatabaseflash storage is implemented as eitherhost flash storage drives(ddr3dimms,pciecards,or SAS/SATAsolidstatedrives(SSD)),orasaSANblock(iSCSIand/orFibreChannel)connectedorNAS(NFSor SMB)filesystemconnectedflashstoragesystem.Flashstoragesystemscomeinhybridstoragesystems(mix ofssdandhdd)andallflasharrays(afa).bothflashstoragedrivesandflashstoragesystemshavetheirpros andcons. GeneralHostBasedFlashStorageDrivesProsandCons The host based flash storage drives SQL database pros include: lowest SQL database to flash storage latency; simple implementations/operations; and relativelylow$/iops. The host based flash storage drive SQL database cons include: limited scalability;limitedecc;limiteddram;nandchipquality;costin$/gbcapacity;tcoishigh;caching 1 often limited to write through (read) caching; write back caching creates shorter wearvlife and greater writev amplification;difficulttoimpossiblepinningsqldatabaseindexesand/orhotdataintotheflashstoragecache; andflashstorageavailability,resilience,continuity,anddataprotectionarenominalatbest.inaddition,flash storageinonehostisnotaddressablefromanotherwithoutadditionalcostlylicensedsoftwarethatclusters thehostsandstorage. GeneralFlashStorageHybridSystemProsandCons FlashstoragehybridsystemSQLdatabase pros include:highperformanceiopsforactivedatawithlower cost storage of inactive or cold data (Dragon Slayer Consulting surveys put inactivedataas>90%ofallitorganizationaldata);inlinededuplicationand/or compression increases both flash and HDD usable capacities with nominal impact on latency and performance even improving performance by keeping more data in cache; excellent total usable capacities; exceptional data protectionandresilience(zerospacesnapshots,clones,replication,andecc); relativelylowoverall$/iops;relativelylowcostin$/gb. 1 Cachingisamandatoryrequirementwhendatamustbesharedonexternalstoragesuchaswhenahypervisorisinvolved. DragonSlayerConsulting Summer2014 5
WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem Flash storage hybrid system SQL database cons include: inline dedupe may have a noticeable negative impactonsqldatabaselatencyandperformance;thereareseveralhybridswithsomewhatconstrainedusable flashcapacities;hybridsthatdoflashcachingordinarilyuseonlywritevthrough(read)caching;maynotbeable topinorfixsqldatabaseindexesand/orhotdataintotheflashstoragecache;storagetieringforcesallwrites tostartonflashincreasingwriteamplificationandshorteningwearvlife(sameissuewithwritecaching);$/iops islowerthanhddsystemsandhigherthanafas;$/gbislowerthanafasandhigherthanallhddsystems. GeneralAllFlashArray(AFA)SystemProsandCons AFA system SQL database pros include: large amounts of total storage system IOPS; inline deduplication and compression increases both flash usablewithnominalimpactonlatencyandperformance;fairtoquitegood totalusableflashcapacities;exceptionaldataprotectionandresilience(zero spacesnapshots,clones,replication,andecc);bestoverall$/iops;okaybut improvingcostin$/gbespeciallywhendedupeandcompressionaretaken intoaccountandthecapacityisusablecapacity. AFA system SQL database cons include: inline dedupe may have a noticeable negative impact on SQL databaselatencyandperformance;maximum flashusablecapacities/scalability lags behind hybridandhdd storage systems; write amplification tends to be higher than hybrids that use writevthrough cache creating shorterwearvlife(sameissueaswritecachingorstoragetiering);$/gbiscurrentlyhigherthanallotherstorage systems(butthegapisshrinking). FlashStorageSQLDatabaseSurprises DBAs find that while flash storage of all kinds is initially an IOPS performance godsend that performance frustratinglydeclinesalmostimmediatelydegeneratingfairlyrapidlyuntilitlevelsoffatamuchlowerlevel. The test performance is higher than the production. This is the result of planning to firstvoutvofvbox performanceversussteadystate.anyonewithaflashstoragebasedlaptopexperiencesthis.thatandseveral other flash storage performance and data corruption issues from electron leakage, read disturb, and cell failureswillreducesqldatabaseperformanceaswellasstabilityifthey renotproperlyhandled. DatabaseFatalFlashFlaws MostnonVstorageexpertshavealotofmisconceptionsaboutflashstorage.Fromhowdataisprogrammed (writtento),howit serased,evenissuescausedbyexcessivereadsareanannoyingsurprisetomostdbas. Flash caching is yet another area of confusion. To understand the flash issues that cause DBAs heartburn requiresabrieflevelsetonhowflashstorageactuallyworks. HowFlashStorageActuallyWritesandReadsData FlashstorageisanonVvolatilestoragemedium.Datacanbewrittentoit(programmed)anderasedfromflash storage.thetwodifferenttypesarenorandnand.basedonprice/performancereasons,todaythevast majorityofcommercialflashstorageisnand.datastorageingeneralisrecordedasbinaryzerosandones. ForHDDsit sbasedonthemagneticpolarityofplusorminus.flashstorageisdifferentandnonvintuitivein how it captures and changes data. It s electrical storage not magnetic storage. Flash states are based on voltagelevelswithinacellmeasuredasbitspercell.onebitpercelliscallsinglelevelcell(slc).twobitsper celliscalledmultivlevelcell(mlc).threebitspercelliscalltriplevlevelcell(tlc).slchastwouniquestates percell(0,1),mlchasfouruniquestatespercell(00,01,10,11),andtlchaseightuniquestatespercell(000, 001,010,011,111,110,101,100).Theamountofvoltagerequiredreadingacellincreaseswiththenumberof states.thishasahugeimpactontheflashperformance(latency),biterrorrates(ber),andlifeexpectancyor programverasecycles(p/e)alsoknownaswriteverasecycles.p/ecyclesarethenumberoftimesaflashcellcan bewrittentoanderasedbeforeitessentiallystopsfunctioning.it scolloquiallyknownasflash wearvlife. Unlike HDDs, flash stored data cannot be changed in place. This is because of the way flash storage programs/writesanderasesdata.dataiswritteninpagesof256bytes,2kbytes,or4kbytesplusafewbytes for storing error correcting code checksums. Pages are combined into blocks. Blocks are commonly 16KB, 128KB,256KB,or512KB.Dataiswrittenrandomlyinbytesbutcanonlybeerasedinblocks.Infact,oncea blockhasbeenwrittentoitcannotbewrittentoagainuntilit serased.thatmeansifonly2kbiswrittentoa 512KBblock,theremaining510KBisinaccessibleuntilthewholeblockiserased.Eachtimeablockiserased thewearvlifeisshortened.thatunusedcapacitynowhasashorterwearvlife.knownaswritevamplification, it sjustoneflashidiosyncrasythathasseriousdatabaseconsequences. DragonSlayerConsulting Summer2014 6
WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem FlashIdiosyncrasies,Issues,orFlawsThatAreOftenFataltoSQLDatabases Therearesevenkeyflashidiosyncrasies,issues,orflawsthatcanhaveameaningfulnegativeeffectonSQL databaseperformance.theyare:bitspercelltradeoffs,p/ecycles(wearvlife),writeamplification,writecliff, steadystateperformance(versusfirstvoutvofvboxperformanceorfob),readdisturb,andhighbiterrorrates. Bits%per%cell%tradeoffsaredeterminedbytheflashstoragebeingSLC,eMLC,MLC,andTLC.Morebitsper cellresultsinlowercostflashstoragebutalsolowerperformance.asbitspercellincreasesodoesthe voltagerequiredtoprogramandreadthecell.increasedvoltageaddslatency,increasesbiterrors,and reducesflashstoragewearalife.slchashighestperformance,lowestlatency,longestwearalife (measuredinp/ecycles)andhighestcostpergb,whereastlctheslowestperformance,highestlatency, shortestwearalife,andlowestcostpergb.theemlcandmlcflashstoragefallinabetweenwithemlc tendingtowardsslcandmlctendingtowardstlc. SQL database performance consequences: SQL database performance will obviously vary by the flash type utilized. But there is a value tradeoff of cost versus performance measured ascost/iops that must be taken into account. In addition, at some point the SQL database performance bottleneck will be pushed into the storage controller or the SQL database server resources making additional flash IOPS impossiblebtobutilize. P/E%cycles%(wear5life)aredeterminedbyflashtype(SLC,eMLC,MLC,TLC).SLCistypicallyratedbetween 100Kand1MP/Ecycles,eMLCfrom30Kto40KP/Ecycles,MLCrangesbetween3Kto10KP/Ecycles, andtlcfrom500to1kp/ecycles.wearlevelingalgorithmtechniquesintheflashstoragedrivehelp mitigatetheissue;although,itoftenrequiresmoresophisticationandprocessingpowerfoundina storagearraysystemforbestresults. SQL database performance consequences: Flash storage weardlife can be a major problem for SQL databases when it comes to data reliability. Cells, pages, and blocks that wear out can cause data loss thatbdestabilizesbthebsqlbdatabase.bb Write amplification shortens the flash usable capacity wearalife because unused capacity isconsistently erased without ever being programmed or written to. There tends to be a series of tradeoffs when it comes to write amplification. Smaller flash storage blocks reduce the amount of waste and write amplification.thedownsidebeingamuchgreaternumberofblocksfortheflashdrivecontrollertotrack for data obsolescence (data no longervalid), being marked for erasure (a.k.a. garbage collection), then being made available in the pool of writeable blocks. That additional processing adds latency, reduces IOPS, and requires additional flash storage controller DRAM. Large block sizes reduce flash drive controller processing and latency buthas higher wearalife. The better bet is when the flash storage array system caches writes to flash in DRAM and serializes the data to cache. Doing so very nearly eliminates write amplification. It also enables costly system DRAM to be shared across all system flas(ecc) that oftenonlyoccurinflashstoragesystems. SQL database performance consequences: Reduced write amplification is good, but the extra cost and higher latency diminishes SQLdatabase performance. Increased write amplification will cause faster cell, page, and block failures leading to data loss and corrupted databases. DRAM caching has the best potentialbofbsignificantlybreducingbwritebamplificationbwhilebincreasingbsqlbdatabasebperformance. Write cliff occurs when the flash storage performance drops suddenly, and permanently, all at once over time. This is predominantly a flash storage drive issue and not so much ofa flash storage system issue. It can still be a flash storage system issue when the system s flash capacity consumption exceeds 90% and the garbage collection process has becomes more frequent while working harder and slower. Write cliff is far more prevalent with flash storage drives generally and flash storage systems not architected specificallyfortheidiosyncrasiesofflash. SQL database performance consequences: Write cliff will show up as a sudden rapid database performancebdeclinebthatbdoesbnotbrecover. DragonSlayerConsulting Summer2014 7
WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem Steady'state performance vs First'Out'of'Box (FOB) performance is the state of the flash storage when it has experienced enough P/E cycles to stabilize the write performance to a predictable sustained level. Enough<P/E<cycles<are<generally<when<most<of<the<flash<storage<blocks<have<been<written<to<at<least<once.< FOB performance is the flash storage s best performance. The gap between FOB and steadycstate performance is nonctrivial often approaching an order of magnitude (i.e. steady state is approximately 10%<of<FOB.)<< SQL database performance consequences: A failure to plan SQL database performance around flash storage steady state will lead to the unpleasant experience of either living with lower SQL database performance;than;expected;or;spending;more;money;on;additional;flash;storage;than;was;budgeted.; Read'disturb<occurs<when<reads<of<a<NAND<cell<causes<data<to<change<on<bordering<or<nearby<NAND<cells< within<the<flash<block.<since<all<cells<on<flash<nand<chips<exist<on<the<same<die<there<is<occasionally<cross< coupling<between<bordering<cells<in<a<block.<the<energy<required<passing<through<a<cell<to<read<its<state< periodically<bleeds<enough<of<a<charge<off<an<adjacent<cell<that<pushes<that<cell's<state<past<its<threshold< changing<its<state.<<readcdisturb<is<more<likely<to<occur<as<the<bits<per<cell<increase<because<more<energy< is<required<to<pass<through<the<cells.<<because<the<reads<required<to<cause<a<read<disturb<is<measured<in<9< figures<it s<not<that<frequent;<however,<when<it<occurs<data<is<changed<or<lost.<<flash<storage<drives<and< systems<attempt<to<prevent<readcdisturb<by<setting<a<block<read<threshold<since<last<erase<cycle<that< copies<the<block<to<another<erased<or<unused<block<resetting<the<counter.<<correcting<readcdisturb< occurrences<requires<more<sensitive<error<detection<and<correction<codes<(ecc)<that<often<only<occur<in< flash<storage<systems. SQL database performance consequences: Read>disturb is more likely to occur in databases where the same data has an exceedingly high read rate and the flash storage does not have safeguards built>in. When;it;does;occur;SQL;databases;will;most;likely;become;corrupted. High bit error rates (BER) are endemic to flash storage. Error correction codes (ECC) are used to monitor and correct errors. The good news is that as NAND flash continues to shrink (now at 19nm heading to 14nm and 10nm) price per GB continues to decline. Thebad news is that NAND die shrinkage causes BER to increase geometrically requiring ECC algorithm capabilities, sensitivity, and complexity to increase right along with it. This in turn requires greater amounts of the flash storage controller s resources to manage that ECC. Therefore as NAND dies shrink, cost per GB drops, but overhead and IOPS latencies rise.<many flash PCIe and SSDs do not adjust their ECC algorithms enough to manage the increased BER requiring<the<storage<system<or<server<to<handle<it.<< SQL database performance consequences: Uncorrected high BER will cause corrupted SQL databases. Today;19nm;NAND;flash;requires;41;ECC;corrections;per;1KB;of;data.;;Future;advances;to;smaller;die;sizes; will require even more ECC corrections. Many flash storage controllers at the drive level do not have that capability.;;some;do,;whereas;most;flash;storage;systems;also;have;more;extensive;ecc;capabilities. FlashstorageisanoutstandingSQLdatabaseperformancestoragetechnologyifimplementedcorrectly and whileaddressingeachoftheseflawseffectively.otherwise,itislikelytocausedashedexpectationsandsevere SQLdatabaseoperationalandfinancialheadaches. HowTegileIntelliFlash StorageArraysSolveSQLDatabaseFlashFatalFlaws Tegile designed, developed, and implemented their IntelliFlash hybrid and all flash arrays to transparently eliminate,manage,andovercomethesesqldatabaseflashfatalflawstransparently. AllTegileIntelliFlashstoragesystemsfromthesmallesttothelargestdeliverthesecapabilities: DragonSlayerConsulting Summer2014 8
WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem EliminatingTheBitsPerCellTradeoffs IntelliFlasheliminatestheSQLdatabasepriceperformancetradeoffsbymakingthelowercostMLCflashdrives perform and behave similar to SLC. It speeds up MLC flash performance through clever use of the DRAM. DRAMisup10timesfasterthanSLCflash.IntelliFlashutilizestheDRAMtocoalescethewritestosequentialize themtothewriteflash.thatsequentializationenableslargerblocksizes(moreonthatinthenextparagraph), meaningfewerblockstotrackperflashstoragedrive,thatreducebothwriteandreadlatenciesfromflash storage drives improving performance. DRAM coalescence also increases the MLC wearvlife. SQL database IntelliFlashlatencieshaveaconsistent1msorless(betterthanmostSLCflashstorage)withthecostofMLC thuseliminatingthepriceperformancetradeoffs. ReducingWriteAmplificationIncreasingWearLife IntelliFlash DRAM coalescence eliminates the random nature of writes to flash that is so prevalent in SQL databases(servervirtualizationtoo).thisallowsintelliflashtoutilizelargerblocksizeswithexceptionallyhigh efficiencies(i.e.minimalunusedpagesinblocks)makingwriteamplificationanonvissuewhiledeliveringvery highwearvlifeandendurance. Eliminating/MitigatingWriteRCliff IntelliFlash flash storage arrays have the builtvin software, processing power, memory, and capacities that makewritevcliffanonveventinawelldesignedflashstoragesystem. Steadystateperformance IntelliFlash storage arrays increase the ramp to processtosteadystateflashperformance through it s large flashcapacities,intelligentuseofdeduplicationandcompression,anddramsequentializationofwrites.that useofdramcachingalsomeansthesteadystateissuedoesnotaffectwrites. IntelliFlashaddsanothertreattothehybridsystems.Inlinededuplicationandcompressionallowsupto10x more data to reside in flash read cache. This allows the pinning of all of the very performancevsensitive portionsofdatabasesinflash.theresultissignificantlylowersqldatabaselatencies,increasedsqldatabase cache hits, reduced HDD paging, and much improved overall database performance. IntelliFlash clearly mitigatestheimpactofsteadystate. EliminatingReadRDisturb Intelliflashflashstoragearraysutilizetheblockreadthresholdsincelasterasecyclethatcopiestheblockto anothererasedorunusedblockresettingthecounter.thuseliminatingreadvdisturbissues. CorrectingHighBER Intelliflashflashstoragearrayshaveamajoredgeindetecting,correcting,andovercominghighlevelsofflash storageber.itstartswiththehighlysensitiveandextensiveendvtovenderrordetectionandcorrectioncodes fromtheiothroughthecputomemorytoflashandevenontohddsandback.iteveneliminateshddsilent datacorruptionthroughchecksummatchingwiththeblocks.thereisnobetterendvtovenderrordetection and correction in the market today. Additionally, IntelliFlash storage systems include zero capacity instantaneous writeable snapshots, cloning, and replication. That data protection capability empowers IntelliFlashtokeepagoodcopyofthedatainanothervolumeorsystemshoulditnotbeabletoautocorrecta BER. TegileIntelliFlashSQLDatabaseProofPoints IntelliFlashhasbeenshippingforseveralyears.It snotjustmarketingtheorybutproductionproven.tegile hasnumeroussqdatabaseuserproofpoints.herearejustafew: GrassValley Grass Valley is a well know manufacturer of broadcast quality digital video equipment. Their implementationofintelliflashstoragereducedtheirsqldatabaseservercpuutilizationdownfrom90%to2%, improvedatabaseresponsetimesfrom30msto1ms,whileincreasingdatabasethroughputby10x.thatcpu utilizationreductionadditionallyallowedthemtoreducethenumberofcoresthedatabaserunsonreducing theirsqldatabaselicensingcosts. St.PaulHousingAuthority TheSt.PaulHousingAuthoritysawa5xincreaseinSQLdatabaseperformanceutilizingIntelliFlash storage.intelliflashalsoreducedtheirpowerandcoolingconsumptionby66%.but,itwastheirdatabase DragonSlayerConsulting Summer2014 9
WHITEPAPER DatabaseFatalFlashFlawsNoOneTalksAbout AndHowtoAvoidThem backups that were causing them the most heartburn. Backups forced them to shutdown their database extendedperiodsoftime.intelliflashreducedthosebackupwindowsbymorethan80%. USRYellowPages TheFloridabasedUSVYellowPageshaveseentheirSQLandSAPqueriesimproveasmuchas20xwhile databaselatenciesareaconsistent1ms. UnnamedHedgeFund AnunnamedHedgefundexperienceda3to5xincreaseindatawarehouseingestionratesonthe IntelliFlash.Soinsteadofrunningasingledatawarehouseanalyticsjobonwhatkindoftradeshouldtheyrun the next day, they now run three or more. This empowered them to perform far more detailed whatvif analysiswhilethemarketsareclosed. InSummary TherearenumerousflashstorageissuesthatmostDBAssimplydonotknowabout.Thoseissuescananddo haveanastyimpactonsqldatabaseperformance.solvingtheseproblemsrequirestheflashstoragevendor toaddressthemspecifically.tegileintelliflashhybridandallflasharraysdojustthat. ForMoreInformation ContactTegileSystems,Inc.at:www.tegile.comorviaEmail:sales@tegile.com. PapersponsoredbyTegileSystems,Inc.Abouttheauthor:MarcStaimeristhefounder,senioranalyst,andCDSofDragon Slayer Consulting in Beaverton, OR. The consulting practice of morethan 16 years has focused in the areas of strategic planning,productdevelopment,andmarketdevelopment.withover34yearsofmarketing,salesandbusinessexperience in infrastructure, storage, server, software, databases, and virtualization, he s considered one of the industry s leading experts.marccanbereachedatmarcstaimer@me.com. DragonSlayerConsulting Summer2014 10