IndexedDB與WebSQL相比非常慢，我做錯了什麼？

我做了一個演示chrome擴展來比較websql和indexeddb，並瞭解如何在更詳細的工作。IndexedDB與WebSQL相比非常慢，我做錯了什麼？

令我驚訝的是，它表明，即使與最天真的sql命令相比，indexeddb也要慢很多。

由於websql已被棄用，贊成indexeddb我認爲indexeddb將會比websql更快或更快。

我假設我在indexeddb代碼中做錯了什麼。因爲棄用速度更快的東西會很愚蠢，我認爲他們知道他們在棄用websql時贊成使用indexeddb時所做的操作。

的SQL查詢碼：

// Search entries 
     var term = search_query; 
     db.transaction(function(tx) { 
      tx.executeSql('SELECT * FROM places', [], function (tx, results) { 
       console.log("sql search"); 
       var count = 0; 
       var wm = WordsMatch.init(term.trim().toLowerCase()); 
       var len = results.rows.length 
       for (var i = 0; i < len; ++i) { 
        var item = results.rows.item(i); 
        if (wm.search(item.url.toLowerCase())) { 
         //console.log(item.id, item.url); 
         ++count; 
        } 
       } 
       console.log("Search matches:", count); 
       console.log("\n"); 
      }); 
     }, reportError);

的IndexedDB的搜索代碼：

PlacesStore.searchPlaces(search_query, function(places) { 
        console.log("indexedDB search"); 
        var count = places.length; 
        console.log("Search matches:", count); 
        console.log("\n"); 
       }); 

var PlacesStore = { searchPlaces: function (term, callback) { 
     var self = this, 
      txn = self.db.transaction([self.store_name], IDBTransaction.READ_ONLY), 
      places = [], 
      store = txn.objectStore(self.store_name); 
     var wm = WordsMatch.init(term.trim().toLowerCase()); 
     Utils.request(store.openCursor(), function (e) { 
      var cursor = e.target.result; 
      if (cursor) { 
       if (wm.search(cursor.value.url.toLowerCase())) { 
        places.push(cursor.value); 
       } 

       cursor.continue(); 
      } 
      else { 
       // we are done retrieving rows; invoke callback 
       callback(places); 
      } 
     }); 
    } 
}/**/ 


var Utils = { 
    errorHandler: function(cb) { 
     return function(e) { 
      if(cb) { 
       cb(e); 
      } else { 
       throw e; 
      } 
     }; 
    }, 

    request: function (req, callback, err_callback) { 
     if (callback) { 
      req.onsuccess = function (e) { 
       callback(e); 
      }; 
     } 
     req.onerror = Utils.errorHandler(err_callback); 
    } 
};

我也做了鍍鉻bug報告，並上載有完整的擴展代碼： http://code.google.com/p/chromium/issues/detail?id=122831

（我不能在這裏上傳擴展zip文件，沒有這個功能）

我填充了websql和indexeddb數據庫，每個數據庫都有38862個用作測試數據的URL。

來源

2012-04-11 user1309439

答：你沒有做錯什麼。您的IndexedDB代碼是正確的。至於結論，其他have found this to be true以及。

附加說明：需要注意的一點是，IndexedDB在不同瀏覽器之間的實現方式不同。 Firefox使用SQLLite和Chrome LevelDB，所以即使你在FF中使用IndexedDB，你仍然在使用SQL支持的技術以及類似SQL的開銷（加上其他所有內容）。

我會很好奇在不同大小的數據庫中看到您的結果。我希望，但還不能證實，IndexedDB可以在更大的數據集上擴展更好（儘管38862似乎足夠大）。

來源

2012-04-11 17:48:02 buley

在哪個宇宙是38862一個「大」數據集？ – ocodo 2014-07-23 03:17:47

在客戶端存儲領域。 – buley 2014-07-27 00:59:32

問題的一部分是IndexedDB實現迄今爲止大部分都在努力實現完整規範，並且不太關注性能。我們最近在Firefox中發現了一些非常愚蠢的錯誤，並且這些錯誤會讓我們更快。

我知道鉻團隊由於其多進程架構而遭受了一些挑戰。我被告知他們最近解決了一些這些問題。

所以我鼓勵你嘗試所有瀏覽器的最新版本，可能包括夜間/金絲雀版本。

但是請注意，我們並沒有棄用WebSQL，因爲IndexedDB速度更快。我們棄用WebSQL是因爲它不是未來的證據。 WebSQL被定義爲使用特定的SQLite後端（如果你看看它的實際寫在那裏的規格）。然而，所有的瀏覽器製造商都需要使用最新版本的SQLite來獲取安全性，性能和穩定性修正。最新版本總是以微妙的方式更改SQL語法。這意味着我們會以微妙的方式打破WebSQL使用的Web應用程序。這對我們來說似乎並不合適。

來源

2012-06-15 23:30:40

很有意思！ – buley 2012-08-27 22:36:55

令人驚訝的是，只有Mozilla在SQLite中存在這個問題。 Android，iOS，Symbian和成千上萬的其他開發者喜愛SQLite。 – 2012-10-06 06:59:04

chrome和firefox的indexeddb版本仍然很慢？ *相對 – 2012-10-10 05:05:33

IndexedDB與WebSQL相比非常慢，我做錯了什麼？

回答

相關問題