HackerTube English?
软件边界与变化 →

一条记录能同时回答「现在」和「当时」吗?

两次查询得到了不同答案。先问你在读哪个时刻的值,再问谁能修改它。保存历史与协调写入解决的是不同的问题。

本文的问题 · 7
  1. 查询模型之外,还要决定是否保留事实的时间
  2. 从状态的时间依赖走向带时间的事实
  3. 从不可变快照扩展到信息值的设计
  4. 时间模型解释了状态为何造成纠缠
  5. 隐藏突变不会自动消除并发耦合
  6. 从访问模式出发,再选择数据项的协调方式
  7. 局部对象各自加锁,不保证组合起来仍然安全

查询模型之外,还要决定是否保留事实的时间

DynamoDB 讲解要求先枚举访问模式,再按查询组织单表、索引和事务;Hickey 则强调事实包含时间,新事实不应让过去的事实变成错误或消失。连接这两点可以把存储设计从“怎样高效读当前实体”推进到“是否需要表达历史事实”,提示读者将时间与访问模式一并纳入建模。

对照原文与时间戳 · 2
understand every access pattern I need to know
AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401) · ▶ 27:59–28:05
no they don't because facts incorporate time how is
The Value of Values with Rich Hickey · ▶ 20:30–20:41

DynamoDB 演讲中的版本控制例子并不等同于完整的事件溯源或历史事实模型;Hickey 的主张是信息建模原则,不是具体数据库实现指南。

从状态的时间依赖走向带时间的事实

Simple Made Easy 讨论可变状态的理解负担;The Value of Values 提出保留带时间的事实,避免用当前位置覆盖历史。可把后者当作处理信息历史的具体方向,但它没有证明所有状态都应永久保存,也没有直接给出数据库实现。

对照原文与时间戳 · 2
Having state in your program is never simple, right?
"Simple Made Easy" - Rich Hickey (2011) · ▶ 36:01–36:08
no they don't because facts incorporate time how is
The Value of Values with Rich Hickey · ▶ 20:30–20:41

同一讲者不同层次的设计论述,不是独立实验证实,也不构成立场逆转。

从不可变快照扩展到信息值的设计

两者都明确把不可变性作为值的属性;The Value of Values 进一步突出语义透明、比较与跨边界共享。适用层次由进程内时间模型延伸到信息表达,而非立场改变。

对照原文与时间戳 · 2
key characteristic of a value is that it's immutable
Are We There Yet - Rich Hickey · ▶ 24:48–24:53
values are immutable right and values are semantically transparent
The Value of Values with Rich Hickey · ▶ 10:43–10:54

同一讲者不同层次的设计论述,不是独立实验证实,也不构成立场逆转。

时间模型解释了状态为何造成纠缠

Are We There Yet? 把值定义为不可变快照,并把身份与状态演进拆开;Simple Made Easy 则从理解成本解释可变状态的复杂性。前者提供机制模型,后者给出设计判断框架。这不是两个独立实验相互验证,也不是对状态的全面禁止。

对照原文与时间戳 · 2
key characteristic of a value is that it's immutable
Are We There Yet - Rich Hickey · ▶ 24:48–24:53
Having state in your program is never simple, right?
"Simple Made Easy" - Rich Hickey (2011) · ▶ 36:01–36:08

同一讲者不同层次的设计论述,不是独立实验证实,也不构成立场逆转。

隐藏突变不会自动消除并发耦合

范畴论导论指出对象封装仍会隐藏突变与数据竞争;Bloch 用日期格式化器和可变尺寸对象说明外观简单的 API 也可能暗含共享状态,因此建议尽量不可变。

对照原文与时间戳 · 2
They hide mutation – they mutate some state inside, right?
Category Theory 1.1: Motivation and Philosophy · ▶ 10:48–10:57
feels like an immutable object, except that it has state inside it.
How To Design A Good API and Why it Matters · ▶ 41:10–41:16

这不是宣称所有对象或可变 API 都不安全;需要明确所有权、生命周期和并发契约。

从访问模式出发,再选择数据项的协调方式

DynamoDB 讲解要求事先了解访问模式并围绕查询设计数据布局;WhatsApp 的讲解展示了另一项访问设计选择:同一记录的操作被路由到单一进程。两者可作为互补问题来读——先确定需要如何访问数据,再决定如何组织数据和协调对同一记录的并发访问。

对照原文与时间戳 · 2
access on a single record is going through a single process
Erlang Factory 2014 - That's 'Billion' with a 'B': Scaling to the Next Level at WhatsApp · ▶ 14:38–14:43
understand every access pattern I need to know
AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401) · ▶ 27:59–28:05

前者讨论 DynamoDB 的表与索引建模,后者讨论 Erlang/Mnesia 系统中的进程路由;不能把单进程访问当作 DynamoDB 的设计建议。

局部对象各自加锁,不保证组合起来仍然安全

这里讨论共享可变状态的协调成本,并未断言所有锁或所有对象设计都有错。

对照原文与时间戳 · 3
values aggregate to values all the benefits apply to Aggregates
The Value of Values with Rich Hickey · ▶ 16:07–16:16
and unfortunately locks don't compose either, right. That's the problem with locks.
Category Theory 1.1: Motivation and Philosophy · ▶ 12:16–12:26
as soon as you have objects being shared encapsulation just flies out the window
Object-Oriented Programming is Bad · ▶ 20:59–21:10

读完再想一步

如果两个请求同时更新同一账户,读者看到什么?事后还找得到旧值吗?