Чем indexedDB концептуально отличается от локального хранилища HTML5?


86
  1. И indexedDB, и локальное хранилище являются хранилищами ключевых значений. В чем преимущество наличия двух хранилищ ключей / значений?
  2. indexedDB является асинхронным, но соединения (что наиболее трудоемко) выполняются вручную. Похоже, что они выполняются в том же потоке, что и асинхронные вызовы. Как это не заблокирует пользовательский интерфейс?
  3. indexedDB позволяет хранить больше. Почему бы не увеличить размер магазина HTML5?
  4. Я чешу затылок. В чем смысл indexedDB?

Ответы:


115

IndexedDB не является хранилищем «ключ-значение» в отличие от локального хранилища. В локальном хранилище просто хранятся строки, поэтому для помещения объекта в локальное хранилище обычным подходом является JSON. Stringify его:

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

Это нормально для поиска объекта с ключом uniq, но единственный способ получить свойства myObject обратно из локального хранилища - это выполнить JSON.parse объекта и изучить его:

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

Это нормально, если у вас есть только один или несколько объектов в локальном хранилище. Но представьте, что у вас есть тысяча объектов, каждый из которых имеет свойство b, и вы хотите что-то сделать только с теми, где b==2. С локальным хранилищем вам придется перебрать весь магазин и проверитьb каждый элемент, что является большой потерей обработки.

С помощью IndexedDB вы можете хранить в значении не только строки, но и такие простые типы, как DOMString и Date, а также экземпляры Object и Array. Не только это, но вы можете создавать индексы для свойств объектов, которые вы сохранили в значении. Таким образом, с помощью IndexedDb вы можете поместить в него те же самые тысячи объектов, но создать индекс для bсвойства и использовать его, чтобы просто извлекать объекты b==2без накладных расходов на сканирование каждого объекта в магазине.

По крайней мере, идея такова. API IndexedDB не очень интуитивно понятен.

Похоже, что они выполняются в том же потоке, что и асинхронные вызовы. Как это не заблокирует пользовательский интерфейс?

Асинхронность - это не то же самое, что многопоточность, JavaScript, как правило, не является многопоточным . Любая тяжелая обработка, которую вы выполняете в JS, будет блокировать пользовательский интерфейс, если вы хотите минимизировать блокировку пользовательского интерфейса, попробуйте Web Workers .

indexedDB позволяет хранить больше. Почему бы не увеличить размер магазина HTML5?

Потому что без надлежащей индексации он становился бы тем медленнее, чем больше он становился.


2
Вы также можете проверить ответы на следующий вопрос о том, как IndexedDB поддерживает транзакции, а локальное хранилище -. Отсутствие поддержки транзакций может быть проблемой при доступе с несколькими вкладками / окнами к локальному хранилищу в браузерах, таких как Chrome и Opera, которые используют отдельный процесс / поток для каждой вкладки.
Стефан

Кроме того, indexeddb - это способ связи между веб-страницами и работающими на них работниками службы. localStorage недоступен для обслуживающего персонала.
Awol

API indexedDB наверняка не очень интуитивно понятен, но есть библиотека-оболочка, такая как Dexie , она упрощает работу
fengshuo

@robertc, вы сказали о обходе всех объектов, чтобы найти объект, где b == 2, зачем это нужно, когда у нас есть ключ, связанный с каждым элементом, который мы храним в localStorage?
Tinu Jos K

@ Tick20 Потому что невозможно использовать ключ, не получив объект, в котором он находится
robertc

8

Я наткнулся на эту хорошую статью, в которой обсуждают localstorage и indexeddb и другие возможные варианты.

(все значения ниже в миллисекундах)

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

сравнение памяти

Резюмируя из статьи (полностью авторские взгляды),

  1. Во всех трех версиях Chrome, Firefox и Edge LocalStorage полностью блокирует DOM, пока вы пишете данные 2. Блокировка намного более заметна, чем при хранении в памяти, поскольку браузер должен фактически сбрасывать данные на диск.
  2. Неудивительно, что, поскольку любой синхронный код блокируется, операции в памяти также блокируются. DOM блокируется во время длительных вставок, но, если вы не имеете дело с большим количеством данных, вы вряд ли заметите, потому что операции в памяти действительно быстрые.
  3. Как в Firefox, так и в Chrome, IndexedDB работает медленнее, чем LocalStorage для базовой вставки ключа и значения, и по-прежнему блокирует DOM. В Chrome он также медленнее, чем WebSQL, который блокирует DOM, но не так сильно. Только в Edge и Safari IndexedDB удается работать в фоновом режиме, не прерывая пользовательский интерфейс, и, что досадно, это два браузера, которые лишь частично реализуют спецификацию IndexedDB.

  4. IndexedDB отлично работает в веб-воркере, где он работает примерно с той же скоростью, но не блокирует DOM. Единственное исключение - Safari, который не поддерживает IndexedDB внутри воркера, но все же не блокирует пользовательский интерфейс.

  5. localmemory идеально подходит, если данные простые и минимальные


6

Добавив к anwser robertc, indexedDB знает «диапазоны», поэтому вы можете искать и извлекать все записи, которые начинаются с «ab» и заканчиваются abd », чтобы найти« abc »и т. Д.


0

Выполните следующее в консоли браузера. Будет создан отдельный объект в Application> Storage вместе с LocalStorage и SessionStorage.

const request = indexedDB.open("notes");
request.onupgradeneeded = e => {
  alert("upgrade");
}
request.onsuccess = e => {
  alert("success");
}
request.onerror = e => {
  alert("error");
}

Вы можете запрашивать это хранилище со всеми операциями CRUD, в отличие от двух других хранилищ, которые имеют меньшую гибкость и функции, с которыми можно играть.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.