Designing Data-Intensive Applications翻译

一. 可用性, 可扩展性, 可维护性应用程序

现在的应用程序已经从计算密集型转变为数据密集型. CPU的算力已经很少是这些应用程序的限制条件,更多的是所需处理的数据的数量, 复杂度以及数据变化的速度.

…

考虑一下数据系统(Data System)

通常我们认为数据库, 队列, 缓存,等等是一些不同类别范围的概念, 尽管可能数据库和消息队列看起来很多相似的地方-- 例如它们都用于某时存储一些数据-- 但是它们具有不同的访问模式, 这就意味着不同的性能特征, 实现方式也完全不同.

那我们为什么把他们放在一块, 以Data System来讲呢?

近年来出现了很多新的组件来实现数据的存储和处理. 它们都各自为了优化某些场景下的需求而实现, 不再完全属于传统的范畴. 例如, 有一些数据存储组件也可以被用作消息队列(如Redis), 也有一些消息队列组件被用于数据库持久化保证(例如Apache Kafka). 这些组件的类别划分变得很模糊.

第二, 越来越多的应用的需求日渐复杂, 无法由一个组件能够满足他们所有的数据处理和数据存储的需求. 相反, 这些工作被分解为子任务, 从而能够获得某个组件的高性能, 而对于不同组件的应用也通过业务代码来将其联系起来.

例如, 如果你有用户管理的缓存层(例如Memcached或类似组件), 或者有一个全文检索服务器(例如Elasticsearch或Solr)与主数据库分离, 通常应该由应用程序的代码来实现这些缓存和索引与主数据库的同步. 如图1-1所示, 大概应该是这样(详情会在后文中给出):

当你组合了几种不同的组件一起使用的时候, 一般是直接使用API调用接口, 内部的实现细节都是被隐藏了的. 假如你现在要基于之前实现的小型通用功能的组件, 实现一个具有一些增强功能(原文为special-purpse)的数据系统, 你使用的多个组件应该具有以下功能: 例如, 1) 缓存能被正确地释放; 2) 写请求能够保证数据一致性. 此时你不仅仅是个程序开发者, 还应该是个数据系统设计师.

这时候就会冒出来很多奇怪的问题: 在软件内部发生故障的时候, 如何保证数据是正确的, 完整的? 当整个系统降级(degraded)的时候, 如何保证性能不降低很多? 如何调整规模来应对负载增加? 一个好的服务API应该是什么样的?

因此在设计数据系统的时候有很多因素需要考虑.