searchcode.com 的 SQLite 数据库可能是世界上最大的数据库之一

searchcode.com 的 SQLite 数据库可能是世界上最大的数据库之一，至少在公共网站上也是如此。它的实际大小为 6.4 TB，比你的数据库大了 6TB。

-rw-r--r-- 1 searchcode searchcode 6.4T Feb 17 04:30 searchcode.db

至少，我认为它是更大的。我没有相反的证据，因为这是我听说过的最大数据库。浏览互联网时，并没有找到任何人公开讨论更大的数据库。我能找到的最大数据库是1TB（没有来源），还有一些人在HN和Reddit上声称他们正在处理GB大小的SQLite数据库。

然而，缺乏证据并不意味着这样的东西不存在，因此如果你有一个更大的数据库，请告诉我，可以在某个评论区嘲笑我，或者直接通过下面的电子邮件联系我。

更有趣的是为什么searchcode.com会有如此庞大的SQLite数据库。对于那些不知道的人来说，这https://searchcode.com是我的一个副业项目。这个项目要求自负盈亏，并且是一个用于搜索源代码的平台。它收集了多个来源，包括GitHub、Bitbucket、CodePlex、SourceForge、GitLab和超过300种编程语言。关于构建自己的索引也非常有趣：如何为searchcode构建自己的索引( https://boyter.org/posts/how-i-built-my-own-index-for-searchcode/)。

searchcode.com 现在已经成为了忒修斯之船项目，因为原先使用过 PHP、CodeIgniter、MySQL、Memcached、Apache2 和 Sphinx 搜索发布版本已经被替换。以下是简要的历史记录：

• 第一个版本使用 PHP、CodeIgniter、MySQL、Memcached、Apache2 和 Sphinx 搜索发布。
• 重写版本使用Python、Django、MySQL、Memcached、Sphinx搜索和Nginx。
• 公开版本使用 Java、MySQL、Memcached 和 Nginx。
• COVID-19疫情开始时使用Go进行重写，并使用MySQL、Redis、Caddy和Manticore搜索。
• 使用自定义索引替换 Manticore 搜索，并继续使用 Go、MySQL、Redis 和 Caddy。
• 前几天更新为Go和SQLite，并继续使用Caddy。

所有版本之间保持一致性都选择作为 MySQL 存储层。然而，在年龄增长后默认配置单个二进制文件变得越来越重要。

为什么选择SQLite呢？因为它可以直接编译到二进制文件中实现二进制单一配置需要安装任何依赖项。对于自己编写的存储持久层来说并不够自信。虽然现在可能非常想要编写自己的索引但引擎不能保证能够在合理的时间内完成这样的工作。

在嵌入式数据库方面尝试了一些 Go 的嵌入式数据库（例如bbolt），但无法处理预期规模并且希望继续留在 SQL 世界中。

不过SQLite也不是完全没有问题，之前遇到“数据库被锁定”错误后找到解决方案：Go中最佳的解决方案是使用两个连接：一个用于读取（限制CPU数量），另一个用于写入（只有一个连接）。以下代码可以实现这一点：

dbRead, _ := connectSqliteDb("dbname.db")
defer dbRead.Close()
dbRead.SetMaxOpenConns(runtime.NumCPU())

dbWrite, _ := connectSqliteDb("dbname.db")
defer dbWrite.Close()
dbWrite.SetMaxOpenConns(1)

另外遇到了与 CGO 的交叉编译问题，在 ARM Mac 开发时部署到 Linux 实例需要添加 CGO 后变得相当麻烦。幸运的是纯 Go 版本https://modernc.org/sqlite解决了这个问题，但问题牺牲了一些性能。

在解决上述问题后，在2024年8月13日开始将MySQL转换为SQLite。转换过程非常简单，只需改善数据库访问即可。感兴趣的人可以编写SQL查询并将其转换成类型安全代码进行调用。

转换到 SQLite 相当简单，几周内就已经有了本地工作概念验证，但需要考虑迁移问题开始出现故障。

将代码存储在数据库中会带来问题所以存储任何代码时始终使用 MySQL 的compress和uncompress函数压缩数据存储能够存储在 SSD 上，但 SQLite 没有类似功能或寻找第三方插件。

查找资料发现以下链接sqlite-zstd看起来很有前景，但由于该链接附带警告“我不会信任我的数据（尚未） ”并且需要使用CGO版本SQLite所以并不理想

TechZing 播客 Discord 上讨论了此问题时考虑了这一点，虽然他们没有尝试过 SQLite 压缩，但建议文件系统级别压缩搜索显示确实可行。

开始在几个附加磁盘Linux虚拟机上进行实验挂载不同的文件系统磁盘并不容易开始研究ZFS因唯一支持压缩功能文件系统最终设置zstd压缩也整齐轻而易举

初步测试显示出显着的数据压缩

$ compsize /mnt/btrfs-partition
Processed 1 file,150753 regular extents (150753 refs),0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       20%      3.8G          18G          18G
none       100%       71M          71M          71M
zstd        20%      3.7G         18G         18G

在导出整个搜索代码数据库之前准备迁移通过连接先前编写的SQL逻辑和新的SQLC完成代码转换确保SQLite插入操作周边使用事务以插入维持性能

显式编码让系统负载下退避生成大小6.4TBSQLite文件检查索引循环运行搜索查询确认所有查询快速返回最多查询返回甚至快于替换掉MySQL实例合情合理因之前涉及网络传输

完成以上所有步骤后还需要考虑是否应该更换服务器搜索代码，同时运行较旧型号的AMD Ryzen™5950X，同时增强CPU每年更新几年硬件提高性能

全局查看后升级至新服务器——拥有更核心更高RAM更可靠ECC内存更快速磁盘例如Hetzner的Hetzner EX130-R配备Intel CPU RAM使得索引容量提升一倍调整布隆过滤器改善了快速匹配率

切换DNS记录新服务器观察保留更新DNS记录如果访问https://searchcode.com/正在使用SQLite全新代码论文已经很长所以保存发布新功能详细介绍其他文章中

计划今年加大力度对搜索代码数据库投入扩展，以实现自负盈亏实现盈利扩展，关注除 GitHub 以外的其他服务，如果运营商第三方代码托管服务请与联系讨论合作。

目前看来SQLite运行良好架构相对简单避免连接正确索引并不指望SQLite如此良好处理备注从搜索获取页面和所有条目建立进程都更快。

作者发布论文时索引仍然在进行每个工作核心索引说明编写的索引可以很好地扩展，即使分配内存损坏垃圾恢复器如下日志输出所示：memoryusage::Alloc =69731 MB::TotalAlloc =196538564 MB::Sys =89425 MB::tNumGC =48080在所有 48 个同时工作总是让人感到非常高兴，看到照明灯确实有特殊的感觉。

下一步呢？计划今年加大对 searchcodedatabase 投入扩展的力度，以实现自负盈亏实现盈利扩展，除关注 GitHub 外其他服务，如果运营商第三方代码托管服务请与现在联系讨论合作。