javascript indexedDB 在概念上与 HTML5 本地存储有何不同？

How is indexedDB conceptually different from HTML5 local storage?

提问by Samuel Danielson

1. Both indexedDB and local storage are key value stores. What is the advantage of having two key/value stores?
2. indexedDB is asynchronous, but joins (the most time-consuming thing) are manual. They appear to run in the same thread as the async calls were made. How will this not block the UI?
3. indexedDB allows a larger store. Why not increase the size of the HTML5 store?
4. I'm scratching my head. What is the point of indexedDB?

1. indexedDB 和本地存储都是键值存储。有两个键/值存储有什么好处？
2. indexedDB 是异步的，但连接（最耗时的事情）是手动的。它们似乎与进行异步调用的线程在同一线程中运行。这如何不会阻止用户界面？
3. indexedDB 允许更大的存储。为什么不增加 HTML5 商店的大小？
4. 我在挠头。indexedDB 的重点是什么？

回答by robertc

IndexedDB is not a key-value store in the same way that Local Storage is. Local storage just stores strings, so to put an object in local storage the usual approach is to JSON.stringifyit:

IndexedDB 不像本地存储那样是键值存储。本地存储只存储字符串，因此要将对象放在本地存储中，通常的方法是JSON.stringify它：

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

This is fine for finding the object with key uniq, but the only way to get the properties of myObject back out of local storage is to JSON.parse the object and examine it:

这对于使用 key 查找对象很好uniq，但从本地存储中获取 myObject 属性的唯一方法是 JSON.parse 对象并检查它：

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

This is fine if you only have one, or a few objects, in local storage. But imagine you have a thousand objects, all of which have a property b, and you want to do something just with those ones where b==2. With local storage you'll have to loop through the entire store and check bon each item, which is a lot of wasted processing.

如果本地存储中只有一个或几个对象，这很好。但是想象一下，您有一千个对象，所有这些对象都有一个属性b，而您只想对那些b==2. 使用本地存储，您必须遍历整个存储并检查b每个项目，这是大量浪费的处理。

With IndexedDB you can store stuff other than strings in the value: "This includes simple types such as DOMString and Date as well as Object and Array instances." Not only that, but you can create indexeson properties of the objects that you stored in the value. So with IndexedDb you can put those same thousand objects in it but create an index on the bproperty and use that to just retrieve the objects where b==2without the overhead of scanning every object in the store.

使用 IndexedDB，您可以在值中存储字符串以外的内容：“这包括简单类型，例如 DOMString 和 Date 以及 Object 和 Array 实例。” 不仅如此，您还可以为存储在值中的对象的属性创建索引。因此，使用 IndexedDb，您可以将那些相同的一千个对象放入其中，但在该b属性上创建一个索引，并使用它来检索对象，b==2而无需扫描存储中的每个对象。

At least that's the idea. The IndexedDB API isn't very intuitive.

至少是这个想法。IndexedDB API 不是很直观。

They appear to run in the same thread as the async calls were made. How will this not block the UI?

它们似乎与进行异步调用的线程在同一线程中运行。这如何不会阻止用户界面？

Asynchronous is not the same thing as multi-threaded, JavaScript, as a rule, is not multi-threaded. Any heavy processing you do in JS will block the UI, if you want to minimize blocking the UI try Web Workers.

异步与多线程不同，JavaScript 通常不是多线程的。你在 JS 中做的任何繁重的处理都会阻塞 UI，如果你想最小化 UI 阻塞，请尝试Web Workers。

indexedDB allows a larger store. Why not increase the size of the HTML5 store?

indexedDB 允许更大的存储。为什么不增加 HTML5 商店的大小？

Because, without proper indexing, it would get increasingly slower the larger it got.

因为，如果没有适当的索引，它会变得越大越慢。

回答by Johan

Adding to the anwser of robertc, indexedDB knows 'ranges' so you can search and retrieve all records that start with 'ab' and end with abd' to find 'abc' etc.

添加到 robertc 的 anwser，indexedDB 知道 'ranges'，因此您可以搜索和检索所有以 'ab' 开头并以 abd' 结尾的记录以查找 'abc' 等。

回答by Amruta-Pani

I came across this good article discussing about localstorage vs indexeddb and other possible options.

我看到了这篇很好的文章，讨论了 localstorage 与 indexeddb 以及其他可能的选项。

(all the below values are in milliseconds)

（以下所有值均以毫秒为单位）

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

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

To summarize from the article (entirely author's views),

总结文章（完全是作者的观点），

1. In all three of Chrome, Firefox, and Edge, LocalStorage fully blocks the DOM while you're writing data 2. The blocking is a lot more noticeable than with in-memory, since the browser has to actually flush to disk.
2. Not surprisingly, since any synchronous code is blocking, in-memory operations are also blocking. The DOM blocks during long-running inserts, but unless you're dealing with a lot of data, you're unlikely to notice, because in-memory operations are really fast.

3. In both Firefox and Chrome, IndexedDB is slower than LocalStorage for basic key-value insertions, and it still blocks the DOM. In Chrome, it's also slower than WebSQL, which does blocks the DOM, but not nearly as much. Only in Edge and Safari does IndexedDB manage to run in the background without interrupting the UI, and aggravatingly, those are the two browsers that only partially implement the IndexedDB spec.

4. IndexedDB works swimmingly well in a web worker, where it runs at roughly the same speed but without blocking the DOM. The only exception is Safari, which doesn't support IndexedDB inside a worker, but still it doesnt block the UI.

5. localmemory is ideal if data is simple and minimal

1. 在 Chrome、Firefox 和 Edge 的所有三个中，LocalStorage 在您写入数据时完全阻塞 DOM 2。阻塞比在内存中更明显，因为浏览器实际上必须刷新到磁盘。
2. 毫不奇怪，因为任何同步代码都是阻塞的，所以内存中的操作也会阻塞。DOM 在长时间运行的插入过程中会阻塞，但除非您正在处理大量数据，否则您不太可能注意到，因为内存操作非常快。

3. 在 Firefox 和 Chrome 中，IndexedDB 在基本键值插入方面比 LocalStorage 慢，并且它仍然阻塞 DOM。在 Chrome 中，它也比阻止 DOM 的 WebSQL 慢，但几乎没有那么多。只有在 Edge 和 Safari 中，IndexedDB 才能够在不中断 UI 的情况下在后台运行，更糟糕的是，这两个浏览器仅部分实现了 IndexedDB 规范。

4. IndexedDB 在 Web Worker 中运行良好，它以大致相同的速度运行，但不会阻塞 DOM。唯一的例外是 Safari，它不支持 worker 内部的 IndexedDB，但它仍然不会阻止 UI。

5. 如果数据简单且最少，localmemory 是理想的选择

回答by Amruta-Pani

Run the following in console of browser. It will create a separate entity in Application > Storage alongside LocalStorage and SessionStorage

在浏览器的控制台中运行以下命令。它将在 Application > Storage 中与 LocalStorage 和 SessionStorage 一起创建一个单独的实体

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

You can query this Storage with all CRUD operations unlike other two storages that has lesser flexibility and functions to play with.

您可以使用所有 CRUD 操作来查询此存储，这与其他两个存储的灵活性和可玩性较差的存储不同。