Хранение данных изображений для автономного веб-приложения (клиентская база данных хранения)

У меня есть автономное веб-приложение с помощью appcaching. Мне нужно предоставить ему около 10 МБ-20 МБ данных, которые он сохранит (на стороне клиента), состоящие в основном из файлов изображений PNG. Операция заключается в следующем:

  1. веб-приложение загружается и устанавливается в appcache (использует манифест)
  2. запросы веб-приложений из файлов данных PNG сервера (как? - смотрите альтернативы ниже)
  3. иногда веб-приложение resyncs с сервером, и делает небольшой частичный обновления / удаления / добавления в базу данных PNG
  4. FYI: сервер-это сервер отдыха JSON, который может размещать файлы в wwwroot для пикапа

вот мой текущий анализ клиентских "баз данных", которые обрабатывают двоичное хранилище blob

смотрите обновление внизу

  • AppCache (через манифест добавить все PNG, а затем обновить по требованию)
    • CON: любое изменение элемента базы данных PNG будет означать полную загрузку всех элементы в манифесте (действительно плохие новости!)
  • WebStorage
    • CON: предназначен для хранения JSON
    • CON: может хранить только капли через кодировку base64 (вероятно, фатальный недостаток из-за стоимости декодирования)
    • CON: жесткий предел 5 Мб для webStorage http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html
  • PhoneGap & SQLLite
    • CON: спонсор отклонит его как родное приложение, требующее сертификации
  • ZIP-файл
    • сервер создает zip-файл, помещает его в wwwroot и уведомляет клиента
    • пользователь должен вручную распаковать (по крайней мере, так я это вижу) и сохранить в клиентской файловой системе
    • веб-приложение использует API файловой системы для ссылки на файлы
    • CON: ZIP может быть слишком большим (zip64?), долгое время создать
    • CON: не уверен, что API файловой системы всегда может читать из песочницы (я так думаю)
  • USB или SD-карта (обратно в каменный век....)
    • пользователь будет локальным на сервере перед переходом в автономный режим
    • чтобы мы могли заставить его вставить SD-карту, пусть сервер заполнит ее PNG-файлами
    • затем пользователь подключит его к ноутбуку, планшету
    • веб-приложение будет использовать API файловой системы для чтения файлы
    • CON: не уверен, что API файловой системы всегда может читать из песочницы (я так думаю)
  • WebSQL
    • CON: w3c отказался от него (довольно плохо)
    • я мог бы рассмотреть оболочку Javascript, которая использует IndexedDB и WebSQL в качестве резервного
  • API файловой системы
    • Chrome поддерживает чтение/запись больших двоичных объектов
    • CON: не ясно о IE и FireFox (IE10, имеет нестандартный msSave)
    • caniuse.com отчеты поддержка IOS и Android (но опять же, это просто r/w JSON, или он включает в себя полный BLOB API для записи?
    • CON: FireFox люди не любят API файловой системы и не ясно, поддерживают ли они сохранение больших двоичных объектов:https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
    • PRO:много быстрее, чем IndexedDB для больших двоичных объектов в соответствии с jsperf http://jsperf.com/indexeddb-vs-localstorage/15 (Страница 2)
  • IndexedDB
    • хорошая поддержка в IE10, FireFox (сохранить, читать blobs)
    • хорошая скорость и более простое управление, чем файловая система (удаление, обновление)
    • PRO: смотрите тесты скорости:http://jsperf.com/indexeddb-vs-localstorage/15
    • посмотреть эту статью: хранение и отображение изображений в индексированные базы данных: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
    • CON: я подтвердил, что Chrome еще не поддерживает запись blob (текущая ошибка, но не ясно, когда она будет исправлена)
    • обновление: разработчики Chrome подтверждают, что они работают над этим как для рабочего стола, так и для android! пока никаких временных рамок.
  • шезлонге JavaScript wrapper http://brian.io/lawnchair/
    • PRO: очень чистая обертка для IndexedDB, WebSQL или любой другой базы данных у вас есть (думаю, polyfill)
    • CON: не может хранить двоичные капли, только данные: uri (кодировка base64) (вероятно, фатальный недостаток из-за стоимости декодирования)
  • индексированные базы данных на jQuery полифилл https://github.com/axemclion/jquery-indexeddb
    • Парашурам имеет writtent хорошую оболочку JQUERY для интерфейса raw IndexedDB
    • PRO: значительно упрощает используя IndexedDB, я надеялся добавить прокладку / polyfill для Chrome FileSystemAPI
    • CON: он должен обрабатывать капли, но я не смог заставить его работать
  • СПР.файловая система.js http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api
    • Эрик Bidelman @ Google уже написано хорошо проверенных полифилл API для файловой системы, которая использует индексированные DB как осень назад
    • PRO: API файловой системы хорошо подходит для хранения больших двоичных объектов
    • PRO: отлично работает на FireFox и Chrome
      • PRO: отлично подходит для синхронизации с облаком на основе CouchDB
    • CON: не ясно, почему, но он не работает на IE10
  • PouchDB библиотека JavaScripthttp://pouchdb.com/
    • отлично подходит для синхронизации CouchDB с локальной БД (использует либо WebSQL или IndexedDB (не моя проблема, хотя)
    • CON: нет минусов, PouchDB теперь поддерживает двоичные капли для всех последних браузеров (IE, Chrome, Firefox, Chrome на мобильном телефоне и т. д.) а также многие старые браузеры. Это было не так, когда я впервые сделал этот пост.

Примечание: чтобы увидеть данные: кодировка uri PNG я создал пример по адресу:http://jsbin.com/ivefak/1/edit

Нужные/Полезные/Uneeded Особенности

  • нет родного (EXE, PhoneGap, ObjectiveC и т. д.) приложения на клиенте (чистое веб-приложение)
  • только должен работать на последних Chrome, FireFox, IE10 для ноутбуков
  • сильно хочу такое же решение для планшета Android (IOS тоже было бы неплохо), но для работы нужен только один браузер (FF, Chrome и т. д.)
  • быстрое начальное население БД
  • требование: очень быстрый поиск изображений с помощью веб-приложения из хранилища (DB, файл)
  • не предназначен для потребителей. Мы можем ограничить браузеры и попросить пользователя выполнить специальные настройки и задачи, но давайте минимизировать это

Реализации IndexedDB

  • есть отличная статья о том, как IE, FF и Chrome внутренне реализуют это по адресу:http://www.aaron-powell.com/web/indexeddb-storage
  • короче:
    • IE использует тот же формат базы данных, что и Exchange и Active Каталог для IndexedDB
    • Firefox использует SQLite, так что это своего рода реализация базы данных NoSQL в базе данных SQL
    • Chrome (и WebKit) используют хранилище ключей/ значений, которое имеет наследие в BigTable

Мои Текущие Результаты

  • я решил использовать подход IndexedDB (и polyfill с FileSystemAPI для Chrome, пока они не отправят поддержку blob)
  • для получения плитки, у меня был dilemna с помощью jQuery люди ропота о добавлении этого в AJAX
  • Я пошел с XHR2-Lib Филом Парсонсом, который очень похож на JQUERY .ajax ()https://github.com/p-m-p/xhr2-lib
  • производительность для загрузки 100 МБ (IE10 4s, Chrome 6s, FireFox 7s).
  • Я не смог заставить ни одну из оболочек IndexedDB работать для больших двоичных объектов (lawnchair, PouchDB, jquery-indexeddb и т. д.)
  • Я свернул свою собственную обертку, и производительность (IE10 2s, Chrome 3s, FireFox 10s)
  • С FF, я предполагаю, что мы видим проблему производительности использования реляционной БД (sqllite) для хранения не sql
  • Примечание, Chrome имеет выдающиеся инструменты отладки (вкладка разработчика, ресурсы) для проверки состояния IndexedDB.

окончательные результаты опубликованы ниже в качестве ответа

обновление

PouchDB теперь поддерживает двоичные капли для всех последних браузеров (IE, Chrome, Firefox, Chrome on мобильный, etc.) а также многие старые браузеры. Это было не так, когда я впервые сделал этот пост.

4 97
javascript html5 web-applications leaflet indexeddb

4 ответа:

результаты Offline blob cache для png slippy maps

тестирование

  • 171 PNG файлов (всего 3,2 МБ)
  • платформы протестированы: Chrome v24, FireFox 18, IE 10
  • также должен работать с Chrome & FF для Android

выборка с веб-сервера

  • использование XHR2 (поддерживается почти во всех браузерах) для загрузки blob с веб-сервера
  • Я пошел с XHR2-Lib Филом Парсонс, что очень похоже на JQUERY .Аякс()

для хранения

  • IndexedDB для IE и FireFox
  • Chrome: Polyfill (blob, сохраненный с помощью API файловой системы, ссылка хранится в IndexedDB) polyfill
  • обязательно прочитайте статью " как браузеры хранят IndexedDB данные"
  • Примечание: FireFox использует SQLlite для NoSQL IndexedDB. Это может быть причиной низкой производительности. (капли хранятся отдельно)
  • Примечание: Microsoft IE использует расширяемый механизм хранения:
  • Примечание: Chrome использует LevelDB http://code.google.com/p/leveldb/

дисплей

  • Я использую листовку http://leafletjs.com/ чтобы показать плитки карты
  • я использовал функциональный плагин tile layer от Ishmael Smyrnow для извлечения слоя плитки из БД
  • Я сравнил слой плиток на основе БД с A чисто локальное (localhost://) хранение
  • нет заметной разницы в производительности! между использованием IndexedDB и локальных файлов!

результаты

  • хром: принести (6.551 ы), магазин (8.247 с), Общее время: (13.714 ы)
  • в Firefox: принести (0.422 сек), магазин (31.519 с), Общее время: (32.836 ы)
  • т. е. 10: принести (0.668 сек), магазин: (0.896 сек), Общее время: (3.758 с)
21

для ваших требований я предлагаю разработать новый полифилл на основе двух других: API файловой системы для IndexedDB и IndexedDB в WebSQL - это лучший вариант.

первый позволит поддерживать хранение больших двоичных объектов в Chrome (API файловой системы) и Firefox (IndexedDB), в то время как последний должен обеспечивать поддержку Android и iOS (WebSQL). Что нужно, так это просто заставить эти полифиллы работать вместе, и я предположим, это не трудно.

Примечание: поскольку я не смог найти никакой информации в интернете об этом, вы должны проверить, будет ли хранение больших двоичных объектов с помощью WebSQL polyfill работать на iOS и Android. Похоже, он должен работать, хотя:

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

источник

4

несколько лет назад (не совсем каменный век) я использовал подписанный Java-апплет, который запрашивал бы свой сервер для синхронизации/обновления требований, загружал соответствующие файлы с сервера и сохранял их в файловой системе пользователя (а не в базе данных). Это решение может работать для вас, хотя вам понадобится кто-то, чтобы написать апплет и подписать его. Для решений баз данных такой апплет может использовать jdbc, доступный для большинства баз данных, использующих localhost на подходящем порту (например, 3306 для MySQL). Я поверьте, что тег апплета устарел в Html5, но он все еще работает. Нет опыта работы на Android таблетки, так что не могу прокомментировать эту часть.

1

у меня есть кэширование карт примеры(откройте пример, откройте области и масштабирование, переключитесь в автономный режим и обнаруженные области будут доступны).

здесь map.js - слой карты для автономного плитки, storage.js - реализация хранилища на основе IndexedDb и WebSQL (но это просто тестовая реализация с низкой производительностью).

  • для файлов сайта (html, css, js и др.) Я предпочитаю использовать кэш приложений.
  • для хранения я предпочитаю использовать индексированную БД (поддержка Blob), веб-и SQL (только в base64), автоматически (поддержка больших двоичных объектов, но только хром). Честно говоря, хранение является большой проблемой для этого. Вам нужно самое быстрое решение для ключевых значений, которое смешает их все. Я думаю, что это хорошее решение-использовать существующие решения.
  • для извлечения я использовал холст с CORS. Но я думаю о WebWorkers и XHR2, и это может быть лучше вместо canvas, потому что у canvas есть некоторые проблемы с CORS в разных браузерах и других (например это заголовок сохраненные плохо в опере).

дополнительная информация о размерах для 2-миллиардного города (Минск):

  • Zoom-9, tiles-2, size-52 kb, with previous-52 kb;
  • масштаб-10, плитки-3, размер-72 кб, с предыдущим-124 КБ;
  • масштаб-11, плитки-7, размер-204 кб, с предыдущим-328 КБ;
  • масштаб-12, плитки-17, размер-348 кб, с предыдущим-676 КБ;
  • Zoom-13, плитки-48, размер - 820 кб, с предыдущей-1,5 Мб;
  • Zoom-14, tiles-158, size-2.2 mb, with previous-3.7 mb;
  • Zoom-15, tiles-586, size-5.5 mb, with previous-9.3 mb;
  • Zoom-16, tiles-2264, size-15 mb, with previous-24.3 mb;
0