数据系统的未来
数据集成
组合使用衍生数据的工具
为了处理任意关键词的搜索查询，将OLTP数据库与全⽂搜索索引集成在⼀起是很常⻅的的需求。尽管⼀些数据库（例如PostgreSQL）包含了全⽂索引功能，对于简单的应⽤完全够了【1】，但更复杂的搜索能⼒就需要专业的信息检索⼯具了。相反的是，搜索索引通常不适合作为持久的记录系统，因此许多应⽤需要组合这两种不同的⼯具以满⾜所有需求。
理解数据流
如果您可以通过单个系统来提供所有⽤户输⼊，从⽽决定所有写⼊的排序，则通过按相同顺序处理写⼊，可以更容易地衍⽣出其他数据表示。 这是状态机复制⽅法的⼀个应⽤，我们在“全序⼴播”中看到。⽆论您使⽤变更数据捕获还是事件源⽇志，都不如仅对全局顺序达成共识更重要
衍生数据与分布式事务
全局有序的限制
排序事件以捕获因果关系
但是如果好友关系状态与消息存储在不同的地⽅，在这样⼀个系统中，可能会出现解除好友事件与发送消息事件之间的因果依赖丢失的情况。如果因果依赖关系没有被捕捉到，则发送有关新消息的通知的服务可能会在解除好友事件之前处理发送消息事件，从⽽错误地向前任发送通知。
批处理与流处理
我会说数据集成的⽬标是，确保数据最终能在所有正确的地⽅表现出正确的形式。这样做需要消费输⼊，转换，连接，过滤，聚合，训练模型，评估，以及最终写出适当的输出。批处理和流处理是实现这⼀⽬标的⼯具。
维护衍生状态
衍⽣数据系统可以同步地维护，就像关系数据库在与被索引表写⼊操作相同的事务中同步更新辅助索引⼀样。然⽽，异步是基于事件⽇志的系统稳健的原因：它允许系统的⼀部分故障被抑制在本地，⽽如果任何⼀个参与者失败，分布式事务将中⽌，因此它们倾向于通过将故障传播到系统的其余部分来放⼤故障
应用演化后重新处理数据
衍⽣视图允许渐进演化（gradual evolution）。如果你想重新构建数据集，不需要执⾏迁移，例如突然切换。取⽽代之的是，你可以将旧架构和新架构并排维护为相同基础数据上的两个独⽴衍⽣视图。然后可以开始将少量⽤户转移到新视图，以测试其性能并发现任何错误，⽽⼤多数⽤户仍然会被路由到旧视图。你可以逐渐地增加访问新视图的⽤户⽐例，最终可以删除旧视图。
Lambda架构
分拆数据库
组合使用数据存储技术
- 次级索引，使您可以根据字段的值有效地搜索记录（参阅“其他索引结构”）
- 物化视图，这是⼀种预计算的查询结果缓存（参阅“聚合：数据⽴⽅体和物化视图”）
- 复制⽇志，保持其他节点上数据的副本最新（参阅“复制⽇志的实现”）
- 全⽂搜索索引，允许在⽂本中进⾏关键字搜索（参⻅“全⽂搜索和模糊索引”）内置于某些关系数据库
创建索引
一切的元数据库
联合数据库：统一读取
分析数据库：统一写入
展开分拆工作
联合和分拆是⼀个硬币的两⾯：⽤不同的组件构成可靠，可扩展和可维护的系统。联合只读查询需要将⼀个数据模型映射到另⼀个数据模型，这需要⼀些思考，但最终还是⼀个可解决的问题。我认为同步写⼊到⼏个存储系统是更困难的⼯程问题，所以我将重点关注它。
分拆系统 vs 集成系统
如果分拆确实成为未来的⽅式，它也不会取代⽬前形式的数据库 —— 它们仍然会像以往⼀样被需要。为了维护流处理组件中的状态，数据库仍然是需要的，并且为批处理和流处理器的输出提供查询服务（参阅“批处理⼯作流的输出”与“流处理”）。专⽤查询引擎对于特定的⼯作负载仍然⾮常重要：例如，MPP数据仓库中的查询引擎针对探索性分析查询进⾏了优化，并且能够很好地处理这种类型的⼯作负载（参阅“对⽐Hadoop与分布式数据库”
围绕数据流设计应用
与电⼦表格的不同之处在于，今天的数据系统需要具有容错性，可扩展性以及持久存储数据。它们还需要能够整合不同⼈群编写的不同技术，并重⽤现有的库和服务：期望使⽤某种特定语⾔，框架或⼯具开发所有软件是不切实际的。
应用代码作为衍生函数
应用代码和状态的分离
现在⼤多数Web应⽤程序都是作为⽆状态服务部署的，其中任何⽤户请求都可以路由到任何应⽤程序服务器，并且服务器在发送响应后会忘记所有请求。这种部署⽅式很⽅便，因为可以随意添加或删除服务器，但状态必须到某个地⽅：通常是数据库。趋势是将⽆状态应⽤程序逻辑与状态管理（数据库）分开：不将应⽤程序逻辑放⼊数据库中，也不将持久状态置于应⽤程序中。
