规范化数据模型是传统关系型数据库设计的核心，它为如何管理关系型数据提供了最佳设计理念，但同时也限制了数据查询的灵活性和高效率。
在云计算、大数据等新技术的带动下，越来越多的企业需要对结构化的数据进行查询、分析、处理和更新。同时，随着创新业务的不断增加，业务的复杂及庞大的体量必然会产生错综复杂且规模巨大的结构化数据，这些都必然迫使企业对数据库的需求指向大规模、高可靠、高扩展及高性能。
什么是数据去中心化
数据去中心化过程也就是数据拆分的过程。依据服务划分数据，将数据从主体数据剥离出来。
为什么需要数据去中心化
规范化数据模型是传统关系型数据库设计的核心，即通过三大范式实现数据的有效存储，并为开发人员提供一整套对数据的操作方式。规范化数据模型有利有弊，它为如何管理关系型数据提供了最佳的设计理念，但同时也限制了数据查询的灵活性和高效性，特别是当查询涉及多关联场景时，会导致查询性能严重低下。
规范化数据模型的另一个问题在于中心化思想，即把数据统一存储在一个中央数据库中。当大量数据存在于同一个数据库时会容易造成数据库访问瓶颈，从而影响数据访问性能，并为系统可用性埋下隐患。
数据去中心化场景
跨表查询场景
单库跨表查询相对于来说场景比较简单，不同业务共享几张数据表，通过关联查询获取需要是数据。应对这种查询是将关联查询拆分为多个单表查询，然后将结果数据进行动态重组，从而形成业务所需要的数据。
跨库查询场景
跨库查询说明不同数据库之间的表也存在着连接查询操作。针对该场景，基本的解决思路有两种：
静态数据
针对一些修改频率不高、相对静态的数据而言，可以采取数据复制的方式达到同一份数据在两个数据库中同时存在的效果，从而将跨库查询转变为同一库中的表查询。
动态数据
对实时性要求比较高的数据，可以通过开放接口的方式实现两个数据库之间的数据集成效果。
技术耦合场景
技术耦合场景表现在使用了特定某种数据存储容器相关的技术体系。对于关系型数据库而言，存储过程、触发器等就是典型的数据库工具级别的特有技术。由于每种数据存储容器对这些具体技术的实现和支持方式都有所不同，所以在原则上我们的业务功能都不应该使用这些技术进行数据处理。如果有，那就坚决去掉。采用的方式也是将这些存储过程、触发器中所涉及的业务逻辑全部用代码重新实现一遍即可。
数据去中心化流程
数据去中心化的步骤：
代码分离
想要对数据库进行拆分，首先要把操作数据库的代码拆分出来。即把原本在单块系统中的代码拆分成几个组成部分。
重复数据库模式
代码拆分完之后，对数据的访问会形成两种模式。一种是数据能够随着代码完成拆分，即这些数据不存在多个系统共同访问的情况，那简单把数据迁移出去供单个系统访问即可。但是很多情况下，代码中充斥着跨表查询，跨库查询和技术耦合场景，不能简单进行数据拆分，所以作为一个过渡环节，我们可以把几个系统公用的数据进行冗余处理。
迁移数据读写操作
完成数据冗余之后，将针对数据库写入和读取操作做单独抽离。一般写入操作比较好抽离，因为插入只涉及单表。难度最大的为读取的抽离，在没有专门的数据拆分之前，同一份数据可能通过各种方式被很多业务所共享，会出现大量跨表查询、跨库查询和技术耦合场景。
抽取服务化接口
在完成数据读写操作的迁移、去除数据定时同步机制之后，我们就可以对单块系统中的代码进行拆分，从而实现服务化。所有的数据访问通过服务化的接口进行。
参考资料
微服务设计原理与架构 郑天民/著（本文部分内容摘录此书，分享知识，尊重作者）
Scott W Ambler, Pramod J Sadalage. 数据库重构[M]. 王海鹏等译