Question

我制作了一个演示镀铬扩展来比较websql和indexeddb，并了解它们如何更详细地工作。

令我惊讶的是，它表明，与最天真的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);
    }
};

我还制作了一个Chrome错误报告，并在那里上传了完整的扩展程序代码： http://code.google.com/p/chromium/issues/detail?id=122831

（我不能在这里上传扩展名zip文件，没有这样的功能）

我在websql和indexeddb数据库中都填充了38862个用作测试数据的URL。

Answer 1

问题的一部分是到目前为止，IndexedDB实现主要是在实现完整的规范，而不是专注于性能。我们最近在Firefox中发现了一些非常愚蠢的错误，它们已得到修复，应该会让我们显着加快速度。

我知道Chrome团队因其多进程架构而面临一些挑战。我被告知他们最近已经解决了一些问题。

所以我鼓励您尝试所有浏览器的最新版本，可能包括夜间/金丝雀版本。

但请注意，我们没有弃用WebSQL，因为IndexedDB更快。我们弃用了WebSQL，因为它不是未来的证明。 WebSQL被定义为使用特定的SQLite后端（如果你查看它实际上在那里清楚地写的规范）。但是，所有浏览器制造商都需要使用最新版本的SQLite才能获得安全性，性能和稳定性修复。最新版本总是以微妙的方式更改SQL语法。这意味着我们将以微妙的方式破坏使用WebSQL的Web应用程序。这对我们来说似乎不太好。

Answer 2

答案：你没有做错任何事。您的IndexedDB代码是正确的。至于结论，其他人have found this to be true也是如此。

额外：有一点需要注意的是，IndexedDB在浏览器中的实现方式不同。 Firefox使用SQLLite和Chrome LevelDB，因此即使您在FF中使用IndexedDB，您仍然使用SQL支持的技术，具有类似SQL的开销（以及其他所有内容）。

我很想在不同大小的数据库中看到您的结果。我希望，但还不能证实，IndexedDB可以在更大的数据集中更好地扩展（尽管38862看起来确实足够大）。

与WebSQL相比，IndexedDB非常慢，我做错了什么？

2 个答案: