liustack

Ex-AI & Cloud Architect. Sharing everything I know about AI.

[liustack @liustack]

telegram 也是用 sqlite 的，现代 im 在手机端，没有不用 sqlite 的。

但是 telegram 对 sqlite 用法是比较原始，基本上 sqlite 只有元数据。早期聊天记录也在 sqlite 存 blob 格式，把 sqlite 当 kv 用，但只会放高度紧凑的自定义二进制协议格式的消息主体（比微信存放消息主体的方式紧凑的多，微信据说存 xml 的）。后期据说只有安卓才在 sqlite 存消息主体，ios 改成存储 kv 了。

telegram 不会放媒体数据 sqlite 的，微信据说就比较野了，据说早期甚至会放小图片进 sqlite 的。其实大媒体文件都不应该放进去的，会严重破坏系统的 page cache 和 sqlite 的 cache 的。

telegram 丝滑跟 sqlite 关系其实不大，应该主要是架构原因，telegram 是服务端存储架构的，客户端都是各种缓存，元数据缓存在 sqlite，媒体缓存在kv。
微信是客户端存储架构的，传说是直接复用 email 的架构，这根本就不是标准的 im 系统架构，导致在推/拉数据上复杂的多

[liustack @liustack]

看见下面很多人在表达没有 sqlite 你这个干不了那个干不了，我就想笑。现在的程序员啊，离开数据库已经不会写代码了，根本没人去关心底层存储系统了。但凡你了解过磁盘原理，了解过怎么实现 kv 存储系统，了解过什么是 newsql，你都会对 sql 存储引擎或者说 db 祛魅。很单机场景的很多功能实现，写文件就是最优解，没有之一。不是说 sqlite 不好，是不需要存复杂关系你就不该上数据库

[𝙋𝙖𝙨𝙨𝙡𝙪𝙤 @passluo]

还是搞不懂为啥你们的微信能聊出几百 G

[liustack @liustack]

我本意只是在吐槽很多程序员除了数据库就不知道其他存储系统了。

云风老师的思路的细节值不值得推敲另说，但这种技术选型的思路， 探索其他存储系统的思路，我是推荐的。

一个产品的存储系统构成本来就会有不同类型，sqlite 做关系数据的事情，文件或对象存储，做文件或对象存储的事情。而不是把所有数据都存在 sqlite 上。

而且为什么你会觉得这是在造另一个 sqlite 呢，我的看法上，他的思路只是在打造一个具备 wal 的轻量级 kv 存储系统，如果硬要归类，它也只能算 nosql 存储系统吧，跟 sqlite 差的远呢。我相信他也不是准备用这个存储系统来存储关系数据的吧，关系数据肯定还是在 sqlite

[liustack @liustack]

@foshuoai 我的观点不是不用 sqlite，而是分类存储， sqlite 和文件存储系统一起用，不需要复杂关系的就是用文件存储系统（包括成熟的 kv 对象存储库），需要关系的用 sqlite

[liustack @liustack]

@sgsg0507 为什么一定要搞成 sqlite 或类似的 sql 数据库呢

存储系统不是只有 sql 数据库这一种东西，存储系统有很多种，很多存储系统不是用 sql 形式读写封装的啊

[liustack @liustack]

@acfortwi888888 直接选一个成熟 kv 存储系统好了，要支持对象存储的 kv 系统。 sqlite 中存引用。

[liustack @liustack]

@friddleleo 我没说现代 im 没有复杂关系，恰恰相反，我的观点是 im 的数据存储要分类存储，sqlite 和 文件存储（存储系统）都需要。只是各司其职罢了。

我说的「不需要复杂关系就不需要上数据库」的场景，这个场景可能是一个产品下的小到某个图片管理功能，而不是代指整个产品。

[liustack @liustack]

我本意只是在吐槽一种现象：很多程序员除了数据库就不知道其他的存储系统了，不知道怎么存储数据了。

云风恰好提供另一种存储数据的思路，抛开他的细节经不经得起推敲不说，也抛开该不该自己造轮子不谈，但寻找另一种存储系统思路我个人是推崇的，因为这才是古典程序员该有的技术追求。而不是手里有了锤子，全世界都是钉子。

我说的写文件只是一种代指，也不是裸写文件，正常人谁会直接fread、fwrite、fsync 直接干文件，怎么得弄个轻量级的文件存储引擎吧，不自己造轮子，也有一堆成熟开源的文件存储库可以直接用啊

而微信的存储的烂，不仅仅是 sqlite 的问题，也根本不是我想讨论的话题

[liustack @liustack]

@wquguru @Gorden_Sun @Jason_Young1231 ccswitch 代理也需要改 base url 为本地回环地址的吧，理论上可以通过 tun 直接拦截 claude code 发送给官方 api 地址，然后重写成中转站的地址。@Jason_Young1231 赶紧支持 tun 模式🤣

[liustack @liustack]

我本意只是在吐槽一种现象：很多程序员离开数据库已经不知道怎么存储数据了。
https://t.co/ifSw5U76av

[liustack @liustack]

先叠个甲：我不是说不能用 sqlite，我是 sqlite 超级粉丝，我甚至像 @levelsio 一样把 sqlite 用到很多服务端系统中。我还给这套基于 sqlite + litestream + cloudflare r2 的系统设计过一致性解决方案。

这个方案的名字叫跨物种补偿最终一致性数据存储系统。
因为这是一种单机的，没有多副本的，半分布式系统，不能基于 log 和 raft 等协议来解决一致性问题。

这个系统它靠人工补偿（赔偿）来解决数据一致性问题。在我设计可以预见的一致性模型里，这套系统的数据丢失和你的财富成正比，如果这套系统数据丢失到离谱，大概你的财富跟马斯克差距应该也不大了，也就不在乎补偿的是钱还是数据了。

所以我只是在吐槽我看到的一种现象：很多程序员离开数据库已经不知道怎么存储数据了。

云风老师的方案完全经得起细细推敲么，也不是。但云风老师的技术思路值得推荐，因为这世界除了数据库，还有其他数据存储的解决方案。

有时候这种方案比数据库更优，比如我们的目的是性能更好或者就是为了造个趁手的轮子。有时候不是，比如我们的目标是降低团队协作和项目维护难度。

[liustack @liustack]

先叠个甲：我不是说不能用 sqlite，我是 sqlite 超级粉丝，我甚至像 @levelsio 一样把 sqlite 用到很多服务端系统中。我还给这套基于 sqlite + litestream + cloudflare r2 的系统设计过一致性解决方案。

这个方案的名字叫跨物种补偿最终一致性数据存储系统。
因为这是一种单机的，没有多副本的，半分布式系统，不能基于 log 和 raft 等协议来解决一致性问题。

这个系统它靠人工补偿（赔偿）来解决数据一致性问题。在我设计可以预见的一致性模型里，这套系统的数据丢失和你的财富成正比，如果这套系统数据丢失到离谱，大概你的财富跟马斯克差距应该也不大了，也就不在乎补偿的是钱还是数据了。

所以我只是在吐槽我看到的一种现象：很多程序员离开数据库已经不知道怎么存储数据了。

云风老师的方案完全经得起细细推敲么，也不是。但云风老师的技术思路值得推荐，因为这世界除了数据库，还有其他数据存储的解决方案。

有时候这种方案比数据库更优，比如我们的目的是性能更好或者就是为了造个趁手的轮子。有时候不是，比如我们的目标是降低团队协作和项目维护难度。

[象牙山刘能 @disksing]

sqlite比自己写文件要复杂吗？显然是（毕竟sqlite支持海量用不上的功能），但也不是，对团队协作来说sqlite的复杂度是封装起来的，它是一个成熟、标准、大家都熟悉的抽象，而不是某种需要开发团队去维护的方言。

[liustack @liustack]

我本意是吐槽很多程序员离开数据库不知道怎么存储数据这个现象，这是技术选型问题。

但很多程序员只熟悉数据库（坦白说我表示怀疑，因为数据库远比底层文件系统复杂），所以就不会觉得存储还能有什么选型问题。

我说的写文件不是裸写文件，有一堆成熟现成的开源库可以用，就算自己写个轻量引擎也没多少代码。我的意思是，这世界除了数据库还有其他存储系统，对存储系统的选择是很灵活的，存储系统类型很丰富的，从底层文件读写到各种类型的 kv 到缓存，不应该吊死在数据库中，不应该什么场景都无脑上数据库。

另外造轮子不是为了证明能力，造轮子的目的从来都是为了更好的解决问题，就像这世界有这么多种编程语言一样

[liustack @liustack]

@PeterlitsZo 这根本就不是个问题，正常做法上日志就完了，比如包括 wal、journal、binlog 等，轻量做法就 checksum 对账完整性，二逼做法暴力 fsync。

上面是单机的，分布式系统你就上 raft 或 paxos，其实也是日志回放+选举协调

没什么花头的，存储系统就那些事

[liustack @liustack]

@Chinese_XU @passluo 哈哈哈，作孽啊

[liustack @liustack]

@fanzzzd_x @passluo 没人在说资历，这里说的经验指的是对存储系统的经验，不是资历。

IM 是上层系统，只是在讨论 IM 这个上层系统要不要把 sqlite 用来存储某些数据或所有数据上，或者说 sqlite 在这个场景是不是好的技术选型，没有说 sqlite 不好，我个人反而是 sqlite 超级粉丝。
我大量使用 sqlite 的。

[liustack @liustack]

这个文章的说法我认可，我也是 sqlite 超级粉丝，但文章的对比对象不一样。
这个文章拿 sqlite 优化过的引擎跟直接调用底层fwrite、fread 比。

但做过底层系统的都知道，所谓自己写文件，自己写文件，其实你根本不会直接读写文件，肯定会做简单的「引擎」出来（没多少代码就能实现超级可靠的引擎）的。

比如最简单的顺序读写等 Kafka 用的技巧也是老生常谈了，比如读写buffer，比如流转批等等。如果需求再高点，会直接拿别人的引擎来用，比如 leveldb 和 rocksdb 来用就完了。

这里哪一种引擎肯定都比 sqlite 的引擎快，但这不是抹杀 sqlite 在关系型数据处理上快以及能力，只是对比维度和适用场景不同而已。

[liustack @liustack]

没想到大佬一个回复，引来这么多围观。

存储这个东西确实是吃经验，不同经历可能导致大家见解完全相反。但是吧，又很神奇，没自己研究和实践过底层存储的人，是不会相信别人说的话，会坚信自己的经验，会觉得底层存储和文件系统特别复杂，哪怕只是幸存者偏差🤣

云风老师在底层这块技术实力，确实是没得说。

[liustack @liustack]

@suwakopro 哈哈哈，确实是这样，现在 vibe coding 时代大家更不关心底层存储的事情，连 codex 底层的存储的实现都一塌糊涂，可见一斑

[liustack @liustack]

sql 和存储是两回事，现代的 db 都是计算和存储分离的。
sql 只是一种数据组织方式，它可能跟存储毫无关系，看看当代大数据那些上层 sql 工具的实现，看看 newsql 计算层的实现，会比较清楚。

如果计算不需要 sql 形式组织数据，也不需要 sql 语法，那么自己实现的存储就不需要 sql，不用 sql 可以更直截了当操作底层磁盘或文件。

至于说现代开发离不开关系类型，我认可大多数场景需要 sql 数据库，但不认可关系类型就代表 sql 或数据库，因为关系类型是一回事，数据组织是另一回事。
对于底层存储，你可以自由的组织数据，选择按关系类型组织还是按非关系类型组织，也就是定义一个自有协议的事情

[liustack @liustack]

@jianshuo 如果是想做云端 agent，建议看看 claude 的 managed agent 文档，会豁然开朗，mcp 和 cli 没有绝对的好坏，cli 也没能完成替代 mcp， 都是看场景的，服务端如果想做到安全收敛，mcp 是不错的选择，sandbox as a tool 也是一种选择