SQLite 的文艺复兴

2023-01-20 10:40:41 +08:00
 bmpidev2019

写了篇文章介绍史上最流行的数据库 SQLite 从进程内到分布式的的文艺复兴故事。

原文地址: https://www.bmpi.dev/dev/renaissance-sqlite/

10188 次点击
所在节点    分享创造
27 条回复
lichao
2023-01-20 11:02:31 +08:00
挑骨头:SQLite 也没有 N+1 查询性能的问题,原因就是没有其他数据库网络通信的开销

这句话不太对,没有网络开销,但是有 IO 开销啊,N + 1 查询一定是非常影响性能的
bmpidev2019
2023-01-20 11:08:25 +08:00
@lichao n+1 最大的开销还是网络,进程内的函数调用开销很小,可以看这个介绍: https://www.sqlite.org/np1queryprob.html
lichao
2023-01-20 11:16:01 +08:00
@bmpidev2019 不太同意这个说法
kele999
2023-01-20 11:23:55 +08:00
9 千多万行,手写的?可能吗,肯定哪里搞错了。邪乎到家必有妖
bmpidev2019
2023-01-20 11:33:46 +08:00
@lichao 还有一些索引和表的 b-tree 有些设计都是在内存里存着,然后 fsync 到文件系统,所以有内存的帮助,I/O 开销并没有那么高,一个证据就是 sqlite 的官网在一个页面就有两百多条 sql 查询而渲染的,但速度能在 0.01 秒内完成,显然是有优化效果的。
bmpidev2019
2023-01-20 11:38:47 +08:00
@kele999 这种怀疑毫无意义,代码是开源的,可以自己去查
hamsterbase
2023-01-20 12:33:55 +08:00
可以看这篇文章 https://www.sqlite.org/testing.html


As of version 3.39.0 (2022-06-25), the SQLite library consists of approximately 151.3 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 608 times as much test code and test scripts - 92038.3 KSLOC.


sqlite 的部分测试是不开源、专有的。
hamsterbase
2023-01-20 12:39:31 +08:00
我基于 CRDT 和 sqlite 设计了一个分布式的稍后读工具,所有节点可以达到分布式一致性。

1. 以 CRDT 文件作为 single source of truth , 保证向前向后兼容。
2. 以 sqlite 数据库作为缓存。 可以按照需求任意修改 sqlite 的数据库格式 。
3. 不同客户端直接通过点对点同步 CRDT 文件, 修改后把 CRDT 的数据同步到 sqlite 。
hahastudio
2023-01-20 13:07:37 +08:00
说起来,SQLite 正在准备用 HC-tree
https://sqlite.org/hctree/doc/hctree/doc/hctree/index.html
feelapi
2023-01-20 13:36:02 +08:00
https://sqlite.org/cloudsqlite/doc/trunk/www/index.wiki

The "Cloud Backed SQLite" (CBS) system allows databases to be stored within cloud storage accounts such that they can be read and written by storage clients without first downloading the entire database to the client.
billzhuang
2023-01-20 14:50:50 +08:00
@feelapi 感觉不错啊,希望国内各大厂商早日跟上,小项目就不用买 rds pg 了。
codehz
2023-01-20 19:42:03 +08:00
@lichao 有没有一种可能,N+1 问题的来源在于原本就需要后续的 N 个数据,不管你发几个请求,总之 N 个数据都得到,传统需要优化合并成一个请求,但数据库仍然需要查询 N+1 个(
这种情况“优化”的不就是这个查询的 rtt 吗)
chenqh
2023-01-20 21:25:18 +08:00
不用 sqlite 的最主要问题不是因为多进程读取和更新的问题的吗?
bmpidev2019
2023-01-21 00:39:59 +08:00
@chenqh wal 模式解决了读取的问题,多写的话目前只能有一个写入者,但多个写入是可以通过 queue 来完成的,一般写入很快,所以问题也不大,当然 hc-tree 这个特性看起来解决了多写的问题,值得期待
kkocdko
2023-01-21 02:13:23 +08:00
忽然有个想法:提前编译 sql ,剥离掉 sqlite 的 sql 编译功能。因为很多嵌入式应用中都不需要动态 sql 。我先找找有没有类似项目,没有的话也许自己糊一个。
bmpidev2019
2023-01-21 06:59:53 +08:00
@kkocdko 你把编译器去掉,虚拟机怎么执行?除非你自己搞个编译器把 sql 编译成字节码。。。
sunmker
2023-01-23 22:47:24 +08:00
@kkocdko 你这个是不是类似于"存储过程"?我刚在看我的《 SQL 必知必会》,他告诉我 SQLite 不支持存储过程
lichao
2023-01-24 10:49:41 +08:00
@codehz 那说明不你不会数据库端的优化
watzds
2023-01-29 10:20:19 +08:00
@lichao #1 估计是影响比较小,一般页面 N 也就几十,SQLite 的 N + 1 相当于一般数据库的 1

如果 N 特别大,另当别论了
xuyang2
2023-01-29 14:35:29 +08:00
就算是 LevelDB, RocksDB 这样的 embedded KV 也可能会有 N + 1 查询的问题吧

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/910008

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX