Czym różni się localStorage od indexedDB?


108

localStorage i indexedDB służą do przechowywania danych offline w HTML5. Jakie są ich główne różnice i która z nich jest lepsza w jakich sytuacjach?


16
Bliscy wyborcy: chociaż całkowicie rozumiem, jak to wydawało się „oparte głównie na opiniach” („vs” w oryginalnej wersji nie pomogło), obie technologie są wyraźnie różne i istnieją obiektywne powody, aby wybrać jedną z nich. użytkownik221287 przeprowadzający minimalne badania w temacie pytania i zrozumienie podstawowych pojęć, zanim o to zapytasz, najprawdopodobniej uchroni cię od negatywnych opinii i bliskich głosów w przyszłości.
yannis

Możesz przetestować wydajność w różnych opcjach przechowywania i w różnych przeglądarkach tutaj: nolanlawson.github.io/database-comparison ( podziękowania dla Nolana Lawsona)
Lucas Basquerotto

Odpowiedzi:


121

Na pozór te dwie technologie mogą wydawać się bezpośrednio porównywalne, jednak jeśli poświęcisz im trochę czasu, wkrótce zrozumiesz, że nie są. Zostały zaprojektowane tak, aby osiągnąć podobny cel - pamięć po stronie klienta, ale podchodzą do zadania z bardzo różnych perspektyw i najlepiej pracują z różnymi ilościami danych.

localStorage, a ściślej mówiąc Web Storage , został zaprojektowany dla mniejszych ilości danych. Zasadniczo jest to pamięć zawierająca tylko ciągi znaków z uproszczonym synchronicznym interfejsem API. Ta ostatnia część jest kluczowa. Mimo że w specyfikacji nie ma niczego, co zabrania asynchronicznego przechowywania DOM, obecnie wszystkie implementacje są synchroniczne (tj. Blokują żądania). Nawet jeśli nie masz nic przeciwko użyciu naiwnego magazynu wartości klucza dla większych ilości danych, Twoi klienci będą musieli czekać wiecznie na załadowanie aplikacji.

Z drugiej strony indexedDB został zaprojektowany do pracy ze znacznie większymi ilościami danych. Po pierwsze teoretycznie zapewnia zarówno synchroniczny, jak i asynchroniczny interfejs API. W praktyce jednak wszystkie bieżące implementacje są asynchroniczne, a żądania nie blokują ładowania interfejsu użytkownika. Dodatkowo indexedDB, jak sama nazwa wskazuje, zapewnia indeksy . Możesz uruchamiać podstawowe zapytania w bazie danych i pobierać rekordy, wyszukując ich klucze w określonych zakresach kluczy . indexedDB obsługuje również transakcje i zapewnia proste typy (np. Data).

W tym momencie indexedDB może wydawać się najlepszym rozwiązaniem w każdej sytuacji. Istnieje jednak kara za wszystkie jego funkcje: w porównaniu z DOM Storage jego interfejs API jest dość skomplikowany. indexedDB zakłada ogólną znajomość koncepcji baz danych, podczas gdy dzięki Web Storage możesz od razu wskoczyć. Jeśli kiedykolwiek pracowałeś z plikami cookie, nie będziesz miał problemu z pracą z Web Storage. Ponadto, ogólnie rzecz biorąc, musisz napisać więcej kodu w indexedDB, aby osiągnąć dokładnie taki sam wynik jak w Web Storage (i więcej kodu = więcej błędów). Ponadto emulowanie magazynu internetowego dla przeglądarek, które go nie obsługują, jest stosunkowo proste. W przypadku indexedDB zadanie nie byłoby warte czasu. Na koniec, zanim zanurzysz się w indexedDB, powinieneś najpierw spojrzeć na API Quota .

Ostatecznie, to zależy od Ciebie, czy w swojej aplikacji korzystasz z Web Storage, indexedDB lub obu. Dobrym przykładem zastosowania do przechowywania danych w sieci byłoby przechowywanie prostych danych sesji, na przykład nazwy użytkownika i zapisywanie niektórych żądań do faktycznej bazy danych. Z drugiej strony dodatkowe funkcje indexedDB mogą pomóc w przechowywaniu wszystkich danych potrzebnych do działania aplikacji w trybie offline.


15
Ponadto IndexedDB jest obsługiwany tylko przez najnowsze przeglądarki : IE 10+, Chrome 23+, Firefox 10+, Opera 15+ i Android 4.4+.
David Harkness

1
@yannis, czy jest jakaś różnica między pamięcią DOM a pamięcią internetową?
SandroMarques,

Wydają się być takie same. en.wikipedia.org/wiki/Web_storage
Lawliet

Również pracownicy usług mogą korzystać z indexedDB, ale nie localStorage
Fabich

9

Odpowiedź @yannis jest doskonała. Po prostu chcę dodać kilka rzeczy.

  1. W kilku sytuacjach, takich jak pracownicy serwisowi, nie można użyć kodu blokującego, dlatego nie można użyć localStorage i należy użyć czegoś takiego jak indexedDB.

  2. Interfejs API dla indexedDB jest złożony i żmudny (posunąłbym się do stwierdzenia „przerażający”, YMMV). Istnieje kilka bibliotek „otokowych” w celu uproszczenia interfejsu API, zdecydowanie sugeruję, aby na nie spojrzeć.


ponownie nie możesz użyć localStorage i kodu blokującego, czy nie możesz owinąć kodu blokującego Obietnicą i sprawić, by nie był blokowany?
joedotnot

3

Dla mnie odkryłem, że mogę przechowywać obiekty BLOB w IndexedDB, natomiast w localStorage mogę przechowywać tylko ciągi znaków. Oznacza to, że IndexdDB jest lepszy dla danych binarnych, takich jak obrazy, audio, wideo. Tak, możemy przechowywać obrazy w base64 w localStorage, ale obiekty BLOB będą mniejsze i szybsze, ponieważ nie musimy ich dekodować.

Cytat z MDN :

The keys and the values are always strings.

Informacje na temat 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

Czy to jest Co na ten temat mówi dokumentacja?
Mael

Przepraszamy, dodano odniesienia do dokumentacji.
Witalij Zdanewicz
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.