基于SQL引擎的全链路压测数据分流系统及方法

基于sql引擎的全链路压测数据分流系统及方法
技术领域
1.本发明涉及全链路压测技术领域，具体涉及基于sql引擎的全链路压测数据分流系统及方法。


背景技术：

2.全链路压测作为一种新兴的软件测试技术，直接在生产系统中做压力测试，旨在准确评估线上环境的性能。与常规的压力测试相比，全链路测试不再单独部署一套测试环境，而是直接在生产环境中，通过模拟海量用户真实请求(例如通过流量回放技术基于真实用户请求生成测试用例)对系统进行压力测试。通过全链路压测，不仅能够减少部署成本，还能够保证流量的真实性和环境的真实性，得出更可靠的压测结论。
3.在生产环境中进行测试，最重要的是保证线上服务不受影响，其核心问题之一是保证生产数据不受到污染，即通过测试生成的数据应与真实的生产数据能够区分开来。现有技术中，基于影子库技术的数据分流技术能够保证全链路压测过程中生产数据不受测试污染。影子库技术，即构建一个与生产库完全相同的数据库(称为影子库)用来存储测试数据。生产库是指生产环境中使用的数据库，用于存储生产数据。同一套生产环境系统可以对应多个不同的生产库。影子库是存储测试数据的数据库，与生产库一一对应。影子库与其对应的生产库通常具有相同的表数量、表结构、表名字及其他的系统配置。影子库中的表称为影子表。影子库技术的典型架构中，生产流量和测试流量同时流入生产环境系统中，生产环境系统执行一些业务处理后，在数据层将转化成sql(structured query language)语句。在数据分流过程中，对sql语句进行分析，通过影子算法判断数据是测试数据还是生产数据后，将流量正确路由到生产库或者影子库中。目前，影子算法主要有两类，基于列的影子算法和基于hint的影子算法。其中，基于列的影子算法通过识别sql中的数据，匹配路由至影子库；基于hint 的影子算法通过识别sql中的注释，匹配路由至影子库。
4.然而，实现一个完整的数据分流系统存在以下挑战：(1)系统复杂度高。不同的项目可能会用到不同的关系型数据库系统(例如oracle、mysql、sql server等)，不同数据库系统的协议和方言不尽相同。此外，即使对于同一个数据库系统，其sql语句类型也是多种多样的，包括简单的选择或插入操作，到复杂的聚合或者表关联操作。要在同一个框架中支持所有这些关系型数据库系统及不同类型sql语句的数据分流极具挑战。(2)分流标准多样。不同的应用场景可能采用不同的数据分流标准。(3)透明性要求。增加数据分流后，要求现有的生产环境系统代码无需做任何修改。(4)高效率要求。由于中间增加了一层路由选择，需要尽可能减少路由带来的性能损耗，保证全链路压测结果的正确性。
5.近年来，各大互联网公司积极构建全链路压测平台，例如美团点评的quake、字节跳动的rhino、京东的forcebot、腾讯的wetest、阿里的amazon以及高德的testpg等，但这些平台关注整个压测流程及其自身的业务逻辑上，对数据分流部分关注不多，且平台均是闭源的，其他机构无法直接使用。而开源的takin系统仅仅支持按照标记进行数据分流，并且采用网页转发的框架，效率受到了极大的影响。


技术实现要素：

6.针对上述现有技术的不足，本发明提供了一种基于sql引擎的全链路压测分流系统及方法，在扩大适用范围的同时，还有效的提升了全链路压测的性能和效率。
7.为了解决上述技术问题，本发明采用了如下的技术方案：
8.基于sql引擎的全链路压测数据分流系统，包括解析器、配置管理器、路由器和执行器；
9.解析器用于对接入流量的sql语句进行解析，将sql语句转化为抽象语法树；
10.配置管理器用于设置配置文件，还用于解析配置文件得到配置信息，并将配置信息在内存中缓存起来供路由器使用；
11.路由器用于根据配置信息和解析后的抽象语法树，得到路由结果，所述路由结果的内容包括将sql语句路由到底层对应的数据库中；
12.执行器用于获取路由器的路由结果，并通过数据库连接技术jdbc调用对应的数据库的接口，将sql语句发送至对应的数据库中，供对应的数据库执行，所述对应的数据库为生产库或影子库；执行器还用于将执行的结果进行封装，并以标准jdbc数据库协议的方式返回给请求方。
13.优选地，所述配置文件的内容包括生产库的属性、影子库的属性、影子表的属性及使用的影子算法；所述影子算法为基于列的影子路由算法或基于hint的影子路由算法。
14.优选地，当影子算法为基于列的影子路由算法时，所述配置文件的内容还包括路由规则，所述路由规则用于进行影子库匹配；路由器对sql语句路由时，针对基于列的影子路由算法，路由器首先判断解析语法树ast中涉及的表集合t
ast
与配置文件中的影子表的集合t
config
是否有交集，如果没有交集，则直接将此sql语句路由到生产库中，否则，遍历t
ast
∩t
config
中的每一张表t，若sql语句中t的影子字段值符合任一路由规则，则将此sql 语句路由到影子库中，并提前结束迭代过程。
15.优选地，当影子算法为基于hint的影子路由算法时，所述配置文件的内容还包括hint影子标记f
config
；路由器对sql语句路由时，针对基于hint的影子路由算法，路由器逐一验证 f
ast
中每一个键值对标记是否与f
config
相同，若相同则路由到影子库中；若所有标记都与f
config
不相同，则路由到生产库中；其中，f
ast
为抽象语法树ast的所有键值对标记集合。
16.优选地，解析器还用于当影子算法为基于hint的影子算法时，对配置文件中的hint影子标记f
config
进行解析，并生成一个单独的注解节点挂载到抽象语法树上。
17.优选地，解析器内预置有多种不同数据库方言；所述多种不同数据库方言包括mysql、 postgresql、oracle、sql server、mariadb和opengauss的方言。
18.本技术还提供一种基于sql引擎的全链路压测数据分流方法，使用上述基于sql引擎的全链路压测数据分流系统，包括以下步骤：
19.s1、根据需求设置配置文件并存储在磁盘中；
20.s2、通过解析器将接入流量的sql语句进行解析，将sql语句转化为抽象语法树；
21.s3、通过配置管理器解析配置文件得到配置信息，并将配置信息在内存中缓存起来供路由器使用；
22.s4、根据配置信息和解析后的抽象语法树，通过路由器将sql语句路由到底层对应的数据库中；
23.s5、通过执行器接收路由器的路由结果，并通过数据库连接技术jdbc调用对应数据库的接口，将sql语句发送至生产库或者影子库中，供底层数据库执行；
24.s6、底层数据库执行结束后，通过执行器对执行结果进行封装，并以标准jdbc数据库协议的方式返回给请求方。
25.优选地，s1中，所述配置文件的内容包括生产库的属性、影子库的属性、影子表的属性及使用的影子算法；其中，所述影子算法为基于列的影子路由算法或基于hint的影子路由算法。
26.优选地，s4中，通过路由器将sql语句路由到底层对应的数据库中时，若配置信息中的影子算法为基于列的影子路由算法，则路由器首先判断解析语法树ast中涉及的表集合t
ast
与配置文件中的影子表的集合t
config
是否有交集，如果没有交集，则直接将此 sql语句路由到生产库中，否则，遍历t
ast
∩t
config
中的每一张表t，若sql语句中t的影子字段值符合任一路由规则，则将此sql语句路由到影子库中，并提前结束迭代过程。
27.优选地，s4中，通过路由器将sql语句路由到底层对应的数据库中时，若配置信息中的影子算法为基于hint的影子路由算法，则路由器逐一验证f
ast
中每一个键值对标记是否与 f
config
相同，若相同则路由到影子库中；若所有标记都与f
config
不相同，则路由到生产库中；其中，f
ast
为抽象语法树ast的所有键值对标记集合；f
config
为配置文件中的hint影子标记。
28.本发明与现有技术相比，具有如下有益效果：
29.1、与现有技术相比，本技术首次基于sql引擎技术设计并实现了一套完整的针对全链路压测的开源数据分流系统，其基本思想是通过对sql语句进行解析，辨别出是压测请求还是生产请求，然后将此sql语句正确路由至对应的数据库中，供底层数据库中执行，整个过程上层应用代码无需做任何改动。并且，本技术不仅可以按标记进行数据分流，还首次提出了按照给定字段的值进行数据分流。不同的数据分流算法满足多种不同的应用场景需求。
30.为了验证本技术的优异性能，申请人采用了两个通用的测试基准，比较了本系统和takin 的性能。实验证明，本技术在平均响应时间、分位响应时间、每秒处理的事务数三个标准下都优于takin系统。具体地，实验结果表明，本系统相对于原生的mysql直连查询tps损耗在1％～6％之间，平均响应时间和90百分位响应时间几乎没有影响。相对于开源全链路压测产品takin，本系统平均有2个数量级的性能提升。
31.2、本技术设计并实现了一个完整的基于sql引擎的全链路压测数据分流系统，该系统采用插件式开发，能够动态支持多种不同的关系型数据库系统。本技术系统实现了所有jdbc (java database connectivity)的接口，使用原生jdbc的应用程序只需要修改初始化数据源的少量代码，即可使用本技术。若使用hibernate、mybatis等框架，则只需要修改配置文件即可，无需修改任何代码。
32.3、本技术中的系统嵌入在用户程序中，无需对请求进行网络转发，因此对效率影响非常小，可保证全链路压测结果的正确性。
33.4、除了能够用于全链路压测外，本技术还可以用于a/b测试、系统预热、灰度发布等数据分流等场景中。
附图说明
34.为了使发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步的详细描述，其中：
35.图1为实施例中基于sql引擎的全链路压测数据分流系统的逻辑框图；
36.图2为实施例中配置示例的内容示例图；
37.图3为实施例中几种不同系统方法在sysbench数据集下的不同场景下的性能比较示意图；
38.图4为实施例中几种不同系统方法在tpcc数据集不同场景性能比较示例图；
39.图5为实施例中几种不同系统方法在sysbench数据集下的性能随请求并发度变化的比较示例图；
40.图6为实施例中几种不同系统方法在sysbench数据集下的性能随数据量变化的比较示例图。
具体实施方式
41.下面通过具体实施方式进一步详细的说明：
42.实施例：
43.如图1所示，本实施例中公开了一种基于sql引擎的全链路压测数据分流系统，包括解析器、配置管理器、路由器和执行器。为了方便说明，本实施例中，将本发明基于sql引擎的全链路压测数据分流系统命名为shadowdb。
44.解析器内预置有多种不同数据库方言；所述多种不同数据库方言包括mysql、 postgresql、oracle、sql server、mariadb和opengauss的方言。解析器用于对接入流量的 sql语句进行解析，将sql语句转化为抽象语法树。
45.本实施例中，解析器基于antlr(一个强大的结构化文本解析生成器)开发，它将用户的sql语句转化为一棵抽象语法树(ast，abstract syntax tree)，方便理解sql的语义信息。相对于其他数据库的解析器，shadowdb的解析器主要有两点不同。首先，为了支持多种不同的底层数据库系统，预置了多种不同的数据库方言。本实施例中，支持6种不同数据库方言的解析，包括：mysql、postgresql、oracle、sql server、mariadb和opengauss。具体实施时，其他任何符合sql-92标准和jdbc编程接口的数据库都可以经过少量修改就可以被轻松支持。其次，针对基于hint的影子算法标记，shadowdb会对其解析，然后生成一个单独的注解节点挂载到抽象语法树上，方便后续路由操作。
46.配置管理器用于设置配置文件，还用于解析配置文件得到配置信息，并将配置信息在内存中缓存起来供路由器使用。具体实施时，所述配置文件的内容包括生产库的属性、影子库的属性、影子表的属性及使用的影子算法；所述影子算法为基于列的影子路由算法或基于hint 的影子路由算法。
47.为便于理解，如图2所示，本实施例提供一个配置示例，其中代码第1～6行定义了数据库的连接参数，包括数据库的连接地址、用户名、密码等信息，其中，db和shadowdb是逻辑的数据库名(用户可自定义)，真实的数据库名可以通过url属性指定；代码第9～12行定义了生产库和影子库，这里只需要与前面定义的数据库建立映射关系即可，例如该例的生产库为db，影子库为shadowdb，并且这种映射关系起名为shadowdatasource(用户自定义名
称)；代码第13～18行定义了影子表及其采用的影子算法，这里表示影子表t_order采用的是 shadowdatasource的映射关系，并采用了名为match-algorithm(用户自定义名称)的影子算法；代码第19～25行定义了基于列的正则匹配影子算法match-algorithm，表示对于插入数据的sql语句，当uid的值为0时，路由到影子库中；代码第26～28行定义了基于hint的影子算法，表示当sql语句中包含注释hintflag:hint(注释标记可以自行指定)时，路由到影子库中。代码第29～30行指定sql引擎需要解析注释，方便执行hint路由操作，否则sql引擎会直接忽略注释。例如，给定sql语句“select*from t_order/*hintflag:hint*/”，因为注释中包含了影子标记，会直接路由到影子库中。
48.路由器用于根据配置信息和解析后的抽象语法树，得到路由结果，所述路由结果的内容包括将sql语句路由到底层对应的数据库中。具体实施时，针对不同的影子算法，其路由判断过程是不同的。
49.当影子算法为基于列的影子路由算法时，所述配置文件的内容还包括路由规则，所述路由规则用于进行影子库匹配；为便于理解，本实施例中给出了基于列的影子路由算法的内容示例，如算法1所示。
[0050][0051]
路由器对sql语句路由时，针对基于列的影子路由算法，路由器首先判断解析语法树ast 中涉及的表集合t
ast
与配置中的影子表集合t
config
是否有交集，如果没有交集，即即直接将此sql语句路由到生产库中(代码第10行)，否则，遍历t
ast
∩t
config
中的每一张表t(代码第3～9行)，若sql语句中t的影子字段值符合任一路由规则(例如满足定义的正则匹配或者值匹配，以及操作的类型匹配)，那么将此sql语句路由到影子库中，并提前结束迭代过程，加速验证效率(代码第6行)。
[0052]
基于hint的影子路由算法稍有不同，因为基于hint的影子路由算法与数据表不绑定。为便于理解，本实施例中给出了基于hint的影子路由算法的内容示例，如算法2所示。
[0053][0054][0055]
当影子算法为基于hint的影子路由算法时，所述配置文件的内容还包括hint影子标记 f
config
；路由器对sql语句路由时，针对基于hint的影子路由算法，路由器逐一验证f
ast
中每一个键值对标记是否与f
config
相同，若相同则路由到影子库中；若所有标记都与f
config
不相同，则路由到生产库中；其中，f
ast
为抽象语法树ast的所有键值对标记集合。
[0056]
解析器还用于当影子算法为基于hint的影子算法时，对配置文件中的hint影子标记f
config
进行解析，并生成一个单独的注解节点挂载到抽象语法树上。
[0057]
执行器用于获取路由器的路由结果，并通过数据库连接技术jdbc调用对应的数据库的接口，将sql语句发送至对应的数据库中，供对应的数据库执行，所述对应的数据库为生产库或影子库；执行器还用于将执行的结果进行封装，并以标准jdbc数据库协议的方式返回给请求方。至此，整个shadowdb的执行流程结束。
[0058]
本发明还提供一种基于sql引擎的全链路压测数据分流方法，使用上述基于sql引擎的全链路压测数据分流系统，包括以下步骤：
[0059]
s1、根据需求设置配置文件并存储在磁盘中；所述配置文件的内容包括生产库的属性、影子库的属性、影子表的属性及使用的影子算法；其中，所述影子算法为基于列的影子路由算法或基于hint的影子路由算法。
[0060]
s2、通过解析器将接入流量的sql语句进行解析，将sql语句转化为抽象语法树；
[0061]
s3、通过配置管理器解析配置文件得到配置信息，并将配置信息在内存中缓存起来供路由器使用；
[0062]
s4、根据配置信息和解析后的抽象语法树，通过路由器将sql语句路由到底层对应的数据库中。
[0063]
具体实施时，通过路由器将sql语句路由到底层对应的数据库中时，若配置信息中的影子算法为基于列的影子路由算法，则路由器首先判断解析语法树ast中涉及的表集合t
ast
与配置文件中的影子表的集合t
config
是否有交集，如果没有交集，则直接将此 sql语句路由到生产库中，否则，遍历t
ast
∩t
config
中的每一张表t，若sql语句中t的影子字段值符合任一路由规则，则将此sql语句路由到影子库中，并提前结束迭代过程。
[0064]
通过路由器将sql语句路由到底层对应的数据库中时，若配置信息中的影子算法为基于 hint的影子路由算法，则路由器逐一验证f
ast
中每一个键值对标记是否与f
config
相同，若相同则路由到影子库中；若所有标记都与f
config
不相同，则路由到生产库中；其中，f
ast
为抽象语法树ast的所有键值对标记集合；f
config
为配置文件中的hint影子标记。
[0065]
s5、通过执行器接收路由器的路由结果，并通过数据库连接技术jdbc调用对应数据库的接口，将sql语句发送至生产库或者影子库中，供底层数据库执行；
[0066]
s6、底层数据库执行结束后，通过执行器对执行结果进行封装，并以标准jdbc数据库协议的方式返回给请求方。
[0067]
与现有技术相比，本技术首次基于sql引擎技术设计并实现了一套完整的针对全链路压测的开源数据分流系统，其基本思想是通过对sql语句进行解析，辨别出是压测请求还是生产请求，然后将此sql语句正确路由至对应的数据库中，供底层数据库中执行，整个过程上层应用代码无需做任何改动。并且，本技术不仅按标记进行数据分流，还首次提出了按照值进行数据分流。不同的数据分流算法满足多种不同的应用场景需求。除此，本技术设计并实现了一个完整的基于sql引擎的全链路压测数据分流系统，该系统采用插件式开发，能够动态支持多种不同的关系型数据库系统。本技术系统实现了所有jdbc(java databaseconnectivity)的接口，使用原生jdbc的应用程序只需要修改初始化数据源的少量代码，即可使用本技术。若使用hibernate、mybatis等框架，则只需要修改配置文件即可，无需修改任何代码。另外，本技术中的系统嵌入在用户程序中，无需对请求进行网络转发，因此对效率影响非常小，可保证全链路压测结果的正确性。
[0068]
除了能够用于全链路压测外，本技术还可以用于a/b测试、系统预热、灰度发布等数据分流等场景中。下面就应用预热及恢复发布进行具体说明。
[0069]
应用预热
[0070]
应用预热指的是从启动程序到程序进入最佳运行状态之间的过程。应用程序启动时，需要一段时间加载动态库或者系统缓存，这段时间系统的性能往往不是最佳的。如何尽可能缩短应用预热的时间是程序开发者需要面临的一个问题。
[0071]
shadowdb可以通过模拟压测流量的方式缩短应用预热的时间。具体的方法是用户可以利用shadowdb配置影子库，将预热流量和真实流量隔离开。然后启动应用程序，向应用程序发送预热流量，在应用程序接受预热流量的过程中，程序本身可以被快速激活，而且预热流量和真实流量也可以通过shadowdb隔离开，简便而安全地完成应用预热的过程。
[0072]
灰度发布
[0073]
灰度发布是一种平滑过渡的软件发布方式。例如在a/b测试中，会让一部分用户继续使用a版本应用，另一部分用户开始使用b版本。如果用户能够接受b版本，再逐步将使用a 版本的用户切换到b版本上，周而复始，直到所有的a版本用户都切换到b版本上。
[0074]
但是灰度发布面临一个很大的挑战：如果不同版本之间的底层数据表不同，就需要对新老版本的数据进行隔离。shadowdb可以很好地解决这个问题。在具体操作时，用户可以使用shadowdb中影子库和影子表的功能，将不同版本应用对应的数据进行隔离，在用户的逐步切换中，逐渐对底层的数据同步进行切换，完成对老版本数据的更新。
[0075]
为了验证本技术的优异性能，申请人采用了两个通用的测试基准，比较了本系统和takin 的性能。为便于理解，本实施例中，先先描述数据集、对比方法和实验设置，然后展示并分析实验结果。
[0076]
数据集
[0077]
本实施例中，使用两个广泛使用的基准测试工具来评估shadowdb的性能：
[0078]
(1)tpcc(版本v5.0)，一个著名的otlp(online transaction processing)基准测试工具，模拟了商店经常使用的几种交易类型，包括新订单(new order,no)、支付(payment,pm)、查询订单状态(order status,os)、查询库存状态(stock level,sl)以及发货(delivery,de)。tpcc 由10张表构成一个仓库，每个仓库大约包含60万条记录；
[0079]
(2)sysbench，一个开源的、模块化的、跨平台的多线程性能测试工具，它提供了一张测试表，表的记录数量可以由用户自行调整。由于原生的sysbench发压机采用c语言实现，无法直接用于java应用程序，因此，申请人实现了一个java版本的发压机(代码已开源)。
[0080]
对比方法
[0081]
以每秒事务数tps(transactions per second)、平均响应时间art(average response time)、 90百分位响应时间90t共3个衡量标准比较shadowdb与另外两个系统的性能：
[0082]
(1)原生mysql(版本v5.7.26)，即相当于单独部署一份测试环境，测试流量直接打入测试数据库，没有路由的时间；
[0083]
(2)takin(版本v1.0.1)，目前能够找到的仅有的全链路压测开源产品，它可以较大程度帮助企业降低生产全链路压测平台的开发复杂度，在无业务代码侵入的情况下(探针方式接入)，获得链路治理、数据隔离、性能瓶颈定位等生产压测核心能力。它同样利用了影子库技术来实现数据隔离。在申请人的测试中，shadowdb和takin的底层数据库系统采用的是 mysql。
[0084]
实验设置
[0085]
为了消除应用程序本身的性能影响，仅测试sql请求的性能。本次实验，使用了华为云上的三台虚拟机，每台虚拟机配备了centos 7.1 64位操作系统，32vcpu,64gb内存和1tb 的机械磁盘。对于shadowdb系统，一台虚拟机运行发压机(即提交sql请求的应用程序)，另外两台分别运行生产库和影子库；对于mysql和takin，申请人选取其中一台运行mysql 系统或takin系统，另外一台作为发压机。默认情况下，申请人使用sysbench作为测试数据，其相关的参数设置如表1所示：
[0086]
表1-sysbench参数设置
[0087][0088]
与对比方法性能比较
[0089]
使用sysbench数据集性能比较
[0090]
图3展示了不同方法在sysbench数据集的不同场景下的性能比较；其中，图3(a)为
mysql、 takin以及本发明shadowdb系统使用sysbench作为测试数据的每秒事务数(tps)比较图，图3(b)为mysql、takin以及本发明shadowdb系统使用sysbench作为测试数据的平均响应时间(art)比较图，图3(c)分别为mysql、takin以及本发明shadowdb系统使用sysbench 作为测试数据的90百分位响应时间(90t)比较图。从图3中可以看出：(1)对于所有的场景，shadowdb相对于mysql系统，其tps有少量的降低，art和90t有少量的提升，这是因为shadowdb需要花费少量的时间对sql语句进行解析和路由；(2)takin系统的性能远远不如mysql和shadowdb。
[0091]
这可能有两个原因：第一，takin采用网络转发的框架，其上层使用spring boot[18]接收 sql请求，然后将sql请求网络转发给数据库，需要花费较多的时间；第二，takin底层的生产库和影子库是同一个库，只是通过影子表的形式进行数据隔离。当生产请求和测试请求打入同一台机器的同一个数据库时，可能会造成资源冲突，因为同一个数据库的总可用连接数、内存资源、计算资源是有限的；(3)不同场景的性能是不同的，通常涉及写操作(例如 wo、rw、ui等)的性能要比只有读操作(例如ps和ro)的性能要低。由于读写场景(rw)是应用程序中最常见的场景，所以后续sysbench实验中，申请人使用它作为默认场景。
[0092]
8.4.2使用tpcc数据集性能比较
[0093]
图4显示的是mysql和shadowdb两个系统在tpcc数据集中不同场景的90t比较。注意，takin未做比较是因为需要修改大量的takin代码以兼容tpcc(从图3可得知takin 相对于shadowdb性能相差很大)。申请人未展示art的原因是申请人使用的tpcc版本不支持平均响应时间的统计。另外，tpcc针对每种场景的请求比例不同且是固定的，无法计算每种场景的tps，因此申请人只给出总tps。在申请人的实验设置下，mysql和shadowdb 的总tps分别为4982.55和4924.87，图4也表明，在不同的tpcc场景下，mysql和 shadowdb的90t相差微乎其微，这进一步证明了使用shadowdb进行全链路压测，能够保证压测结果的可靠性。
[0094]
不同参数性能比较
[0095]
1不同的查询并发度
[0096]
图5给出了不同系统在sysbench数据集下性能随请求并发度变化的情况对比；其中，图 5(a)为takin和本发明shadowdb系统使用sysbench作为测试数据的每秒事务数(tps)随着请求并发度变化的比较图，图5(b)为takin和本发明shadowdb系统使用sysbench作为测试数据的平均响应时间(art)随着请求并发度变化的比较图，图5(c)分别为takin和本发明 shadowdb系统使用sysbench作为测试数据的90百分位响应时间(90t)随着请求并发度变化的比较图；图5中，由于mysql和shadowdb的数据线几乎完全重合，因此mysql的结果并未在图中画出。由图5可观察到：(1)随着访问并发度的增加，shadowdb的tps先增加，然后趋于平稳，而takin的tps先增加，然后逐渐降低；(2)随着并发度的提高，shadowdb 和takin的art和90t都呈上升趋势，但是takin的上升幅度更大；(3)对于所有的并发度，shadowdb的性能都远远优于takin。对于shadowdb而言，由于sql路由几乎不受网络影响，其瓶颈在于底层的数据库系统，当并发度增加时，尽管会出现资源抢占情况，但 shadowdb对每个请求仍能够在较短的时间内返回(25毫秒以内)。对于takin而言，其瓶颈在于网络，当并发度增大时，每条请求的响应时间达到了2.5秒以上，导致其tps慢慢降低。
[0097]
2不同的数据量
[0098]
图6比较了不同方法的性能在sysbench数据集下随数据量变化的情况对比，其中，
图6(a) 为mysql、takin以及本发明shadowdb系统使用sysbench作为测试数据的每秒事务数(tps) 随数据量变化的比较图，图6(b)为mysql、takin以及本发明shadowdb系统使用sysbench 作为测试数据的平均响应时间(art)随数据量变化的比较图，图6(c)分别为mysql、takin 以及本发明shadowdb系统使用sysbench作为测试数据的90百分位响应时间(90t)随数据量变化的比较图。由图6可知，随着数据量的增加，mysql和shadowdb的性能先保持不变，但当数据量大于1400万时，其性能缓慢降低，因为数据库系统通常以树状的形式构建索引，当数据表中的数据量越大，索引的层级越高，即使对于同一个请求，需要访问磁盘的次数也增加，导致响应时间增加和tps降低。有趣的是，对于takin系统而言，其性能似乎跟底层数据量的大小无关，原因可能是其瓶颈并不在底层的数据库中，而是在网络转发上，底层数据库的减慢相对于耗时的网络转发来说是可以忽略不计的。同样可以看到，shadowdb 和mysql在不同的数据量情况下性能不相上下，而takin的性能则差很多。
[0099]
不同的影子算法
[0100]
为了验证本技术的优异性能，申请人还比较了shadowdb不同影子算法的性能，其结果如表2所示。由表可知，基于hint的影子算法的性能要稍微弱于基于列的影子算法性能。原因主要有两个方面。首先，在sql解析阶段，基于hint的影子算法要求开启sql解析注释，解析注释需要更多的时间；其次，在sql路由阶段，基于列的影子算法通过检查sql语句所涉及的表是否为影子表，这能够避免进一步的无效检查，而基于hint的影子算法在路由时仍需要去解析注释中的键值对，然后逐一判断是否为影子标签，需要消耗更多的时间。
[0101]
表2 sysbench数据集不同影子算法性能比较
[0102][0103]
sql引擎是数据库系统的核心部分之一，不管是传统的关系型数据库系统，还是新型数据库系统，抑或是专有数据库系统，都实现了sql引擎，帮助研发人员更方便地管理数据。 sql引擎通常包括sql解析、sql校验、sql优化、sql执行四个步骤。
[0104]
在全链路压测平台中，利用sql引擎进行数据路由并不多见，通常，现有的全链路压测平台通过显示地在请求链接或者请求头中添加测试标记，从而达到数据分流的目的。然而，这种方法无法支持本文提出的基于列的影子算法。本文利用sql引擎的sql解析技术，设计并实现了面向全链路压测的sql路由器，从而能够达到高效数据分流的目的，还能够灵活支持多种影子算法。实验证明，本技术在平均响应时间、分位响应时间、每秒处理的事务数三个标准下都优于takin系统。具体地，实验结果表明，本系统相对于原生的mysql直连查询tps损耗在1％～6％之间，平均响应时间和90百分位响应时间几乎没有影响。相对于开源全链路压测产品takin，本系统平均有2个数量级的性能提升。
[0105]
最后需要说明的是，以上实施例仅用以说明本发明的技术方案而非限制技术方案，本领域的普通技术人员应当理解，那些对本发明的技术方案进行修改或者等同替换，而不脱离本技术方案的宗旨和范围，均应涵盖在本发明的权利要求范围当中。