一、键值型：储物柜模型

键值型（Key-Value）：每条数据就两个零件——键（Key）＋ 值（Value）。

键（唯一）          值
─────────────────────────────
user:1001       →  "{...用户信息...}"
session:abc123  →  "登录状态数据"
pv:2026-09-24   →  87346592

• 存：给个键，塞进对应的值——SET 键 值
• 取：报键名，立刻拿值——GET 键
• 键必须唯一（同一个键只能有一个值）；值里放什么格式，数据库不管（字符串、数字、整块 JSON 都行）

生活原型：超市储物柜——一条数据一把柜子：按键（凭条号）开柜拿包，不用管柜子在哪个角落。柜子按凭条号定位，一找一个准。

代表产品：Redis——最出名的键值型数据库，数据放内存里，取值快到微秒级，常当【缓存】用。

二、键值型强在哪、弱在哪

强：快。

• 查询模式只有一种【按键取值】，不需要解析条件、不需要连接、不需要扫描全表——定位直接
• 所以它在【读多写多、结构简单】的场景封神：缓存、排行榜、会话记录、点赞计数

弱：只会按键找。

• 想查【值里含【宜昌】的所有数据】？——储物柜只认凭条不认包，只能一个个柜子开过去（全量扫描）
• 它不认【值的内容】，自然也谈不上对值做复杂查询

一句话：按键查＝闪电；按键以外的方式查＝抓瞎。 用它的前提是想清楚【查询永远按键走】。

三、面向列型：按列打包

关系型表（2-2）在磁盘上是按行存的——张三一整行、李四一整行挨着放。这叫行式存储。

面向列型（Column-Oriented）反过来：按列存——【姓名】这一列的所有值打包放一起，【年龄】这一列再打包放一起。

行式（关系型）：  [张三,17][李四,16][王五,18]...
列式（面向列型）：[张三,李四,王五,...] [17,16,18,...]

好处立刻显形。想算【全表平均年龄】：

• 行式：每行都要读进来，但【姓名】等大半字段读了没用——白读
• 列式：只读【年龄】那一包——别的列一个字节都不碰

生活原型：图书馆按类分区——要查【所有地理类图书的借阅次数】，直接去地理区翻台账；不用像行式那样把文学区、科技区每个书架都过一遍。

代表产品：HBase、Cassandra——常扛海量日志和用户行为数据。

四、面向列型强在哪、弱在哪

强：批量分析省。

• 聚合计算（求和/平均/计数）只动需要的列，I/O 少一个量级
• 同列数据类型相同、长得像，压缩率也高——存储更省

弱：单条读写别扭。

• 取【张三的完整信息】要跨【姓名】【年龄】…好几列包各取一片——拼装费劲
• 所以它适合【写一批、批量读着分析】，不适合【频繁改某一条】

对照记忆：键值型为【点查】而生，面向列型为【扫列分析】而生。

五、动手 Demo：算两种存储的读取量

表：100 万行 × 10 列，每列 10 字节（一行 100 字节）。任务：算【全表某一列的总和】。

1. 行式：必须整行整行读——读取量 ＝ 100 万 × 100 字节 ＝ 1 亿字节
2. 列式：只读目标那一列——读取量 ＝ 100 万 × 10 字节 ＝ 1000 万字节
3. 结论：只读十分之一——列数越多、差距越大（10 列差 10 倍，100 列差 100 倍）

看到什么算成功：能自己算出【1 亿 vs 1000 万】，并说出原因【行式读了大量用不上的列】。

六、30 秒实验

回忆你看过的【年度账单】【运动年报】（支付宝年账单、微信运动年度报告）：

• 后台是从几亿条流水里按某几列聚合出来的统计——典型的列式分析场景
• 想象这活让【按行存】的关系型来干：每条流水十个字段全要读进来，只为了加总其中一个金额——累不累？

七、常见误区

1. "键值型的值必须是指定类型" —— 不需要，值可以是任意字节串；数据库只管【按键找到】，不管值里装什么。
2. "面向列型就是把表的列拆开存，还是关系型" —— 组织方式完全不同：它是为【批量扫某几列】设计的专门存储，没有表连接、没有固定 schema 那套关系型规矩。
3. "列式一定比行式快" —— 分场景：批量聚合列式碾压；单条按主键取完整记录行式更顺（拼一整行一翻就是，列式要跨包凑）。没有万能，只有对症。

• ☐ 下一节（2-7 面向文档型、图型-NoSQL数据库的种类2-表现分层结构与关系的模型）

相关笔记

• NoSQL-非关系模型 —— 上一节：家族总表，本节细看前两族
• 🗄️ 数据库基础 · 索引 —— 全课路线图