web-dev-qa-db-fra.com

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

  1. IndexedDB et le stockage local sont des magasins de valeurs clés. Quel est l'avantage d'avoir deux magasins clé/valeur?
  2. indexedDB est asynchrone, mais les jointures (la chose la plus longue) sont manuelles. Ils semblent s'exécuter dans le même thread que les appels asynchrones ont été effectués. Comment cela ne bloquera-t-il pas l'interface utilisateur?
  3. indexedDB permet un plus grand magasin. Pourquoi ne pas augmenter la taille de la boutique HTML5?
  4. Je me gratte la tête. Quel est l'intérêt de la base de données indexée?
javascripthtmlindexeddb
69
Samuel Danielson

IndexedDB n'est pas un magasin de valeurs-clés de la même manière que le stockage local. Le stockage local stocke juste des chaînes, donc pour mettre un objet dans le stockage local, l'approche habituelle est de JSON.stringify it:

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

C'est très bien pour trouver l'objet avec la clé uniq, mais la seule façon de récupérer les propriétés de myObject hors du stockage local est de JSON.parse l'objet et examinez-le:

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

C'est très bien si vous ne disposez que d'un ou de quelques objets dans le stockage local. Mais imaginez que vous avez mille objets, qui ont tous une propriété b, et que vous voulez faire quelque chose juste avec ceux où b==2. Avec le stockage local, vous devrez parcourir l'intégralité du magasin et vérifier b sur chaque article, ce qui représente une perte de traitement considérable.

Avec IndexedDB, vous pouvez stocker autre chose que des chaînes dans la valeur : "Cela inclut des types simples tels que DOMString et Date ainsi que des instances Object et Array." 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. Donc, avec IndexedDb, vous pouvez y placer ces mêmes milliers d'objets mais créer un index sur la propriété b et l'utiliser pour récupérer simplement les objets où b==2 sans la surcharge de numérisation de chaque objet dans le magasin.

C'est du moins l'idée. L'API IndexedDB n'est pas très intuitive.

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

Asynchrone n'est pas la même chose que multi-thread, JavaScript, en règle générale, n'est pas multi-thread . Tout traitement lourd que vous effectuez dans JS bloquera l'interface utilisateur, si vous voulez minimiser le blocage de l'interface utilisateur, essayez Web Workers .

indexedDB permet un plus grand magasin. Pourquoi ne pas augmenter la taille de la boutique HTML5?

Parce que, sans indexation appropriée, il deviendrait de plus en plus lent à mesure qu'il grossissait.

92
robertc

Ajoutant à la réponse de robert, indexedDB connaît les "plages" afin que vous puissiez rechercher et récupérer tous les enregistrements qui commencent par "ab" et se terminent par abd "pour trouver" abc ", etc.

6
Johan

Je suis tombé sur ce bon article discutant de localstorage vs indexeddb et d'autres options possibles.

(toutes les valeurs ci-dessous sont en millisecondes)

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

memory comparison

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

  1. Dans les trois Chrome, Firefox et Edge, LocalStorage bloque complètement le DOM pendant que vous écrivez des données 2. Le blocage est beaucoup plus visible qu'avec la mémoire, car le navigateur doit réellement vider le disque.
  2. Sans surprise, comme tout code synchrone bloque, les opérations en mémoire le bloquent également. Le DOM se bloque pendant les insertions de longue durée, mais à moins que vous n'ayez à traiter un grand nombre de données, il est peu probable que vous le remarquiez, car les opérations en mémoire sont très rapides.

  3. Dans Firefox et Chrome, IndexedDB est plus lent que LocalStorage pour les insertions de valeur-clé de base, et il bloque toujours le DOM. Dans Chrome, il est également plus lent que WebSQL, qui bloque 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, ce qui est aggravant, ce sont les deux navigateurs qui n'implémentent que partiellement la spécification IndexedDB.

  4. IndexedDB fonctionne à merveille dans un travailleur Web, où il fonctionne à peu près à la même vitesse mais sans bloquer le DOM. La seule exception est Safari, qui ne prend pas en charge IndexedDB à l'intérieur d'un travailleur, mais il ne bloque toujours pas l'interface utilisateur.

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

3
Amruta-Pani

Exécutez ce qui suit dans la console du navigateur. Il créera une entité distincte dans Application> Stockage aux côtés 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.

0
Vinit Khandelwal