IndexedDB性能

Question

有没有人能给我推荐一篇关于IndexedDB (最好是Chrome)性能的文章，或者最好能提供一些性能方面的经验--获取、插入和更新的性能是什么样的？

似乎有相当多的观点认为，它对于超过几千条记录的数据集几乎不可用，但我不确定这是否只是因为缺乏索引-从概念上讲，它不可能比web存储慢，因为两者都在内部使用键值存储？

谢谢

Answer 1

我最近在WebSQL和IndexedDB之间做了一些性能比较。令人惊讶的是，IndexedDB赢了(这是我没想到的)。

http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb

编辑:上述网址已关闭，但在archive.org上可用：http://web.archive.org/web/20160418233232/http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb

总而言之：

WebSQL完成查询并呈现结果平均耗时约750-850ms；IndexedDB呈现完全相同的结果平均耗时约300-350ms。

Answer 2

我见过的唯一一篇关于性能的文章是the one produced by @Scott (the other answer to this question的作者)。不幸的是，他的文章没有讨论Web SQL数据库的正义性，因为它使用了一个低效的HAVING子句来限制结果集的大小。我调整了Scott的SQL，将HAVING、GROUP BY和LEFT JOIN替换为(几乎)等效的WHERE和sub-selects：

SELECT p.Name AS ProgramName,
       s.rowid,
       s.Name,
       s.NowShowing,
       s.ProgramID,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS IN ('Watched', 'Recorded', 'Expected') OR STATUS IS NULL) AS EpisodeCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Watched') AS WatchedCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Recorded') AS RecordedCount,
       (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Expected') AS ExpectedCount
  FROM Program p
  JOIN Series s ON p.rowid = s.ProgramID
 WHERE s.NowShowing IS NOT NULL OR
       EXISTS (SELECT * FROM Episode WHERE SeriesID = s.rowid AND STATUS IN ('Recorded', 'Expected'))
ORDER BY CASE
           WHEN s.NowShowing IS NULL THEN 1
           ELSE 0
         END,
         s.NowShowing,
         p.Name

这比原来的IndexedDB快了28倍--在我的电脑上是20ms比560ms--从斯科特的数据推断，它比同等的IndexedDB快了大约10倍。我不能确认这一点，因为IndexedDB代码在我的浏览器中不能工作，似乎是由于API的改变。

我应该解释一下我上面写的“(几乎)”。Scott的原始SQL和我的原始SQL具有微妙的不同含义:我的EpisodeCount上的一个不必要的WHERE子句-它的效果是用索引搜索代替表扫描-如果它没有涵盖所有可能的状态值，可能无法计算某些事件。删除此子句将消除差异，代价是将执行时间增加一倍，达到40毫秒。

注意，在前面，我用discussed with Scott对他的SQL做了一个较小的更改，也达到了40ms的时间。

更新：非常感谢斯科特更新了他的article，承认了我们的讨论。

Answer 3

对IndexeDB与其他客户端和服务器端数据库进行了性能比较。性能取决于浏览器的性能，因为火狐实现的IndexeDB应用程序接口比Chrome或IE要先进得多。火狐使用SQLlite作为后端数据库，所以IndexedDB是在它上面实现的。你可以找到许多关于IndexedDB性能的文章，但大多数研究人员和开发人员都说，使用SQL作为后端时，IDB的性能更快。相比于在LevelDB之上实现IDB的Chrome实现(也就是NOSQL)，要比火狐慢得多。另一方面，WEBSQL(折旧)在Chrome中执行得很快，在Firefox中不再受支持。

我发表了一篇论文，其中包含一些IndexedDB性能结果。https://www.researchgate.net/profile/Stefan_Kimak/publication/281065948_Performance_Testing_and_Comparison_of_Client_Side_Databases_Versus_Server_Side/links/55d3465c08ae0a3417226302/Performance-Testing-and-Comparison-of-Client-Side-Databases-Versus-Server-Side.pdf