[FEATURE] Store the tracking data in IndexedDB

[Tokisaki-Galaxy]

连续使用了差不多三年，我的数据量挺大的，似乎有点点接近5mb的限制了。另外非常感谢这个项目。
想询问一下，目前使用的localStorage存储，还没有设置unlimitedStorage标志，意味着只能存储5mb数据，要不要考虑在src/manifest.ts添加unlimitedStorage标志，解除5mb的限制，存储更多的数据？
另外想问问有没有考虑使用indexedDB来存储数据？这样在高数据量下的表现更加好

[Tokisaki-Galaxy]

如果需要迁移indexedDB，我可以帮忙

[sheepzh]

@Tokisaki-Galaxy 之前也想过用 IndexedDB，不过底层改造和测试工作量都比较大，迟迟没动工。unlimited 这个倒好办，加一个 optionalPermission，用户觉得空间快满了手动申请就好了。

当然也欢迎一起加入开发，我的想法是直接重构现有的【数据管理】页面，加上 storage 类型管理，支持用户从 localStorage -> unlimitedStorge -> indexedDb 的不可逆类型切换。其他现用功能都要兼容对应的存储方案，这一部分工作量是最复杂的。先构建一个同时兼容 storage 和 indexedDB 的新存储规范，并且还要兼容现有的所有数据，后面的业务兼容就很简单了

[sheepzh]

@Tokisaki-Galaxy 我拉了分支 #678 ，新增了一个开关，支持用户选择将时间数据存储在 chrome.storage.local 或者 IndexedDB。然后用相同的数据对比了一下两边的性能，差距没有很大。不过也有可能是我没有针对 IndexedDB 做深度优化，目前只是简单粗暴地用 IndexedDB 适配了 Chrome Storage 的 API，后面我再优化一下试试。

目前实现比较粗糙，很多产品细节还没处理，也欢迎 @Tokisaki-Galaxy 参与讨论更多细节

[Tokisaki-Galaxy]

非常感谢您！谢谢，我去试试去，
indexDB理论上检索的时候不用整个数据都读进去，只需要读需要的部分，
测试阶段性能差距也有可能是数据量很小所以不明显？我去看看试试

[sheepzh]

从云端导了 7000 条数据下来。数据稀疏的话 IndexedDB 走索引更快，如果结果集数据量大的话，IndexedDB 因为 I/O 等原因还是没有 storage 快