2015-07-01 34 views
5

Obecnie eksperymentuję z localStorage, aby przechowywać dużą liczbę obiektów tego samego typu i jestem nieco zdezorientowany.Najlepsza praktyka korzystania z localstorage do przechowywania dużej ilości obiektów

Jednym ze sposobów myślenia jest przechowywanie całego obiektu w tablicy. Ale wtedy dla każdego odczytu/zapisu pojedynczego obiektu muszę deserializować/serializować całą tablicę.

Innym sposobem jest bezpośrednie przechowywanie każdego obiektu z jego kluczem w localStorage. Ułatwi to dostęp do każdego obiektu, ale martwię się ilością obiektów, które będą przechowywane (dziesiątki tysięcy). Ponadto, pobieranie wszystkich obiektów będzie wymagało iteracji całego localStorage!

Zastanawiam się, która droga będzie lepsza w twoim doświadczeniu? Czy warto byłoby wypróbować bardziej rozbudowaną bazę danych po stronie klienta, taką jak PouchDB?

+0

Czy jest szansa, że ​​Twój projekt może zebrać ponad 5 MB danych w trybie offline? Jeśli tak, to zdecydowanie potrzebujesz PouchDB i jego adapterów WebSQL i IndexedDB (nadal posiadasz opcję localStorage dla bardzo starych przeglądarek). –

+0

Jestem świadomy limitu 5 MB na localstorage. Jak na razie jest dobrze, więc nie martwię się tym zbytnio. PouchDB to zależność 100k + Nie chcę tego dodawać, jeśli to naprawdę pomoże. – Wudong

+0

Cóż, jeśli przestrzeń nie jest problemem, to dlaczego nie pójść do PouchDB i uniknąć wszystkiego, zastanawiasz się, jak przechowywać dane i jak je późno aktualizować. Pozwól, aby interfejs API PouchDB dbał o to zamiast Ciebie. Masz również bardzo dobre wsparcie dla mapowania/zmniejszania stylu CouchDB, a nawet wtyczek SQL, GQL i Mongo do pisania zapytań w stylu SQL, Google QL lub Mongo. Powodzenia –

Odpowiedz

1

Jeśli nie chcesz mieć dużo klawiszy, można:

  • concat wierszy JSONs z \n i przechowywać je w postaci pojedynczego klucza
  • kompilacji i zaktualizować indeks (-y) przechowywane w oddzielne klucze, z których każdy łączy jakiś klucz z konkretnym numerem wiersza.

W tym przypadku analiza wierszy to tylko .split('\n'), czyli o ~ 2 rzędy wielkości szybsza, a następnie JSON.parse.

Należy zauważyć, że do synchronizacji kilku otwartych kart prawdopodobnie potrzebny jest specjalny wysiłek. Może to stanowić wyzwanie w złożonych przypadkach.

localStorage ma zarówno dobre, jak i złe części.

Dobre części:

  • synchronicznych;
  • niezwykle szybko, zarówno odczytu i zapisu to tylko memcpy - to 100 + MB/s przepustowość nawet na słabych urządzeń (na przykład JSON.stringify jest na ogół 5-20 razy wolniej niż localStorage.setItem);
  • dokładnie przetestowane i niezawodne.

Bad news:

  • żadne transakcje, więc trzeba wysiłku inżynierii synchronizacji zakładek;
  • uważasz, że masz nie więcej niż 2Mb (ponieważ istnieją systemy z tym limitem);
  • 2 MB pamięci to właściwie 1M znaków, które można zapisać.

Te punkty pokazują granice możliwości stosowania localStorage jako bazy danych. LS jest dobry do zadań, w których potrzebujesz synchronizacji i szybkości oraz gdzie możesz przyciąć DB, aby zmieścić się w limicie.

Tak więc localStorage jest dobre dla pamięci podręcznych i dzienników. Nie więcej.

1

Osobiście nie użyłem localStorage do zarządzania tak wieloma elementami.

Jednak zazwyczaj używam do zarządzania danymi danych, aby załadować pełną bazę danych informacji do obiektu javascript, zarządzać nim w pamięci podczas procesu i zapisać go ponownie do localStorage po zakończeniu procesu.

Oczywiście ten wzór może nie być dobrym podejściem do potrzeb użytkownika, w zależności od specyfikacji projektu.

Jeśli zachodzi potrzeba ciągłego zapisywania danych, dostęp do danych może stać się problemem, a zatem prawdopodobnie lepszym rozwiązaniem będzie użycie jakiegoś małego dostępu do bazy danych.

Jeśli objętość danych jest wyjątkowo duża, może to być również problem z zarządzaniem nią w pamięci, jednak w zależności od modelu danych można go zbudować na wydajnych strukturach, które umożliwiają ładowanie i zapisywanie danych właśnie wtedy, gdy jest to potrzebne.

2

Jeśli chcesz czegoś prostego do przechowywania dużej ilości kluczy/wartości, a nie chcesz się martwić o typy, polecam LocalForage. Możesz przechowywać łańcuchy, liczby, tablice, obiekty, obiekty typu blob, cokolwiek chcesz. Używa IndexedDB i WebSQL tam, gdzie są dostępne, więc storage limits są znacznie wyższe niż LocalStorage.

PouchDB też działa, ale interfejs API jest bardziej złożony i lepiej nadaje się do synchronizacji danych z CouchDB na serwerze.