來源：云數據庫技術

數據庫打工仔喃喃自語的八卦歷史

1. 為導彈巡洋艦設計，用在手機上的數據庫 2. Small and Simple, and Better 3. 如何看出是自己的娃：產品定位，特點和邊界

1. 產品設計

作為產品設計/產品管理的從業者，日常工作的一個核心就是明確產品的優勢和定位，加上同樣重要，又常常被忽略的維度：產品邊界

姚明是中鋒，并不是說他不能像后衛一樣投三分，他明確的知道自己的長處和定位，和能力邊界。

我們今天就討論一個數據庫專注細分領域的，甚至可以說是小眾的，但是又最流行的，產品邊界清晰的數據庫SQLite

SQLite Logo

圖片來源 - SQLite.org

2. 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。

3. 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 需求

做數據庫的產品經理可能很難遇到如此具體的需求，驅逐艦奧斯卡.奧斯丁上的某個任務對話框彈出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]。

2.4.2 標準數據庫

1. 支持數據庫最重要的事務ACID。

2. 兼容標準的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) 推薦的獨立于平臺的開放格式的四種數據存儲格式之一。

此官方認證與國內的政府認證，語音類似，差距很大。

3. 馬后炮，評英雄

《成功學》最重要的優勢就在于：面對一個已經成功的產品，項目，人或者團隊，總結（堆砌）其英明決策。

現實世界是黑白多變的，歷史偶然性多于必然性，尤其是具體的人和事。回頭看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和Andriod

SQLite唯一獲得的獎項是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. 一點感觸

4.1 業務引導技術方向 - 國內和國際不同的實踐

技術服務業務，是行內比較普遍的認知，合乎邏輯。但當我們看到細節的時候，會發現國際和國內的明顯不同。

中國和歐美IT技術開發既有相似處，比如美國為聯邦政府提供IT軟件服務也有類似中國的認證流程，本著對納稅人負責的態度，嚴謹但也死板，同時政府也常常是重要的金主甲方。不同點是，中國政府可以集中力量辦大事，遠的高鐵，近期的芯片和新能源汽車，政府的方向性是明確清晰的。國際上，技術革新的大方向常常是技術公司和商業引導的，比如說Telsa/SpaceX的跨時代的突破，基本上沒有政府的引導，更準確的說是Telsa引導（游說）政府給以免稅政策。

具體到SQLite這個國家圖書館的“官方”認證，說起來很有力，其實對于SQLite的成敗影響力就非常有限了。

一點感想吧，如果讀者的產品計劃進軍國際市場，個人建議：

? 業務銷售人員要積極關注政府合規認證；

? 技術開發人員專注設計前沿和產品實現，切忌迎合。

4.2 描述產品的片兒湯話

產品常見的商業口號同質化嚴重，基本上是快好省的衍生詞匯。

比如："與 MySQL 和 PostgreSQL 兼容的關系數據庫，專為云而打造。性能和可用性與商用數據庫相當，成本只有其 1/10" , 2022年9月13日摘抄AWS Aurora 官網。如果是某個領域的先行者，比如Aurora，倒也罷了，因為是采用了某個突破性新技術，可以擔當快好省的評價。之后的追隨者，也如此定位宣傳，就有些東施效顰的偷懶和尷尬了。

PPT/膠片是技術產品人員常常使用的工具，評價一個材料的好壞，用心與否，可以把PPT中的產品名字蓋住，用模版的把顏色和字符統一一下，是否還能看出是哪一個大廠的哪一款產品？粗略估計，80%的產品描述過不了此關。

5. 八卦篇

阿波羅登月

提到小而精的經典程序，必須跪拜一下阿波羅登月計劃中的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. 信息來源

由于平臺對應引用鏈接的限制，無法準確標注信息來源。需要了解，請參考原文

審核編輯 黃昊宇