5

websql と indexeddb を比較し、両方がどのように機能するかを詳しく知るために、デモ chrome 拡張機能を作成しました。

驚いたことに、最も素朴な sql コマンドと比較しても、indexeddb はかなり遅いことがわかりました。

websql は indexeddb を優先して非推奨になっているため、indexeddb は websql と同じかそれ以上に高速であると想定しました。

indexeddb コードで何か間違ったことをしていると思います。はるかに高速なものを非推奨にするのはばかげているため、indexeddbを優先してwebsqlを非推奨にするときに何をしていたかを知っていたと思います。

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 をそれぞれ入力しました。

4

2 に答える 2

14

問題の一部は、これまでのところ、IndexedDB の実装が完全な仕様を実装することにほとんど取り組んでおり、パフォーマンスにはあまり重点を置いていなかったことです。私たちは最近、Firefox で非常にばかげたバグを発見しました。これらは修正され、大幅に高速化されるはずです。

マルチプロセス アーキテクチャが原因で、chrome チームがいくつかの課題に苦しんでいることは知っています。最近、これらの問題のいくつかが修正されたと言われています。

そのため、ナイトリー ビルドやカナリア ビルドを含め、すべてのブラウザーの最新バージョンを試すことをお勧めします。

ただし、IndexedDB の方が高速であったため、WebSQL を非推奨にしたわけではないことに注意してください。WebSQL は将来の証明ではなかったため、非推奨にしました。WebSQL は、特定の SQLite バックエンドを使用するように定義されています (仕様を見ると、実際にそこに明確に書かれています)。ただし、すべてのブラウザー メーカーは、セキュリティ、パフォーマンス、および安定性の修正プログラムを取得するために、SQLite の最新バージョンを使用する必要があります。また、最新バージョンでは常に SQL 構文が微妙に変更されています。つまり、WebSQL を使用する Web アプリケーションを微妙な方法で壊してしまうことになります。これは私たちにはうまくいきませんでした。

于 2012-06-15T23:30:40.543 に答える
8

回答：あなたは何も悪いことをしていません。IndexedDBコードは正しいです。結論として、他の人もこれが真実であることに気づきました。

追加：注目すべき興味深い点の1つは、IndexedDBの実装がブラウザー間で異なることです。FirefoxはSQLLiteとChromeLevelDBを使用しているため、FFでIndexedDBを使用している場合でも、SQLのようなオーバーヘッド（およびその他すべて）を備えたSQLに裏打ちされたテクノロジーを使用しています。

さまざまなサイズのデータ​​ベースで結果を確認したいと思います。IndexedDBがより大きなデータセット間でより適切にスケーリングされることを願っていますが、まだ確認できません（38862は十分に大きいように見えますが）。

于 2012-04-11T17:48:02.787 に答える