存储脱机Web应用程序的图像数据（客户端存储数据库）

我有一个使用appcaching的离线web应用程序。 我需要提供大约10MB – 20MB的数据（主要由PNG图像文件组成）保存（客户端）。 操作如下：

1. Web应用程序下载并安装在appcache中（使用清单）
2. 来自服务器PNG数据文件的Web应用程序请求（如何？请参阅下面的替代方法）
3. 偶尔web应用与服务器重新同步，并对PNG数据库进行小部分更新/删除/添加
4. 仅供参考：服务器是一个JSON REST服务器，可以将文件放入wwwroot中取出

这里是我目前对处理二进制BLOB存储的基于客户端的“数据库”的分析

请参见底部的更新

• AppCache （通过清单添加所有的PNG，然后按需更新）
  • CON：对PNG数据库项目的任何更改都意味着完全下载清单中的所有项目（真是坏消息！）
• WebStorage
  • CON：专为JSON存储而devise
  • CON：只能通过base64编码存储blob（由于解码成本可能是致命的缺陷）
  • CON：webStorage硬盘限制为5MB http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html
• PhoneGap＆SQLLite
  • CON：赞助商将拒绝作为需要authentication的本地应用程序
• ZIP文件
  • 服务器创build一个zip文件，将其放置在wwwroot中，并通知客户端
  • 用户必须手动解压缩（至less这是我如何看到它）并保存到客户端文件系统
  • Web应用程序使用FileSystem API来引用文件
  • CON：ZIP可能太大（zip64？），需要很长时间才能创build
  • CON：不知道FileSystem API总是可以读出沙盒（我想是这样）
• USB或SD卡 （回到石器时代….）
  • 离线前，用户将在服务器本地
  • 所以我们可以让他插入一个SD卡，让服务器填充PNG文件
  • 然后用户将其插入笔记本电脑，平板电脑
  • Web应用程序将使用FileSystem API来读取文件
  • CON：不知道FileSystem API总是可以读出沙箱（我这么认为）
• 的WebSQL
  • CON：w3c已经放弃了（很糟糕）
  • 我可能会考虑一个使用IndexedDB和WebSQL作为后备的Javascript包装器
• FileSystem API
  • Chrome支持读/写blob
  • CON：不清楚IE和FireFox（IE10，有非标准的msSave）
  • caniuse.com报告IOS和Android的支持（但是，这又是，这只是JSON的R / W，还是它包括用于写作的完整的blob API？
  • CON：FireFox的人不喜欢FileSystem API，不清楚他们是否支持保存blob： https : //hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
  • PRO：根据jsperf http://jsperf.com/indexeddb-vs-localstorage/15 （第2页）比用于blob的IndexedDB快得多
• IndexedDB的
  • 在IE10，FireFox（保存，读取blob）
  • 比文件系统更好的速度和更容易的pipe理（删除，更新）
  • PRO：看速度testing： http : //jsperf.com/indexeddb-vs-localstorage/15
  • 请参阅这篇关于在IndexedDB中存储和显示图像的文章： https ：//hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
  • CON：我确认Chrome还不支持blob写入（目前的错误，但不清楚什么时候会修复）
  • 更新：Chrome开发人员确认他们正在为桌面和Android工作！ 没有时间表呢。
• LawnChair JavaScript包装http://brian.io/lawnchair/
  • PRO：对于IndexedDB，WebSQL或其他任何数据库都非常干净的包装（想想polyfill）
  • CON：不能存储二进制blob，只有数据：uri（base64编码）（由于解码成本可能是致命的缺陷）
• IndexedDB JQUERY polyFill https://github.com/axemclion/jquery-indexeddb
  • Parashuram为原始的IndexedDB接口写了一个很好的JQUERY包装器
  • PRO：大大简化了使用IndexedDB，我希望为Chrome FileSystemAPI添加填充/填充
  • CON：它应该处理斑点，但我无法得到它的工作
• idb.filesystem.js http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api
  • Eric Bidelman @ Google已经编写了一个经过testing的PolyFill FileSystem API，它使用索引数据库作为后备
  • PRO：FileSystem API非常适合存储blob
  • PRO：在FireFox和Chrome上效果很好
    • PRO：非常适合与基于云的CouchDB同步
  • CON：不清楚为什么，但它不是在IE10上工作
• PouchDB JavaScript库http://pouchdb.com/
  • 非常适合与本地数据库同步CouchDB（使用WebSQL或IndexedDB（不是我的问题）
  • CON：NO CONS，PouchDB现在支持所有最新浏览器（IE，Chrome，Firefox，Chrome on mobile等）以及许多旧版浏览器的二进制blob。 当我第一次做这个职位时情况并非如此。

注意：要查看数据：PNG的uri编码我创build了一个示例： http : //jsbin.com/ivefak/1/edit

期望/有用/不需要的特征

• 客户端上没有本机（EXE，PhoneGap，ObjectiveC等）应用程序（纯Web应用程序）
• 只需运行最新的Chrome，FireFox，IE10便携式电脑
• 非常想要Android平板电脑的相同的解决scheme（IOS会很好），但只需要一个浏览器工作（FF，铬等）
• 快速的初始DB人口
• 要求：通过Web应用程序从存储（数据库，文件）快速检索图像
• 不是为了消费者。 我们可以限制浏览器，并要求用户做特殊的设置和任务，但我们尽量减less

IndexedDB实现

• 有一篇关于IE，FF和Chrome如何在内部实现这个的精彩文章： http : //www.aaron-powell.com/web/indexeddb-storage
• 简而言之：
  • IE使用与Exchange和Active Directory相同的数据库格式用于IndexedDB
  • Firefox正在使用SQLite，所以在SQL数据库中实现了NoSQL数据库
  • Chrome（和WebKit）正在使用一个在BigTable中具有遗产的Key / Value商店

我当前的结果

• 我select了使用IndexedDB的方法（并使用FileSystemAPI for Chrome进行填充，直到他们提供blob支持）
• 为了获取瓷砖，我有一个困境，因为JQUERY的人都在向AJAX添加这个东西
• 我和Phil Parsons一起使用了XHR2-Lib，这非常像JQUERY .ajax（） https://github.com/pmp/xhr2-lib
• 100MB下载性能（IE10 4s，Chrome 6s，FireFox 7s）。
• 我无法得到任何的IndexedDB包装工作blob（lawnchair，PouchDB，jquery-indexeddb等）
• 我推出了自己的包装，性能是（IE10 2s，Chrome 3s，FireFox 10s）
• 使用FF，我假设我们正在看到使用关系数据库（sqllite）作为非sql存储的性能问题
• 注意，Chrome具有优秀的debugging工具（开发人员选项卡，资源），用于检查IndexedDB的状态。

最终结果如下所示

更新

PouchDB现在支持所有最新浏览器（IE，Chrome，Firefox，移动设备上的Chrome等）以及许多旧浏览器的二进制blob。 当我第一次做这个职位时情况并非如此。

Answer 1

结果离线blob高速caching的PNG slippy地图

testing

• 171个PNG文件（共3.2MB）
• testing的平台：Chrome v24，FireFox 18，IE 10
• 还应该使用适用于Android的Chrome和FF

从Web服务器获取

• 使用XHR2（在几乎所有浏览器上都支持）从Web服务器进行Blob下载
• 我和Phil Parsons一起使用了XHR2-Lib，这很像JQUERY .ajax（）
  • https://github.com/pmp/xhr2-lib

存储

• IE和FireFox的IndexedDB
• Chrome：填充（使用FileSystem API存储的blob，参考保存在IndexedDB中）填充
• 必须阅读“如何浏览器存储IndexedDB数据”
  • http://www.aaron-powell.com/web/indexeddb-storage
• 注意：FireFox使用SQLlite作为NOSQL IndexedDB。 这可能是性能下降的原因。 （blob单独存储）
• 注意：Microsoft IE使用可扩展存储引擎：
  • http://en.wikipedia.org/wiki/Extensible_Storage_Engine
• 注意：Chrome使用LevelDB http://code.google.com/p/leveldb/

显示

• 我正在使用Leaflet http://leafletjs.com/来显示地图图块;
• 我使用Ishmael Smyrnow的function性瓷砖层插件从数据库中获取瓷砖层
  • https://github.com/ismyrnow/Leaflet.functionaltilelayer
• 我比较了基于DB的瓷砖层和纯粹的本地（localhost：//）存储
• 性能没有明显的差异！ 在使用IndexedDB和本地文件之间！

结果

• Chrome：抓取（6.551s），存储（8.247s），总时间（13.714秒）
• FireFox：取（0.422s），商店（31.519s），总时间（32.836s）
• IE 10：取（0.668秒），存储（0.896秒），总时间（3.758秒）

Answer 2

为了您的要求，我build议开发一个基于另外两个新的polyfill： FileSystem API到IndexedDB和IndexedDB到WebSQL – 是最好的select。

前者将支持在Chrome（FileSystem API）和Firefox（IndexedDB）中存储Blob，而后者应该支持Android和iOS（ WebSQL ）。 我们需要的是使这些填充物一起工作，我想这不是难的。

注意：因为我在网上找不到任何有关这方面的信息，所以你应该testing一下使用WebSQL的polyfill存储blob是否可以在iOS和Android上使用。 它看起来应该工作，虽然：

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

资源

Answer 3

几年前（不完全是石器时代），我正在使用一个签名的java applet来查询其服务器的同步/更新需求，从服务器下载适当的文件并将其保存在用户的文件系统（而不是数据库）上。 这个解决scheme可能适合你，虽然你需要有人写小程序并签名。 对于数据库解决scheme，这样一个applet可以使用适用于大多数数据库的jdbc，这些数据库在合适的端口上使用本地主机（例如3306 for MySQL）。 我相信这个applet标签在Html5中已经被弃用了，但它仍然可以工作。 没有Android平板电脑的使用经验，所以不能评论这部分。

Answer 4

我有地图caching示例 （打开示例，发现区域和缩放，切换离线和发现区域将available）。

有map.js – 离线贴图的地图图层， storage.js – 基于IndexedDb和WebSQL的存储实现（但这只是性能较差的testing实现）。

• 对于网站文件（html，css，js等），我更喜欢使用应用程序caching。
• 对于存储，我更喜欢使用索引数据库（支持blob），Web SQL（只有base64），FileWriter（支持blob，但只有铬）。 坦率地说，存储是这个问题的一大问题。 你需要最快速的键值解决scheme，将所有的混合。 我认为使用现有解决scheme是一个很好的决定。
• 为了获取我用canvas与CORS。 但我想到的WebWorkers和XHR2，这可能是更好的，而不是帆布，因为canvas有不同的浏览器和其他（例如， 这个标题存储在歌剧坏 ）一些麻烦。

有关20亿城市（ 明斯克 ）规模的更多信息：

• 缩放 – 9，瓷砖 – 2，大小 – 52 kb，与以前 – 52 kb;
• 缩放 – 10，瓷砖 – 3，大小 – 72 kb，与以前 – 124 kb;
• 缩放 – 11，瓷砖 – 7，大小 – 204 kb，与以前 – 328 kb;
• 缩放 – 12，瓷砖 – 17，大小 – 348 kb，与以前 – 676 kb;
• 缩放 – 13，瓷砖 – 48，大小 – 820 kb，与以前 – 1.5 MB的;
• 缩放 – 14，瓷砖 – 158，大小 – 2.2 MB，以前 – 3.7 MB;
• 缩放 – 15，瓷砖 – 586，大小 – 5.5 MB，以前 – 9.3 MB;
• 缩放 – 16，瓷砖 – 2264，大小 – 15 MB，以前 – 24.3 MB;