索引数据库性能

Question

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

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

谢谢

Answer 1

我最近对 ​​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 2

我见过的唯一一篇关于性能的文章是 由@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 毫秒 vs 560 毫秒 — 根据 Scott 的数据推断，使其比同等 IndexedDB 快约 10 倍。我无法确认这一点，因为 IndexedDB 代码在我的浏览器中不起作用，这似乎是由于 API 更改所致。

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

请注意，早些时候，我与 Scott 讨论过对 SQL 进行较小的更改，也实现了 40 毫秒的时间。

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

Answer 3

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

Dexie 的表现非常出色。它的批量方法利用
indexedDB 中一个不为人知的功能可以存储
不听每个 onsuccess 事件的东西。这加快了
性能最大化。

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

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

Answer 4

对 IndexeDB 与其他客户端和服务器端数据库进行一些性能比较。性能取决于浏览器，因为 Firefox 对 IndexeDB API 的实现比 Chrome 或 IE 领先得多。
Firefox 使用 SQLlite 作为后端数据库，因此 IndexedDB 是在其之上实现的。您可以找到许多有关 IndexedDB 性能的文章，但大多数研究人员和开发人员都说，使用 SQL 作为后端时，IDB 的性能更快。
与 Chrome 实现相比，IDB 是在 LevelDB（即 NOSQL）之上实现的，与 Firefox 相比要慢得多。另一方面，WEBSQL（已弃用）在 Chrome 中执行速度很快，但在 Firefox 中不再受支持。

我发表了一篇论文，其中包含一些 IndexedDB 性能结果。 <一href="https://www.researchgate.net/profile/Stefan_Kimak/publication/281065948_Performance_Testing_and_Comparison_of_Client_Side_Databas es_Versus_Server_Side/links/55d3465c08ae0a3417226302/客户端数据库与服务器端的性能测试和比较.pdf" rel="nofollow noreferrer">https://www.researchgate.net/profile/Stefan_Kimak/publication/281065948_Performance_Testing_and_Comparison_of_Client_Side_Databa ses_Versus_Server_Side/links/55d3465c08ae0a3417226302/客户端数据库与服务器端的性能测试和比较.pdf