Stockage des données D'Image pour une application Web hors ligne (base de données de stockage côté client)

J'ai une application Web hors ligne utilisant appcaching. Je dois lui fournir environ 10 Mo-20 Mo de données qu'il va enregistrer (côté client) composé principalement de fichiers image PNG. L'opération est comme suit:

  1. téléchargements et installations D'applications Web dans appcache (utilise manifest)
  2. requêtes d'applications Web à partir de fichiers de données PNG du serveur (Comment? - voir les alternatives ci-dessous)
  3. occasionnellement, l'application web resynchronise avec le serveur et effectue de petites mises à jour/suppressions/ajouts partiels au PNG base de données
  4. FYI: Server est un serveur REST JSON, qui peut placer des fichiers dans wwwroot pour le Ramassage

Voici mon analyse actuelle des "bases de données" basées sur le client qui gèrent le stockage blob binaire

Voir Mise à jour en bas

  • AppCache (via manifest ajouter tout le PNG, puis mettre à jour à la demande)
    • CON: toute modification D'un élément de base de données PNG signifiera le téléchargement complet de tous les éléments du Manifeste (vraiment mauvais nouvelles!)
  • WebStorage
  • PhoneGap & SQLLite
    • CON: le Sponsor le rejettera comme une application native nécessitant certification
  • fichier ZIP
    • le serveur crée un fichier zip, le place dans wwwroot et avertit le client
    • l'utilisateur doit décompresser manuellement (au moins c'est comme ça que je le vois) et enregistrer dans le système de fichiers client
    • L'application web utilise L'API du système de fichiers pour référencer les fichiers
    • CON: ZIP pourrait être trop grand (zip64?), longtemps pour créer
    • CON: Je ne sais pas si L'API du système de fichiers peut toujours lire dans le bac à sable (je pense)
  • USB ou SD carte (retour à l'âge de pierre....)
    • l'Utilisateur sera local au serveur avant de se déconnecter
    • pour qu'on puisse lui faire insérer une carte SD, laisser le serveur la remplir de fichiers PNG
    • Ensuite, l'utilisateur le branchera sur l'ordinateur portable, la tablette
    • l'application web utilisera L'API du système de fichiers pour lire les fichiers
    • CON: Je ne sais pas si L'API du système de fichiers peut toujours lire dans le bac à sable (je pense)
  • WebSQL
    • CON: le w3c l'a abandonné (joli mauvais)
    • je pourrais considérer un wrapper Javascript qui utilise IndexedDB et WebSQL comme un repli
  • API du système de fichiers
    • Chrome prend en charge la lecture/écriture des gouttes
    • CON: pas clair sur IE et FireFox (IE10, a mssave non standard)
    • caniuse.com rapports iOS et Android support (mais encore une fois, est-ce juste r / w de JSON, ou inclut-il l'API Blob complète pour l'écriture?
    • CON: les gens de FireFox n'aiment pas L'API du système de fichiers et ne savent pas s'ils le sont prise en charge des blobs d'économie: https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
    • PRO: beaucoup plus rapide que IndexedDB pour les blobs selon jsperf http://jsperf.com/indexeddb-vs-localstorage/15 (page 2)
  • IndexedDB
    • bon support dans IE10, FireFox (enregistrer, lire blobs)
    • bonne vitesse et gestion plus facile qu'un système de fichiers (suppressions, mises à jour)
    • PRO: voir essais de vitesse: http://jsperf.com/indexeddb-vs-localstorage/15
    • Voir cet article sur le stockage et l'affichage des images dans IndexedDB: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
    • CON: j'ai confirmé que Chrome ne supporte pas encore l'écriture blob (bug actuel, mais pas clair quand il sera corrigé)
    • mise à jour: les développeurs Chrome confirment qu'ils travaillent sur ce pour le bureau et android! aucun calendrier n' encore.
  • LawnChair JavaScript wrapper http://brian.io/lawnchair/
    • PRO: wrapper très propre pour IndexedDB, WebSQL ou n'importe quelle base de données que vous avez (pensez polyfill)
    • CON: impossible de stocker les blobs binaires, uniquement data: uri (codage base64) (défaut probablement fatal dû au coût du désencodage)
  • IndexedDB JQUERY polyFill https://github.com/axemclion/jquery-indexeddb
    • Parashuram a writtent un belle enveloppe JQUERY pour l'interface IndexedDB brute
    • PRO: simplifie grandement L'utilisation de IndexedDB, j'espérais ajouter un shim / polyfill pour Chrome FileSystemAPI
    • CON: il devrait gérer les blobs, mais je n'ai pas pu le faire fonctionner
  • bid.système de fichiers.js http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api
    • Eric Bidelman @ Google a écrit un PolyFill bien testé L'API du système de fichiers qui utilise la base de données indexée comme repli
    • PRO: filesystem API est bien adapté pour stocker des blobs
    • PRO: fonctionne très bien sur FireFox et Chrome
      • PRO: idéal pour la synchronisation avec CouchDB basé sur le cloud
    • CON: pas clair pourquoi, mais il ne fonctionne pas sur IE10
  • PouchDB Bibliothèque JavaScript http://pouchdb.com/
    • idéal pour synchroniser un CouchDB avec une base de données locale (utilise WebSQL ou IndexedDB (pas mon problème cependant)
    • CON: pas de contre, PouchDB prend désormais en charge les blobs binaires pour tous les navigateurs récents (IE, Chrome, Firefox, Chrome sur mobile, etc.) ainsi que de nombreux navigateurs plus anciens. Ce n'était pas le cas quand j'ai fait ce post.

NOTE: pour voir un encodage de données: uri de PNG, j'ai créé un exemple à: http://jsbin.com/ivefak/1/edit

Caractéristiques Souhaitées/Utiles/Non Nécessaires

  • Aucune application native (EXE, PhoneGap, ObjectiveC, etc) sur le client (Web pur application)
  • ne doit fonctionner que sur les derniers Chrome, FireFox, IE10 pour les ordinateurs portables
  • veulent fortement la même solution pour tablette Android (IOS serait bien aussi) mais seulement besoin d'un navigateur pour fonctionner (FF, Chrome, etc.)
  • Population DB initiale rapide
  • exigence: récupération très rapide des images par application web à partir du stockage (DB, fichier)
  • pas destiné aux consommateurs. Nous pouvons restreindre les navigateurs, et demander à l'utilisateur de faire une configuration spéciale et des tâches, mais minimisons que

Implémentations IndexedDB

  • Il y a un excellent article sur la façon dont IE,FF et Chrome implémentent cela en interne à: http://www.aaron-powell.com/web/indexeddb-storage
  • en bref:
    • IE utilise le même format de base de données que Exchange et Active Directory pour IndexedDB
    • Firefox utilise SQLite, donc implémente une base de données NoSQL dans la base de données SQL
    • Chrome (et WebKit) utilisent un magasin de clés/ valeurs qui a du patrimoine dans BigTable

Mes Résultats Actuels

  • j'ai choisi d'utiliser une approche IndexedDB (et polyfill avec FileSystemAPI pour Chrome jusqu'à ce qu'ils embarquent le support blob)
  • Pour aller chercher les tuiles, j'ai eu un dilemna puisque les gens de JQUERY sont en train de discuter de l'ajout de ceci à AJAX
  • je suis allé avec XHR2-Lib de Phil Parsons, qui ressemble beaucoup à JQUERY .ajax () https://github.com/p-m-p/xhr2-lib
  • Performance pour 100Mb téléchargements (IE10 4s, Chrome 6s, FireFox 7s).
  • Je n'ai pas pu faire fonctionner les wrappers IndexedDB pour les blobs (lawnchair, PouchDB, jQuery-indexeddb, etc.)
  • j'ai roulé mon propre wrapper, et la performance est (IE10 2s, Chrome 3s, FireFox 10s)
  • avec FF, je suppose que nous voyons le problème de performance de l'utilisation d'une base de données relationnelle (sqllite) pour un stockage non-sql
  • notez que Chrome dispose d'outils de débogage exceptionnels (onglet Développeur, ressources) pour inspecter l'état du IndexedDB.

Les résultats finaux affichés ci-dessous comme réponse

Mettre à jour

PouchDB prend désormais en charge les blobs binaires pour tous les navigateurs récents (IE, Chrome, Firefox, Chrome sur mobile, etc.) ainsi que de nombreux navigateurs plus anciens. Ce n'était pas le cas quand j'ai fait ce post.

97
demandé sur Dr.YSG 2013-01-01 22:56:52

4 réponses

Résultats cache blob hors ligne pour les cartes PNG slippy

Test

  • 171 fichiers PNG (total de 3,2 Mo)
  • plates-formes testées: Chrome v24, FireFox 18, IE 10
  • devrait également fonctionner avec Chrome & FF pour Android

Récupérer à partir du serveur web

  • Utilisation de XHR2 (pris en charge sur presque tous les navigateurs) pour le téléchargement blob à partir du serveur web
  • je suis allé avec XHR2-Lib de Phil Parsons, qui ressemble beaucoup à JQUERY .Ajax()

De Stockage

Affichage

Les Résultats

  • Chrome: Fetch (6.551 s), Store (8.247 s), temps total écoulé: (13.714 s)
  • FireFox: Fetch (0.422 s), le Magasin de (31,519 s), temps total écoulé: (32,836 s)
  • IE 10: Fetch (0.668 s), Store: (0.896 s), temps total écoulé: (3.758 s)
21
répondu Dr.YSG 2013-01-24 17:37:46

Pour vos besoins, je suggère que le développement d'un nouveau polyfill basé sur deux autres: API du système de fichiers à IndexedDB et IndexedDB à WebSQL - est la meilleure option.

Le premier permettra de prendre en charge le stockage des blobs dans Chrome (API du système de fichiers) et Firefox (IndexedDB), tandis que le second devrait fournir le support pour Android et iOS (WebSQL). Ce qu'il faut, c'est simplement faire fonctionner ces polyfills ensemble, et je suppose que ce n'est pas le cas dur.

NB: Comme je n'ai trouvé aucune information sur le web à ce sujet, vous devriez tester si le stockage de blobs en utilisant WebSQL polyfill fonctionnera sur iOS et Android. Il semble que cela devrait fonctionner cependant: 

var sql = ["CREATE TABLE", idbModules.util.quote(storeName), "(key BLOB", createOptions.autoIncrement ? ", inc INTEGER PRIMARY KEY AUTOINCREMENT" : "PRIMARY KEY", ", value BLOB)"].join(" ")

Source

4
répondu Bogdan Kulynych 2013-01-01 21:38:12

Il y a quelques années (pas exactement l'âge de Pierre), j'utilisais une applet java signée qui interrogeait son serveur pour la synchronisation/mise à jour des exigences, téléchargeait les fichiers appropriés à partir du serveur et les enregistrait sur le système de fichiers de l'Utilisateur (pas une base de données). Cette solution peut fonctionner pour vous, bien que vous ayez besoin de quelqu'un pour écrire l'applet et la signer. Pour les solutions de base de données, une telle applet peut utiliser le jdbc disponible pour la plupart des bases de données utilisant localhost sur un port approprié (par exemple, 3306 pour MySQL). Je croyez que la balise de l'applet est obsolète en Html5 mais cela fonctionne toujours. Aucune expérience sur les tablettes Android, donc ne peut pas commenter cette partie.

1
répondu Manidip Sengupta 2013-01-01 19:18:18

J'ai la mise en cache de la carte exemples (Exemple ouvert, découvrir les régions et les zooms, désactiver et les régions découvertes seront disponibles).

Il y a map.js - couche de carte pour les tuiles hors ligne, storage.js - implémentation de stockage basée sur IndexedDb et WebSQL (mais cela ne fait que tester l'implémentation avec de mauvaises performances).

  • pour les fichiers de site (html, css, js et etc.) Je préfère utiliser le cache d'application.
  • pour le stockage, je préfère utiliser la base de données indexée( support blob), Web SQL (uniquement base64), FileWriter (support blob, mais seulement chrome). Franchement stockage est gros problème pour cela. Vous avez besoin de la solution de valeur clé la plus rapide qui les mélangera tous. Je pense que c'est une bonne décision d'utiliser la solution exist.
  • Pour aller chercher, j'ai utilisé canvas avec CORS. Mais je pense à WebWorkers et XHR2 et cela peut être mieux à la place canvas car canvas a quelques problèmes avec CORS dans différents navigateurs et autres (par exemple ce titre {[4] } a été stocké mauvais dans opéra).

Informations supplémentaires sur les tailles pour 2 milliards de ville (Minsk):

  • Zoom-9, tuiles-2, taille-52 ko, avec précédent-52 Ko;
  • Zoom-10, tuiles-3, Taille-72 ko, avec précédent-124 Ko;
  • Zoom-11, tuiles-7, taille-204 kb, avec précédent-328 kb;
  • Zoom - 12, tuiles - 17, taille - 348 ko, avec les précédents - 676 ko;
  • Zoom-13, tuiles-48, taille - 820 ko, avec précédent-1,5 Mo;
  • Zoom-14, tuiles - 158, Taille-2,2 mo, avec précédent-3,7 Mo;
  • Zoom-15, tuiles-586, taille-5,5 Mo, avec précédent-9,3 Mo;
  • Zoom-16, tuiles-2264, taille-15 Mo, avec précédent-24,3 Mo;
0
répondu tbicr 2017-05-19 01:39:08