¿En qué se diferencia conceptualmente indexedDB del almacenamiento local HTML5?

1. Tanto indexedDB como el almacenamiento local son almacenes de valores clave. ¿Cuál es la ventaja de tener dos almacenes clave / valor?
2. indexedDB es asincrónico, pero las uniones (lo que lleva más tiempo) son manuales. Parece que se ejecutan en el mismo hilo que se realizaron las llamadas asíncronas. ¿Cómo no bloqueará esto la interfaz de usuario?
3. indexedDB permite una tienda más grande. ¿Por qué no aumentar el tamaño de la tienda HTML5?
4. Me estoy rascando la cabeza. ¿Cuál es el punto de indexedDB?

IndexedDB no es un almacén de valores-clave de la misma forma que el almacenamiento local. El almacenamiento local solo almacena cadenas, por lo que para poner un objeto en el almacenamiento local, el enfoque habitual es JSON .

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

Esto está bien para encontrar el objeto con la clave uniq, pero la única forma de recuperar las propiedades de myObject del almacenamiento local es analizar JSON, analizar el objeto y examinarlo:

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

Esto está bien si solo tiene uno o algunos objetos en el almacenamiento local. Pero imagina que tienes mil objetos, todos los cuales tienen una propiedad b, y quieres hacer algo solo con aquellos donde b==2. Con el almacenamiento local, tendrá que recorrer toda la tienda y verificar bcada artículo, lo cual es una gran cantidad de procesamiento desperdiciado.

Con IndexedDB puede almacenar otras cosas que no sean cadenas en el valor : "Esto incluye tipos simples como DOMString y Date, así como instancias de Object y Array". No solo eso, sino que puede crear índices en las propiedades de los objetos que almacenó en el valor. Entonces, con IndexedDb puede colocar esos mismos mil objetos en él, pero crear un índice en la bpropiedad y usarlo para recuperar los objetos b==2sin la sobrecarga de escanear cada objeto en la tienda.

Al menos esa es la idea. La API IndexedDB no es muy intuitiva.

Parece que se ejecutan en el mismo hilo que se realizaron las llamadas asíncronas. ¿Cómo no bloqueará esto la interfaz de usuario?

Asincrónico no es lo mismo que multiproceso, JavaScript, por regla general, no es multiproceso . Cualquier procesamiento pesado que realice en JS bloqueará la interfaz de usuario, si desea minimizar el bloqueo de la interfaz de usuario, pruebe con Web Workers .

indexedDB permite una tienda más grande. ¿Por qué no aumentar el tamaño de la tienda HTML5?

Porque, sin la indexación adecuada, se volvería cada vez más lento cuanto más grande se hiciera.

Me encontré con este buen artículo que habla sobre localstorage vs indexeddb y otras opciones posibles.

(todos los valores siguientes están en milisegundos)

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

Para resumir del artículo (opiniones enteramente del autor),

1. En los tres de Chrome, Firefox y Edge, LocalStorage bloquea completamente el DOM mientras estás escribiendo datos 2. El bloqueo es mucho más notable que en la memoria, ya que el navegador tiene que descargarse en el disco.
2. Como era de esperar, dado que cualquier código síncrono se bloquea, las operaciones en memoria también lo están. El DOM se bloquea durante inserciones de larga duración, pero a menos que esté tratando con una gran cantidad de datos, es poco probable que lo note, porque las operaciones en memoria son realmente rápidas.

3. Tanto en Firefox como en Chrome, IndexedDB es más lento que LocalStorage para las inserciones básicas de clave-valor y aún bloquea el DOM. En Chrome, también es más lento que WebSQL, que bloquea el DOM, pero no tanto. Solo en Edge y Safari IndexedDB logra ejecutarse en segundo plano sin interrumpir la interfaz de usuario y, lo que es más grave, esos son los dos navegadores que solo implementan parcialmente la especificación IndexedDB.

4. IndexedDB funciona muy bien en un trabajador web, donde se ejecuta aproximadamente a la misma velocidad pero sin bloquear el DOM. La única excepción es Safari, que no admite IndexedDB dentro de un trabajador, pero aún así no bloquea la interfaz de usuario.

5. localmemory es ideal si los datos son simples y mínimos

Agregando a la respuesta de robertc, indexedDB conoce los 'rangos' para que pueda buscar y recuperar todos los registros que comienzan con 'ab' y terminan con abd 'para encontrar' abc ', etc.

Ejecute lo siguiente en la consola del navegador. Creará una entidad separada en Aplicación> Almacenamiento junto con LocalStorage y SessionStorage

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

Puede consultar este almacenamiento con todas las operaciones CRUD a diferencia de otros dos almacenamientos que tienen menos flexibilidad y funciones para jugar.