2012-04-11 2 views
4

데모 크롬 확장을 사용하여 websql과 indexeddb를 비교하고 둘 다 더 자세히 작업하는 방법을 배웠습니다.WebSQL에 비해 IndexedDB가 매우 느리며, 무엇을 잘못하고 있습니까?

놀랍게도 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); 

색인화 된 검색 코드 :

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 구현이 전체 사양을 구현하고 성능에 초점을 맞추지 않는 데 주로 집중하고 있다는 점입니다. 우리는 최근 파이어 폭스에서 버그가 발견되어 상당히 빨리 수정해야하는 버그를 발견했습니다.

크롬 팀은 멀티 프로세스 아키텍처로 인해 몇 가지 어려움을 겪었습니다. 나는 최근에이 문제들 중 일부를 수정했다고 들었습니다.

야간/카나리아 빌드를 포함하여 모든 브라우저의 최신 버전을 사용해 보시기 바랍니다.

그러나 IndexedDB가 빠르기 때문에 WebSQL을 사용하지 않습니다. 우리는 미래의 증거가 아니기 때문에 WebSQL을 사용하지 않았습니다. WebSQL은 특정 SQLite 백엔드를 사용하도록 정의되었습니다 (실제로 여기에 명시된 사양을 보면). 그러나 모든 브라우저 제조업체는 보안, 성능 및 안정성 픽스를 받기 위해 최신 버전의 SQLite를 사용해야합니다. 그리고 최신 버전은 항상 SQL 구문을 미묘한 방식으로 변경합니다. 즉, 웹 애플리케이션을 사용하여 WebSQL을 미묘하게 손상 시켰을 것입니다. 이것은 우리에게 괜찮은 것 같지 않았습니다.

+0

매우 흥미 롭습니다! – buley

+0

모질라 만이 SQLite에 이런 문제가 있다는 것은 놀랍습니다. Android, iOS, Symbian 및 수천 명의 다른 개발자가 SQLite를 좋아합니다. –

+0

chrome과 firefox의 indexeddb 버전은 여전히 ​​느린가요? *상대적인 –