一种数据的管理方法和系统与流程

文档序号:35093969发布日期:2023-08-10 03:55阅读:28来源:国知局
一种数据的管理方法和系统与流程

本发明涉及数据处理,具体涉及一种数据的管理方法和系统。


背景技术:

1、随着零售行业的发展以及行业竞争愈发的激烈,设备数字化的进程是不可避免的。在全国各地广泛的铺开智能柜设备后,由设备产生的数据量也随之变的更加庞大。此时在宏观层面对各维度数据的统计,或者想要实时动态的了解数据变化和趋势,用于公司或企业化管理。在传统的存储分析和查询的方案中(即:mysql+redis),变得难以支撑,所以为了优化效率,对于数据而言,在分析的方式、存储的过程、查询的效率,这些优化点上成为了亟需解决的问题。

2、传统方案中,最核心重要的地方就是【db层】,用于数据存储和读取的地方,也是最容易产生瓶颈的点,接下来,我们来仔细看一下mysql对于数据分析、存储结构,什么情况下开始导致效率逐渐变得低下。

3、首先需要了解mysql的结构:

4、1、首先服务端向mysql发起网络请求;

5、2、请求由mysql的客户端连接器接受;

6、3、客户端连接器向mysql server端发出请求;

7、4、mysql server经过一系列的请求解析、sql拆分、优化等操作后按照对应的存储引擎规则,向存储引擎,读取或写入数据,如果是读取,即返回读取结果,如果是写入,即返回写入成功(不管是读取结果,还是通知写入成功,这都是一种返回结果);

8、5、最终服务端读取到结果,可以继续做后续操作或是流程流转。

9、我们知道,在计算机中,对于磁盘的读写操作是会消耗大量的io资源的,每一次的读取或是写入,都是一次io的消耗,而计算机资源是有限的,所以,我们可以简单的计算出mysql存储的数据量以及对应的io次数。

10、1、innodb存储引擎是以数据页为单位,每个单位16k,即16x1024=16384b(字节),最终对应的是文件系统块;

11、2、文件系统块,每个单位4k,最终对应的是磁盘扇区;

12、3、磁盘扇区,每个单位512b;

13、根据innodb存储引擎描述,所有真实有效数据,存储在叶子节点,需要计算数据量,就只需要计算叶子节点所属的父节点所包含的指针数量,计算方式如下:

14、1.假设订单表,每一行数据大小为1k,即一个数据页可以存储16条数据。

15、2.主键id为bigint类型,长度为8字节,而指针大小在innodb源码中设置为6字节,这样一共14字节。

16、3.那么一个数据页能存储的指针,16384(字节)/14(字节),约为1170(个)。

17、4.每一个指针指向一个数据页,1170(个)x 16(条)=18720(条)。

18、5.那么2阶b+树,理论上最多可以存储18720条订单数据。

19、6.3阶b+树,理论上最多可以存储1170(个)x 1170(个)x 16(条)=21902400(条)。

20、7.以上,得出结论,如果通过主键id查询,2-3阶的b+树,往往只需要1-3次io查询,即可得到想要的结果;

21、但是现实往往是不同于理论结果的,就拿订单数据而言,订单数据通过设备端产生,如果每天平均30万数据量(具体数量取决于设备数量,公司/企业运营情况等),简单计算的结果就是,1个月会产生30万x 30天即900万数据量,1年的数据量大小为900万x12个月即1亿800万,按照目前业务范围,至少需要保持2年内的数据,即2亿多(接近200g)的数据,这对于mysql的单表而言,是庞大的,难以消化的数据量,这还仅仅是众多业务表中的其中一张表,这首先对于磁盘就是一次巨大的存储挑战,对于数据读取,实际上,往往根据已知设定好的关联关系,进行多个业务表的关联查询,这就需要消耗更多的io次数,和内存资源,如果遇到更为复杂的业务需求,消耗只会更多,这对于服务器的压力是巨大的,那么对于客户端而言,效率是难以忍受的,甚至会服务超时。

22、总结一下问题重点:

23、1、数据存储量压力大;

24、2、io次数过多;

25、3、消耗的时间过长;

26、mysql虽然也有分区设计,但是需要大范围查询统计结果时,依然无法有效缓解数据量过大带来的上述总结问题。本发明方案,针对于这两个重点问题会展开具体实现。


技术实现思路

1、本发明的目的在于克服上述技术不足,提供一种数据的管理方法和系统,解决现有技术中如何提高数据的查询效率的技术问题。

2、为达到上述技术目的,本发明的技术方案提供一种数据的管理方法,包括以下步骤:

3、s 1、数据库服务器获取第-分析结果,所述第一分析结果通过设备服务器从设备端获得mysql数据进行分析得到;

4、s2、所述数据库服务器将所述第一分析结果解析成业务实体对象拆分送至mysql数据库和clickhouse数据库。

5、进一步地,在步骤s2之后还包括步骤:

6、s3、客户端通过客户服务器从所述mysql数据库和/或所述clickhouse数据库查询数据。

7、进一步地,在步骤s1中,所述my5ql数据包括新增操作、更新操作和删除操作产生的mysql数据。

8、进一步地,在步骤s2中,所述业务实体对象包括订单表中的字段,订单金额、时间、商品货号和货架id中的一种或者多种。

9、进一步地,在步骤s2中,根据已有关联关系和业务关联关系拆分送至所述mysql数据库和所述clickhouse数据库。

10、进一步地,在步骤s2中,所述mysql数据库包括订单小时表,订单天表和订单月表。

11、进一步地,在步骤s3中,所述查询数据的方式包括时间范围查询、区域范围查询和综合条件查询。

12、进一步地,在步骤s3中,所述客户端通过客户服务器还包括从redis数据库查询数据;所述redis数据库用于缓存部分查询结果。

13、此外,被发明还提出一种数据的管理系统,包括:设备端、设备服务器、mysql数据库、clickhouse数据库和数据库服务器;所述设备服务器分别与所述设备端和所述数据库服务器连接,所述数据库服务器分别与所述mysql数据库和所述clickhouse数据库连接。

14、进一步地,还包括客户端和客户服务器,所述客户服务器分别与所述mysql数据库和所述clickhouse数据库连接;所述客户端与所述客户服务器连接。

15、与现有技术相比,本发明的有益效果包括:数据库服务器获取第一分析结果,所述第一分析结果通过设备服务器从设备端获得mysql数据进行分析得到;所述数据库服务器将所述第一分析结果解析成业务实体对象拆分送往至mysql数据库和clickhouse数据库;引入clickhouse数据库可以更好的压缩数据,解决存储量过大,从而更快的查询效率,大幅提升系统性能。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1