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

  • Оба индексированных DB и локального хранилища являются хранилищами ключевых значений. Что это преимущество наличия двух хранилищ ключей/значений?
  • indexedDB является асинхронным, но присоединяется (самая трудоемкая вещь)   являются ручными. Кажется, что они работают в том же потоке, что и вызовы async   был сделан. Как это не заблокирует пользовательский интерфейс?
  • indexedDB позволяет увеличить объем хранилища. Почему бы не увеличить размер       Магазин HTML5?
  • Я почесываю голову. Что такое indexedDB?

Ответ 1

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

Добавляя к anwser robertc, indexedDB знает "диапазоны", чтобы вы могли искать и извлекать все записи, начинающиеся с "ab" и заканчивая abd, чтобы найти "abc" и т.д.

Ответ 3

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

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

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

memory comparison

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

  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 идеально подходит, если данные просты и минимальны

Ответ 4

Запустите следующее в консоли браузера. Это создаст отдельную сущность в 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 в отличие от двух других хранилищ, которые имеют меньшую гибкость и функции для работы.