IndexedDB性能

Question

任何人都可以指向我的文章,或者最好提供一些IndexedDB(理想情况下是Chrome)的性能体验 - 获取,插入和更新性能如何？

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

谢谢

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

我见过的唯一表现是@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毫秒 - 通过斯科特的数字推断,它比同等的IndexedDB快10倍.我无法确认这一点,因为IndexedDB代码在我的浏览器中不起作用,似乎是由于API的变化.

我应该解释一下上面写的"(几乎)".Scott最初的SQL和我的SQL有着微妙的不同含义:我的EpisodeCount上的一个无偿的WHERE子句 - 它具有用索引搜索替换表扫描的效果 - 如果不覆盖所有可能的Status值,可能无法计算一些剧集.删除此子句会以将执行时间加倍到40 ms为代价来消除差异.

请注意,在早些时候,我与Scott讨论了对他的SQL的一个较小的改变,也达到了40毫秒的时间.

更新:非常感谢斯科特更新他的文章以承认我们的讨论.