Hvilken skrivning er rigtig? Et kig på I / O-cachemetoder

Forfatter: Laura McKinney
Oprettelsesdato: 1 April 2021
Opdateringsdato: 22 Juni 2024
Anonim
Hvilken skrivning er rigtig? Et kig på I / O-cachemetoder - Teknologi
Hvilken skrivning er rigtig? Et kig på I / O-cachemetoder - Teknologi

Indhold


Kilde: Kgtoh / Dreamstime.com

Tag væk:

En applikationshastighed er stort set afhængig af cache I / O-hastighed. Her sammenligner vi forskellige cache I / O-metoder.

Applikationsydelsen er forankret i hastighed - hastighed ved udfyldelse af læse- og skriveanmodninger, som dine applikationer kræver fra din infrastruktur. Opbevaring er ansvarlig for hastigheden af ​​returnering af I / O (input / output) anmodninger, og den metode, der er valgt til at forpligte skrivninger og levere læsninger, har en dybtgående indflydelse på applikationsydelsen. En almindelig metode i nutidens branche er at bruge SSD'er til cache til traditionel opbevaring af spindisk diske, hybride arrays eller all-flash-arrays. De fleste cacheløsninger har fremskyndet læsning for applikationer, men det virkelige spørgsmål er fortsat, "Hvilken skrivning er rigtig?"

Lad os se på, hvorfor skriveoptimering påvirker din applikationsydelse så drastisk. Skriv I / O indebærer, at det er nye data, der ikke er skrevet på din underliggende lager. I traditionel SAN-lagring skrives for eksempel skriv direkte på det underliggende lager og returneres derefter til applikationen. Med applikationer, der konstant skriver nye data, primært store databaseapplikationer (SQL osv.), Kan traditionelle spindeskiver ikke holde trit. Cache til SSD'er blev en løsning, der gjorde det muligt at skrive lokalt og cache baseret på hyppigheden af ​​applikationsbehovet; der er dog flere metoder til at skrive-cache-forholdet til den underliggende lagring, der forårsager en enorm forskel i ydelse.


Dette er de 3 former for I / O-skrivning:

  1. Writ-Around (omkring cachen)
  2. Skrive gennem (gennem cachen)
  3. Skriv-tilbage (fra cachen)

Alle tre former har forskellige fordele, der primært er baseret på den type data, der skrives: sekventiel kontra tilfældig. Sekventiel I / O er den mest optimerede af den underliggende disk (filer eller videostrømme for eksempel), mens tilfældige I / Os optimeres af cachen. De fleste cache-apparater har ikke den dynamiske intelligens til at ændre form for skriveteknologi baseret på datatypen. Lad os forstå forskellen mellem de tre former for I / O-skrivning.

Write-Around

Omskrivning, også kendt som skrivebeskyttet cache-tilstand, er udelukkende fordelagtig for at frigøre plads til cache-læsninger. Indgående I / O rammer aldrig cachen. I / Os skrives direkte til permanent lager uden at gemme data.

Hvad kan muligvis være fordelene ved cachen, hvis den ikke bruges? Det hjælper med at reducere cachen, der oversvømmes med skriv I / O, som ikke efterfølgende vil blive genlæst, men har den ulempe, at en læseanmodning om for nylig skrevet data skaber en "cache-miss" og skal læses fra langsommere bulklagring og oplev højere forsinkelse. Hvis din applikation er transaktion, som de fleste missionskritiske applikationer er, vil applikationshastigheden blive langsommere, og I / O-køer vokser. I det væsentlige ville værdien af ​​denne tilstand være i sjældne brugstilfælde, fordi den er tidskrævende, langsom og ikke præstativ.


Write-Through

Denne metode bruges ofte i cache- og hybridopbevaringsløsninger i dag. Gennemskrivning er kendt som en læst cache-tilstand, hvilket betyder, at alle data skrives til cachen og den underliggende lagring på samme tid. Skrivningen betragtes KUN som komplet, når den er skrevet til dit lager. Det lyder faktisk temmelig sikkert… men der er en hurtig ulempe.

Her er problemet: Hver skrivning udføres to gange, i cachen og derefter i permanent opbevaring. Inden applikationer kan fortsætte, skal den permanente lagring returnere I / O-forpligtelsen tilbage til cachen og derefter tilbage til applikationerne. Denne metode implementeres almindeligt med henblik på fiasko-elasticitet og for at undgå implementering af en failover- eller HA-strategi med cache, fordi data lever på begge steder. Imidlertid forekommer Writ-Through latenstid, da I / O-forpligtelsen bestemmes af hastigheden på det permanente lager, hvilket ikke svarer til hastighederne på CPU og netværk. Du er kun så hurtig som din langsomste komponent, og Writ-Through kan kritisk hæmme applikationshastighed.

Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv

Du kan ikke forbedre dine programmeringsevner, når ingen er interesseret i softwarekvalitet.

Skrive tilbage

Skrive-back forbedrer systemresultaterne med hensyn til hastighed - fordi systemet ikke behøver at vente på, at skrivninger går til underliggende lager.

Når data kommer til at blive skrevet, vil Writ-Back sætte dataene i cachen, en "alt gjort" og opbevare dataene til skrivning til lagringsdisken senere.

Dette løser en masse af latensproblemerne, fordi systemet ikke behøver at vente på disse dybe skrivninger.

Med den rigtige understøttelse kan Writ-Back være den bedste metode til cachelagring i flere trin. Det hjælper, når cachen har store mængder hukommelse (dvs. hukommelse målt i terabyte, ikke gigabyte) for at håndtere store mængder aktivitet. Sofistikerede systemer har også brug for mere end et faststofdrev, hvilket kan tilføje omkostninger. Det er kritisk vigtigt at overveje scenarier som strømafbrydelse eller andre situationer, hvor kritiske data kan gå tabt. Men med den rigtige "cache-beskyttelse" kan Writ-Back virkelig fremskynde en arkitektur med få nedadvendte sider. For eksempel kan Writ-Back-systemer bruge RAID eller overflødige designs for at holde dataene sikre.

Endnu mere detaljerede systemer vil hjælpe cachen og SAN eller den underliggende lagringsdisk til at arbejde sammen med hinanden som "efter behov", og delegerer skriver til enten deep storage eller cache afhængigt af disks arbejdsbelastning.

Designfilosofien for Writ-Back er en, der afspejler den problemløsning, som nutidens avancerede datahåndteringssystemer bringer store opgaver. Ved at oprette en mere kompleks arkitektur og bruge en cache på en kompleks måde ødelægger Writ-Back forsinkelsesproblemer, og selvom det muligvis kræver mere overhead, giver det mulighed for bedre systemvækst og færre voksensmerter.