我觉得这部分想象空间还是蛮大的
Vditor 编辑器和后端用的同一套 md 引擎，所以如果以后社区要基于块做，可以和链滴的块打通
全量解析好块，构建树，然后就可以各种搜索和 CRUD 了
这个点上性能问题应该不大，我对 Lute 还是有信心的，现在 CPU 和 IO 都很快，文本其实顶多几十兆，再多的话异步做问题也不大
但是一开始肯定有一次全量索引
是的，索引结构后期可以考虑持久化
只能自己定义数据结构，基于内存来做
这种结构用数据库做不下去的
块基于数据库存储肯定会遇到性能问题
我觉得我可能发现了我来的一个技术架构问题，他们后端可能是基于数据库的。
总的设计大概就是这样，块是每次启动的时候构建，暂时不考虑缓存或者持久化。
链滴下一步的计划是先做本地，整体基于 tb 格式，每个文档一个 .tb 目录，通过文件系统来组织文档（tb 目录）关系。持久化的存储结构就按这来，逻辑方面基于块，内存全量索引构建块树，支持基于块级的双向链接。
这样就比较让人放心可靠了
人类可读，使用标准开放格式
最重要的是不要带有业务操作，持久化就是文件系统的东西
存储的问题还是存储解决比较好
链滴笔记，连接点滴
等再考虑考虑，链滴笔记准备发力了
还占用端口，性能也有点损失
挂载的逻辑就是本地启动一个 WebDAV 服务器伺服
处理本地磁盘也是这个逻辑，走的一套 WebDAV 抽象结构
WebDAV 这个是个抽象层
导致我想打开任意 md 文件都要先挂载一下，很麻烦
增加复杂度，实用性并不高
所以我在想基于 WebDAV 的架构有点残废实际上
但是坚果云那个提供的并发有点低，操作密集很容易报错
增加一层抽象有点多余
感觉其实靠网盘就能解决的问题
WebDAV 架构我正在犹豫是否坚持
我来的创始人微信 QQ 双线对战，真的好有精力
我觉得这部分想象空间还是蛮大的
Vditor 编辑器和后端用的同一套 md 引擎，所以如果以后社区要基于块做，可以和链滴的块打通
全量解析好块，构建树，然后就可以各种搜索和 CRUD 了
这个点上性能问题应该不大，我对 Lute 还是有信心的，现在 CPU 和 IO 都很快，文本其实顶多几十兆，再多的话异步做问题也不大
但是一开始肯定有一次全量索引
是的，索引结构后期可以考虑持久化
只能自己定义数据结构，基于内存来做
这种结构用数据库做不下去的
块基于数据库存储肯定会遇到性能问题
我觉得我可能发现了我来的一个技术架构问题，他们后端可能是基于数据库的。
总的设计大概就是这样，块是每次启动的时候构建，暂时不考虑缓存或者持久化。
链滴下一步的计划是先做本地，整体基于 tb 格式，每个文档一个 .tb 目录，通过文件系统来组织文档（tb 目录）关系。持久化的存储结构就按这来，逻辑方面基于块，内存全量索引构建块树，支持基于块级的双向链接。
这样就比较让人放心可靠了
人类可读，使用标准开放格式
最重要的是不要带有业务操作，持久化就是文件系统的东西
存储的问题还是存储解决比较好
等再考虑考虑，链滴笔记准备发力了
还占用端口，性能也有点损失
挂载的逻辑就是本地启动一个 WebDAV 服务器伺服
处理本地磁盘也是这个逻辑，走的一套 WebDAV 抽象结构
WebDAV 这个是个抽象层
导致我想打开任意 md 文件都要先挂载一下，很麻烦
增加复杂度，实用性并不高
所以我在想基于 WebDAV 的架构有点残废实际上
但是坚果云那个提供的并发有点低，操作密集很容易报错
增加一层抽象有点多余
感觉其实靠网盘就能解决的问题
WebDAV 架构我正在犹豫是否坚持
我来的创始人微信 QQ 双线对战，真的好有精力