En quoi l'indexedDB est-il conceptuellement différent du stockage local HTML5 ?

Question

1. La base de données indexée et le stockage local sont tous deux des magasins de valeurs clés. Quel est l'avantage avantage d'avoir deux magasins clés/valeurs ?
2. La base de données indexée est asynchrone, mais les jointures (la chose qui prend le plus de temps) sont manuelles. Elles semblent s'exécuter dans le même thread que celui dans lequel les appels asynchrones ont été effectués. Comment faire pour que cela ne bloque pas l'interface utilisateur ?
3. indexedDB permet un stockage plus important. Pourquoi ne pas augmenter la taille du magasin HTML5 ?
4. Je me gratte la tête. Quel est l'intérêt de la base de données indexée ?

Answer 1

IndexedDB n'est pas un key-value store comme l'est le stockage local. Le stockage local ne stocke que des chaînes de caractères, donc pour placer un objet dans le stockage local, l'approche habituelle est de JSON.stringify il :

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

C'est parfait pour trouver l'objet avec la clé uniq mais le seul moyen de récupérer les propriétés de monObjet à partir du stockage local est d'analyser l'objet en JSON et de l'examiner :

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

Cela convient si vous n'avez qu'un seul ou quelques objets dans le stockage local. Mais imaginez que vous ayez un millier d'objets, qui ont tous une propriété b et vous voulez faire quelque chose juste avec ceux-là. b==2 . Avec le stockage local, vous devrez faire une boucle dans tout le magasin et vérifier b sur chaque élément, ce qui représente beaucoup de traitement gaspillé.

Avec IndexedDB, vous pouvez stocker des éléments autres que des chaînes de caractères dans la valeur : "Cela inclut des types simples tels que DOMString et Date ainsi que des instances d'objets et de tableaux." Non seulement cela, mais vous pouvez créer des index sur les propriétés des objets que vous avez stockés dans la valeur. Ainsi, avec IndexedDb, vous pouvez placer ces mêmes milliers d'objets dans la base, mais en créant un index sur l'objet b et l'utiliser pour récupérer les objets dans lesquels b==2 sans avoir à scanner chaque objet du magasin.

Du moins, c'est l'idée. L'API IndexedDB n'est pas très intuitive.

Ils semblent s'exécuter dans le même thread que celui où les appels asynchrones ont été effectués. Comment cela ne va-t-il pas bloquer l'interface utilisateur ?

Asynchrone n'est pas synonyme de multithreading, JavaScript, en règle générale, n'est pas multithreadé. . Tout traitement lourd que vous effectuez en JS bloquera l'interface utilisateur, si vous voulez minimiser le blocage de l'interface utilisateur, essayez de Travailleurs du Web .

indexedDB permet un stockage plus important. Pourquoi ne pas augmenter la taille du magasin HTML5 ?

Parce que, sans une indexation appropriée, il serait de plus en plus lent au fur et à mesure qu'il s'agrandirait.

Answer 2

Je suis tombé sur ce bon article qui traite du stockage local par rapport à la base de données indexée et des autres options possibles.

(toutes les valeurs ci-dessous sont en millisecondes)

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

Pour résumer l'article (entièrement l'avis de l'auteur),

1. Dans les trois versions de Chrome, Firefox et Edge, LocalStorage bloque entièrement le DOM pendant l'écriture des données 2. Le blocage est beaucoup plus perceptible qu'avec l'écriture en mémoire, puisque le navigateur doit effectivement effectuer un vidage sur le disque.

2. Il n'est pas surprenant que, puisque tout code synchrone est bloquant, les opérations en mémoire le sont également. Le DOM se bloque pendant les longues insertions, mais à moins que vous ne traitiez beaucoup de données, il est peu probable que vous le remarquiez, car les opérations en mémoire sont vraiment rapides.

3. Dans Firefox et Chrome, IndexedDB est plus lent que LocalStorage pour les insertions de base clé-valeur, et il bloque toujours le DOM. Dans Chrome, elle est également plus lente que WebSQL, qui bloque également le DOM, mais pas autant. Ce n'est que dans Edge et Safari qu'IndexedDB parvient à s'exécuter en arrière-plan sans interrompre l'interface utilisateur et, fait aggravant, ce sont les deux navigateurs qui n'implémentent que partiellement la spécification d'IndexedDB.

4. IndexedDB fonctionne très bien dans un web worker, où il fonctionne à peu près à la même vitesse mais sans bloquer le DOM. La seule exception est Safari, qui ne supporte pas IndexedDB dans un worker, mais qui ne bloque pas l'interface utilisateur.

5. La mémoire locale est idéale si les données sont simples et minimales.

Answer 3

Pour compléter la réponse de Robertc, la base de données indexée connaît les "plages", ce qui permet de rechercher et de récupérer tous les enregistrements qui commencent par "ab" et se terminent par "abd" pour trouver "abc", etc.

Answer 4

Exécutez ce qui suit dans la console du navigateur. Cela créera une entité distincte dans Application > Storage à côté de LocalStorage et SessionStorage.

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

Vous pouvez interroger ce stockage avec toutes les opérations CRUD, contrairement aux deux autres stockages qui ont moins de flexibilité et de fonctions pour jouer avec.