javascript - tutorial - ¿Cómo es indexedDB conceptualmente diferente del almacenamiento local HTML5?

sqlite javascript html5 tutorial

Question

1. Tanto el indexedDB como el almacenamiento local son almacenes de valores clave. ¿Cuál es la ventaja de tener dos tiendas clave / valor?
2. indexedDB es asincrónico, pero las uniones (la cosa que más tiempo consume) son manuales. Parece que se ejecutan en el mismo hilo que las llamadas asincrónicas. ¿Cómo esto no bloqueará la UI?
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?

Answer 1

Añadiendo al guion de robertc, indexedDB conoce ''rangos'' para que pueda buscar y recuperar todos los registros que comienzan con ''ab'' y terminan con abd ''para encontrar'' abc '', etc.

Answer 2

IndexedDB no es un almacén de clave-valor de la misma manera que lo es el almacenamiento local. El almacenamiento local solo almacena cadenas, por lo que para colocar un objeto en el almacenamiento local, el enfoque habitual es JSON.stringify :

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

Esto está bien para encontrar el objeto con uniq clave, pero la única forma de recuperar las propiedades de myObject del almacenamiento local es usar el objeto JSON.parse 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 en donde b==2 . Con el almacenamiento local, tendrá que recorrer toda la tienda y comprobar b en cada elemento, que es un gran desperdicio de procesamiento.

Con IndexedDB puede almacenar 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 sobre las propiedades de los objetos que almacenó en el valor. Entonces, con IndexedDb puede poner esos mismos mil objetos pero crear un índice en la propiedad b y usar eso para simplemente recuperar los objetos donde b==2 sin la sobrecarga de escanear cada objeto en la tienda.

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

Parece que se ejecutan en el mismo hilo que las llamadas asincrónicas. ¿Cómo esto no bloqueará la UI?

Asíncrono no es lo mismo que multihilo, JavaScript, como regla, no tiene múltiples subprocesos . Cualquier procesamiento pesado que haga en JS bloqueará la interfaz de usuario, si desea minimizar el bloqueo de la interfaz de usuario intente Web Workers .

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

Porque, sin una indexación adecuada, se volvería cada vez más lenta cuanto más grande fuera.

Answer 3

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

(todos los valores a continuación están en milisegundos)

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

Para resumir desde el artículo (puntos de vista del autor),

1. En los tres de Chrome, Firefox y Edge, LocalStorage bloquea completamente el DOM mientras escribes datos 2. El bloqueo es mucho más notable que con la memoria, ya que el navegador tiene que enjuagar el disco.
2. No es sorprendente que, dado que cualquier código síncrono esté bloqueando, las operaciones en memoria también sean bloqueantes. Los bloques DOM durante las inserciones de larga ejecución, pero a menos que tenga que lidiar 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 valores-clave, 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 puede ejecutarse en segundo plano sin interrumpir la interfaz de usuario, y lo que es más grave, esos son los dos navegadores que implementan solo parcialmente la especificación IndexedDB.

4. IndexedDB funciona maravillosamente bien en un trabajador web, donde funciona 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