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?
Потому что без надлежащей индексации он становился бы тем медленнее, чем больше он становился.
Я наткнулся на эту хорошую статью, в которой обсуждают localstorage и indexeddb и другие возможные варианты.
(все значения ниже в миллисекундах)
https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/
Резюмируя из статьи (полностью авторские взгляды),
Как в Firefox, так и в Chrome, IndexedDB работает медленнее, чем LocalStorage для базовой вставки ключа и значения, и по-прежнему блокирует DOM. В Chrome он также медленнее, чем WebSQL, который блокирует DOM, но не так сильно. Только в Edge и Safari IndexedDB удается работать в фоновом режиме, не прерывая пользовательский интерфейс, и, что досадно, это два браузера, которые лишь частично реализуют спецификацию IndexedDB.
IndexedDB отлично работает в веб-воркере, где он работает примерно с той же скоростью, но не блокирует DOM. Единственное исключение - Safari, который не поддерживает IndexedDB внутри воркера, но все же не блокирует пользовательский интерфейс.
localmemory идеально подходит, если данные простые и минимальные
источник
Добавив к anwser robertc, indexedDB знает «диапазоны», поэтому вы можете искать и извлекать все записи, которые начинаются с «ab» и заканчиваются abd », чтобы найти« abc »и т. Д.
источник
Выполните следующее в консоли браузера. Будет создан отдельный объект в 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, в отличие от двух других хранилищ, которые имеют меньшую гибкость и функции, с которыми можно играть.
источник