Wie unterscheidet sich indexedDB konzeptionell vom lokalen HTML5-Speicher?

1. Sowohl die indizierte Datenbank als auch der lokale Speicher sind Schlüsselwertspeicher. Was ist der Vorteil von zwei Schlüssel- / Wertspeichern?
2. indexedDB ist asynchron, aber Joins (die zeitaufwändigste Sache) sind manuell. Sie scheinen im selben Thread zu laufen wie die asynchronen Aufrufe. Wie wird dies die Benutzeroberfläche nicht blockieren?
3. indexedDB ermöglicht einen größeren Speicher. Warum nicht den HTML5-Store vergrößern?
4. Ich kratzte mir am Kopf. Was ist der Sinn von indexedDB?

IndexedDB ist kein Schlüsselwertspeicher wie Local Storage. Im lokalen Speicher werden nur Zeichenfolgen gespeichert. Um ein Objekt in den lokalen Speicher zu verschieben , wird normalerweise JSON.stringify verwendet :

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

Dies ist in Ordnung, um das Objekt mit dem Schlüssel zu uniqfinden. Die einzige Möglichkeit, die Eigenschaften von myObject aus dem lokalen Speicher wiederherzustellen, besteht darin, das Objekt mit JSON.parse zu untersuchen und zu untersuchen:

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

Dies ist in Ordnung, wenn Sie nur ein oder mehrere Objekte im lokalen Speicher haben. Aber stellen Sie sich vor, Sie haben tausend Objekte, die alle eine Eigenschaft haben b, und Sie möchten etwas nur mit denen tun, bei denen b==2. Bei lokalem Speicher müssen Sie den gesamten Speicher durchlaufen und bjeden Artikel überprüfen , was eine Menge verschwendeter Verarbeitung bedeutet.

Mit IndexedDB können Sie andere Dinge als Zeichenfolgen im Wert speichern : "Dies umfasst einfache Typen wie DOMString und Date sowie Objekt- und Array-Instanzen." Darüber hinaus können Sie Indizes für Eigenschaften der Objekte erstellen , die Sie im Wert gespeichert haben. Mit IndexedDb können Sie also dieselben tausend Objekte einfügen, aber einen Index für die bEigenschaft erstellen und damit nur die Objekte abrufen, bei denen b==2nicht jedes Objekt im Geschäft gescannt werden muss.

Zumindest ist das die Idee. Die IndexedDB-API ist nicht sehr intuitiv.

Sie scheinen im selben Thread zu laufen wie die asynchronen Aufrufe. Wie wird dies die Benutzeroberfläche nicht blockieren?

Asynchron ist nicht dasselbe wie Multithreading, JavaScript ist in der Regel kein Multithreading . Jede schwere Verarbeitung, die Sie in JS ausführen, blockiert die Benutzeroberfläche. Wenn Sie die Blockierung der Benutzeroberfläche minimieren möchten, versuchen Sie es mit Web Workers .

indexedDB ermöglicht einen größeren Speicher. Warum nicht den HTML5-Store vergrößern?

Denn ohne ordnungsgemäße Indizierung würde es mit zunehmender Größe immer langsamer werden.

Ich bin auf diesen guten Artikel gestoßen, in dem es um localstorage vs indexeddb und andere mögliche Optionen ging.

(Alle folgenden Werte sind in Millisekunden angegeben.)

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

Um aus dem Artikel zusammenzufassen (vollständig die Ansichten des Autors),

1. In allen drei Versionen von Chrome, Firefox und Edge blockiert LocalStorage das DOM vollständig, während Sie Daten 2 schreiben. Die Blockierung ist viel deutlicher als bei In-Memory, da der Browser tatsächlich auf die Festplatte leeren muss.
2. Es ist nicht überraschend, dass speicherinterne Operationen ebenfalls blockieren, da jeder synchrone Code blockiert. Das DOM wird während lang laufender Einfügungen blockiert. Wenn Sie jedoch nicht mit vielen Daten arbeiten, ist es unwahrscheinlich, dass Sie dies bemerken, da In-Memory-Vorgänge sehr schnell sind.

3. Sowohl in Firefox als auch in Chrome ist IndexedDB langsamer als LocalStorage für grundlegende Schlüsselwerteinfügungen und blockiert weiterhin das DOM. In Chrome ist es auch langsamer als WebSQL, das das DOM blockiert, aber bei weitem nicht so stark. Nur in Edge und Safari kann IndexedDB im Hintergrund ausgeführt werden, ohne die Benutzeroberfläche zu unterbrechen. Erschwerend kommt hinzu, dass dies die beiden Browser sind, die die IndexedDB-Spezifikation nur teilweise implementieren.

4. IndexedDB funktioniert in einem Web-Worker sehr gut, wo es ungefähr mit der gleichen Geschwindigkeit ausgeführt wird, ohne jedoch das DOM zu blockieren. Die einzige Ausnahme ist Safari, das IndexedDB in einem Worker nicht unterstützt, die Benutzeroberfläche jedoch nicht blockiert.

5. localmemory ist ideal, wenn die Daten einfach und minimal sind

IndexedDB ergänzt die Antwort von robertc und kennt "Bereiche", sodass Sie alle Datensätze suchen und abrufen können, die mit "ab" beginnen und mit "abd" enden, um "abc" usw. zu finden.

Führen Sie Folgendes in der Konsole des Browsers aus. Neben ApplicationStorage und SessionStorage wird unter Anwendung> Speicher eine separate Entität erstellt

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

Sie können diesen Speicher mit allen CRUD-Vorgängen abfragen, im Gegensatz zu anderen zwei Speichern, die weniger Flexibilität und Funktionen zum Spielen bieten.