开发者动力不足

这个主要是指开发者觉得使用者需求不足、不统一，而宁愿花时间在其他问题上的状况。

开发者不上容量

这个我倒是大大赞同的！为啥扩容变成这种离谱的方式……要是按一年 8g100 块这种容量包卖不好吗？非得变成大容量用户统一转第三方 S3……

反正我这方面是坚决反对开发者现在的方案的。

因为很简单，插件可以写的随意、垃圾且不稳定，但本体不行。

假如我作为一个想给思源增加功能的开发者，我首选会写一个 js 代码，其次是插件，如果做不到，我会考虑向官方要接口，最后才是直接修改本体。

因为社区开发者和官方都不愿意给自己增加维护的负担，社区开发者最希望是遇到问题 you can you up，而官方维护本体就已经筋疲力尽了。

举个例子，长啥样的 html 形式的 img？

嗯，你说的对。我使用思源的历程，大概可以概括成：《前端：从思源到入土》

不过说说具体东西吧。

1. 移动端：这个不用说，不好用众所周知，但人力就这样限制，等明年吧。
2. 双击打开：原来就是的，到底是谁提议改掉的！目前处于很多人想改回来，但开发者动力不足的阶段。
3. 移动端桌面模式：我觉得这不能算常规需求的说……除了思源没有哪一家需要移动端改成桌面模式。
4. 嵌入块：还好吧，动态查询有已经比没有强很多了，但是做查询 UI……我觉得连移动端优化都抽不出时间就别提更少人用的东西了。给个简单点的小目标，能用“and or not”这些查询语法怎么样？

浏览器上大概都不行，因为使用了 open("siyuan://block")，换个跳转方案也许可以试试。

点个 star，不过这东西咋用？

我对于功能理念之类都是无所谓的，毕竟大家记笔记的习惯各不相同，所以各有所好。只是说这个东西实现起来并不简单，所以才说是颠覆。

关于移动……这个东西是可以直接搜索过滤的，我觉得这无论怎么说也不能说慢吧。

第一个问题是不够直观，但我挺好奇在这种情况下——指笔记很多的情况下，onenote 有何优势呢？就是它跟你不创建子文档，笔记本作为一级，笔记内容直接就是二级，它的区别在哪？

第二个问题，同上，二级文档树的优势在哪？就是 onenote 会快吗？思源我记得是可以直接文档树右键选择移动进行移动的，对于你的问题，实际上可以先移动移动到指定的文档下，然后再移出来，变为它的上方或下方，OneNote 有什么更简单的方案吗？

你在提出一个颠覆性的要求，虽然在构架上并不是不可能实现，但是你的理由目前在我看来还不是很充足。

分割不是问题，没有合并才是问题。你在 100 个文件里分别打了一个字，结果产生了 100 个分块和 100 个新的文件索引，这属实让人难绷。

分割本身就对应的是大文件，把他们进行分割反而改善速度，利用上多线程下载和上传。

答案就是：节省空间，并且在大文件上传下载时加速。由于每个块只对应一个文件，所以能下载最少的内容到本地快照。由于一个大文件被拆成多个分块，所以能很好利用 s3 在少量大文件批量上传的速度。

数据库和索引是不经过同步的，它们放在 temp 目录下。

调用一堆内核 api 跟很多数据发生变化无关，我指的是打开 siyuan.log，看这一堆东西的上下文：

I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/c4/0294c4d4c1c85d1d3c85d9ad8527c8988d4121]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/c4/0294c4d4c1c85d1d3c85d9ad8527c8988d4121, 561/6604]
I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/cf/5e4f6bad5e4a80d2e2e596b5bb084eb1447915]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/cf/5e4f6bad5e4a80d2e2e596b5bb084eb1447915, 562/6604]
I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/89/24958a3954bd9c8bad705e0f6a03a8d33f6273]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/89/24958a3954bd9c8bad705e0f6a03a8d33f6273, 563/6604]
I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/d9/2c22093eaa028952d2a912f5af45c8a24d0328]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/d9/2c22093eaa028952d2a912f5af45c8a24d0328, 564/6604]
I 2024/08/17 00:06:34 s3.go:94: uploaded object [repo/objects/60/3ddb05be9c7b26b7b962eb6bd4948c50a78915]
I 2024/08/17 00:06:34 sync.go:1265: uploaded chunk [objects/60/3ddb05be9c7b26b7b962eb6bd4948c50a78915, 565/6604]

它们就是实际上传下载的数据分块，如果数量小，时间短，那就说明并不是在这一步阻塞的。

我打几个字就是会产生很多小碎片，如果说，用户打了几个字，只动了一个思源文档，但是思源产生了一堆数据块，这个作为一个个人使用的本地软件，不是一种冗余吗？要怪在用户不了解的头上吗？

我并没有说”用户打了几个字，只动了一个思源文档，但是思源产生了一堆数据块“是合理的，只是我觉得实际上并不只是修改了那一个文档，而是不知不觉中修改了多个文件。这些文件的修改当然是要改进的问题，但是这不是同步机制的问题。

在这里的语境中，我指的是建立快照时，产生的数据分块，也就是把文件变动后加入快照，产生的加密小文件。跟思源文档中的块是不同的概念。

这些文件本来就是运行时文件，而思源不通过中间件处理对接，反而放在了同步里面，内核我也看，很多数据发生了改变=很多文件发生了改变？

所以你的运行时文件是指什么，中间件处理对接又是什么，很多数据发生了改变是什么情况？

那我的意思也并没有说思源目前同步的机制在速度上是好的，不然这个标题也不会是”这么慢的探究“了……

我想指出的只是，速度慢的原因与大多数人想的情况并不一样，使用思源这种快照、分块、加密的形式也能达到一个比较好的速度，举了 restic 和 livesync 作为例子。

但是，我最后也得到了另一方面的结论，思源对速度不友好，但是对于空间占用、上下传流量是最友好的。这在另一种层面上，就是要时间还是要空间的考虑，思源的同步机制并不是一无是处的。

你的意思是另一端直接知道要校验那几个文件的索引？这个……其实 livesync 不管这个的。obsidian 也不管 livesync 的，更别说 dataview 之类插件的索引了。它们都是使用文件系统的事件来更新的。确定是那几个文件需要校验确实有帮助，不过目前快照直接进行索引对比也能找出更改文件。这方面的主要问题还是 D 偷懒！没有利用这个信息！

这个可能不是你觉得自己打几个字就真的是几个字了，你得看看实际数据块的数量。实际上真正的打几个字的场景就是开了同步感知进行交替同步，目前我测试的延迟就是 6s 左右。你可能得看看内核日志，确定到底主要在干啥了。

主要是我没理解你提出中间件干啥，你的描述已经完全不是只使用 s3 了，而是一个 anytype 作为一个服务端调用储存后端，那我想象出来的对等情况就是思源里面绑着一个 s3……然后忽然反应过来这不如直接伺服得了。

所以你是觉得这样就算结构化了嘛。那这个要求和难度都不算太高，改善也不大就是了。

这个实现无论是轮询还是系统监听都能做到，但是还是如上面所说，这方面再怎么改善也是提高了在快照上传到云端前的快照建立速度，但无论什么情况下，基本快照建立都不是主要时间。oss 的并发上传限制、思源保守的云端锁、快照分片数量、本地索引校验机制，无论哪一个的改善都远远比这个显著。

所有你看到我的结论归纳分 4 个了，因为它们确实都有影响。

对于少量更新，思源需要带锁同步，这时候没碰到小文件上传的并发上限，那么就会有 0.5（扫盘）+0.3（少量修改产生新快照）+1（云端尝试锁定）+0.5（文件上传完成）+1（云端解除锁定）总计 3.3s，也就是那一端最少需要等待 3s 才能进入同步状态。因此，整个交替同步流程最少是需要 6s 的时间，这与打开同步感知后进行同步的体验大致相同。

至于插件，插件确实会产生很多新文件的，特别是你进行了批量更新。一个插件最少带有 5 个文件，以我这里的例子来说平均是 29 个（49 个插件 1454 个文件），一次批量更新我们假设是 10 个插件，那么就会产生 300 个文件变动，假设每个插件只实际更新 50% 的文件内容，那么会实际产生个 150 文件变动。150 个变动文件假设大小都不大，每个产生一个分片，那么就总计 150 个分片、150 个文档索引、一个最新索引，在我的设备上，这个数据量意味着 300/20 = 15s+4s 总共 19s 的同步时间。当然，这是最好的情况下。

我再说的通俗一点，如果你家里宽带有 10000 兆的带宽，那么你下载腾讯 s3 的速度就是一万兆，你个人就算是硬盘提供得了这么大的速度吗？详情见这里，https://doc.fincloud.tencent.cn/tcloud/Storage/COS/845813/uploaddownloadfaq
对象存储的性能和带宽不上限，只按量，远超你自己局域网运行一个 docker 的性能

对象储存对于少量大文件的带宽确实能跑满，但是大量小文件就不太行了。这个我已经在腾讯云上尝试过了，参照上面的记录，golang 并发上传数设为 640，但是每秒上传文件数他就是有上限的，腾讯云也只能达到每秒 20 个，目前看来，对于小文件，还是 minio 在本地是比较快。

如果你测试出更好的数据，可以跟我说一下怎么写，我也可以改进下 siyuan 这方面的代码。

我说了没有那么好的事情，即自由又稳定，况且，又不是没有解决方案，只需要把附件这种不会频繁变动的内容单独走另一个单独的上传信息通道就好了，而不是放到高频索引里面再扫一遍

可是实际上外部变动主要就是改附件啊，单纯思源本身的笔记文件反而不太会被改，因为其他软件读不懂……

至少 ob 可以直接知道该同步哪一个 md 文件，思源可以在操作后马上知道该同步哪一个 sy 文件吗？倘若能，为什么要去扫盘？难道是因为我改了一个 sy 文件，每一次都要扫库看看我有没有改其他文件吗？那为什么不一直扫，万一我改了其他的文件但是没该文档，岂不是没有办法了，只能等我改文档的时候再帮我检测一下？这个思路倒是可以理解了。我是真的觉得，和用户的操作一块进行，监听哪些文件发生更改，然后没有中间服务商直接同步哪些文件，都比现在快。

我倒是没有否认 ob livesync 建立快照速度更快，更有优越性，只不过 golang 上没有太好可用的包。

我知道你不停的强调建立一个快照或者索引有多快，但是，在我用的过程中，建立快照并不是卡我的原因，原因是这个快照索引本身就是没有时效性的，不可靠的，所以它不是建立完就没事了，他需要下载下来，然后解析，然后一个个核对，我的同步大部分时间就是花在这个核对索引上，一直在校验索引，少则校验 5-6s，多则半分钟，3.10 版本有时候校验索引都会卡死，扫盘建立的索引，终究还是要扫盘去核对

此索引非彼索引啊，这里有两个概念的索引，siyuan sqlite 里的索引和快照 dejavu 使用的文档索引。思源懒得判断文档变化情况选择全部校验一遍来重建 sqlite 确实是懒政情况了，但是这跟同步的索引和快照完全是两回事啊。解决问题终究还是要一个个来的。

局域网内客户端是可以互相沟通同步的，每个客户端都具有与储存器之间的完整的中间件

我觉得对等点本身就是一个服务端了吧……硬要这么说，思源也可以内部塞一个 webdav 或 s3 实现，然后直接通过局域网发现协议互相找到端口，进行同步。但是这种情况下思源自己就成为服务端了，这跟思源作为伺服的区别有多大呢？

刚刚用腾讯云测试了下，以下是测试结果:

I 2024/08/17 00:06:11 s3.go:94: uploaded object [repo/objects/95/4cc61e297a67c163cb1e3ae0f66353c8b2178f]
I 2024/08/17 00:06:11 sync.go:1265: uploaded chunk [objects/95/4cc61e297a67c163cb1e3ae0f66353c8b2178f, 82/6604]

I 2024/08/17 00:06:32 s3.go:94: uploaded object [repo/objects/28/551765ccb476243d2d9deae94d52c16fb301c1]
I 2024/08/17 00:06:32 sync.go:1265: uploaded chunk [objects/28/551765ccb476243d2d9deae94d52c16fb301c1, 521/6604]

每秒 20 个，还行吧，比七牛稍微好点，但也不多。目前尝试的 s3 对于批量小文件的支持都挺一般的。

Anytype 的后端存储也是对象存储，冷备份热备份根本就和你用不用云端实例没有半毛钱关系

可我记得 anytype 没法只用对象储存吧……它总得有个对接的服务器。我是从来不在意用的是不是对象储存、webdav 的，我考虑的只是需不需要云端需要一个服务后端进行对接。

自己搭建的 minio 吗？个人服务器性能一般都是丐中丐，如果是海外的对象存储

我不是用个人服务器，我是直接在我自己的电脑上，用 docker 运行 minio，minio 跟思源甚至没经过外网网络交互，全部都是在一台电脑上进行。在 40 并发上传时，minio 的 cpu 占用已经飙升到 40% 了。在我没上传前，它的占用是 0.2%。我觉得 minio 作为这方面最流行的个人 s3 项目，它的代码不至于拉跨商业主流技术好几代，而我给他分配的资源，我个人觉得也应该远胜大部分公有云给你分配的量级。

你说的外部修改因素我当然是有提及，不然也不会说禁止用户和插件通过思源调用 fs，我的评价是锁都锁了，直接禁止 fs 模块或者其他三方修改，被改了就报错，为什么要承担用户自己外部修改的责任？想要自由度又想要稳定性，哪里来的这么多好事，一切操作最多只通过 api 进行就是最合理的方法，或者直接打乱目录，防止本地有人直接修改本地明文

如果能这样当然最好，但是确实是有需要放 word，然后外部修改的例子，这方面的应用数不胜数，甚至都需要 D 专门放行，方便内核运行时不会报错，全封了不太对吧……

你说的只是对比索引然后增量同步而已，我很明确的指出了是只进行同步单个文档的操作，目前就和扫盘然后看一下哪里变了然后同步没什么区别

因为有上述前提，所以不扫描就是不行的。而且，还是那句话，扫描一遍还真就不花什么时间，它不是制约同步速度的主要因素。

而 live 并不存在这种情况，虽然没有实时通信的实例，但是它在本地运行了一个可以做到改动与同步同时进行的程序，没错，随着同步和改动一起进行

我研究过它的代码了，实际上他就是在文件改动的时候动态的把内容加入快照库，然后触发同步，把更新的块打包，和索引一起上传上去。它并没有做所谓的同步操作缓存，至于结构化，我不太理解你的意思。你的意思难道是它会准确的识别操作具体的内容，比如说 md 文本里最后插入了”this is sync“，它就能发送一个{insert:"this is sync"}之类的东西？那你可能要失望了，你可以看看这部分的代码：

https://github.com/vrtmrz/obsidian-livesync/blob/630889680e6da80a58c55f44ca764eb265758f4c/src/storages/StorageEventManager.ts#L78

https://github.com/vrtmrz/obsidian-livesync/blob/630889680e6da80a58c55f44ca764eb265758f4c/src/main.ts#L1586

https://github.com/vrtmrz/obsidian-livesync/blob/630889680e6da80a58c55f44ca764eb265758f4c/src/main.ts#L3092

https://github.com/vrtmrz/obsidian-livesync/blob/630889680e6da80a58c55f44ca764eb265758f4c/src/storages/SerializedFileAccess.ts#L87

以上代码的逻辑就是获取文件更改，然后直接视为 string 或二进制，创建快照分片而已，在我的标准里，属实算不上什么结构化。思源要进行这种操作也能做到的，无非就是动态获取修改内容，然后新建指定快照罢了。之前是扫盘获取需要建立快照的文件，现在是你给定路径确定建立快照的文件，区别不大，思源的性能可能还高一点。

啊，这我倒是不了解了，你是用什么方法触发同步的？

这我倒是赞同的，livesync 也没做多好的同步合并，但是同步的够快，所以就看不出问题了。

对象储存高并发支持得不好吗？

可悲的是，确实不高，我自己手动修改了并发数后运行的效果确实如果。可能 minio 的性能有限，可能官方同步在控制台对于并发数做了限制，但是事实就是，大量小文件的并发上传和下载速度并不好。

可能花尽心思搞一堆东西，也就优化个一两秒

这倒不能这么说，只使用 s3 的 obsidian livesync 算是为我们揭示冷备份方案的上限了，他确实没有在云端运行一个实例的。就算算上思源跟 livesync 建立同步上的差异，对于 20mb、650 个文件的同步，那也能从 90s 砍到 4（建立快照） + 3s，这是极大的提升了。

就做一个最简单的同步，单纯从打开窗口或者后端 api 请求判断哪个 sy 文件发送了改变，上传了哪些文件，删除了哪些文件，禁止 fs，真正的按需同步，也比现在快

不太行，因为有外部修改的因素，不考虑这个就确实可以。

obsidian 使用了 node 的 fs.watch 来递归监听文件夹变化，它也不是靠监听窗口和自身的修改动作实现文件修改事件的监听的。livesync 归根结底也是调用了 obsidian 的这个接口。可惜，golang 没有这么方便的东西，有归有，但是 windows、linux、mac 各有各的接口，头都大了。目前最有希望的还是使用轮询机制动态监听，而不是在同步时才扫描文档、建立快照。

但现在恐怕连修改了 3 个字就只同步这个文档的操作都没做到

这个据我所知应该是实现了？不过每次同步最少是要上传、下载一份索引，这个索引体积依照 data 而定，我的 data 大概需要 134kb 的索引，emmm……

同学，读题不认真啊，livesync 有一个 couchdb 部署版本，这应该就是你说的服务器吧？但是他后面又出了一个只需要 S3 进行同步的，我就好奇的是这一个。经过代码的研究后，我确定他跟思源一样是使用加密和分块的方案。

你说的真正原因有部分是对的，也就是文件并行数这一块，至于文件和文件夹的深度和数量……我感觉你说的不是同步的 repo 文件夹，而是思源 data 的目录？这个倒是影响不大的，因为思源的深度和数量还没到会影响快照生成的等级。转成快照之后，文件数量是多了，但是深度是小了很多。

另外，快照生成的文件数多，这是我确定出来的原因，也是我认为同步慢最主要的原因。

至于加密，在生成快照这一块就已经进行加密了，如我文章所说，他并不慢。

最后，在这里必须明确一下，livesync、restic、siyuan，都是使用的分块、加密的方案，加密上可能算法上存在一些差异，主要的区别是在分块以及上传上。

livesync 的粒度是最大的，他会把更新的内容打包成一个文件，直接上传上去。restic 中等，他同样会进行打包，但打包之后还会分块。思源的粒度最小，一个文件最少会生成一个分块，大的文件，会生成多个分块。因此，思源的上传下载量、本地占用储存空间最少，但是速度最慢，livesync 速度理论上是最快的，但是上传下载量、本地储存空间占用最大。

总体来说，正如我文章最后所言，省时间换空间还是省空间换时间？这是一个永恒的问题。

这倒是，这样就绝对不用担心文件被外部占用了

目前是可以删除快照，清理删除未引用的分块的，但 restic 的版本可能就没法简单的清理未引用分块了，因为可能虽然只有最新的快照，但全是被引用的分块……要做复杂的操作来重新分块。

当然，这只是最差的情况，对于大多数人来说，其实 restic 的方案应该不会有太大区别，比如我，因为我就没有清理过快照 😋 这种情况下 restic 方案就是纯优点了。

我觉得思路要放开点，为啥要一直往思源里塞呢，直接写个浏览器插件，在视频网站用 iframe 打开思源的界面进行操作不行吗