IndexedDB sehr langsam im Vergleich zu WebSQL, was mache ich falsch?

Question

Ich habe eine Demo-Chrome-Erweiterung erstellt, um websql und indexeddb zu vergleichen und zu lernen, wie beide ausführlicher arbeiten.

Zu meiner Überraschung zeigte sich, dass indexeddb viel langsamer ist, sogar im Vergleich zum naivsten SQL-Befehl.

Da websql zugunsten indexeddb veraltet ist, nahm ich an, indexeddb wäre so schnell oder schneller als websql.

Ich nehme an, ich mache etwas falsch im Indexeddb-Code. Weil etwas, das viel schneller ist, zu verwerfen, wäre dumm und ich nehme an, sie wussten, was sie taten, wenn sie websql zugunsten indexeddb abschätzten.

Der SQL-Suchcode:

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

Der IndexedDB Suchcode:

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

ich auch einen Chrom Bugreport gemacht und hochgeladen die volle Dateisuffix dort: http://code.google.com/p/chromium/issues/detail?id=122831

(Ich kann die Extension-Zip-Datei hier nicht hochladen, keine solche Funktion)

Ich füllte sowohl websql und indexeddb Datenbanken jeweils mit 38862 URLs, die ich als Testdaten verwendet.

Answer 1

Antwort: Sie machen nichts falsch. Ihr IndexedDB-Code ist korrekt. Wie für den Abschluss, andere have found this to be true als auch.

Extra: Eine interessante Sache zu beachten ist, dass IndexedDB in den verschiedenen Browsern unterschiedlich implementiert ist. Firefox verwendet SQLLite und Chrome LevelDB. Selbst wenn Sie IndexedDB in FF verwenden, verwenden Sie immer noch eine SQL-unterstützte Technologie mit SQL-ähnlichem Overhead (und allem anderen).

Ich wäre gespannt, Ihre Ergebnisse in Datenbanken unterschiedlicher Größe zu sehen. Ich hoffe, kann aber noch nicht bestätigen, dass IndexedDB bei größeren Datenmengen besser skalieren würde (auch wenn 38862 ausreichend groß erscheint).

Answer 2

Ein Teil des Problems besteht darin, dass IndexedDB-Implementierungen bisher größtenteils daran gearbeitet haben, die vollständige Spezifikation zu implementieren, und weniger auf die Leistung ausgerichtet waren. Wir haben kürzlich einige wirklich dumme Bugs in Firefox gefunden, die behoben wurden und uns wesentlich schneller machen sollten.

Ich weiß, dass das Chrome-Team aufgrund seiner Multi-Prozess-Architektur einige Probleme hatte. Mir wurde gesagt, dass sie in letzter Zeit einige dieser Probleme behoben haben.

Also ich würde Sie ermutigen, die neueste Version aller Browser zu versuchen, möglicherweise einschließlich nächtlichen/kanarischen Builds.

Beachten Sie jedoch, dass wir WebSQL nicht veraltet haben, da IndexedDB schneller war. Wir haben WebSQL für veraltet erklärt, weil es nicht zukunftssicher war. WebSQL wurde definiert, um ein bestimmtes SQLite-Backend zu verwenden (wenn man sich die Spezifikation anschaut, wird sie dort eindeutig geschrieben). Alle Browser-Hersteller müssen jedoch die neueste Version von SQLite verwenden, um Sicherheits-, Leistungs- und Stabilitätsprobleme zu beheben. Und die neuesten Versionen ändern immer die SQL-Syntax auf subtile Weise. Das bedeutet, dass wir Ihre WebSQL-verwendenden Webanwendungen auf subtile Art und Weise durchbrochen haben. Dies erschien uns nicht in Ordnung.