IndexedDB: 瀏覽器裏內置的數據庫簡介

時間 2019-11-11

原文原文鏈接

1、概述：

全部的應用程序都須要「數據」支持。對於大多數的Web應用程序來講，數據是在服務器端進行組織和整理，而後由客戶端（瀏覽器端）經過網絡請求獲取。隨着瀏覽器的處理能力不斷加強，能夠在瀏覽器端存儲和操縱應用程序須要的數據，所以愈來愈多的網站開始考慮，將大量數據儲存在本地客戶端，這樣能夠減小用戶等待從服務器端獲取數據的時間。javascript

現有的瀏覽器端數據儲存方案，都不適合儲存大量數據。Cookie不超過4KB，且每次請求都會發送回服務器端；Window.name屬性缺少安全性，且沒有統一的標準；LocalStorage容量在2.5MB到10MB之間，且其以字符串形式進行存儲。所以，須要一種新的技術解決方案，這就是IndexedDB誕生的背景。html

IndexedDB 是一種瀏覽器端文檔數據庫，能夠被網頁腳本程序建立和操做。它容許儲存大量數據，而且提供查詢接口，且能夠創建索引。這些特性都是localStorage技術所不具有的。就數據庫類型而言，IndexedDB不屬於關係型數據庫（不支持SQL查詢語句），更接近NoSQL數據庫。關係型數據庫（如SQL Server，MySQL，Oracle等）的數據存儲在表中；文檔數據庫（如MongoDB，CouchDB，Redis）將數據集做爲個體對象來存儲。
經過使用IndexedDB，開發者能夠經過慣於在服務器端數據庫幾乎相同的方式進行建立、讀取、更新和刪除大量數據記錄的操做。前端

IndexedDB具有如下幾項特色：
（1）鍵值對儲存（Key-Value）
IndexedDB內部採用對象倉庫（object store）存放數據。全部類型的數據均可以直接存入，包括JavaScript對象。在對象倉庫中，數據以「鍵值對」的形式保存，每個數據都有對應的鍵名，且鍵名必須是獨一無二的，不能有重複，不然會拋出錯誤。html5

（2）異步API（asynchronous API ）
IndexedDB數據庫在執行增、刪、改和查的操做時不會鎖死瀏覽器，用戶依然能夠進行其它操做。相比之下，localStorage的操做都是同步的。異步設計是爲了防止大量數據的讀寫時拖慢網頁，而影響用戶的網站體驗。java

（3）支持事務（transaction）
IndexedDB支持事務（transaction），這意味着一系列操做步驟之中，只要有一步失敗，整個事務就都取消，數據庫回到事務發生以前的狀態，不存在只改寫一部分數據的狀況。git

（4）同域限制
IndexedDB也受到同域限制，每個數據庫對應建立該數據庫的域名。來自不一樣域名的網頁，只能訪問自身域名下的數據庫，而不能訪問其餘域名下的數據庫。github

（5）存儲空間大
IndexedDB的存儲空間比localStorage大得多，通常來講很多於250MB。IE的儲存上限是250MB，Chrome和Opera是硬盤剩餘空間的某個百分比，Firefox則沒有上限。web

（6）支持二進制儲存
IndexedDB不只能夠儲存字符串，還能夠儲存二進制數據。數據庫

2、IndexedDB VS LocalStorage, Web SQL, Cookies

IndexedDB VS LocalStorage

IndexedDB和LocalStorage都是用來在瀏覽器裏存儲數據，但它們使用不一樣的技術，有不一樣的用途，你須要根據本身的狀況適當的選擇使用哪一種。api

LocalStorage是用key-value鍵值模式存儲數據，但跟IndexedDB不同的是，它的數據並非按對象形式存儲。它存儲的數據都是字符串形式。若是你想讓LocalStorage存儲對象，你須要藉助JSON.stringify()能將對象變成字符串形式，再用JSON.parse()將字符串還原成對象。但若是要存儲大量的複雜的數據，這並非一種很好的方案。畢竟，localstorage就是專門爲小數量數據設計的，它的api是同步的。

IndexedDB很適合存儲大量數據，它的API是異步調用的。IndexedDB使用索引存儲數據，各類數據庫操做放在事務中執行。IndexedDB甚至還支持簡單的數據類型。IndexedDB比localstorage強大得多，但它的API也相對複雜。對於簡單的數據，你應該繼續使用localstorage，但當你但願存儲大量數據時，IndexedDB會明顯的更適合，IndexedDB能提供給你更爲複雜的查詢數據的方式。

IndexedDB VS Web SQL

WebSQL也是一種在瀏覽器裏存儲數據的技術，跟IndexedDB不一樣的是，IndexedDB更像是一個NoSQL數據庫，而WebSQL更像是關係型數據庫，使用SQL查詢數據。W3C已經再也不支持這種技術。具體狀況請看：http://www.w3.org/TR/webdatabase/。由於再也不支持，因此你就不要在項目中使用這種技術了。

IndexedDB VS Cookies

Cookies(小甜點)聽起來很好吃，但實際上並非。每次HTTP接受和發送都會傳遞Cookies數據，它會佔用額外的流量。例如，若是你有一個10KB的Cookies數據，發送10次請求，那麼，總計就會有100KB的數據在網絡上傳輸。Cookies只能是字符串。瀏覽器裏存儲Cookies的空間有限，不少用戶禁止瀏覽器使用Cookies。因此，Cookies只能用來存儲小量的非關鍵的數據。

3、IndexedDB架構及技術實現

IndexedDB的架構很像在一些流行的服務器端NoSQL數據庫實現中的設計典範類型。面向對象數據經過object stores(對象倉庫)進行持久化，全部操做基於請求同時在事務範圍內執行；事件生命週期使你可以控制數據庫的配置，錯誤經過錯誤冒泡來使用API管理。

IndexedDB之打開數據庫的請求生命週期（Life cycle）

瀏覽器原生提供indexedDB對象，能夠經過window.indexedDB來直接獲取到瀏覽器提供的該對象，做爲開發者的操做接口。IndexedDB.open方法用於打開瀏覽器本地數據庫。
IndexedDB使用事件生命週期管理數據庫的打開和配置操做。

IndexedDB之基於請求（Request）

對數據庫的每次操做，能夠描述爲經過一個請求打開數據庫，訪問一個object store，再繼續。IndexedDB API天生是基於請求的，這也是異步API本性所示。對於在數據庫執行的每次操做，都必須首先爲這個操做建立一個請求。當該請求完成，能夠響應由請求結果產生的事件或錯誤。

IndexedDB之對象倉庫（Object Store）

Object store是IndexedDB數據庫的基礎。Object store至關於關係型數據庫中的一張張記錄數據的表。Object stores中包括一個或多個索引(index)，在store中按照一對鍵-值操做，這提供了一種快速定位數據的方法。

IndexedDB之一切操做基於事務（Transaction）

不一樣於一些傳統的關係數據庫的實現，每個對數據庫操做是在一個事務的上下文中執行的。事務範圍一次影響一個或多個object stores，你經過傳入一個object store名字的數組到建立事務範圍的函數來定義。

建立事務的第二個參數是事務模式。當請求一個事務時，必須決定是按照只讀(ReadOnly)仍是讀寫(ReadWrite)模式請求訪問。事務是資源密集型的，因此若是你不須要更改data store中的數據，你只須要以只讀模式對object stores集合進行請求訪問。

IndexedDB之錯誤冒泡

固然，有時候，請求可能不會按預期完成。IndexedDB API經過錯誤冒泡功能來幫助跟蹤和管理錯誤。若是一個特定的請求遇到錯誤，你能夠嘗試在請求對象上處理錯誤，或者你能夠容許錯誤經過調用棧冒泡向上傳遞。這個冒泡天性，使得你不須要爲每一個請求實現特定錯誤處理操做，而是能夠選擇只在一個更高級別上添加錯誤處理，它給你一個機會，保持你的錯誤處理代碼簡潔。
Try……catch機制。