lightdb周边-聚合查询的事出有因

bit-byte

已于 2023-11-14 09:42:52 修改

阅读量111

点赞数 1

分类专栏： lightdb 文章标签： java 数据库微服务

于 2023-06-12 10:17:18 首次发布

本文链接：https://blog.csdn.net/z465759695/article/details/131163367

版权

lightdb 专栏收录该内容

39 篇文章 0 订阅

订阅专栏

文章探讨了微服务架构在信创平台中的应用，面临的查询问题如分页、聚合和排序，提出三种解决方案：聚合服务、查询库和数据库网关，并详细介绍了基于自定义数据库表函数的聚合查询方案，该方案具有灵活扩展性和类SQL查询支持，能有效解决内存管理和并发问题。

摘要由CSDN通过智能技术生成

当前技术局面

微服务（微服务前世今生）作为这个互联网时代最火的技术之一，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构。

相比于x86架构，信创（信创的起源）平台架构的处理能力比较弱，超大型服务单机在信创软硬件下难以满足业务的SLA要求，这种要求进一步推动了微服务架构的广泛采用。

微服务架构的一个非常明显的特征就是一个服务所拥有的数据只能通过这个服务的API来访问。通过这种方式来解耦，这样就会带来查询问题。以前通过join就可以满足要求，现在如果需要跨多个服务集成查询就会非常麻烦。

所以通常有三种实现方式：

1、聚合服务封装查询。简单来说，就是把不同服务的数据统一组装在一个新的服务里做聚合，对外提供统一入口API接口查询。通俗来说下，就是以前在同一个数据库里面的表之间使用join来关联，现在可能这些表不在同一个数据库上了，怎么办，可以把每一个数据库里面的数据查询出来，最后使用java等语言把最终需要的结果拼装起来。

聚合服务的数据组装是以API接口调用来实现，一般不建议直连数据库连表查询。这样做的好处是减少服务间调用次数以及查询库表压力。

使用API组合模式检索分散在多个服务中的数据会导致昂贵、低效的内存中连接。

支持的能力非常受限，比如对于groupby/order by等自定义排序、分页、统计支持有限或实现非常复杂。

2、查询库。这种方式将各个业务库的数据通过实时或离线的方式同步到专门的查询数据库或大数据平台，所有的查询服务编写的各种复杂SQL请求查询库返回结果。

主从结构一要增加数据同步组件的开发和维护，其次存在主从延迟，导致往主库写入的数据跟从库读出来的数据不一致。尤其是在高并发状态往主库写入的数据量很多的时候，延迟会很严重。

3、外部表或数据库网关。对于关系型数据库如oracle、postgresql，也提供了访问异构数据库的dblink，他们也可以用于聚合访问其它异构数据库如mysql、sqlserver中的表。它们通常仅支持有限类型的二维关系表访问，深度扩展支持各种自定义协议难度大以及增加了耦合性。

业务侧的部分痛点

结合上小节提到的微服务拆分以及可能部分大表上的分库分表拆分，业务常常会面临如下业务需求痛点。

分页问题

前端需要分页展示一组业务数据，数据分布在不同的微服务组件当中。

聚合问题

前端需要展示的数据并不是简单的业务数据直接展示，涉及到一些数据再运算，如求和、求平均等场景。

排序问题

同样一组业务数据，业务人员会通过不同的视角去观察，这会衍生出一个基本的排序需求，排序字段是多变的。

聚合查询解决方案

本方案通过实现自定义的数据库表函数完成插件式调用，实现对http/dubbo/t2/t3协议等微服务异构接口服务的结果集进行聚合，并拥有灵活的拓展性；目前接入层主要以http/t3方式为主。架构如下

从上图来看，有如下关键点：

1、当接入层聚合微服务启动后，会首先从注册中心加载各个业务域（用户域、订单域、产品域）微服务的实际地址，并订阅注册中心的变更以便实时更新可用的服务，打通提供数据的业务侧。

2、同时接入层会扫描mybatis的xml配置文件，并以API方式为用户提供查询服务（模板化请求的优点在于有效的管理聚合查询以及聚合查询的认证管理，不至于无需增长演变为即席查询），打通用户查看数据的接入侧。
如下mybatis的xml配置SQL片段所示：

3、配置的每个聚合查询都会交给引擎层去计算，可以包含单表，多表，外关联，聚合函数，子查询，排序。数据可以来自HTTP服务以及私有协议如恒生T3服务。所有的微服务和数据源都被封装为二维表以JSON返回给用户。主要的SQL特性、分析和连接都可以应用于返回的数据集进行二次处理。打通跨服务数据聚合，复杂计算，分页计算。

优势

灵活的插件扩展体系，方便后续拓展出不同的协议场景。
支持类SQL语句查询，简化开发编程难度，提供简易的定制化查询需求。
相比于传统聚合查询服务，传统查询在java层进行结果拼装和处理上所带来的功能限制，以及在大容量、高并发时的内存不足、限流能力不足等在本方案上都得到有效解决，本方案天然基于非常成熟的LightDB底座、支持各种复杂SQL关联和统计、大表查询，稳定性和支持的特性比传统聚合查询方案高数倍以上。
相比查询库，不需要维护数据同步组件和冗余数据存储，更加的轻量化。
相比大数据方案，本方案更加轻量、可靠和可扩展，同时符合信创要求。
高效的内存保护机制(work_mem)，当内存不够时，会在磁盘中进行( quicksort in memory, 到externalmerge disk method)，有效解决基于java 跨服务查询的内存溢出问题。