云的数据考虑

云服务的搭建需要将许多数据特性考虑在内。简单列举如下：

• 物理特性
• 性能要求
• 易变性
• 容量
• 监管要求
• 事务边界
• 保存期限

所有这些数据需求都会对如何存储底层数据造成决策影响。我们必须做出两个关键性的决策：

1. 单租户还是多租户
2. 使用何种数据存储格式：SQL、NoSQL、文件等

数据特性

下面我们将针对每一种数据特性在设计时需要考虑的因素进行讨论。

物理特性

我们需要手机很多数据点来进行物理特性的分析。数据的位置是一条重要的信息。数据已存在还是全新的数据集？数据是否高度敏感？是否需要分析数据的法律责任、归属于公司还是用户？不同的国家对于数据进入和离开大欧有着不同的法律规定。

对于搭建 SaaS、PaaS、IaaS 方案的公司而言，对数据所有和数据共享方式的确定，会对为了满足某些有关隐私、安全和服务等级协议（SLA）的特定需求，是否需要隔离数据库甚至按每个客户隔离数据库服务器这样的设计决策产生决定性的影响。

性能要求

性能分为三类：实时、近实时以及延时。响应时间分类决定了主要的设计决策。所要求的响应时间越短，架构师越有可能需要使用内存而不是磁盘。常见的用于大容量高性能数据集的设计模式是：

• 使用缓存层；
• 减少数据集的大小（存储属性的哈希值或二进制表示形式）；
• 将数据库区分为只读节点和只写节点；
• 将数据进行切片，分成特定的客户切片、特定时间切片或特定区域切片；
• 对陈旧数据进行归档，降低表的大小；
• 对数据集进行非规范化处理。

理解性能需求对于设计决策起着关键作用。

易变性

易变性是指数据变化的评率。数据集可以分为静态数据局和动态数据集两类。

**静态数据集通常是事件驱动的数据，按时间顺序发生。**比较常见的是日志数据、交易数据，此类数据是“一次写入，多次读取”类型的数据集，在某一个时间点发生，但是会反复读取分析以检测模式和观察行为。这些数据集通常会存放很长一段时间，占用 TB 级的数据空间。具有这种性质的大型静态数据集通常会要求采用非标准化的数据库操作来使性能最大化。挖掘这类数据集的常见操作是对数据进行非规范化处理、使用星型或雪花模式（schema）、使用 NoSQL 数据库，以及最近更常见的是应用大数据技术。

**动态数据要求完全不同的设计。**如果数据经常变化，规范化的关系型数据管理系统（RDMS）就是最常见的解决方案。关系型数据库非常适合处理 ACID（原子性、一致性、隔离性和持久性）事务以确保数据的可靠性。规范化的关系型数据库通过确保重复数据和孤儿记录不存在来保护数据的完整性。

易变性的另一个重要特征是数据的频率。一个月产生一百万数据要比一分钟产生一百万数据容易设计的多。数据流动（增、改、删）的速度是决定数据层整体架构的重要影响因素。所以，确认数据很重要，这样我们才能选用最适当的磁盘存储系统来解决特定问题。

容量

容量是指一个系统必须保存和处理的数据量。使用关系型数据库好处很多，但当数据容量达到某一规模时，关系型数据库会变得非常慢，维护费用也搞得难以承受。架构师同样必须明确有多少数据必须在网上维护和访问，以及有多少数据应进行存档或存放在较慢且价格较低的磁盘上。容量还影响了备份策略的设计。对数据库和文件系统进行备份是保证业务可持续性和灾难恢复的关键，必须满足李四 SSAE 16 和其他监管法规的要求。如果没有合理的设计，备份很可能会消耗大量的 CPU 资源，并对整个系统的性能造成影响。全备份通常会每天进行，而增量备份则会在一天的多个时间内进行。一种常见的策略是在从数据库上进行备份，这样应用程序的性能就不会受到影响。

监管要求

法规在制定与数据有关的决策时扮演了重要角色。被划为 PII（个人身份认证信息）一类的数据在运行和存储时必须进行加密，这就带来了一定的性能消耗，在这些字段内容经常变化且数据很大时情况尤为明显。PII 数据是公司选择使用私有云和混合云的主要原因，因为许多公司拒绝将敏感和私有数据放在公有、多租户环境中。理解法规的限制和风险可以驱动部署模式的决策。

事务边界

事务边界可以理解成一种工作单元。理清事务边界对于明确哪些数据点需要进行状态的存储、哪些又不需要非常重要。切记，RESTful¹ 服务需要设计成无状态的，所以架构师需要明确为这种符合事务状态保留的最佳方法，比如可能需要进行缓存、写入队列、写入临时表或磁盘等。如果复合事务场景可能会经常发生，那么将数据写入表或磁盘可能会造成性能的瓶颈，在内存中对数据进行缓存或许会是一个更好的方案。

保存期限

保存期限是指数据必须保存的时限。例如，财务数据通常需要保存 7 年以满足审计的需求。但这并不意味必须保持 7 年在线可访问，只是说 7 年内不应进行销毁。

理解保存期限对于选择适当的存储解决方案非常重要。需要留存但不必要提供实时或近实时网络访问的数据可以放在非常便宜的离线磁盘或磁带上。通常这些存档数据会被异地保存在一个灾难恢复站点处。而需要立刻进行检索的数据则需要被存放在一个具有冗余备份且可以快速从故障中恢复的高性能磁盘上。

多租户或单租户

系统的租用应由前述的各项数据特性来决定。当提到一个架构的数据层时，多租户（multitenancy）意味着有多个组织或客户（租户）共享一组服务器。绝大多数定义中会说到是是一台服务器，但实际上通常会需要多台服务器（主从服务器）来支撑一个租户。单租户意味着每组服务器只支撑一个租户。

• 完全隔离
• 数据隔离
• 数据分离

选择数据存储类型

使用什么样的数据存储类型是另一个重要的决策问题。许多IT部门都对关系型数据库非常熟悉，下意识地会直接选择用关系型数据库来解决所有的数据问题。但就像我们说过的，你可以用锤子来建造房子，但有时候把钉枪或许更顺手。

为了将数据存放在数据库中，关系型数据库必须保证事务得到成功处理，因此非常适合联机事务处理(OLTP)行为。此外，关系型数据库还有着卓越的安全特性和有力的查询引擎。现在NoSOL数据库开始逐渐流行起来，原因主要有两点:越来越多的数据存储和访问都在弹性云计算资源中进行;磁盘解决方案变得日益廉价，但速度却在不断提高，公司因而存放了比以往任何时候都要多的数据。现在，一个公司有着 PB级的数据再也不是什么稀罕事。而这么大量的数据通常又主要用于完成分析、数据挖掘模式识别、机器学习和其他工作。企业可以借助云配置多合服务器来将工作负载分配到多个节点上来加快分析，然后在分析结束后再撤销对所有服务器的部署。

当数据变得这么大时，关系型数据库的处理速度就很难满足速度的需求了。关系型数据的构建强调了参照完整性。为了达到这一点，在数据库引警中内置了大量的开销来确保在数据存放进表之前完成事务的处理和提交。关系型数据同时还要求索引来加快对记录的检索。而如果记录数足够大，索引就会产生相反的结果，数据库的性能也将变得无法接受。

NoSOL 数据库的出现正是为了解决这些问题。当前有 4 种 NoSOL 数据库。

键值存储

键值存储数据库采用了哈希表，每个带有指针的唯一的键都会指向一个特定的数据项。这是 4 种 NoSOL 数据库类型中最简单的一种，速度快，高扩展，在处理类似发推这种海量写入行为时用处明显。当然在读取类似历史订单、时间和交易这种大型、静态、结构化数据时也有良好的表现。不足之处在于，这种技术没有对数据库的结构描述（schema），所以不适合处理复杂的数据和关系。键值存储数据库的代表产品有 Redis、Voldemort（LinkedIn）、DynamoDB（亚马逊）。

列存储

列存储器的出现是为了存储和跨多台机器之上的大规模分布式数据。哈希键指向以列家族进行组织的多个列。这种数据库的威力在于，可以在运行中添加列，并且允许行值出现空缺。列存储数据库的优势在于，这种数据库的速度极快，扩展性也好，并且在运行时也更容易做出变更。列存储在对多源异构数据进行整合时会表现非常优秀，但不太实用高度连接的数据源。列存储数据库的典型代表是 Hadoop 和 Cassandra。

文档存储

文档存储数据库用于存储以文档形式进行存放的非结构化数据。数据通常以XML、JSON、PDF、Word、Excel和其他常见的文档类型进行封装。大多数日志解决方案使用文档存储将来自不同数据源的日志文件整合在-起，比如数据库日志、Web 服务器日志、应用服务器日志、应用日志等这些数据库在由不同格式组成的大规模数据的扩展方面表现突出，但同样在高度连接的数据的处理上差强人意。文档存储数据库的代表是 CouchDB和 MongoDB。

图像数据库

图形数据库用于存储和管理彼此关联的关系。这些数据库通常用于展现关系的可视化表述，尤其是在社交媒体分析领域。这些数据库在绘图方面表现优异;但由于为了产生结果必须对整个关系树进行遍历，所以在更多的其他方面却性能较差。图形数据库的代表是Neo4j和InfoGrid。

其他存储方式的选择

我们讨论了 SQL和 NoSQL 的选择，但有时我们也会以文件的方式存储数据。比如像照片、视频和 MP3 这样的大型文件可能有数兆字节或更大。Web 服务器如果用数据库对这些大字段进行存储和检索的话，可能很难提供高性能的用户体验。更好的方法是利用内容分发网络(CDN)这种通过互联网连接的位于多个数据中心的分布式计算机网络。CDN能提供高可用性和高性能，是流媒体和其他带宽密集型数据的选择工具之一。

数据有各种特性，理解这些特性和每种特性的不同要求，对于选择正确的云服务模型、云部署模型、数据库设计和数据存储系统至关重要。没人会在搞清楚房屋的要求和分析建筑平面图之前就动手盖房子，但是有些公司却会在完全理解其数据需求之前就动手搭建软件。不管是搭建新的系统还是迁移现有系统，架构师都应该和产品团队一起花些时间，对本章所叙述的各种数据特性都进行一下评估。只有完全了解了各种数据特性，才能搭建一个满足业务需求的最佳系统。