indexedDB는 HTML5 로컬 저장소와 개념적으로 어떻게 다른가요?

indexedDB는 HTML5 로컬 저장소와 개념적으로 어떻게 다른가요?

---

1. indexedDB와 로컬 저장소는 모두 키 값 저장소입니다. 두 개의 키 / 값 저장소가 있으면 어떤 이점이 있습니까?
2. indexedDB는 비동기식이지만 조인 (가장 시간이 많이 걸리는 작업)은 수동입니다. 비동기 호출이 수행 된 것과 동일한 스레드에서 실행되는 것으로 보입니다. 이것이 UI를 차단하지 않는 방법은 무엇입니까?
3. indexedDB는 더 큰 저장소를 허용합니다. HTML5 스토어의 크기를 늘리는 것은 어떻습니까?
4. 머리를 긁적입니다. indexedDB의 요점은 무엇입니까?

---

IndexedDB는 로컬 저장소와 같은 방식으로 키-값 저장소가 아닙니다. 로컬 저장소는 문자열 만 저장하므로 개체를 로컬 저장소에 넣는 일반적인 방법은 JSON.stringify 하는 것입니다.

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

이것은 key로 객체를 찾는 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하여 저장소의 모든 개체를 검색하는 오버 헤드없이 개체를 검색 할 수 있습니다.

적어도 그 아이디어입니다. IndexedDB API는 그다지 직관적이지 않습니다.

비동기 호출이 수행 된 것과 동일한 스레드에서 실행되는 것으로 보입니다. 이것이 UI를 차단하지 않는 방법은 무엇입니까?

비동기식은 다중 스레드와 동일하지 않으며, JavaScript는 일반적으로 다중 스레드가 아닙니다 . JS에서 무거운 처리를하면 UI가 차단됩니다. UI 차단을 최소화하려면 Web Workers를 사용 해보세요 .

indexedDB는 더 큰 저장소를 허용합니다. HTML5 스토어의 크기를 늘리는 것은 어떻습니까?

적절한 인덱싱이 없으면 크기가 커질수록 점점 느려질 것입니다.

---

robertc의 anwser에 추가하면 indexedDB는 '범위'를 알고 있으므로 'ab'로 시작하고 abd '로 끝나는 모든 레코드를 검색하고 검색하여'abc '등을 찾을 수 있습니다.

---

나는 localstorage 대 indexeddb 및 기타 가능한 옵션에 대해 논의하는이 좋은 기사를 보았습니다.

(아래의 모든 값은 밀리 초 단위입니다.)

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

---

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

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

유연성과 기능이 낮은 다른 두 저장소와 달리 모든 CRUD 작업으로이 저장소를 쿼리 할 수 ​​있습니다.

참고 URL : https://stackoverflow.com/questions/5924485/how-is-indexeddb-conceptually-different-from-html5-local-storage