html - 索引数据库性能

Question

谁能指点我一篇关于 IndexedDB 性能的文章，或者最好提供一些关于 IndexedDB 性能的经验（最好是在 Chrome 中）——获取、插入和更新性能是什么样的？

似乎有合理的意见认为它对于超过几千条记录的数据集几乎无法使用，但我不确定这是否仅仅是由于缺乏索引 - 当然从概念上讲它不能比网络存储慢两者都可能在内部使用键值存储？

谢谢

score 13 · Accepted Answer

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

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

编辑：上面的 URL 已关闭，但可在 archive.org 上找到：http://web.archive.org/web/20160418233232/http: //blog.oharagroup.net/post/16394604653/a-performance-comparison-websql -vs-indexeddb

总之：

WebSQL 平均需要大约 750-850 毫秒来完成查询并呈现结果；IndexedDB 平均需要大约 300-350 毫秒来呈现完全相同的结果。

score 11 · Accepted Answer

我见过的唯一性能文章是由@Scott（该问题的另一个答案的作者）制作的。不幸的是，他的文章没有做到 Web SQL 数据库公正，因为它使用低效的 HAVING 子句来限制结果集的大小。我调整了 Scott 的 SQL，用（几乎）等效的 WHERE 和子选择替换了 HAVING、GROUP BY 和 LEFT JOIN：

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

这比原来的速度快了大约 28 倍——在我的计算机上是 20 毫秒对 560 毫秒——根据 Scott 的数字推断，它比等效的 IndexedDB 快了大约 10 倍。我无法确认这一点，因为 IndexedDB 代码在我的浏览器中不起作用，似乎是由于 API 更改。

我应该解释一下我上面写的“（几乎）”。Scott 的原始 SQL 和我的 SQL 有微妙的不同含义：我的 EpisodeCount 上的一个免费的 WHERE 子句——它具有用索引搜索替换表扫描的效果——如果它没有涵盖所有可能的 Status 值，则可能无法计算某些情节。删除此子句以将执行时间加倍至 40 毫秒为代价消除了差异。

请注意，早些时候，我与 Scott 讨论了对他的 SQL 的较小更改，该更改也达到了 40 毫秒的时间。

更新：非常感谢 Scott 更新他的文章以承认我们的讨论。

score 2 · Accepted Answer

在 IndexeDB 与其他客户端和服务器端数据库之间进行一些性能比较。性能取决于浏览器，因为 IndexeDB API 的 Firefox 实现比 Chrome 或 IE 领先得多。Firefox 使用 SQLlite 作为后端数据库，因此 IndexedDB 是在它之上实现的。您可以找到很多关于 IndexedDB 性能的文章，但大多数研究人员和开发人员都说 IDB 使用 SQL 作为后端时性能更快。与在 LevelDB（即 NOSQL）之上实现 IDB 的 Chrome 实现相比，与 Firefox 相比要慢得多。另一方面，WEBSQL(depreciated) 在 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