知识卡片

应用代码作为衍生函数,与状态管理的分离

普通读书笔记卡

内容

一个数据集衍生自另一个数据集,本质是经历了某种转换函数:次级索引挑出被索引字段的值并按其排序,全文搜索索引应用分词/词干化/拼写纠正等自然语言处理函数后构建倒排索引,机器学习模型是从训练数据经特征提取和统计分析衍生出的产物,缓存则是聚合成适合UI展示形式的数据。次级索引这类衍生函数如此常见,以至于被内建成CREATE INDEX这样的核心数据库功能;但当衍生逻辑不是这类标准搬砖函数时(比如领域特定的全文索引调优、机器学习特征工程),就需要自定义代码——而这正是许多数据库力不从心的地方:触发器、存储过程、用户定义函数虽然存在,却更像数据库设计里的事后反思。理论上数据库本可以像操作系统一样成为任意应用代码的部署环境,但实践中它并不擅长依赖管理、版本控制、滚动升级、监控指标、网络服务调用这些现代应用开发的基本需求;Mesos/YARN/Docker/Kubernetes这类专注做好”运行应用代码”这一件事的工具反而做得更好。因此让系统的一部分专门做持久数据存储、另一部分专门跑应用代码,二者保持独立又能互动,是更合理的分工——大多数Web应用采用的”无状态服务+数据库”部署模式正体现了这种分离(函数式编程社区调侃为”我们相信教会与国家的分离”):应用逻辑不进数据库、持久状态不进应用。

参考来源

- 位置:《数据密集型应用系统设计》第十二章《数据系统的未来》"应用代码作为衍生函数""应用代码和状态的分离"(源文件:_epub-src/ch12_split_001.html) - 结论依据:原文列举次级索引/全文索引/机器学习模型/缓存四类衍生函数,说明数据库对自定义应用代码支持薄弱而专用部署工具做得更好,并引用"教会与国家分离"的比喻说明无状态应用与状态数据库分离的合理性,直接支撑本卡片结论。 - 原始内容:当创建衍生数据集的函数不是像创建二级索引那样的标准搬砖函数时,需要自定义代码……Mesos,YARN,Docker,Kubernetes等部署和集群管理工具专为运行应用代码而设计……我们相信教会与国家的分离。