2012-04-11 105 views
4

私はwebsqlとindexeddbを比較するためのデモクロム拡張を行い、どちらの方法がより詳細に機能するかを学びました。IndexedDBはWebSQLに比べて非常に遅いですが、何が間違っていますか?

私の驚いたことに、indexeddbは最も単純なSQLコマンドと比べてもずっと遅いことがわかりました。

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); 
    } 
}; 

私はまた、クロムバグレポートを作って、そこに完全な拡張コードをアップロードしています http://code.google.com/p/chromium/issues/detail?id=122831

(私は拡張機能のzipファイルをここにアップロードすることはできません。そのような機能はありません)

テストデータとして使用した38862のURLを持つwebsqlデータベースとindexeddbデータベースの両方にデータを入力しました。

答えて

6

回答:あなたは間違ったことはしていません。あなたのIndexedDBコードは正しいです。結論は、他have found this to be trueでも同様です。

追加情報:興味深いことに、IndexedDBはさまざまなブラウザで実装されています。 FirefoxはSQLLiteとChrome LevelDBを使用しているため、FFでIndexedDBを使用していても、SQLのようなオーバーヘッド(他のすべてを含む)を持つSQLバックアップ技術を使用しています。

私は、異なるサイズのデータ​​ベースであなたの結果を見るのが好きです。私は望むが、まだ確認することはできないが、IndexedDBは大規模なデータセット(38862が十分に大きいと思われるにもかかわらず)の方がスケールが良くなることを願っている。

+2

ユニバースは38862の "大きな"データセットですか? – ocodo

+8

クライアント側のストレージユニバース内。 – buley

12

この問題の一部は、IndexedDBの実装では、これまでほとんどの場合、フルスペックの実装に取り​​組んできており、パフォーマンスに集中していませんでした。私たちは最近Firefoxでいくつかのバグを見つけました。これは修正されており、大幅に高速化するはずです。

私は、クロムチームがマルチプロセスアーキテクチャのためにいくつかの課題を抱えていることを知っています。私は最近、これらの問題のいくつかを修正したと言われています。

だから、夜間/カナリアのビルドを含むすべてのブラウザの最新バージョンをお試しください。

ただし、IndexedDBが高速だったためWebSQLを非推奨にしていないことに注意してください。我々はWebSQLを非難しました。将来的な証拠ではないからです。 WebSQLは、特定のSQLiteバックエンドを使用するように定義されています(実際にそこに明記されている仕様を見ると)。しかし、すべてのブラウザメーカーは、セキュリティ、パフォーマンス、および安定性の問題を解決するために最新バージョンのSQLiteを使用する必要があります。また、最新のバージョンでは、常にSQL構文が微妙に変更されています。つまり、微妙な方法でWebアプリケーションを使用してWebSQLを壊してしまったということです。これは私たちにとっては大丈夫だとは思わなかった。

+0

非常に興味深い! – buley

+0

これは、MozillaだけがSQLiteでこの問題を抱えていることは驚くべきことです。 Android、iOS、Symbianなど数多くの開発者がSQLiteを愛用しています。 –

+0

chromeとfirefoxのバージョンのindexeddbはまだ遅いですか? *相対 –

関連する問題