如何加速百万级别的文件索引

目前,我有一个文件数量五十万的库。
所有文件都放在一个文件夹里。
第一次打开的时间很久,随后可以进入索引。
但是索引的速度非常缓慢。
另外,内存也暴涨接近6G.
请问,是否如果把所有文件分成多个文件夹会不会降低内存以及加速索引速度?
obsidian是怎么索引的?

具体机制还是得开发者来说明,但是分库还是能有效减少索引时间的。所以在不需要那么多文件的情况下,还是分库使用。

不过感觉这 50w 文件不全是笔记吧。个人建议不要把 ob 当成文件管理软件了,这样意义不大= =。

并没有当成文件管理器。
我一般是多条笔记嵌入空笔记内,组织上下文形成新笔记。
笔记的可以会拆分得非常细致,然后通过嵌入的方式构建树状结构等。

很有意思的使用方式~
远超出普通场景的使用,确实会给工具带来挑战。
没有直接经验,但有些问题思考过,部分尝试过,供参考:

  • 我对工具性能是极关注的。测试新工具性能,习惯做法有两项:一是把原来云笔记时代积累的6000+笔记导入;二是导入单篇长文档,例如35万字的鲁迅笔记。以初步判断单篇笔记、笔记库的上限。
  • 笔记间的关联性越强大,笔记就可以越碎。这也更合理,方便收集,积累。
  • 以文件方式进行管理,在极多文件时,比如万、十万,很容易遇到瓶颈。这种场景数据库更合适。(曾经见过两款工具,明确说过考虑了几十万条笔记的场景:一是很久不更新极小众几乎搜索不到的 Tobu,体验并不好;二是目前比较活跃的 Trilium Notes ,但实现效果也不满意)
  • 十万文件,对其他的管理,比如搜索、备份,也是考验。

自己能做的:

  • 升级硬件:前段时间因为 Roam Research 速度慢,而更换了笔记本,速度提升明显。
  • 调整使用方式:比如,不关机、不关闭 Obsidian。
  • 在 笔记数量-单体大小 权衡上,适度微调。

相信你也测试过其他工具,也欢迎分享它们在 50万笔记 面前的优点与缺点。

1 个赞

相关测试

  • 我在roam和wolai以及logseq上测试过

    • 三千左右文件
    • 总字数一千万
  • 的数量级。

  • roam只要不是一个页面太大,操作上都是比较流畅的,但是关闭后再打开会很慢,即使是本地roam也很慢。

  • wolai则可以一次性导入,并且打开和使用都没什么变化。只不过wolai不管多少数量级都不够流畅。

  • logseq则是直接阵亡,侥幸有一次打开了,使用也比较卡,并且重新打开内存爆6+g,接着失去响应。

以上测试都再5800x+32gDDR4的台式机上跑过。
猜测这种量级已经让node.js无法处理,无论更换什么级别的主机都无法跑出更好的成绩。
最后,所有测试过的软件,obsidian是性能最佳的,当然,最需要折腾的也是obsidian。

解决方案

不关闭软件肯定是不行了,我会经常切换设备。
解决这种超大量级的方法我有想过,比如将所有分库同步到主库,如此就能通过主库找到多个分库之间的关联。
但是,具体操作起来也是一个新流程,肯定还要写一些筛选文件的文件同步脚本,并且验证的结果不一定满意。

1 个赞

我慢,但数据再多,也不会更慢!——这也算个优点:blush:

1 个赞

:rofl: :rofl: :rofl:
:rofl: :rofl: :rofl: