数据比代码活得久

一栋房子几十年间会重新粉刷、换家具、甚至翻修屋顶——但第一天浇下的地基会留着,因为换掉它意味着要把整栋房子抬起来。

语言会变,框架会被换掉,UI 会被重画十遍。数据和它的结构通常留着,因为在一个装满真实记录的运行中系统上去改它们,既慢又险。所以数据库是第一件要认真想清楚的事,也是最不能仓促的事。

数据库回答两个问题

挑一个存东西的地方,要问两件事:这些东西是什么形状——是书架上的书,还是挂钩上奇形怪状的工具?——以及它们必须多安全——是一个保险库,还是一个顺手的抽屉?

每一种存储都由两件事定义。第一,它的数据模型:它如何塑造数据——刚性的表、灵活的文档、一张由链接构成的图。第二,它的保证:严格的正确性,还是用更松的承诺换来速度与可用性。几乎每一次数据库选型,都是对这两点的一个不同回答——而这门课其余的部分,就是那份菜单。

Access pattern——按你怎么读和写来挑

一个文件柜、一个卡片目录、一条传送带,全都是「存储」——但你按自己将怎么取东西来挑,而不是按哪个看上去最新。

没有最好的数据库。一个对快速键查找堪称完美的存储,用在深层关系查询上就错了;一个为巨量写入而生的存储,用在严格的银行事务上就错了。对的问题是你的访问模式(access pattern):你读什么,你写什么,多频繁,以及当事情出错时它必须怎么表现。

地图:六组共 20 个概念

一张地铁线路图:先看到整条线路,再一站一站地坐过去。

这门课的概念分成六组:relational 核心、NoSQL 家族、专用存储、保证、扩展技术,以及如何把它们全部组合起来。

下面每个概念都得到同样的对待:它的英文名称(你去查文档时要搜的那个词)、一幅生活中的画面、一幅图示,以及一张卡片,字段有:问题、思路、例子、代价、何时使用 和 关联。结尾有一页纸的速查表在等着你。

Relational Database——表、行与关系

一张做对了的电子表格:每个工作表是一类东西(客户、订单),每一行是一条记录,而订单指回它所属的那个客户。

这就是关系型数据库(relational database)。它把数据存在带固定 schema 的表里,并通过引用把表连起来——一条订单行存着它所属客户的 id。这个引用叫做外键(foreign key)。schema 是一份关于形状的承诺:每条订单都有它该有的列,在进来的路上就被校验。先付出结构,换取日后的安稳。

SQL——说出你要什么,而不是怎么拿到

你对图书管理员说「1950 年以后出版的、法国作家的每一本小说,按年份排序」——他自己想办法去找。你描述的是结果,而不是搜索过程。

SQL(Structured Query Language,结构化查询语言)是一种声明式查询语言:你说出想要的答案,数据库自己规划怎么取到它,包括把表连接起来(JOIN)。这个规划由查询规划器(query planner)制定。SELECT ... JOIN ... WHERE ... 能回答你在设计时从没预料到的问题——这是关系模型一项悄无声息的超能力。

Transactions——要么全做,要么全不做

一笔转账是两次写入——这边减、那边加——但只有一个意图。要么两个都发生,要么都不发生;转到一半是一场灾难。

这就是事务(transaction):一组更改,要么完整地提交(commit),要么完整地回滚(rollback),与其他事务相互隔离,一旦确认就能扛过崩溃。这一整套承诺合称 ACID(第 5 章会详讲)。这就是为什么银行、订单、库存都放在 SQL 里——当正确性比原始速度更重要时,你要的就是这份承诺。

为什么它是正确的默认选择

一件好用的通用工具:在任何单项活儿上都不是最快的,但在某个活儿明确要求别的工具之前,它就是你伸手去拿的那一件。

有结构的数据、真实的关系、临时起意的查询、强保证——关系型数据库这些都做得好,而且现代 Postgres 还能处理 JSON、全文搜索,甚至向量。每个项目都从这里开始; 只有当一个具体的痛点——规模、形状或访问模式——把你推出去时,才去找别的。

Document Store——每样东西一个 JSON 文档

一夹填好的表格,每张表格的字段都可以略有不同——没有一个中央模板强迫它们全都一致。

这就是文档存储(document store)。它把记录保存为灵活的、类 JSON 的文档,嵌套、无 schema(schema-less),所以同一个集合(collection)里的两条记录可以不一样。当形状各异或演变很快时非常合适,而一整件东西——一个商品、一份用户资料——就是一个文档,一次读取就能取回。

Key-Value Store——一张巨大的哈希表

一个衣帽寄存处——你递上一个号码牌,拿回的正是你的外套。不用找,不用问,立刻就有。

这就是键值存储(key-value store)——最简单的形状:键进,值出,快得惊人。非常适合缓存、会话、rate-limit(限流)计数器,以及任何凭已知 id 来取的东西。

Wide-Column Store——为海量写入而造

一座巨大的仓库,有无尽的相同过道,布局让一千辆叉车可以同时上货而不会互相碰撞。

这就是 wide-column 存储。它按分区键(partition key)把数据分散到许多台机器上,换来海量的写入吞吐和规模,代价是放弃丰富的查询和严格的一致性,好去吞下一股洪流般的数据。强大——但要运维好也需要更多工作。

Graph Database——当链接才是重点

侦探的线索板——用线连起来的照片。价值不在任何一张照片里,而在谁和谁相连的那张网里。

这就是图数据库(graph database)。它把数据建模成节点和它们之间的边(edge),让关系查询——「喜欢这个的朋友的朋友」「这两个账号之间的路径」——变得自然而快速,而用 SQL 则需要痛苦的多层 join。当连接比记录本身更重要时,就用它。

Time-Series Database——被时钟盖了戳的数据

心率监护仪的纸带——一条没有尽头的读数长带,每个读数都系着一个时刻,而你几乎总是在问「这两个时间之间发生了什么?」

这就是时序数据库(time-series database)。它为按时间顺序到来、并按时间来查询的数据而调优——指标、传感器读数、价格。它能摄入巨大的数据流,并快速回答「过去一周每分钟的平均值」,还内置对旧数据的过期清理(retention,保留策略)。

Search Engine——全文与相关性

一个能容忍拼写错误的搜索框,把最佳匹配排在最前,你输入「run」它也能找到「running」——像一个懂你意思的图书管理员。

这就是搜索引擎(search engine)。它建立一个倒排索引(inverted index)——「词 → 文档」——来做快速的全文搜索,带排序、模糊匹配和过滤:这些是 SQL 里的 LIKE '%word%' 做得又慢又差的事。它通常和你的主数据库并排运行,保持同步,支撑搜索栏和日志探查。

Vector Database——按含义搜索

不再匹配确切的词,而是问「给我找些感觉和这个一样的东西」——它按相似度返回邻居,而不是按关键词。

这就是向量数据库(vector database)。它存储 embedding——含义的数字指纹——并找出最近邻(nearest neighbours),所以你可以按相似度而不是确切文字来搜索。这是语义搜索和 RAG 背后的引擎,AI 应用靠它取回最相关的片段来作答。

Object Storage——大文件去的地方

一间自助仓储间——放的不是索引卡片,而是家具:体积庞大的东西,凭标签保管,整件搬出来。

这就是对象存储(object storage)。它不是数据库,但大块的二进制数据——图片、视频、备份、文档——就放在这里,通过 bucket(存储桶)里的键来寻址,并能大规模地廉价提供服务。这个模式几乎是通用的:文件放进对象存储,在数据库里留一行指向它。记录在数据库里,载荷在 bucket 里。

ACID——悲观、正确、谨慎

一位银行柜员,每笔记录都复核两遍,账不平就不往下走——更慢,但从不出错。

ACID 是关系型数据库对事务做出的严格承诺:每个事务要么让数据正确而完整,要么根本不发生。四个字母:Atomicity(原子性,全有或全无)、Consistency(一致性,数据的规则始终成立)、Isolation(隔离性,并发的事务互不干扰)、Durability(持久性,已确认的内容能扛过崩溃)。对钱、订单,以及任何容不得出错数字的地方,这就是你要的取舍。

BASE——乐观、可用、最终正确

一家繁忙的商店,即使在更新价签的同时也让大家继续买——数字过一会儿就会跟上,这没关系。

许多 NoSQL 系统采取相反的立场:BASE(Basically Available、Soft state、Eventually consistent)。它们保持快速和可用,并接受数据的各个副本在趋于一致之前可能短暂地不一致。这叫做最终一致性(eventual consistency)。

CAP Theorem——网络断开时选哪边

一支被断掉的电话线隔开的团队:每一半都可以各自继续工作(但会渐渐分歧),或者放下工具等重新连上(但就停工了)。两样不可兼得。

CAP 定理说:当一次网络分区(network partition)把你数据库的机器隔开时,你必须在 Consistency(拒绝写入,保持正确)和 Availability(继续服务,冒着不一致的风险)之间选一个——分区期间你不能两者都要。每个分布式数据库都要做这个决定。知道你的存储选了哪个,就知道它在最糟糕的日子里会怎么表现。

Index——数据的书末索引

要在一本 900 页的书里找一个词,你不会逐页去读——你翻到书末的索引,直接跳过去。

索引(index)是一个旁路结构,把全表扫描(full table scan)变成直接查找——它是提升读取速度最大的杠杆。 代价是:每个索引都占存储空间,并拖慢写入(每次插入也得更新它)。

Replication——留下副本,扛住故障

一份文件放在三栋楼里的三个保险柜中——一个烧毁了,其他的还留着它,而且三个人可以同时读。

复制(replication)把数据的副本保存在多台机器上。所有写入都进入主节点(leader),从节点(副本)(follower, replica)接收一份拷贝并提供读取。如果主节点挂了,一个从节点接管(failover,故障切换)。麻烦在于复制延迟(replication lag):从节点可能落后片刻,所以你刚写入的值也许还没出现在某个副本上。

Sharding——一只箱子装不下时就拆分

一个塞爆了的文件柜,变成一个柜子放 A–M、另一个柜子放 N–Z。空间多了——但现在你得知道某个名字放在哪个柜子里。

当数据或写入负载超出单台机器时,分片(sharding)把数据拆分到许多台机器上——用户 A–M 放这边,N–Z 放那边。每一部分是一个 shard,你用来拆分的那个字段是分片键(shard key)。它带来近乎无限的规模,但分片键是一个艰难、近乎永久的选择: 选错了,你就会遇到热点(hotspot),或者必须访问每一个 shard 的查询。

Normalization / Denormalization——一个事实放一处,还是为了速度留副本

一份人人都引用的地址总表(没有矛盾),对比把地址的一份拷贝订在每一张订单上(读起来更快,但现在有一堆副本要保持诚实)。

规范化(normalization)让每个事实只存在于恰好一个地方——干净,没有矛盾,是关系型的默认做法。反规范化(denormalization)则故意复制数据,让读取更快、需要的 join 更少。两者都成立;规矩是要有意识地去做,并且始终清楚哪一份是事实来源,哪一份只是快速的副本。(和缓存是同一个教训。)

Polyglot Persistence——有意地使用多个存储

厨房里有冰箱、冷冻柜和储物柜——而不是一只箱子被逼着同时干这三件事。各自存放适合它的东西。

这就是多语言持久化(polyglot persistence)模式。成熟的系统通常会用好几个存储:Postgres 作事实来源,Redis 做缓存和会话,一个搜索索引服务搜索栏,也许再加一个向量存储给 AI 功能用,以及对象存储放文件。每个存储做它擅长的事。要守的纪律是始终清楚哪一个握有真相,其余的都是保持同步的快速副本。

Postgres First——从 Postgres 起步,有意地逐步超越它

一把瑞士军刀,在你需要整套工具箱之前,能应付惊人多的事情。

这就是 Postgres first 的做法。现代 Postgres 的能力令人惊讶——relational 核心、JSON 文档、全文搜索、向量,甚至一个够用的任务队列。大多数产品应该只从 Postgres 开始,只有当一个真实的、可度量的痛点需要时,才加一个专用存储。每多一个数据库,就多一样要运维、备份和保持一致的东西。最便宜的存储,就是你没加的那个。

这一切是怎么连起来的

走了很久的路之后的街区地图:现在你看得出哪条街通向哪里。

这门课里的概念不是孤立存在的。关系型数据库是带 ACID 保证的事实来源;索引加速它的读取;搜索引擎和向量数据库是从它喂出来的副本;对象存储存放它的行所指向的文件。当一台机器不够用时,复制和分片就登场了——随之而来的是 CAP 的抉择。NoSQL 家族常常选 BASE——ACID 的反面。