深入讲解OLTP类系统数据结转最佳实践

　   OLTP也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。

　　本文着重介绍了京东数据结转平台的技术架构，及OLTP类系统数据结转最佳实践，探讨解决大数据背景下的数据结转问题。

一、 背景介绍

　　业务系统在长期运行的过程中会积累大量的数据，这些数据有些是需要长期保存的，例如一些订单数据，有些只需要短期保存，例如一些日志信息。业务数据一般都会有一个生命周期，生命周期内的我们叫生产数据，生命周期之外(即业务已经关闭)的叫历史数据，我们这里提到的数据结转，指的是将需要长期保存的历史数据从生产库迁移到历史库(转)，而将需要短期保存的数据定期删除(结)。

　　我们已经进入了大数据时代，但在OLTP类系统中，关系型数据库依然占据主导地位，在关系型数据库中，如果不及时进行数据结转，会严重影响系统的性能。

　　关系型数据库单机容量有限，因此业界普遍的做法是进行垂直分库和水平分片，一些大型互联网企业由于业务量庞大，仅分片的集群规模就能达到上千节点，再加上分库的集群，规模非常巨大。传统的数据归档方法往往针对单库操作，难以处理如此大规模集群的数据归档。

　　同时，在大型互联网企业，每日的数据增长量非常大，数据结转的频率远大于传统行业，这些行业的IT系统往往是7*24小时不间断提供服务，而且全天24小时的并发量都很大，因此数据结转操作必须尽量减少对生产库的性能影响。

　　为此，我们自主研发了数据结转平台，以解决大数据背景下的数据结转问题。

　　二、 技术架构

　　2.1 设计要点

　　(1)尽量减少对生产库的影响

　　数据结转操作没有复杂的业务逻辑，因此对数据库性能的影响主要体现在IO方面，减少对生产库的影响，最主要的就是减少对生产库的IO操作。目前我们采用的方案是通过从库查询数据，将数据插入历史库，然后再从主库中删除，如图1数据结转逻辑图所示，将查询的IO操作转嫁到从库上，可以大大减轻对主库的影响。为了保障数据库的高可用，业内基本都采用了主从部署模式，因此这个方案具有很高的通用性。

　　                                                                        图1 数据结转逻辑图

　　(2)支持分库分片集群

　　我们希望数据结转平台的配置足够简单并且易于理解。在和用户的沟通过程中，我们发现他们最强烈的需求就是分库分片集群的数据结转。传统的单机数据结转操作可以抽象描述为：将数据库实例A中表B的历史数据结转到历史库C，用户的配置主要有4个元素：生产库实例A、结转表B、结转条件和历史库。对于大规模的分库分片集群规模，如果采用传统单机数据结转的配置方式，每一个数据库实例都要配置4个元素，配置量非常大。

　　在我们的方案中，按照图2所示对数据库集群进行划分，将主库、从库、历史库作为一个结转单元，对于分片的数据库集群，表结构相同，我们将其作为一个分组，对于分库的集群，表结构不同则划分为不同的分组。用户进行配置的时候不是面向一个数据库实例，而是面向一个分组，数据结转操作抽象为：结转分组X中表B的历史数据，用户的配置元素有3个：分组X、结转表B和结转条件。分组信息仅需配置一次。这样大大简化了用户的配置工作。

　　(3)支持水平扩展

　　由于数据库集群规模较大，数据结转平台应该具备水平扩展能力。我们采用的方案是将数据结转最核心的组件定时任务和数据库操作(数据结转执行器)独立出来，进行分布式部署。如下图3所示，

　                                                                           　图2 数据库集群模型

　　配置中心为用户的入口，用户通过配置中心定义数据结转任务，任务的关键属性包括：触发条件、执行条件、目标分组等，配置中心将结转任务分发给代理程序，同时对代理程序的执行状态进行监控。结转任务的触发条件配置在代理程序中的定时任务中，而执行条件和目标分组则作为数据结转执行器的执行参数。通过水平扩展代理程序，我们对更多的数据库进行结转。

　　                                                                          图3 数据结转组件关系图

　　2.2 总体架构

　　综合上面提到的3个设计要点，我们得到图4所示的总体架构，需要特别说明的是，对于水平分片的分组，我们采用的是多线程结转，对于不同结转单元不存在数据共享问题，所以无需考虑并发锁等问题。

　　OLTP与大数据

　　事务系统包含巨量数据的更新，是业务延续性的重中之重，并提供对重要数据的近实时访问，包括让企业更有竞争力的数据。

　　联机事务处理分析范围扩展到近实时数据，尤其是客户数据；提供近乎实时的虚拟数据仓库；对主数据管理的负载均衡更新，增加企业信息化架构的灵活性。

　　要在这些新任务上成功应用OLTP，就必须重新定义OLTP在企业信息化体系结构中的地位。OLTP不再只是一套能处理订单的老式应用程序。对典型的OLTP系统处理的大规模数据流更新进行同时分析，这种情况很罕见，因为一般认为这不是OLTP的目的。然而数据仓库更新固有的延迟阻碍着对最新数据的近实时分析。组织如果要对于数据的变化迅速作出反应，IT部门就必须让OLTP产生比以往更大的作用。[1]

　　OLTP设计注意事项
　　事务处理系统数据库应设计为支持：

　　1.很好的数据放置。

　　对于OLTP系统，输入/输出瓶颈是一个尤为关心的问题，原因在于修改整个数据库中数据的用户很多。确定数据的可能访问模式，并将经常访问的数据放在一起。在此过程中，可辅以文件组和RAID（独立磁盘冗余阵列）系统。

　　2.缩短事务以将长期锁减至最少，提高并发性。

　　在事务期间，避免用户交互。无论何时，只要有可能，就通过执行单个存储过程来处理整个事务。在事务内对表的引用顺序可能会影响并发性。将对经常访问的表的引用置于事务的末尾，以便将控制锁的持续时间减至最短。

　　3.联机备份。

　　OLTP系统通常的特征是连续操作（一天24小时，一周7天），为达到此目的，停工时间要保持绝对最短。尽管MicrosoftSQLServer2000可以在数据库正在使用时对其进行备份，但是应将备份过程安排在活动不频繁时进行，以使对用户的影响减至最小。

　　4.数据库的高度规范化。

　　尽可能减少冗余信息以提高更新的速度，从而提高并发性。减少数据还可以提高备份的速度，因为只需要备份更少的数据。

　　5.很少或没有历史或聚合数据。

　　可以将很少引用的数据归档到单独的数据库中，或者从经常更新的表中移出，并置于仅含历史数据的表中。这将保持表尽可能地小，从而缩短备份时间，改善查询性能。

　　6.小心使用索引。

　　每次添加或修改行时，必须更新索引。若要避免对经常更新的表进行过多的索引，索引范围应保持较窄。请用索引优化向导设计索引。

　　三、 一些经验总结

　　a) 配置中心与代理程序之间的信息同步

　　                                                                        图4 数据结转总体架构图

　　配置中心和代理程序在我们的方案中被设计为一种松耦合结构：在系统的运行过程中，代理程序宕机不会影响配置中心的运行，同样配置中心短暂的不可用也不会影响代理程序的运行。松耦合结构可以大大增强系统的可用性，而且配置中心、代理程序升级的时候不会影响整个系统的正常运行。

　　为了实现松耦合的结构，配置中心与代理程序之间的信息同步我们都是采用的异步处理，比如配置中心向代理程序分发结转任务，实际处理的时候我们采用的是拉的方式，而不是推的方式，我们在配置中心和代理程序之间维持了一个心跳，心跳的内容是代理程序负载的所有结转任务的校验码(该校验码在代理程序向配置中心发送心跳信息时由配置中心计算)，当代理程序发现从配置中心得到的校验码和本地校验码不同时，则说明用户对结转任务进行了修改(包括新增、修改、删除)，此时代理程序主动向配置中心发起同步结转任务的请求。这样做的好处是，代理程序在发生宕机重启后，会自动进行任务的同步。

　　b) 进度可视化

　　结转任务的进度在我们的方案中是实时汇总到配置中心的，我们称为进度可视化，代理程序通过一个独立的线程来异步处理进度可视化，一方面这样可以降低对结转任务性能的干扰，另一方面可以避免由于网络问题、配置中心暂时不可用等问题导致结转任务异常。进度可视化对于用户来说非常重要，用户在第一次定义结转任务并执行该任务的时候，进度可视化信息是用户和系统互动的唯一窗口，对用户来说是莫大的心理安慰。

　　c) 异常可视化

　　代理程序在执行数据结转任务时，会遇到各种异常信息，比如数据库URL配置错误，历史库生产库表结构不一致等，对于这些异常信息，除了在本地记录日志外，我们还将它们发送到了配置中心。将这些异常可视化，而不是让用户在大量的日志中去检索，这种方式非常便于在线问题的诊断。

　　d) 事务一致性

　　将生产库数据转到历史库本身是一个分布式的事务，在我们的方案中，不能保证数据的强一致性，比如在历史数据Insert到历史库的瞬间，用户修改了生产库的数据，我们的方案不会检测这种变化，会导致用户的修改并不会反映到历史库中，造成数据不一致。虽然在生产库中删除历史数据时，可以增加强一致性的校验，以解决这种问题，但是这样会对生产库造成一定的压力，同时考虑到这种情况发生的概率极低，因此并没有进行特殊处理。

　　历史数据Insert到历史库后，可能由于某种异常导致生产库执行Delete操作时失败，此时会造成数据冗余(生产库和历史库存在相同数据)。对于这种问题，我们的方案是利用Redo Log(重做日志)机制，在结转任务重新执行时根据Redo Log恢复异常现场，纠正异常数据。

　　e) 结转数据的回滚

　　我们提供了一个数据回滚功能，可以将已经结转到历史库的数据逆向回滚到生产库，用户可以配置Where条件精确指定需要回滚的数据。有些特殊情况，业务上需要对已经结转的历史数据进行修改，该功能主要用于处理这种情况。同时在测试阶段，我们可以通过该功能快速恢复测试数据，方便对数据结转平台的测试。

　　f) 代理程序的自动升级

　　代理程序和配置中心本质上是一种典型的C/S(客户端/服务端)结构，客户端是多实例部署，服务器端是集群部署，为了系统能够平滑地进行升级，我们需要对客户端的版本进行统一管理，同时我们提供了代理程序的自动升级功能，系统管理员可以通过配置中心对代理程序部署实例进行升级。自动升级功能，统一了代理程序的版本，使得我们可以不用被兼容性问题羁绊，是我们能够进行快速迭代开发有力支撑。

　　根据综合性数据的组织方式的不同，常见的OLAP主要有基于多维数据库的MOLAP及基于关系数据库的ROLAP两种。MOLAP是以多维的方式组织和存储数据，ROLAP则利用现有的关系数据库技术来模拟多维数据。在数据仓库应用中，OLAP应用一般是数据仓库应用的前端工具，同时OLAP工具还可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。

　　更多详细内容尽在编程学习网哦！