In che modo localStorage è diverso da indexedDB?


108

localStorage e indexedDB sono utilizzati per l'archiviazione offline dei dati in HTML5. Quali sono le loro differenze chiave e quale è preferibile in quali situazioni?


16
Elettori vicini: anche se capisco perfettamente come questo sia sembrato "principalmente basato sull'opinione" (il "vs" nella versione originale non ha aiutato), le due tecnologie sono nettamente diverse e ci sono ragioni obiettive per scegliere l'una rispetto all'altra. user221287 facendo qualche minima ricerca preliminare sull'argomento della domanda e ottenendo una comprensione di base dei concetti coinvolti prima di porre la domanda, molto probabilmente ti salverà da voti negativi e voti stretti in futuro.
yannis,

Puoi testare le prestazioni tra le diverse opzioni di archiviazione e attraverso i browser qui: nolanlawson.github.io/database-comparison (crediti a Nolan Lawson)
Lucas Basquerotto,

Risposte:


121

In apparenza le due tecnologie possono sembrare direttamente comparabili, ma se passi del tempo con loro ti accorgerai presto che non lo sono. Sono stati progettati per raggiungere un obiettivo simile, l'archiviazione lato client, ma affrontano l'attività a portata di mano da prospettive significativamente diverse e funzionano meglio con diverse quantità di dati.

localStorage, o più precisamente Web Storage , è stato progettato per piccole quantità di dati. È essenzialmente un archivio di chiavi-valore-chiave , con un'API sincrona semplicistica . L'ultima parte è la chiave. Sebbene non ci sia nulla nelle specifiche che proibisca un DOM storage asincrono, attualmente tutte le implementazioni sono sincrone (cioè richieste di blocco). Anche se non ti dispiace usare una chiave ingenua - valore di archiviazione per grandi quantità di dati, i tuoi clienti resteranno in attesa per sempre di caricare l'applicazione.

indexedDB , d'altra parte, è stato progettato per funzionare con quantità di dati significativamente maggiori. In primo luogo, in teoria, fornisce un'API sia sincrona che asincrona. In pratica, tuttavia, tutte le implementazioni correnti sono asincrone e le richieste non bloccano il caricamento dell'interfaccia utente. Inoltre, indexedDB, come rivela il nome, fornisce indici . È possibile eseguire query rudimentali sul database e recuperare i record cercando le loro chiavi in intervalli di chiavi specifici . indexedDB supporta anche le transazioni e fornisce tipi semplici (ad es. Data).

A questo punto, indicizzato DB potrebbe sembrare la soluzione superiore per ogni situazione di sempre. Tuttavia, c'è una penalità per tutte le sue funzionalità: rispetto all'archiviazione DOM, la sua API è piuttosto complicata. indexedDB assume una familiarità generale con i concetti del database, mentre con Web Storage puoi entrare subito. Se hai mai lavorato con i cookie, non avrai problemi a lavorare con Web Storage. Inoltre, in generale dovrai scrivere più codice in indexedDB per ottenere esattamente lo stesso risultato di Web Storage (e più codice = più bug). Inoltre, emulare l'archiviazione Web per i browser che non la supportano è relativamente semplice. Con indexedDB, l'attività non varrebbe la pena. Infine, prima di immergerti in IndexedDB, dovresti prima dare un'occhiata all'API Quota .

Alla fine della giornata, dipende completamente da te se usi Web Storage o IndexedDB, o entrambi, nella tua applicazione. Un buon caso d'uso per l'archiviazione Web potrebbe essere la memorizzazione di semplici dati di sessione, ad esempio il nome di un utente, e il salvataggio di alcune richieste nel database effettivo. Le funzionalità aggiuntive di indexedDB, d'altra parte, potrebbero aiutarti a archiviare tutti i dati necessari affinché la tua applicazione funzioni offline.


15
Inoltre, IndexedDB è supportato solo da browser recenti : IE 10+, Chrome 23+, Firefox 10+, Opera 15+ e Android 4.4+.
David Harkness,

1
@yannis, c'è qualche differenza tra l'archiviazione DOM e l'archiviazione Web?
SandroMarques,

Sembrano essere gli stessi. en.wikipedia.org/wiki/Web_storage
Lawliet,

Anche gli addetti alla manutenzione possono utilizzare IndexDDB ma non localStorage
Fabich

10

La risposta di @yannis è eccellente. Voglio solo aggiungere un paio di cose.

  1. In alcune situazioni, come Service Workers, non è possibile utilizzare il codice di blocco, quindi non è possibile utilizzare localStorage e è necessario utilizzare qualcosa come indexedDB.

  2. L'API per indexedDB è complessa e noiosa (arriverei al punto di dire "orribile", YMMV). Esistono diverse librerie "wrapper" per semplificare l'API, ti consiglio vivamente di esaminarle.


non puoi usare localStorage e il codice di blocco, non potresti racchiudere il codice di blocco con una Promessa e renderlo non bloccante?
Joedotnot,

3

Per quanto mi riguarda, ho scoperto che posso archiviare blob in IndexedDB mentre in localStorage posso memorizzare solo le stringhe. Significa che IndexdDB è migliore per i dati binari come immagini, audio, video. Sì, possiamo archiviare le immagini in base64 nel localStorage, ma i BLOB saranno più piccoli e più veloci perché non è necessario decodificarli.

Citazione da MDN :

The keys and the values are always strings.

Informazioni su IndexedDB :

Any objects supported by the structured clone algorithm can be stored:  
All primitive types However not symbols
Boolean object   
String object    
Date     
RegExp  The lastIndex field is not preserved.
Blob     
File     
FileList     
ArrayBuffer  
ArrayBufferView This basically means all typed arrays like Int32Array etc.
ImageData    
Array    
Object  This just includes plain objects (e.g. from object literals)
Map  
Set

È? Cosa dice la documentazione a riguardo?
Mael,

Siamo spiacenti, sono stati aggiunti riferimenti alla documentazione.
Vitaly Zdanevich,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.