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

Question 1

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

Question 2

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 차단을 최소화하려면 Web Workers를 사용해보십시오 .

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

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

Question 3

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

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

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

기사에서 요약하면 (전체 저자의 견해),

Chrome, Firefox 및 Edge의 세 가지 모두에서 LocalStorage는 데이터를 쓰는 동안 DOM을 완전히 차단합니다. 2. 차단은 브라우저가 실제로 디스크에 플러시해야하므로 인 메모리보다 훨씬 더 눈에 띕니다.
당연히 모든 동기 코드가 차단되므로 메모리 내 작업도 차단됩니다. 장기 실행 삽입 중에 DOM 블록이 발생하지만 많은 데이터를 처리하지 않는 한 인 메모리 작업이 정말 빠르기 때문에 눈치 채지 못할 것입니다.
Firefox와 Chrome 모두에서 IndexedDB는 기본 키-값 삽입에 대해 LocalStorage보다 느리며 여전히 DOM을 차단합니다. Chrome에서는 DOM을 차단하는 WebSQL보다 느리지 만 그다지 많지는 않습니다. Edge와 Safari에서만 IndexedDB가 UI를 중단하지 않고 백그라운드에서 실행되도록 관리하며, 이는 IndexedDB 사양을 부분적으로 만 구현하는 두 브라우저입니다.
IndexedDB는 거의 동일한 속도로 DOM을 차단하지 않고 실행되는 웹 워커에서 잘 작동합니다. 유일한 예외는 Safari로, 작업자 내부에서 IndexedDB를 지원하지 않지만 여전히 UI를 차단하지 않습니다.
localmemory는 데이터가 단순하고 최소 인 경우 이상적입니다.

Question 4

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

Question 5

브라우저 콘솔에서 다음을 실행합니다. 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 작업으로이 저장소를 쿼리 할 수 있습니다.