CN118170760A - 一种用于SaaS系统的高效数据存储和检索方法 - Google Patents

一种用于SaaS系统的高效数据存储和检索方法 Download PDF

Info

Publication number
CN118170760A
CN118170760A CN202410271975.1A CN202410271975A CN118170760A CN 118170760 A CN118170760 A CN 118170760A CN 202410271975 A CN202410271975 A CN 202410271975A CN 118170760 A CN118170760 A CN 118170760A
Authority
CN
China
Prior art keywords
data
message
server
order
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202410271975.1A
Other languages
English (en)
Inventor
高延军
李源
千山焜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huashang Chuangke Technology Xi'an Co ltd
Original Assignee
Huashang Chuangke Technology Xi'an Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huashang Chuangke Technology Xi'an Co ltd filed Critical Huashang Chuangke Technology Xi'an Co ltd
Priority to CN202410271975.1A priority Critical patent/CN118170760A/zh
Publication of CN118170760A publication Critical patent/CN118170760A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2453Query optimisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24552Database cache management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2458Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2462Approximate or statistical queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Software Systems (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明涉及一种用于SAAS系统的数据存储检索方法,包括步骤S1:根据业务数据的不同类型,建立关系型数据库表结构;步骤S2:将业务数据按照路由规则写入相应的关系型数据库表中;步骤S3:设置监听;用于监听关系型数据库的日志文件;步骤S4:将关系型数据库的日志数据写入消息中间件;步骤S5:消费端消费消息中间件的日志数据,重新写入NoSQL数据库;步骤S6:解析请求的url匹配数据查询的方式。本发明通过将业务数据全量及增量的方式同步到NoSQL数据库和缓存来处理,提高SAAS系统数据检索和查询效率。

Description

一种用于SaaS系统的高效数据存储和检索方法
技术领域
本发明属于设计数据处理技术领域,具体涉及一种用于SaaS系统的高效数据存储和检索方法。
背景技术
随着SAAS系统租户高速增长,伴随着数据规模的日趋增长、业务复杂度也在提高。传统的数据存储系统在处理大量数据时可能会面临性能瓶颈,单机存储容量、连接数、处理能力都有限。业务数据采用水平拆分的方式储存在不同的物理节点上,将原来单一数据库、单一数据表的数据量变小来缓解数据库的性能问题,从而达到提升性能的目的,同时带来数据跨节点的查询、分页、排序耗费高资源的问题,而查询优化可以将资源消耗较大的对象拆分成若干资源消耗小的查询对象,但实际效果并不明显。
发明内容
为了解决上述问题,本发明目的在于提供一种用于SaaS系统的高效数据存储和检索方法,采用缓存技术和数据冗余做读写分离,进一步提高数据检索和查询效率。
为了实现上述目的,本发明采用的技术方案如下:
一种用于SAAS系统的数据存储检索方法,其特征在于:包括下述步骤:
步骤S1:根据业务数据的不同类型,建立关系型数据库表结构;
步骤S2:将业务数据按照路由规则写入相应的关系型数据库表中;
步骤S3:设置监听;用于监听关系型数据库的日志文件;
步骤S4:将关系型数据库的日志数据写入消息中间件;
步骤S5:消费端消费消息中间件的日志数据,重新写入NoSQL数据库;
步骤S6:解析请求的url匹配数据查询的方式。
进一步,所述步骤S1具体包括:
步骤S110:创建交易订单表;
步骤S112:C端用户提交订单信息到订单系统;
步骤S113:创建一个order_info的文档。
进一步,所述步骤S2中,所述路由规则为:每张表中有一个字段商户编号mch_id,把不同商户的数据分散写入到不同的表中,但同一个商户的订单信息写入到一张表,对mch_id先进行hash,会得到一个数值,然后所得的数值对表的个数进行取模,最后得到的数字前面拼接上order_info_就是要写入的表的名字;
订单系统接收到C端用户提交上来的订单数据,订单系统通过商品skuID查询商品所属的商家ID,mch_id,根据所述路由规则,把数据写入表中。
进一步,所述步骤S3具体包括:
步骤S31:在Canal客户端中进行相应的配置以指定要监控的信息;
步骤S32:canal server服务器等待来自数据库的变更事件;
步骤S33:Canal Server服务器解析数据库生成的binlog,将解析得到的变更数据封装成JSON格式的消息;
步骤S34:Canal客户端连接到Canal Server服务器将解析得到的变更数据通过网络协议发送给相应的客户端。
进一步,所述步骤S4具体包括:
步骤S41:启动MQ的服务端,在创建的应用工程中引入MQ的客户端库,添加配置文件,配置连接消息中间件服务端的参数。
步骤S42:初始化MQ的生产者实例,把消息发送到MQ的服务端;
canal监听到的数据,构建成一个消息对象,对象中包含消息要发送的目标Topic,目标tag,消息ID,及消息内容体,消息内容体就是监听到的数据内容;通过调用MQ初始化好的生产者实例发送消息的API,把消息发送到MQ的服务端。
进一步,所述步骤S5具体包括:
步骤S51:通过消费消息队列中的消息新建一个消费者的应用工程;
步骤S52:根据从消息队列拉取到的元数据的操作类型分辨选择插入或更新操作;
步骤S53:消费到数据;先拼装出数据主键;查询redis中是否包含该数据;如果redis中未查询到该数据,然后把数据主键为key存入Redis中。
步骤S54:将整行元数据进行存储。
进一步,所述步骤S6具体包括:
步骤S61:登录运营管理平台,给客户端返回一个认证标识token,token的生成方式采用JWT;
步骤S62:客户端查询信息;包括:请求的URL为/mng/order/list服务端接收到平台发送的请求,请求的header头中要携带上客户端登录成功后的token信息,开始以/mng开头就是去关系型数据库查询,服务端从header中取出token,知道token后使用JWT解析出token中的商户编号mch_id,对mch_id先进行hash,会得到一个数值,然后所得的数值对表的个数进行取模,最后得到的数字前面拼接上写入的表的名字,最终数据写入表中;
或者请求的URL为/report/order/growth,以/report此类业务开头URL,去NoSQL表中直接查询;若为全文检索,先通过NoSQL数据库检索出相关性高的数据的业务主键id,然后通过id拼接出缓存的业务key,批量从缓存中把详细数据查询出来。
本发明由于采取以上技术方案,其具有以下优点和效果:
本发明提供的一种用于SaaS系统的高效数据存储和检索方法,首先通过数据存储模块用于SAAS系统中海量数据的写入,通过业务模式对业务进行分库、分表,根据业务字段将数据路由的不同的库表中,避免大量的并发请求因单一数据源导致的写入失败,提高数据库的性能、可扩展性和并发处理能力;再通过数据检索模块用于数据写入数据库后大量C端用户的查询、统计可以根据业务路由信息到指定的库表查询,或者基于缓存的方式将核心业务字段缓存起来,通过计算得出数据库的主键ID,通过主键ID再到缓存查询全量数据信息;并且采用读写分离的方式对数据库进行查询检索、避免查询时全表扫描,对于涉及到复杂统计的功能采用数据冗余的方式,将业务数据全量及增量的方式同步到NoSQL数据库和缓存来处理,提高SAAS系统数据检索和查询效率。
附图说明
图1是本发明的方法流程图。
具体实施方式
本发明提供一种用于SAAS系统的数据存储检索方法,通过将数据存储模块用于SAAS系统中海量数据的写入,通过业务模式对业务进行分库、分表,根据业务字段将数据路由的不同的库表中,避免大量的并发请求因单一数据源导致的写入失败,提高数据库的性能、可扩展性和并发处理能力。通过数据检索模块将数据写入数据库后大量C端用户的查询、统计可以根据业务路由信息到指定的库表查询,或者基于缓存的方式将核心业务字段缓存起来,通过计算得出数据库的主键ID,通过主键ID再到缓存查询全量数据信息。
如图1所示。本发明的一种用于SAAS系统的数据存储检索方法,具体包括下述步骤:
步骤S1:根据需要同步的交易业务数据创建关系型数据库交易表的表结构。
具体包括:步骤S11:先创建交易订单表。
订单表的核心字段包括主键ID、订单编号、商家id、创建时间等。
如:id BIGINT PRIMARY KEY COMMENT'主键id',
trade_id VARCHAR(32)NOT NULL COMMETN'交易编号',
order_no VARCHAR(32)NOT NULL COMMENT'订单编号',
mch_id VARCHAR(32)NOT NULL'商家编号',
create_time DATETIME NOT NULL COMMENT'订单创建时间',
create_by VARCHAR(32)COMMENT'创建人'。
步骤S12:C端用户通过小程序提交订单信息(商品skuID、数量等)到订单系统。
订单数据的量随着业务的增长,数据库交易表的写入性能和查询性能都会随之下降。为解决单库表性能瓶颈的问题,订单数据采用了水平切分的策略,将一个大的数据库拆分成多个小的数据库或表,使得数据存储和查询操作可以分布在不同的数据库服务器上,这样的结构称之为分库分表,采用水平分表的方式拆分成多张表,每张表有独立的编号。
例如订单表使用标准的SQL语法创建8张相同结构的表,表名分别为order_info_0,order_info_1...order_info_7。
NoSQL数据库是一类非关系型数据库,采用文档型的数据库,借助其强大的数据存储和检索方面的优势,并且通常更适用于某些特定的应用场景,如有时间维度、交易额维度、区域维度、商家维度、范围查询等,用作数据的冗余的库。
步骤S13:创建一个order_info的文档。每天都创建一个新的文档,按照日期名字建文档。创建文档的目的用于将关系型数据库的数据冗余到非关系型数据库Elasticsearch中,多维度地对交易数据统计查询,这样做的好处是避免在交易高峰期运营在统进行统计查询时到关系数据库查询影响到正常的交易数据写入和查询。创建文档的方式如order_info_yyyy-MM-dd。
步骤S2:同步的业务数据按照路由规则写入相应的关系型数据库表中。
具体地说,先介绍下路由规则,例如在步骤S1中建立了8张订单表,每张表中有一个字段商户编号mch_id,把不同商户的数据分散写入到不同的表中,但同一个商户的订单信息写入到一张表,提升后续商户查询数据的效率,对mch_id先进行hash,会得到一个数值,然后所得的数值对表的个数进行取模,最后得到的数字前面拼接上order_info_就是要写入的表的名字。如hash(mch_id)%8=3,最终数据写入order_info_3这张表中。
订单系统接收到C端用户提交上来的订单数据,订单系统通过商品skuID查询商品所属的商家ID(mch_id)。根据上述的路由规则,把数据写入表中。
步骤S3:设置监听,监听关系型数据库的日志文件。监听数据库的日志文件,使用了开源的第三方组件canal,其主要原理就是捕获数据的变更日志,并将这些变更实时传递给其他系统,实现数据的实时同步。具体包括下述步骤:
步骤S31:安装好canal server服务器后,需要在Canal客户端中进行相应的配置,配置canal的instance配置文件,包括数据连接信息和Binlog配置,以指定要监控的数据库实例、连接参数、要捕获的表等信息;
步骤S32:启动canal server服务器,该服务器会连接到数据库并监听Binlog;然后创建一个新的应用工程,在工程中引入canal客户端库。canal server服务器将作为一个服务运行,并等待来自数据库的变更事件。当数据库中的数据发生变更(如插入、更新、删除操作),数据库会生成相应的binlog(二进制日志);
步骤S33:新建配置文件,配置文件中指定需要订阅的canal server服务器上监听的表名和操作事件;Canal Server服务器会解析数据库生成的binlog,将解析得到的变更数据封装成JSON格式的消息;
步骤S34:初始化canal客户端并连接到Canal Server,读取配置文件中信息的数据库实例和数据库表,canal客户端会接收到数据库的Binlog事件,解析Binlog事件,获取数据库的变更信息。Canal客户端将解析得到的变更数据通过网络协议(如TCP)发送给相应的客户端。
步骤S4:将关系型数据库的日志数据写入消息中间件。具体包括下述步骤:
步骤S41:启动MQ的服务端。消息中间件使用了开源的RocketMQ,后边简称MQ,分别启动MQ的nameserver和broker,在创建的应用工程中引入MQ的客户端库,添加配置文件,配置连接消息中间件服务端的参数,包括服务器地址、队列个数等信息,初始默认8个队列。
步骤S42:初始化MQ的生产者实例,把消息发送到MQ的服务端。
由于canal监听到的数据,构建成一个消息对象,对象中包含消息要发送的目标Topic(order_info_topic),目标tag,消息ID,及消息内容体,消息内容体就是监听到的数据内容。通过调用MQ初始化好的生产者实例发送消息的API,把消息发送到MQ的服务端,为了保证数据的一致性,必须要将同一个订单的数据发送到MQ同一个Topic中的同一个队列中,所以发送前根据订单的ID对队列个数取模,如orderId%8=6所得值可确定唯一队列,数据会发送到order_info_topic的第6个队列中。这样保证同一个业务的数据进入到同一个队列,避免写到不同队列引发乱序的问题,消息发送到消息中间件服务器后等待消息消费者的消费。
步骤S5:消费端消费消息中间件的日志数据,重新写入NoSQL数据库。
具体包括下述步骤:
步骤S51:新建一个消费者的应用工程,主要用消费消息队列中的消息。消费者应用中引入消息队列的客户端库,应用的配置文件中配置好消息服务器的地址和要订阅的topic,启动消费者应用。消费者应用从消息中间件拉取消息,拉取到的消息写入缓存中和NoSQL数据库。
消费者应用中还要引入NoSQL数据库的客户端类库和驱动,配置数据库的地址和认证信息等创建连接。
步骤S52:根据从消息队列拉取到的元数据的操作类型(新增、修改、删除)分辨选择插入或更新操作。读取到的数据需要校验幂等性,防止数据重复写入NoSQL数据库。每次消费到的消息数据中都有可以区分业务数据唯一的属性,且全局不能重复,称之为数据主键。数据主键=业务ID+操作类型。消费者读取到数据后将数据主键key存入Redis缓存中并且给该值设置一个过期时间,过期时间根据业务定义。Redis存储采用基础数结构(String)。
步骤S53:消费到数据。
具体为:第一步,先拼装出数据主键;第二,查询redis中是否包含该数据;第三,如果redis中未查询到该数据,然后把数据主键为key存入Redis中。第二和第三保证原子性,如果第二步查询到数据,则系统程序退出。
步骤S54:将整行元数据进行存储。数据内容为步骤S1中创建的表结构属性,存储整行数据可以根据不同的维度去统计分析数据,不同维度可以基于商户维度汇总统计,也可以根据时间维度汇总统计。基于NoSQL文档属性定义,若存入NoSQL文档的属性是来源于多张表的字段属性,通过去关系型数据库关联查询的方式将数据补全,方便后续业务更多维度的查询。也可以选择保存部分关键字段,用于列表查询,当大量数据进行条件、排序、分页查询的时候的占用内存比较大。仅仅对部分字段进行条件过滤后,查询出每条数据在关系型数据中的主键,带着主键去关系型数据库中查询全量数据。
步骤S6:解析请求的url匹配数据查询的方式。
具体包括下述步骤:
步骤S61:商户的运营人员登录运营管理平台,输入正确的用户名、密码,服务端校验通过后给客户端(操作运营管理平台的浏览器)返回一个认证标识token,token的生成方式采用JWT。
步骤S62:客户端查询信息。比如在平台上查看今日的销售订单数据和销售总额。请求的URL为/mng/order/list服务端接收到平台发送的请求,请求的header头中要携带上客户端登录成功后的token信息,开始以/mng开头就是去关系型数据库查询,服务端从header中取出token,知道token后使用JWT解析出token中的商户编号(mch_id),对mch_id先进行hash,会得到一个数值,然后所得的数值对表的个数进行取模,最后得到的数字前面拼接上order_info_就是要写入的表的名字。如hash(mch_id)%8=3,最终数据写入order_info_3这张表中。遇到业务复杂的查询场景。如统计类的报表查询销售订单的同步、环比等,请求的URL为/report/order/growth,以/report此类业务开头URL,去NoSQL表中直接查询。若为全文检索,先通过NoSQL数据库检索出相关性高的数据的业务主键id,所谓相关性高就存量数据跟搜索的关键词做匹配,匹配相似度比较高的数据,然后通过id拼接出缓存的业务key,批量从缓存中把详细数据查询出来。

Claims (7)

1.一种用于SAAS系统的数据存储检索方法,其特征在于:包括下述步骤:
步骤S1:根据业务数据的不同类型,建立关系型数据库表结构;
步骤S2:将业务数据按照路由规则写入相应的关系型数据库表中;
步骤S3:设置监听;用于监听关系型数据库的日志文件;
步骤S4:将关系型数据库的日志数据写入消息中间件;
步骤S5:消费端消费消息中间件的日志数据,重新写入NoSQL数据库;
步骤S6:解析请求的url匹配数据查询的方式。
2.根据权利要求1所述的一种用于SAAS系统的数据存储检索方法,其特征在于:所述步骤S1具体包括:
步骤S110:创建交易订单表;
步骤S112:C端用户提交订单信息到订单系统;
步骤S113:创建一个order_info的文档。
3.根据权利要求1或2所述的一种用于SAAS系统的数据存储检索方法,其特征在于:所述步骤S2中,所述路由规则为:每张表中有一个字段商户编号mch_id,把不同商户的数据分散写入到不同的表中,但同一个商户的订单信息写入到一张表,对mch_id先进行hash,会得到一个数值,然后所得的数值对表的个数进行取模,最后得到的数字前面拼接上order_info_就是要写入的表的名字;
订单系统接收到C端用户提交上来的订单数据,订单系统通过商品skuID查询商品所属的商家ID,mch_id,根据所述路由规则,把数据写入表中。
4.根据权利要求3所述的一种用于SAAS系统的数据存储检索方法,其特征在于:所述步骤S3具体包括:
步骤S31:在Canal客户端中进行相应的配置以指定要监控的信息;
步骤S32:canal server服务器等待来自数据库的变更事件;
步骤S33:Canal Server服务器解析数据库生成的binlog,将解析得到的变更数据封装成JSON格式的消息;
步骤S34:Canal客户端连接到Canal Server服务器将解析得到的变更数据通过网络协议发送给相应的客户端。
5.根据权利要求4所述的一种用于SAAS系统的数据存储检索方法,其特征在于:所述步骤S4具体包括:
步骤S41:启动MQ的服务端,在创建的应用工程中引入MQ的客户端库,添加配置文件,配置连接消息中间件服务端的参数。
步骤S42:初始化MQ的生产者实例,把消息发送到MQ的服务端;
canal监听到的数据,构建成一个消息对象,对象中包含消息要发送的目标Topic,目标tag,消息ID,及消息内容体,消息内容体就是监听到的数据内容;通过调用MQ初始化好的生产者实例发送消息的API,把消息发送到MQ的服务端。
6.根据权利要求5所述的一种用于SAAS系统的数据存储检索方法,其特征在于:所述步骤S5具体包括:
步骤S51:通过消费消息队列中的消息新建一个消费者的应用工程;
步骤S52:根据从消息队列拉取到的元数据的操作类型分辨选择插入或更新操作;
步骤S53:消费到数据;先拼装出数据主键;查询redis中是否包含该数据;如果redis中未查询到该数据,然后把数据主键为key存入Redis中。
步骤S54:将整行元数据进行存储。
7.根据权利要求6所述的一种用于SAAS系统的数据存储检索方法,其特征在于:所述步骤S6具体包括:
步骤S61:登录运营管理平台,给客户端返回一个认证标识token,token的生成方式采用JWT;
步骤S62:客户端查询信息;包括:请求的URL为/mng/order/list服务端接收到平台发送的请求,请求的header头中要携带上客户端登录成功后的token信息,开始以/mng开头就是去关系型数据库查询,服务端从header中取出token,知道token后使用JWT解析出token中的商户编号mch_id,对mch_id先进行hash,会得到一个数值,然后所得的数值对表的个数进行取模,最后得到的数字前面拼接上写入的表的名字,最终数据写入表中;
或者请求的URL为/report/order/growth,以/report此类业务开头URL,去NoSQL表中直接查询;若为全文检索,先通过NoSQL数据库检索出相关性高的数据的业务主键id,然后通过id拼接出缓存的业务key,批量从缓存中把详细数据查询出来。
CN202410271975.1A 2024-03-11 2024-03-11 一种用于SaaS系统的高效数据存储和检索方法 Pending CN118170760A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410271975.1A CN118170760A (zh) 2024-03-11 2024-03-11 一种用于SaaS系统的高效数据存储和检索方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410271975.1A CN118170760A (zh) 2024-03-11 2024-03-11 一种用于SaaS系统的高效数据存储和检索方法

Publications (1)

Publication Number Publication Date
CN118170760A true CN118170760A (zh) 2024-06-11

Family

ID=91354173

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410271975.1A Pending CN118170760A (zh) 2024-03-11 2024-03-11 一种用于SaaS系统的高效数据存储和检索方法

Country Status (1)

Country Link
CN (1) CN118170760A (zh)

Similar Documents

Publication Publication Date Title
CN100596353C (zh) 提供日志服务的方法及系统
US8898147B2 (en) Method and system for a transparent application of multiple queries across multiple data sources
CN104699718B (zh) 用于快速引入业务数据的方法和装置
US7690000B2 (en) Metadata journal for information technology systems
CN108647357B (zh) 数据查询的方法及装置
US7464069B2 (en) System and method for eager relationship caching of entity beans
CN113312376B (zh) 一种用于Nginx日志实时处理分析的方法及终端
CN111506559A (zh) 数据存储方法、装置、电子设备及存储介质
CN109241384B (zh) 一种科研信息的可视化方法及装置
CN108228322B (zh) 一种分布式链路跟踪、分析方法及服务器、全局调度器
CN104199978A (zh) 基于NoSQL实现元数据缓存与分析的系统及方法
CN111046041B (zh) 数据处理方法和装置、存储介质及处理器
CN112416991A (zh) 一种数据处理方法、装置以及存储介质
CN114201505A (zh) 数据查询方法及装置、数据库系统
CN114971714A (zh) 一种基于大数据标签的精准客户运营方法和计算机设备
CN114398520A (zh) 数据检索方法、系统、装置、电子设备及存储介质
CN114090530A (zh) 分布式架构下的日志汇总查询方法及装置
CN118170760A (zh) 一种用于SaaS系统的高效数据存储和检索方法
CN115391286A (zh) 一种链路追踪数据管理方法、装置、设备及存储介质
CN115905313A (zh) 一种MySQL大表关联查询系统及方法
CN108183966A (zh) 一种云储存系统
US11829343B2 (en) Generating a business object
CN117591737A (zh) 一种客户通讯信息的查询方法及相关装置
CN116823436A (zh) 一种征信数据报送方法、装置及设备
CN111814043A (zh) 版权信息的查询方法、装置及服务器

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination