数据分布的演变

数据分布就是一个关于数据存放在哪里的问题。数据存储的地方不是固定的。随着应用规模的扩大，为了治理的方便，会适时地调整，其中就会包括数据存储的调整：

• 数据与应用部署在同一台设备。
  在早期以及我们现在刚入门学习编程的时候，都会把数据存储在本地，比如：本地文件或者本地的小型数据库。随着数据的扩大，对数据运算的次数将会急剧增多。应用本身需要运算，再叠加上数据运算，这必然导致设备的资源使用率高升。因此，出现下一阶段的演变。

• 数据与应用分别部署。
  这种部署方式使得应用运算与数据运算互不干扰，应用服务器只处理应用的运算，数据库服务器只负责数据运算，因此，这两台设备的资源占用率又下降到相对低的水平。
  然而，这种方式是基于网络来连接两台设备，应用服务器需要发送运算指令给数据库服务器去执行，而数据库服务器执行完运算指令后，将结果返回给应用服务器。这个过程会面临网络不通的风险。它造成的后果有可能是数据运算指令到达不了数据库服务器，也有可能是运算结果返回不到使用服务器。对于后者，造成的危害会更大，因为应用端可能因为收不到结果而重复发送运算指令（最可怕的是比如：重复向同一个账户转账）。不过，这种情况可以通过程序设计来规避。而对于前者，网络不通会造成新的事务一直无法完成,这就是所谓的单点故障。当数据库服务器宕机后，整个系统就运作不了了。所以，随后就在应用与数据分离的基础上，发展出主备结构的部署模式。

• 主备结构
  这种部署方式需要主与备机的数据保持一致。毕竟是两台独立的设备，所以数据同步会存在一定的延迟。
  对于应用程序，它配置数据源的时候需要配置两个，当主的数据库宕机，它能够使用备的数据库继续工作。
  假如一个事务在处理过程中，主的数据库宕机了，应用程序必然会接收到异常（请看《Mysql Connector/J 源码分析（普通Connection）》），因此该事务必然中止。在应用未能够成功切换数据源到备机的这一片刻，新来的事务必然也是无法成功。当新的数据源建立好连接并且成功切换后，新来的事务就有可能被成功处理。说“有可能”成功是因为有可能关键数据在宕机前未来得及同步到备机，而造成数据非预期的改变。
  主备结构对于应用程序来说，可能就象字面一样，一个是主设备，一个是备设备。平时备设备同步主设备，当主设备宕机后应用切换数据源到备机。但也存在另一种使用方式，就是两台设备互为主备。这种情况下对于应用程序来说可以实现负载均衡。但是，无论哪一种方式，都无法掩盖数据同步的延迟带来的风险。要解决未来得及同步更新数据就宕机的情况，写日志是可选的方式。每一笔成功的事务都需要写日志。当出现数据的非期望的更改时，至少有日志可作为佐证。

• 分布式存储、
  随着业务数据的不断增长，就会面临因为数据量过大而极大的增加事务处理耗时。这时候，分布式存储出现了。分布式的核心就是依据某种规则将数据分布在不同的设备（即：场地），这些场地数据的并集才是数据的全量。这种规则比较常见的是以ID作为解释对象。可能是某一段范围ID的数据放置在这个场，另一段范围ID的数据放置在另一个场；也可能通过hash计算，将某些ID的数据放在一个场，某些ID的数据放在另一个场这样。随着ID的不断增长，可以安排到新的场。这样就确保了每个场的数据量不会太多而影响运算性能。
  但是，这种模式下同样面临数据同步延迟带来的风险。数据同步的操作来源于：
  1）对每个场同步全局数据
  2）为解决每个场的单点问题，而进行多机部署

本节介绍了数据分布的演变。其内在的驱动演变的动力在于降低每台设备的资源消耗，包括CPU，内存，以及硬盘空间。做法就是让每台设备只负责一部分数据的存储和计算，从面达到降低每台设备的资源消耗，同时保证运算耗时不太长。

数据的使用

我自已觉得数据的使用存在层级的关系，具体点就是下层的数据为上层提供依据。
比如，在一开始的时候，我的系统只服务器广东省，数据库存放的都是广东省内员工、业务信息。平时数据操作主要就是增删改查本省的数据，并且会统计少量的指标值。随着公司业务的发展，业务延伸到广西省，这时候我就有可能要考虑在广西部署一套服务于广西的系统。广西系统的数据操作也主要是增删改查，并且会统计少量的指标值。当我决定要开拓广西的业务时，自然而然会想到：将来还有可能拓展到更多的地域。当真的从一个点开拓出更多点后，从管理上，伴随而来的需求就是对各个点进行综合比较，分析出产生差异的原因，从而制定更宏观的政策以及对各个点的差异发展规划。
这时候，就会诞生新的管理系统，它为客户功能提供的功能不再是在增删改某个员工的信息，或者分页查询员工信息。它要展示的内容将会变成各个点的员工数量变化的对比，各个点的业务增速等。不难发展，这些数据以指标类为主。
所以，从抽象的角度讲，底层的数据为上层数据服务。这种理念会对数据的分布产生影响。既然上层需要的是指标类数据，那么就没必要把各个点的数据都同步到上层系统去，各个点只要计算出自己的指标然后上传给上层系统就行了。上层用户如果希望查看形生某个指标值的原始数据，上层系统可向下层系统发送指令，下层系统接受到指令后返回原始数据给上层系统。这样的处理即满足的客户的查看需要，又节约了上层系统的存储空间。
现在我们知道上层系统存放的是下层系统的指标类数据，那么数据存储的分布也同样的适用于上一章节所描述的方式。
可能有人会问，既然下层系统提供了指标类数据，按道理上层系统的数据应该是极少的，不应该存在分布式部署的方式呀。确实，仅从下层系统上传的指标类数据是不会太多，但是仅依赖这些指标也不足以挖掘出更多有经济效益的数据，因此，更多的可能是需要从下层系统同步一些有挖掘价值的数据到上层系统。这样上层系统就需要有足够的存储空间，同时也要保证系统功能的响应时间了。上层系统有了这些待挖掘数据后，才有可能发现某种规律或者现象，为领导的决策或者发展方针的制定或者调整提供数据上的支撑。

总结

本文介绍数据分布的演变，最终是以分布式的方向发展。然后从数据的使用角度进行探讨，提出上层系统与下层系统的概念，并且讲述它们间对于数据使用的区别和联系。另外，上层系统必定有新的赋能，它同样需要足够的存储空间来实现新的需求。因此，对于上层系统的数据分布，必然同样会向着分布式的方向发展。