ฉันมีแอปพลิเคชันเว็บออฟไลน์โดยใช้ appcaching ฉันต้องให้ข้อมูลประมาณ 10MB - 20MB ที่จะบันทึก (ฝั่งไคลเอ็นต์) ซึ่งประกอบด้วยไฟล์ภาพ PNG เป็นหลัก การดำเนินการมีดังนี้:

1. ดาวน์โหลดและติดตั้งแอปพลิเคชันบนเว็บใน appcache (ใช้รายการ)
2. คำขอเว็บแอปจากไฟล์ข้อมูล PNG ของเซิร์ฟเวอร์ (อย่างไร - ดูทางเลือกอื่นด้านล่าง)
3. บางครั้งเว็บแอปจะซิงค์กับเซิร์ฟเวอร์และทำการอัปเดต / ลบ / เพิ่มเติมบางส่วนในฐานข้อมูล PNG
4. FYI: เซิร์ฟเวอร์เป็นเซิร์ฟเวอร์ JSON REST ที่สามารถวางไฟล์ใน wwwroot เพื่อรับได้

นี่คือการวิเคราะห์ "ฐานข้อมูล" แบบไคลเอ็นต์ในปัจจุบันของฉันที่จัดการพื้นที่จัดเก็บไบนารี Blob

ดูอัปเดตที่ด้านล่าง

• AppCache (ผ่านรายการเพิ่ม PNG ทั้งหมดแล้วอัปเดตตามต้องการ)

  • CON: การเปลี่ยนแปลงใด ๆ ของรายการฐานข้อมูล PNG จะหมายถึงการดาวน์โหลดรายการทั้งหมดในไฟล์ Manifest (ข่าวร้ายจริงๆ!)

• WebStorage

  • CON: ออกแบบมาเพื่อการจัดเก็บ JSON
  • CON: สามารถจัดเก็บ blobs ผ่านการเข้ารหัส base64 เท่านั้น (อาจเป็นข้อบกพร่องร้ายแรงเนื่องจากค่าใช้จ่ายในการเข้ารหัส)
  • CON: ขีด จำกัด ฮาร์ด 5MB สำหรับ webStorage http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html

• PhoneGap และ SQLLite

  • ข้อเสีย: ผู้สนับสนุนจะปฏิเสธเป็นแอปเนทีฟที่ต้องการการรับรอง

• ไฟล์ ZIP

  • เซิร์ฟเวอร์สร้างไฟล์ zip วางไว้ใน wwwroot และแจ้งให้ลูกค้าทราบ
  • ผู้ใช้ต้องทำการคลายซิปด้วยตนเอง (อย่างน้อยก็คือวิธีที่ฉันเห็น) และบันทึกลงในระบบไฟล์ไคลเอ็นต์
  • เว็บแอปใช้ FileSystem API เพื่ออ้างอิงไฟล์
  • ข้อเสีย: ZIP อาจใหญ่เกินไป (zip64?) ใช้เวลานานในการสร้าง
  • CON: ไม่แน่ใจว่า FileSystem API สามารถอ่านออกจาก sandbox ได้ตลอดเวลาหรือไม่ (ฉันคิดอย่างนั้น)

• USB หรือการ์ด SD (ย้อนกลับไปในยุคหิน .... )

  • ผู้ใช้จะอยู่ในเครื่องเซิร์ฟเวอร์ก่อนที่จะออฟไลน์
  • เราจะให้เขาใส่การ์ด SD แล้วให้เซิร์ฟเวอร์เติมไฟล์ PNG
  • จากนั้นผู้ใช้จะเสียบเข้ากับแล็ปท็อปแท็บเล็ต
  • เว็บแอปจะใช้ FileSystem API เพื่ออ่านไฟล์
  • CON: ไม่แน่ใจว่า FileSystem API สามารถอ่านออกจาก sandbox ได้ตลอดเวลาหรือไม่ (ฉันคิดอย่างนั้น)

• WebSQL

  • CON: w3c ละทิ้งมันไป (ค่อนข้างแย่)
  • ฉันอาจพิจารณา Javascript wrapper ที่ใช้ IndexedDB และ WebSQL เป็นตัวสำรอง

• FileSystem API

  • Chrome รองรับการอ่าน / เขียน blobs
  • ข้อเสีย: ไม่ชัดเจนเกี่ยวกับ IE และ FireFox (IE10 มี msSave ที่ไม่ได้มาตรฐาน)
  • caniuse.com รายงานการรองรับ IOS และ Android (แต่อีกครั้งนี่เป็นเพียง r / w ของ JSON หรือรวมถึง blob API สำหรับการเขียนด้วย?
  • ข้อเสีย: ผู้คน FireFox ไม่ชอบ FileSystem API และไม่ชัดเจนว่าพวกเขารองรับการบันทึก blobs หรือไม่: https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
  • PRO: มากเร็วกว่า IndexedDB สำหรับ blobs ตาม jsperf http://jsperf.com/indexeddb-vs-localstorage/15 (หน้า 2)

• IndexedDB

  • รองรับ IE10, FireFox ได้ดี (บันทึก, อ่าน blobs)
  • ความเร็วที่ดีและการจัดการที่ง่ายกว่าระบบไฟล์ (ลบอัปเดต)
  • PRO: ดูการทดสอบความเร็ว: http://jsperf.com/indexeddb-vs-localstorage/15
  • ดูบทความนี้เกี่ยวกับการจัดเก็บและแสดงภาพใน IndexedDB: https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
  • ข้อเสีย: ฉันยืนยันว่า Chrome ยังไม่รองรับการเขียนแบบหยด (ข้อบกพร่องในปัจจุบัน แต่ไม่ชัดเจนว่าจะได้รับการแก้ไขเมื่อใด)
  • อัปเดต: บล็อกโพสต์เดือนมิถุนายน 2014แนะนำว่า Chrome รองรับ Blobs ในรูปแบบIndexedDB
  • อัปเดต: caniuse / indexeddbยืนยัน: "Chrome 36 และต่ำกว่าไม่สนับสนุนวัตถุ Blob เป็นค่า indexedDB"; แนะนำ> Chrome36 รองรับวัตถุ Blob

• LawnChairเสื้อคลุม JavaScript http://brian.io/lawnchair/

  • PRO: Wrapper ที่สะอาดมากสำหรับ IndexedDB, WebSQL หรือฐานข้อมูลใด ๆ ที่คุณมี (คิดว่าเป็น polyfill)
  • CON: ไม่สามารถจัดเก็บ binary blobs ได้เฉพาะข้อมูล: uri (การเข้ารหัส base64) (อาจเป็นข้อบกพร่องที่ร้ายแรงเนื่องจากค่าใช้จ่ายในการเข้ารหัส)

• IndexedDB JQUERY polyFill https://github.com/axemclion/jquery-indexeddb

  • Parashuram เขียน JQUERY wrapper ที่ดีสำหรับอินเทอร์เฟซ IndexedDB แบบดิบ
  • PRO: ทำให้การใช้ IndexedDB ง่ายขึ้นมากฉันหวังว่าจะเพิ่ม shim / polyfill สำหรับ Chrome FileSystemAPI
  • ข้อเสีย: ควรจัดการกับ blobs แต่ฉันไม่สามารถใช้งานได้

• idb.filesystem.js http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api

  • Eric Bidelman @ Google ได้เขียน PolyFill FileSystem API ที่ผ่านการทดสอบมาเป็นอย่างดีซึ่งใช้ Indexed DB เป็นตัวสำรอง
  • PRO: FileSystem API เหมาะสำหรับการจัดเก็บ blobs
  • PRO: ใช้งานได้ดีกับ FireFox และ Chrome
    • PRO: เหมาะสำหรับการซิงโครไนซ์กับ CouchDB บนคลาวด์
  • CON: ไม่ชัดเจนว่าทำไม แต่มันไม่ทำงานบน IE10

• PouchDB JavaScript Library http://pouchdb.com/

  • เหมาะสำหรับการซิงค์ CouchDB กับฐานข้อมูลท้องถิ่น (ใช้ WebSQL หรือ IndexedDB (ไม่ใช่ปัญหาของฉัน)
  • ข้อเสีย: ไม่มีข้อตกลงตอนนี้ PouchDB รองรับ binary blobs สำหรับเบราว์เซอร์ล่าสุดทั้งหมด (IE, Chrome, Firefox, Chrome บนมือถือ ฯลฯ ) รวมถึงเบราว์เซอร์รุ่นเก่าจำนวนมาก นั่นไม่ใช่กรณีแรกที่ฉันโพสต์นี้

หมายเหตุ: หากต้องการดูข้อมูล: การเข้ารหัส uri ของ PNG ฉันสร้างตัวอย่างที่: http://jsbin.com/ivefak/1/edit

คุณสมบัติที่ต้องการ / มีประโยชน์ / ไม่จำเป็น

• ไม่มีแอปเนทีฟ (EXE, PhoneGap, ObjectiveC ฯลฯ ) บนไคลเอนต์ (แอปพลิเคชันเว็บแท้)
• ต้องทำงานบน Chrome, FireFox, IE10 ล่าสุดสำหรับแล็ปท็อปเท่านั้น
• ต้องการโซลูชันเดียวกันสำหรับแท็บเล็ต Android (IOS ก็น่าจะดีเช่นกัน) แต่ต้องการเบราว์เซอร์เดียวเท่านั้นที่จะทำงานได้ (FF, Chrome ฯลฯ )
• ประชากร DB เริ่มต้นอย่างรวดเร็ว
• สิ่งที่ต้องมี: การดึงภาพอย่างรวดเร็วโดยใช้เว็บแอปพลิเคชันจากที่จัดเก็บข้อมูล (DB, ไฟล์)
• ไม่ได้มีไว้สำหรับผู้บริโภค เราสามารถ จำกัด เบราว์เซอร์และขอให้ผู้ใช้ทำการตั้งค่าและงานพิเศษได้ แต่จะลดขนาดนั้นลง

การใช้งาน IndexedDB

• มีบทความที่ยอดเยี่ยมเกี่ยวกับการใช้งาน IE, FF และ Chrome ภายในที่: http://www.aaron-powell.com/web/indexeddb-storage
• ในระยะสั้น:
  • IE ใช้รูปแบบฐานข้อมูลเดียวกับ Exchange และ Active Directory สำหรับ IndexedDB
  • Firefox ใช้ SQLite ดังนั้นจึงเป็นการใช้ฐานข้อมูล NoSQL ในฐานข้อมูล SQL
  • Chrome (และ WebKit) ใช้ที่เก็บคีย์ / ค่าซึ่งมีมรดกใน BigTable

ผลลัพธ์ปัจจุบันของฉัน

• ฉันเลือกที่จะใช้แนวทาง IndexedDB (และ polyfill ด้วย FileSystemAPI สำหรับ Chrome จนกว่าพวกเขาจะให้การสนับสนุน Blob)
• สำหรับการดึงกระเบื้องฉันมีปัญหาเนื่องจากคน JQUERY กำลังคิดเกี่ยวกับการเพิ่มสิ่งนี้ใน AJAX
• ฉันไปกับ XHR2-Lib โดย Phil Parsons ซึ่งเหมือนกับ JQUERY .ajax () https://github.com/pmp/xhr2-lib
• ประสิทธิภาพสำหรับการดาวน์โหลด 100MB (IE10 4s, Chrome 6s, FireFox 7s)
• ฉันไม่สามารถนำเครื่องห่อ IndexedDB มาใช้กับ blobs (เก้าอี้สนามหญ้า, PouchDB, jquery-indexeddb ฯลฯ )
• ฉันรีดเสื้อคลุมของตัวเองและประสิทธิภาพคือ (IE10 2s, Chrome 3s, FireFox 10s)
• ด้วย FF ฉันคิดว่าเรากำลังเห็นปัญหาประสิทธิภาพของการใช้ฐานข้อมูลเชิงสัมพันธ์ (sqllite) สำหรับที่เก็บข้อมูลที่ไม่ใช่ sql
• หมายเหตุ Chrome มีเครื่องมือดีบักที่โดดเด่น (แท็บนักพัฒนาทรัพยากร) สำหรับตรวจสอบสถานะของ IndexedDB

ผลลัพธ์สุดท้ายโพสต์ไว้ด้านล่างเป็นคำตอบ

อัปเดต

ขณะนี้ PouchDB รองรับ binary blobs สำหรับเบราว์เซอร์ล่าสุดทั้งหมด (IE, Chrome, Firefox, Chrome บนมือถือ ฯลฯ ) รวมถึงเบราว์เซอร์รุ่นเก่าอีกมากมาย นั่นไม่ใช่กรณีแรกที่ฉันโพสต์นี้

ผลลัพธ์ออฟไลน์ blob cache สำหรับแผนที่ลื่นไถล PNG

การทดสอบ

• ไฟล์ PNG 171 ไฟล์ (รวม 3.2MB)
• แพลตฟอร์มที่ทดสอบ: Chrome v24, FireFox 18, IE 10
• ควรทำงานร่วมกับ Chrome & FF สำหรับ Android

ดึงข้อมูลจากเว็บเซิร์ฟเวอร์

• ใช้ XHR2 (รองรับบนเบราว์เซอร์เกือบทั้งหมด) สำหรับการดาวน์โหลดหยดจากเว็บเซิร์ฟเวอร์
• ฉันไปกับ XHR2-Lib โดย Phil Parsons ซึ่งเหมือนกับ JQUERY มาก .ajax ()
  • https://github.com/pmp/xhr2-lib

การจัดเก็บ

• IndexedDB สำหรับ IE และ FireFox
• Chrome: Polyfill (blob ที่จัดเก็บโดยใช้ FileSystem API อ้างอิงเก็บไว้ใน IndexedDB) polyfill
• ต้องอ่านบทความเกี่ยวกับ "วิธีที่เบราว์เซอร์จัดเก็บข้อมูล IndexedDB"
  • http://www.aaron-powell.com/web/indexeddb-storage
• หมายเหตุ: FireFox ใช้ SQLlite สำหรับ NOSQL IndexedDB นั่นอาจเป็นสาเหตุของการทำงานที่ช้า (blobs เก็บแยกต่างหาก)
• หมายเหตุ: Microsoft IE ใช้เอ็นจิ้นการจัดเก็บที่ขยายได้:
  • http://en.wikipedia.org/wiki/Extensible_Storage_Engine
• หมายเหตุ: Chrome ใช้ LevelDB http://code.google.com/p/leveldb/

แสดง

• ฉันใช้ Leaflet http://leafletjs.com/เพื่อแสดงไทล์แผนที่
• ฉันใช้ปลั๊กอินเลเยอร์ไทล์ที่ใช้งานได้โดย Ishmael Smyrnow เพื่อดึงเลเยอร์ไทล์จาก DB
  • https://github.com/ismyrnow/Leaflet.functionaltilelayer
• ฉันเปรียบเทียบเลเยอร์กระเบื้องที่ใช้ฐานข้อมูลกับที่เก็บข้อมูลในเครื่อง (localhost: //) ล้วนๆ
• มีประสิทธิภาพไม่แตกต่างกันอย่างเห็นได้ชัด! ระหว่างการใช้ IndexedDB และไฟล์ในเครื่อง!

ผล

• Chrome: Fetch (6.551 วินาที), Store (8.247 วินาที), เวลาที่ผ่านไปทั้งหมด: (13.714 วินาที)
• FireFox: ดึงข้อมูล (0.422 วินาที), ร้านค้า (31.519 วินาที), เวลาที่ผ่านไปทั้งหมด: (32.836 วินาที)
• IE 10: การดึงข้อมูล (0.668 วินาที), ร้านค้า: (0.896 วินาที), เวลาที่ผ่านไปทั้งหมด: (3.758 วินาที)

สำหรับความต้องการของคุณฉันขอแนะนำให้พัฒนา polyfill ใหม่โดยใช้สองตัวอื่น ๆ ได้แก่ FileSystem API ไปยัง IndexedDBและIndexedDB ไปยัง WebSQL - เป็นตัวเลือกที่ดีที่สุด

ก่อนหน้านี้จะเปิดใช้งานการสนับสนุนการจัดเก็บ blobs ใน Chrome (FileSystem API) และ Firefox (IndexedDB) ในขณะที่รุ่นหลังควรให้การสนับสนุนสำหรับ Android และ iOS ( WebSQL ) สิ่งที่จำเป็นคือการทำให้ polyfills เหล่านี้ทำงานร่วมกันและฉันคิดว่ามันไม่ยาก

หมายเหตุ:เนื่องจากฉันไม่พบข้อมูลใด ๆ บนเว็บเกี่ยวกับเรื่องนี้คุณควรทดสอบว่าการจัดเก็บ blobs โดยใช้ 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(" ")

ที่มา

ฉันมีตัวอย่างการแคชแผนที่( ตัวอย่างแบบเปิดค้นหาพื้นที่และซูมสลับออฟไลน์และภูมิภาคที่ค้นพบจะพร้อมใช้งาน)

มีmap.js- เลเยอร์แผนที่สำหรับไทล์ออฟไลน์storage.js- การใช้งานพื้นที่จัดเก็บตาม IndexedDb และ WebSQL (แต่นี่เป็นเพียงการทดสอบการใช้งานที่มีประสิทธิภาพต่ำ)

• สำหรับไฟล์ไซต์ (html, css, js และอื่น ๆ ) ฉันชอบใช้แคชของแอปพลิเคชัน
• สำหรับพื้นที่จัดเก็บฉันชอบใช้ Indexed DB (support blob), Web SQL (เฉพาะ base64), FileWriter (รองรับ blob แต่เฉพาะ chrome) การจัดเก็บอย่างตรงไปตรงมาเป็นเรื่องใหญ่สำหรับเรื่องนี้ คุณต้องการโซลูชันค่าคีย์ที่เร็วที่สุดซึ่งจะผสมผสานทั้งหมด ฉันคิดว่าเป็นการตัดสินใจที่ดีที่จะใช้โซลูชันที่มีอยู่
• สำหรับการดึงฉันใช้ผ้าใบกับ CORS แต่ฉันคิดเกี่ยวกับ WebWorkers และ XHR2 และสิ่งนี้อาจดีกว่า canvas เนื่องจาก canvas มีปัญหากับ CORS ในเบราว์เซอร์ที่แตกต่างกันและอื่น ๆ (เช่นชื่อนี้ถูกเก็บไว้ไม่ดีในโอเปร่า )

ข้อมูลเพิ่มเติมเกี่ยวกับขนาดของเมือง 2 พันล้าน ( มินสค์ ):

• ซูม - 9, กระเบื้อง - 2, ขนาด - 52 กิโลไบต์ก่อนหน้า - 52 กิโลไบต์;
• ซูม - 10, กระเบื้อง - 3, ขนาด - 72 กิโลไบต์ก่อนหน้า - 124 กิโลไบต์;
• ซูม - 11 กระเบื้อง - 7 ขนาด - 204 กิโลไบต์ก่อนหน้า - 328 กิโลไบต์;
• ซูม - 12 กระเบื้อง - 17 ขนาด - 348 กิโลไบต์ก่อนหน้า - 676 ​​กิโลไบต์
• ซูม - 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;

ไม่กี่ปีที่ผ่านมา (ไม่ใช่ยุคหิน) ฉันใช้ java applet ที่ลงนามซึ่งจะค้นหาเซิร์ฟเวอร์เพื่อซิงค์ / อัปเดตข้อกำหนดดาวน์โหลดไฟล์ที่เหมาะสมจากเซิร์ฟเวอร์และบันทึกลงในระบบไฟล์ของผู้ใช้ (ไม่ใช่ฐานข้อมูล) วิธีนี้อาจใช้ได้ผลสำหรับคุณแม้ว่าคุณจะต้องมีคนเขียนแอพเพล็ตและเซ็นชื่อก็ตาม สำหรับโซลูชันฐานข้อมูลแอพเพล็ตดังกล่าวสามารถใช้ jdbc ที่มีให้สำหรับฐานข้อมูลส่วนใหญ่โดยใช้ localhost บนพอร์ตที่เหมาะสม (เช่น 3306 สำหรับ MySQL) ฉันเชื่อว่าแท็กแอพเพล็ตเลิกใช้งานใน Html5 แล้ว แต่ก็ยังใช้งานได้ ไม่มีประสบการณ์บนแท็บเล็ต Android จึงไม่สามารถแสดงความคิดเห็นในส่วนนั้นได้