索引数据库性能

Question

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

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

谢谢

Answer 1

在 IndexeDB 与其他客户端和服务器端数据库之间进行一些性能比较。性能取决于浏览器，因为 Firefox 的 IndexeDB API 实现比 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

Answer 2

我在大量插入时遇到问题（100.000 - 200.000 条记录）。我已经使用 Dexie 库解决了我所有的 IndexedDB 性能问题。它有一个重要的特点：

Dexie 的表现非常出色。它的批量方法利用 indexedDB 中一个不为人知的特性，它可以存储 不听每一个 onsuccess 事件的东西。这加快了 性能发挥到极致。

德西：https://github.com/dfahlander/Dexie.js

BulkPut() -> http://dexie.org/docs/Table/Table.bulkPut()

Answer 3

我最近对 ​​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 毫秒来呈现完全相同的结果。

Answer 4

我看到的唯一性能文章是the one produced by @Scott（the other answer to this question 的作者）。不幸的是，他的文章没有做到 Web SQL 数据库公正，因为它使用低效的 HAVING 子句来限制结果集的大小。我调整了 Scott 的 SQL，将 HAVING、GROUP BY 和 LEFT JOIN 替换为（几乎）等效的 WHERE 和子选择：

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 毫秒为代价消除差异。

请注意，之前，我discussed with Scott 对他的 SQL 进行了较小的更改，也达到了 40 毫秒的时间。

更新：非常感谢 Scott 更新他的article 以感谢我们进行的讨论。