数据火器库八卦系列之瑞士军刀随 APP 携带的 SQLite

作者：阿里云情报局

2022 年 9 月 19 日
浙江
本文字数：5985 字
阅读完需：约 20 分钟

来源：云数据库技术

数据库打工仔喃喃自语的八卦历史

1. 为导弹巡洋舰设计，用在手机上的数据库 2. Small and Simple, and Better3. 如何看出是自己的娃：产品定位，特点和边界

产品设计作为产品设计/产品管理的从业者，日常工作的一个核心就是明确产品的优势和定位，加上同样重要，又常常被忽略的维度：产品边界

姚明是中锋，并不是说他不能像后卫一样投三分，他明确的知道自己的长处和定位，和能力边界。

我们今天就讨论一个数据库专注细分领域的，甚至可以说是小众的，但是又最流行的，产品边界清晰的数据库 SQLite

SQLite Logo

图片来源 - SQLite.org

SQLite - 兆级数据库从数据库实例维度，全世界最流行的数据库，不是那些数据库元老（O,DB2,SQL Server), 不是云上新贵（Aurora, Snowflake, Azure)，不是开源 MySQL/PG, 不是大数据 HBase/Spark。他们加在一起，也比不上 SQLite 的零头。

现今世界上正在运行的 SQLite，有超过万亿（1000B，1e12)的实例。每一位现代人的日常是被 SQLite 围绕的 :

• 所有的 Android 手机/手环（华为，小米，三星...)

• 所有的苹果 iOS 设备手机/Pad/手表

• 所有的苹果电脑 Mac

• 所有的微软 Windows10 电脑

• 通用浏览器（Firefox, Chrome, and Safari）

• 智能电脑/机顶盒

• 车载多媒体系统

• ....

SQLite 不需要传统意义的安装，部署，调试，是纯粹意义上的 Zero-Configuration。不需要 DBA, It just work for a developer，甚至许多 i/OS, andriod 手机 APP 的开发者，根本不知道他们在使用 SQLite。

SQLite 产品设计产品设计，开发实现与应用实践，三者之间不是流水线或 waterfall 的单行道，而是循环往复，螺旋上升的。

SQLite 由 Dwayne Richard Hipp 个人开发开源的。Hipp 也算是计算机领域中 N 多个从学校肄业的大牛之一，区别在于 Hipp 是在 Duke 读博士的时候才悟出来的，比 Gates(大三）和 Jobs(大一）逊色不少。当年 2000 年甲方爸爸，世界五大国防工业提供商（俗称军火制造商）之一，列入 Fortune 100 的通用动力公司（General Dynamics）需要为美国海军的提供软件系统，Hipp 是其中一个临时工。

如果对 GD 不熟悉，那可以补课旗舰产品 F-16

Hipp 作为政府的合同工，恰巧因为联邦政府关门（对的，就是那种没有钱导致的政府关门），暂时失业了。待业在家（笔者刚刚短暂的享受了几天），Hipp 搞出的事情就是写个数据库，处理个战舰损管控制系统。

2.1 需求

驱逐舰奥斯卡.奥斯丁舰名来自荣誉勋章获得者奥斯丁下士图片来源 - wiki 百科

做数据库的产品经理可能很难遇到如此具体的需求，驱逐舰奥斯卡.奥斯丁上的某个任务对话框弹出 DBA 梦幻信息：

Can’t connect to database server

而这个任务是战斗损管系统，也就是在弹雨枪林下，水深火热中，需要报警表示那些管道/设施需要应急维修。真枪实弹的秒级交互场景中，如果出现数据库无法联接，操作员心中怎能不万马奔腾？

这个联系不上的数据库系统，是当年赫赫有名的 Informix。虽然不如 Oracle, Db2(那是还没有 SQL Server 的时代），Informix 也是 top5 的数据库，二十年前被 IBM 用 10 亿美刀收购，也算体现价值了。可是 Informix 不是为这个业务场景设计的，事实上当年没有任何一款数据库符合此场景。

2.2 边界：不是什么一方面 Informix 和已有数据库不适合上述场景，另一方面新产品也不用背负老系统的功能集和业务职责。

NOT another RDBMS：

• 不是替代当年成熟的数据库(Db2, Oracle)

• 不是(2000 年代）新宠的数据仓库（Netezza, greenplum)

• 不是复杂的服务器 Server-base 系统

• 速度不是重要指标

• 存储量也不是重要指标

• 跨平台不是设计指标（对比 2000 java 的崛起）

• 功能齐全不是设计目的

2.3 定位：为单一 APP 服务的数据库 SQLite 是自己自足 Self contained 的关系数据库管理系统，直接服务某应用某块。此概念与现在流行的 microservices 有类似之处。

SQLite 面临的不是提高 Informix 链接数，复杂的链接池算法，或者断点续连的问题。而是面向的是每一个控制模块需要恶劣环境下，甚至出现物理切割的情况下，单模块系统依然可以对立运行，完成大部分设计功能。特别明确一下，这里的模块指代某个硬软件一体的工业模块，不是数据库内部的纯软件模块。

让我们做一个业务对比：现在中国的银行系统是采用中心体系的，每次一个支行或柜员机的业务操作是与总行数据中心连接完成的。好处是用户可以跨区域跨分行操作，异地存储转账，不足是如果与总行的线路出现问题，分行是瘫痪的。而 SQLite 的定位是，在正常情况下与总枢纽指挥中心联络，通讯通道异常时，比如前炮台，后轮机，均需要独立完成 90%以上的职责。

2.4 特点（优点）：NOT Faster, Better, Cheaper 咬文嚼字的说，优点是销售词汇，产品设计角度应该强调的是特点。特点在适合的场景中才是优势。SQLite，不是最快最大最全的数据库，恰恰相反它是最小的标准数据库 RDBMS。

SQLite 的特点是如此明显的，所以宣传它不用那些看不出产品特点的片儿汤话。事实上 SQLite 的早期成功同商务宣传没有半毛钱关系。它为一个特殊的细分市场提供了具有基础数据库能力的嵌入式系统，这个细分市场在短短几年跳跃进庞大的智能手机时代，而 SQLite 的生命力强大到轻轻松松的站在时代的浪尖。

2.4.1 小：Small and Simple

通过 C 编写，在正式发布 5 年之后，向 Google/Andriod 的推广时，SQLite 的 binary 也不过 250KB。出世 20 多年过程中，添加了全文检索，CTE，JSON 等高级功能后，SQLite 的发布版也只有小小的 700KB。

今日头条（ andriod 版）的安装后大小 161MB，1:200 的关系。对了，今日头条 APP 中很可能也用了 SQLite（请字节同学确认，同样问题抛给阿里淘宝，腾讯微信）

SQLite 其实很"大"，3.33.0(2020GA)可以最大支持 281TB 的数据。其系统测试分四大类，几百万测试 case。即使最小的，为开发程序员日常 check in 的把关的“very quick”的 Tcl 测试，也有 30 万个。它对产品质量的重视，是否可以让许多大厂的号称企业级的系统测试汗颜了[^9]。

[^9]: How SQLite Is Tested https://sqlite.org/testing.html

2.4.2 标准数据库

支持数据库最重要的事务 ACID。
兼容标准的 SQL-92，第一版 SQLite 1.0 使用 PostgreSQL6.5 语法。

3. C/C++ interface 作为原始编程语言接口，为后期衍生开发提供可扩展的链接

2.4.3 嵌入式

大家熟悉数据库系统，Oracle, DB2, MySQL 等，是存在于应用程序之外的独立系统，一个 Oracle 为多个应用服务。还以银行系统为例，应用(application)包括存取（强事务 write)，流水单（单储户 Read Only），储户留存分析（月底报表, BI Report)，都可以在同一个 Oracle 集群上操作。

SQLite 是嵌入式的数据库，作为应用（APP）的一个部件，同时安装，同应用和用户常常都是一对一关系。SQLlite 的小赋予了它可以被嵌入的能力。

2.4.4 利用文件系统

定位决定了特殊性：并发少，权限管理简单，性能要求不高。

SQLite 不用类似系统级数据库，深度管理定制的存储管理系统，比如 MySQL 开发自己的 innoDB, TiDB 采用 TiKV 和 RocksDB。SQLite 依赖操作系统自带的文件系统，读写自己 DB file，并且继承文件系统的权限管理。

此设计理念简化系统复杂度，但也并不是没有缺陷。并发读写就是 SQLite 的明显短板之一。因为整个数据库是一个大文件，依靠文件锁来控制读写冲突。只有在后期（2010）实现 WAL 后，才提供了并发功能，当然也是有代价的。

2.4.5 Serverless

大家常常混淆了“Serverless”这个技术，与云 Serverless Computing 这个技术+业务手段，比如[Serverless Database] (https://en.wikipedia.org/wiki/Serverless_computing#Serverless_databases)，其实还是 client/server 的服务架构，准确的说是有服务器(Server)的。

Serverless 作为一个技术，其经典定义（现在比较小众了）就是纸面意思：没有服务器/no server。SQLite 是 Serverless，因为它与应用程序的同一个进程内运行，公用共享同一块内存空间，相互之间直接读写，而不通过消息协议(比如 RPC call）和网络交互。

2.4.6 "官方"认证

美国国会图书馆，又称美国国家图书馆（Library of Congress) 推荐的独立于平台的开放格式的四种数据存储格式之一。

此官方认证与国内的政府认证，语音类似，差距很大。

马后炮，评英雄《成功学》最重要的优势就在于：面对一个已经成功的产品，项目，人或者团队，总结（堆砌）其英明决策。

现实世界是黑白多变的，历史偶然性多于必然性，尤其是具体的人和事。回头看 SQLite, 也是可以总结一些契机和事后方知的因素，促成了它的今天。

3.1 项目 vs. 产品 SQLite 肯定不是某领导英明决策的结果。本来是个项目（解决 Informix 掉链问题），Hipp 闲的无聊把它作成了产品。

反观许多产品团队打着产品的名号做项目。在短期业务压力下，或者是因为大厂内部竞争，或者因为初创企业生存压力。团队早期做有生命力有世界水平数据库的梦想，很快向现实环境低头了。被甲方爸爸或领导指挥左右，对自己的产品拔苗助长。项目也许拿下了的代价是产品做残了。

3.2 开源 SQLite 从第一天就是开源的，特别要明确一下，不是开源项目。

Hipp 一个人开发，开源的。他没有想到 SQLite 二十年后支持了现代人的分分秒秒的日常生活。甚至在头几年，Hipp 都不知道谁使用，搞笑的是他之所以了解到通用电气和日立青睐 SQLite，是因为出口管制需要走法律流程时，两个大厂不得不找 Hipp 了解情况。他才知道已经被白嫖多年。

很幸运的是，Hipp 这个工程师得到一个有法务背景的 IT 商人， Mitchell Baker， CEO of Mozilla Foundation，指导和帮助。SQLite 才真正成为一个项目 SQLite 联盟，有了稳定的资金，同时又保留了开发者主导决策产品的发展的权利。

3.3 Google 和 AndriodSQLite 唯一获得的奖项是 2005 Google O’Reilly Open Source Award。

当 iphone/智能手机被业界认为是后 PC 革命的时候，smartphone 已经开始使用 SQLite, Symbian（Nokia）属于最早的之一。

Google/Andriod 在 iphone 获得早期风光之后，也走进了掌上的舞台。他们选中了 SQLite。于是所有的 Andriod APP, 都用 SQLite 作为默认的数据库管理。实际情况是 APP 开发者并不了解数据库，也没有动力去选型。APP 使用 SQLite 因为 Google/Andriod 是选择（平台作用），也是所有 APP 教程的选择（生态作用）。

3.4 测试 SQLite 突然直面了百万的用户，各种 bug 如雨后春笋一般暴露出来。Hipp 花了整整一年时间写测试用例。大多数产品在 GA，商业化之后，很难有时间和机会专门提供测试覆盖和产品质量。Hipp 是幸运的，在关键时刻等到认可和资助；SQLite 是幸运的，它是开发者的孩子而不是简单的赚钱的工具。SQLite 像是成长中的少年，等到了机会，吸收了营养，长大成人。

一点感触 4.1 业务引导技术方向 - 国内和国际不同的实践技术服务业务，是行内比较普遍的认知，合乎逻辑。但当我们看到细节的时候，会发现国际和国内的明显不同。

中国和欧美 IT 技术开发既有相似处，比如美国为联邦政府提供 IT 软件服务也有类似中国的认证流程，本着对纳税人负责的态度，严谨但也死板，同时政府也常常是重要的金主甲方。不同点是，中国政府可以集中力量办大事，远的高铁，近期的芯片和新能源汽车，政府的方向性是明确清晰的。国际上，技术革新的大方向常常是技术公司和商业引导的，比如说 Telsa/SpaceX 的跨时代的突破，基本上没有政府的引导，更准确的说是 Telsa 引导（游说）政府给以免税政策。

具体到 SQLite 这个国家图书馆的“官方”认证，说起来很有力，其实对于 SQLite 的成败影响力就非常有限了。

一点感想吧，如果读者的产品计划进军国际市场，个人建议：

• 业务销售人员要积极关注政府合规认证；

• 技术开发人员专注设计前沿和产品实现，切忌迎合。

4.2 描述产品的片儿汤话产品常见的商业口号同质化严重，基本上是快好省的衍生词汇。

比如："与 MySQL 和 PostgreSQL 兼容的关系数据库，专为云而打造。性能和可用性与商用数据库相当，成本只有其 1/10" , 2022 年 9 月 13 日摘抄 AWS Aurora 官网。如果是某个领域的先行者，比如 Aurora，倒也罢了，因为是采用了某个突破性新技术，可以担当快好省的评价。之后的追随者，也如此定位宣传，就有些东施效颦的偷懒和尴尬了。

PPT/胶片是技术产品人员常常使用的工具，评价一个材料的好坏，用心与否，可以把 PPT 中的产品名字盖住，用模版的把颜色和字符统一一下，是否还能看出是哪一个大厂的哪一款产品？粗略估计，80%的产品描述过不了此关。

八卦篇阿波罗登月提到小而精的经典程序，必须跪拜一下阿波罗登月计划中的 AGC 系统，提供登月过程中航天器的制导、导航和控制。全部系统安装在 72KB 的只读 ROM 里(头条 APP 的 2 千分之一），运行空间是 4KB(byte) RAM（约为本篇 Markdown 文本的四分之一）。

友情奉送 Github 打卡地址，膜拜一下阿波罗 11 号导航软件 AGC 中指令模块（Comanche055）和登月模块（Luminary099）原码。

当然再牛的软件都有 bug, 如果论如果论惊险性，AGC 的 1202 肯定是历史前 10 的。有兴趣的同学，可以移步代码1202，50年前的阿波罗登月给自动驾驶汽车留下宝贵一课，或英文原版Apollo 11's Infamous Landing Error Code 1202 Offers Earthly Lessons For Self-Driving Cars。

花无百日红讽刺的是 SQLite 当年并没有被 GD 采纳，因为决策者还是保守的使用成熟且风险小的 Informix。

SQLite 的设计也没有考虑到现在强烈的端（手机）和云之间的数据协同/同步需求。加上 SQLite 不隶属于大厂，商业竞争过程中渐渐被同类产品压迫。比如 Google 大力扶持的 firebase 端云系统，MongoDB 并购了 Realme 也是为此服务。业界比较成功的云原生的时序数据库 TDengine 也在接口了除 SQLite 以外的多个端侧数据采集模块。

随着手机市场的成熟，IoT 和智能汽车的发展，SQLite 的强力竞争者将越来越多。SQLite 步入软件的中年危机，我们拭目以待，期望它老而弥坚吧。

6. 信息来源由于平台对应引用链接的限制，无法准确标注信息来源。需要了解，请参考原文https://github.com/nidmgh/ArmoryBase/blob/main/chapters/06-SQLite.md

https://www.discovermagazine.com/the-sciences/apollo-11s-1202-alarm-explained

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

https://www.sqlite.org/mostdeployed.html

https://www.loc.gov/preservation/resources/rfs/data.html

https://www.discovermagazine.com/the-sciences/apollo-11s-1202-alarm-explained

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

https://github.com/chrislgarry/Apollo-11/

https://thenewstack.io/the-origin-story-of-sqlite-the-worlds-most-widely-used-database-software/

https://sqlite.org/testing.html, How SQLite Is Tested

https://www.baike.com/wiki/%E5%A4%9A%E5%BF%AB%E5%A5%BD%E7%9C%81