javascript - Hur skiljer sig indexedDB konceptuellt från HTML5 local storage?

  1. Både indexedDB och lokal lagring är nyckel-värde-lagringssystem. Vad är fördelen med att ha två nyckel/värde-lagringssystem?
  2. indexedDB är asynkront, men joins (det mest tidskrävande) är manuella. De verkar köras i samma tråd som de asynkrona anropen gjordes. Hur kommer detta inte att blockera användargränssnittet?
  3. indexedDB tillåter ett större lagringsutrymme. Varför inte öka storleken på HTML5-lagret?
  4. Jag kliar mig på huvudet. Vad är poängen med indexedDB?

Svar #1

IndexedDB är inte ett nyckel-värde-lager på samma sätt som Local Storage är. Local Storage lagrar bara strängar, så för att lägga ett objekt i Local Storage är det vanliga sättet att använda JSON.stringify:

myObject = {a: 1, b: 2, c: 3};
localStorage.setItem("uniq", JSON.stringify(myObject));

Detta är bra för att hitta objektet med nyckeln uniq, men det enda sättet att få ut egenskaperna från myObject ur lokal lagring är att JSON.parse objektet och undersöka det:

var myStorageObject = JSON.parse(localStorage.getItem("uniq"));
window.alert(myStorageObject.b);

Detta är okej om du bara har ett, eller några objekt, i lokal lagring. Men tänk om du har tusen objekt, som alla har en egenskap b, och du vill göra något enbart med de där b==2. Med lokal lagring måste du loopa igenom hela lagret och kontrollera b på varje objekt, vilket blir mycket onödig bearbetning.

Med IndexedDB kan du lagra saker annat än strängar i värdet: "Detta inkluderar enkla typer såsom DOMString och Date samt instanser av Object och Array." Inte nog med det, du kan skapa index på egenskaper hos de objekt som du lagrat i värdet. Så med IndexedDB kan du lägga in samma tusen objekt i det men skapa ett index på b-egenskapen och använda det för att enbart hämta objekten där b==2 utan att behöva skanna varje objekt i lagret.

Åtminstone är det idén. IndexedDB-API:et är inte särskilt intuitivt.

De verkar köras i samma tråd som de asynkrona anropen gjordes. Hur kommer detta inte att blockera användargränssnittet?

Asynkron är inte samma sak som multitrådning, JavaScript är som regel inte multitrådat. All tung bearbetning du gör i JS kommer att blockera användargränssnittet; om du vill minimera blockeringen av användargränssnittet, försök med Web Workers.

indexedDB tillåter ett större lagringsutrymme. Varför inte öka storleken på HTML5-lagringen?

För utan korrekt indexering skulle det bli allt långsammare ju större det blev.

Svar #2

Jag stötte på denna bra artikel som diskuterar localstorage vs indexeddb och andra möjliga alternativ.

(alla nedanstående värden är i millisekunder)

https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/

Sammanfattningsvis från artikeln (endast författarens åsikter),

  1. I alla tre, Chrome, Firefox och Edge, blockerar LocalStorage DOM helt medan du skriver data 2. Blockeringen är mycket mer märkbar än med minneslagring, eftersom webbläsaren faktiskt måste skriva till disken.

  2. Inte förvånande, eftersom all synkron kod är blockerande, är även operationer i minnet blockerande. DOM blockeras under långvariga insättningar, men om du inte hanterar mycket data är det osannolikt att du märker det, eftersom operationer i minnet verkligen är snabba.

  3. I både Firefox och Chrome är IndexedDB långsammare än LocalStorage för grundläggande nyckel-värde-inmatningar, och det blockerar fortfarande DOM. Endast i Edge och Safari kan IndexedDB köras i bakgrunden utan att störa användargränssnittet, och irriterande nog är det de två webbläsarna som endast delvis implementerar IndexedDB-specifikationen.

  4. IndexedDB fungerar utmärkt i en webbworker, där det körs ungefär i samma hastighet men utan att blockera DOM. Det enda undantaget är Safari, som inte stödjer IndexedDB inuti en worker, men det blockerar fortfarande inte användargränssnittet.

  5. lokalt minne är idealiskt om data är enkel och minimal

Relaterade artiklar