CN109828994A - 一种政府能源管理平台的数据管理方法和*** - Google Patents

一种政府能源管理平台的数据管理方法和*** Download PDF

Info

Publication number
CN109828994A
CN109828994A CN201811478986.8A CN201811478986A CN109828994A CN 109828994 A CN109828994 A CN 109828994A CN 201811478986 A CN201811478986 A CN 201811478986A CN 109828994 A CN109828994 A CN 109828994A
Authority
CN
China
Prior art keywords
data
enterprise
energy consumption
database
information
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
CN201811478986.8A
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.)
SHENZHEN CITY SHUANGHE ELECTRIC CO Ltd
Original Assignee
SHENZHEN CITY SHUANGHE ELECTRIC 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 SHENZHEN CITY SHUANGHE ELECTRIC CO Ltd filed Critical SHENZHEN CITY SHUANGHE ELECTRIC CO Ltd
Priority to CN201811478986.8A priority Critical patent/CN109828994A/zh
Publication of CN109828994A publication Critical patent/CN109828994A/zh
Pending legal-status Critical Current

Links

Classifications

    • Y—GENERAL 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
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE 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/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明提供一种政府能源管理平台的数据管理方法及***，所述方法包括：采用MongoDB数据库来存储和管理企业能耗数据信息，采用Redis数据库来存储和管理企业基础数据信息。本发明的政府能源管理平台的数据管理方法运行效率高、维护成本低的优点。

Description

一种政府能源管理平台的数据管理方法和***
技术领域
本发明涉及数据库领域，具体涉及一种政府能源管理平台的数据管理方法和***。
背景技术
传统的关系型数据库，适用于数据结构统一、明确的应用环境。但如果数据结构不统一明确，使用传统关系型数据库则会使***设计复杂、维护成本高、运行效率低。对于政府级的能耗信息管理平台，接入各行各业、工艺、消耗能源类别、信息化程度都不相同的企业的能耗数据，它们的数据结构是各不相同的。比如工艺简单、信息化程度低的企业，可能只能提供一个总能耗数据；而工艺复杂、信息程度高的企业，可以提供4、5个工艺段，4、5种不同类型能源消耗量。这种情况，如果采用传统关系型数据库，要么设计一个大而全的表，这样既浪费计算机磁盘空间，也影响***效率。要么按多个关联表的方案拆分设计，这样也使设计复杂、提高***维护成本、影响***运行效率。
对于政府级的能源管理平台，假设一个企业10秒钟产生一条能耗数据，有1万家企业接入平台，则平台一天就可产生8千多万条数据。对于这样的海量数据，采用磁盘阵列这种传统技术的传统数据库，支撑起来是比较吃力的。而随着***业务的发展，对***数据库的扩容需求，传统数据库执行起来也是非常费时费力、耗费大量成本的。
发明内容
本发明的目的是提供一种政府能源管理平台的数据管理方法和***，以解决现有技术的政府能源管理平台的运行效率低、维护成本高的技术问题。
本发明为了解决其技术问题所采用的技术方案是：
本发明实施例中，提供了一种政府能源管理平台的数据管理方法，其包括：
采用MongoDB数据库来存储和管理企业能耗数据信息，采用Redis数据库来存储和管理企业基础数据信息。
本发明实施例中，所述企业基础数据信息包括区域信息、行业信息、企业信息。
本发明实施例中，在Redis数据库中，采用区域信息表来存储区域id、区域名称，采用行业信息表来存储行业id、行业名称，采用企业信息表来存储企业id、存储区域id、行业id和行业名称。
本发明实施例中，所述MongoDB数据库中，采用能耗明细表对所述企业能耗数据信息进行存储，所述企业能耗数据信息包括企业id、行业id、区域id、数据生成时间、工艺段类型、消耗能源类型、能耗数据、企业在该统计时间段全厂总能耗数据中的一种或多种。
本发明实施例中，当***要往MongoDB数据库添加一条能耗明细数据时，先从Redis数据库查到对应企业的信息，并将查询得到企业所属的行业id、区域id添加到所述能耗明细数据中，然后添加到MongoDB数据库；当***从MongoDB数据库查询统计能耗明细数据时，先将所需的能耗明细数据查询出来，再根据查询数据中包含的企业id、区域id或行业id，从Redis数据库查找对应的企业名称、区域名称、行业名称添加到对应的能耗明细数据中。
本发明实施例中，还提供了一种政府能源管理平台的数据管理***，其特征在于，包括MongoDB数据库、Redis数据库和平台***服务程序，
所述MongoDB数据库，用于存储和管理企业能耗数据信息；
所述Redis数据库，用于存储和管理企业基础数据信息；
所述平台***服务程序，用于对所述MongoDB数据库和所述Redis数据库进行数据操作。
本发明实施例中，所述企业基础数据信息包括区域信息、行业信息、企业信息。
本发明实施例中，在Redis数据库中，采用区域信息表来存储区域id、区域名称，采用行业信息表来存储行业id、行业名称，采用企业信息表来存储企业id、存储区域id、行业id和行业名称。
本发明实施例中，所述MongoDB数据库中，采用能耗明细表对所述企业能耗数据信息进行存储，所述企业能耗数据信息包括企业id、行业id、区域id、数据生成时间、工艺段类型、消耗能源类型、能耗数据、企业在该统计时间段全厂总能耗数据中的一种或多种。
本发明实施例中，当***要往MongoDB数据库添加一条能耗明细数据时，所述平台***服务程序先从Redis数据库查到对应企业的信息，并将查询得到企业所属的行业id、区域id添加到所述能耗明细数据中，然后添加到MongoDB数据库；当***从MongoDB数据库查询统计能耗明细数据时，所述平台***服务程序先将所需的能耗明细数据查询出来，再根据查询数据中包含的企业id、区域id或行业id，从Redis数据库查找对应的企业名称、区域名称、行业名称并添加到对应的能耗明细数据中。
与现有技术相比较，本发明的政府能源管理平台的数据管理方法和***，采用MongoDB数据库来存储和管理企业能耗数据信息，采用Redis数据库来存储和管理企业基础数据信息，解决了政府级的能源管理平台，企业能耗数据结构无法统一的问题；结合Redis数据库解决政府级的能源管理平台中MongoDB数据库关联查询问题；提高了政府级的能源管理平台的数据存储量和访问量，并可以实现数据库的弹性扩容。
附图说明
图1为本发明实施例的政府能源管理平台的数据管理***的结构示意图。
图2为本发明实施例的政府能源管理平台的数据管理***的数据库的架构示意图。
图3为本发明实施例的政府能源管理平台的数据管理***的能耗数据的收集过程示意图。
图4为本发明实施例的政府能源管理平台的数据管理***的能耗数据的查询过程示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明实施例中，提供了一种政府能源管理平台的数据管理方法和***，所述数据管理方法中，采用MongoDB数据库来存储和管理企业能耗数据信息，采用Redis数据库来存储和管理企业基础数据信息。
图1示出了本发明实施例提供的政府能源管理平台的数据管理***，其包括MongoDB数据库、Redis数据库和平台***服务程序。下面分别进行详细说明。
所述MongoDB数据库，用于存储和管理企业能耗数据信息。
所述MongoDB数据库中，采用能耗明细表对所述企业能耗数据信息进行存储，所述企业能耗数据信息包括企业id、行业id、区域id、数据生成时间、工艺段类型、消耗能源类型、能耗数据、企业在该统计时间段全厂总能耗数据中的一种或多种。
由于MongoDB数据库为非关系型数据库，不像关系型数据库那样要事先设计好表结构，所以可采用JSON语言的风格，能耗明细表的设计方式示例如下：
上面三条数据，“Company_id”代表企业id，分别对应企业1、2、3；“Trade_id”，所属行业id；“Area_id”，所属地区id；“Datatime”是数据生成时间；“ProcEnergys”是各主要工艺段能耗数据，是数组类型，其中的“proctype”是工艺段类型，“energytype”是消耗能源类型，“val”是能耗数据。“TotalEnergy”是企业在该统计时间段全厂总能耗。可以看到，第一条数据工艺段能耗数据有三组数据，表示这家企业有3个主要工艺流程，且3个工艺段的能耗数据都能采集。第二条数据表示这家企业只采集了一个主要工艺段的能耗。而第三条数据，则没有工艺段能耗数据。实际上，工艺段能耗数据可以有很多组数据，也可以完全没有，具体依据各企业上送的数据。这些结构不同，长短不一的数据，***到同一张表中，对MongoDB来说是没有问题的。
从上面数据实例中，可以看到本发明实施例采用部分反范式设计思想。所属行业id、所属地区id按照范式设计思想，应放在企业信息表中，通过企业id关联到企业信息表获得所属行业id、所属地区id。但这样关联查询，会降低MongoDB的效率。所以采用反范式设计，将企业所属行业id、所属地区id都放在能耗明细表中，这样按区域或按行业查询统计时，都不需要跨表关联查询。而这样的冗余设计，仅多两个整形数据，不会带来太多的容量浪费。
所述Redis数据库，用于存储和管理企业基础数据信息。所述企业基础数据信息包括区域信息、行业信息、企业信息。本发明实施例中，在Redis数据库中，采用区域信息表来存储区域id、区域名称，采用行业信息表来存储行业id、行业名称，采用企业信息表来存储企业id、存储区域id、行业id和行业名称。
查询统计数据展现给用户时，必须要带企业名称、行业名称、区域名称这些信息，但本发明实施例没有采用完全反范式的设计模式将这些信息也放到能耗明细表中。因为这些信息占用空间比较大，当表中有千万条数据时，所造成的容量浪费也是不可忽略的。因此本发明实施例将这些信息存放在另外的表中，并用Redis数据库来解决MongoDB数据库的跨表查询问题。
Redis数据库中，基础数据表设计如下：
区域信息表：
行业信息表：
Key Trade_id Trade_name
T_00001 00001 电子电路
企业信息表：
由于区域信息、行业信息、企业信息这些基础数据是不会轻易更改的，而这些信息数据量比较小，这些特性就决定了用Redis这种内存型key-value数据库来管理是比较合适的。Redis数据库是效率非常高的内存型数据库，上述表中的Key作为Redis的key值，其它数据以哈希数据格式作为对应的value存放在Redis数据库中。其中：
区域信息表的key固定以“A_”作为前缀，后面跟区域id(Area_id)的值。添加一条区域信息到Redis数据命令：HMSET“A_00001”“Area_id”00001“Area_name”"罗湖区”。从Redis取一条区域数据命令：HGETALL“A_00001”。
行业信息表的key固定以“T_”作为前缀，后面跟行业id(Trade_id)的值。添加一条行业信息到Redis数据命令：HMSET“T_00001”“Trade_id”00001“Trade_name”"电子电路”。从Redis取一条行业数据命令：HGETALL“T_00001”。
企业信息表的key固定以“C_”作为前缀，后面跟企业id(Company_id)的值。添加一条企业信息到Redis数据命令：HMSET“C_00001”“Company_id”00001“Area_id”00001“Trade_id”00001“Company_name”"深圳市XXX电子股份有限公司”。从Redis取一条企业数据命令：HGETALL“C_00001”。
所述平台***服务程序，用于对所述MongoDB数据库和所述Redis数据库进行数据操作。
本发明实施例中，当***要往MongoDB数据库添加一条能耗明细数据时，所述平台***服务程序先从Redis数据库查到对应企业的信息，并将查询得到企业所属的行业id、区域id添加到所述能耗明细数据中，然后添加到MongoDB数据库；当***从MongoDB数据库查询统计能耗明细数据时，所述平台***服务程序先将所需的能耗明细数据查询出来，再根据查询数据中包含的企业id、区域id或行业id，从Redis数据库查找对应的企业名称、区域名称、行业名称并添加到对应的能耗明细数据中。
图2示出了本发明实施例所述的政府能源管理平台的数据管理***的数据库架构。其中：
数据库请求路由器(Router)负责请求的分发，本身不需要太多空间，也不存储数据，因此可以部署在应用服务器(AppSever)上。Router重启时，先从配置服务器获取分片等相关的配置信息到内存中。应用程序要操作数据库，则需要连接Router，通过Router转发数据库的操作请求，Router根据集群负载情况，自动合理地将请求发送到合适的数据库。而操作哪个数据库，这个过程对应用程序是透明的，应用程序不需要关心。
配置服务采用一主二从(1台主配置服务器，2台从服务器)的配置模式。配置服务器保存分片配置等重要配置信息。当配置有变化时，配置服务器自动通知所有Router，让Router更新它本地的配置信息。
分片配置：一个分内的配置，也采用一主二从的配置模式。主从配置模式可以起到相互容灾备份的功能。当往主数据库写入数据时，会自动同步数据到两个从数据库上。而查询数据时，可以配置从从数据库上读取数据，实现读写分离，进一步提高***整体效率。如果主服务器故障不能提供服务，则分片自动从两个从服务器中挑选一个作为主服务器，而这个过程对Router来说是透明的。不同的分片，各负责一部分数据的存储，以便均衡整个***的负载。
Redis数据库对资源的需求量也不会太大，因此也可以部署在应用服务器上。
MongoDB数据库的部署具有很大的灵活性。如上一步所讲的MongoDB集群的设计，每一个配置服务、每一个数据库都部署独立的硬件服务器上。但实际上，在平台运行初期，业务量不是很大时，它们是可以部署在同一台硬件服务器上的，这样可以避免初期过多的硬件投资。上述各服务的IP，可以配置成同一个IP，只需要每一个不同的服务分配不同的端口，而同一台硬件服务器上，是可以同时启动多个MongoDB实例的，这样就可以实现同一台硬件服务器部署多个MongoDB数据库。
而随着平台业务量的扩大，MongoDB数据库扩容也很简单。购买新的服务器，安装MongoDB环境，给它们分配新的IP、端口，配置新的分片名，并把新配置添加到配置服务器，用网线把它们接入集群网中，便可实现数据库的扩容，整个扩容过程完全不影响线上***的运行。
图3示出了本发明实施例所述的政府能源管理平台的数据管理***中能耗数据的收集过程。能耗数据由在企业端的***收集企业自身的能耗数据，通过https协议传给平台服务程序，能耗数据包含企业id。服务程序通过企业id从Redis数据库获取其它相关基础数据，比如企业所属区域id、所属行业id等等，将这些基础数据添加到能耗数据中，并通过MongoDB路由器，根据MongoDB自身的负载均衡策略存储到其中一个MongoDB分片数据库的能耗明细表中。
图4示出了本发明实施例所述的政府能源管理平台的数据管理***中能耗数据的查询过程。***平台的高级用户(比如能源管理部门、能源研究机构等)或者企业用户通过***的web页面查询统计能耗数据。如果是企业用户只能查询统计自身的数据。查询统计请求通过平台***服务程序操作MongoDB数据库。不论按企业、按行业、按区域查询或按其它条件查询统计能耗数据，在MongoDB数据库上的查询统计均不涉及跨表操作。MongoDB数据库的查询统计结果返回给服务程序，服务程序根据统计结果中包含的企业id、行业id、区域id、能源种类等等信息，从Redis数据库查询对应的名称，并将这些名称信息添加到查询统计结果中返回给***界面。
综上所述，本发明的政府能源管理平台的数据管理方法和***，采用MongoDB数据库来存储和管理企业能耗数据信息，采用Redis数据库来存储和管理企业基础数据信息，解决了政府级的能源管理平台，企业能耗数据结构无法统一的问题；结合Redis数据库解决政府级的能源管理平台中MongoDB数据库关联查询问题；提高了政府级的能源管理平台的数据存储量和访问量，并可以实现数据库的弹性扩容。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种政府能源管理平台的数据管理方法，其特征在于，包括：
采用MongoDB数据库来存储和管理企业能耗数据信息，采用Redis数据库来存储和管理企业基础数据信息。
2.如权利要求1所述的政府能源管理平台的数据管理方法，其特征在于，所述企业基础数据信息包括区域信息、行业信息、企业信息。
3.如权利要求2所述的政府能源管理平台的数据管理方法，其特征在于，在Redis数据库中，采用区域信息表来存储区域id、区域名称，采用行业信息表来存储行业id、行业名称，采用企业信息表来存储企业id、存储区域id、行业id和行业名称。
4.如权利要求3所述的政府能源管理平台的数据管理方法，其特征在于，所述MongoDB数据库中，采用能耗明细表对所述企业能耗数据信息进行存储，所述企业能耗数据信息包括企业id、行业id、区域id、数据生成时间、工艺段类型、消耗能源类型、能耗数据以及企业在该统计时间段全厂总能耗数据中的一种或多种。
5.如权利要求4所述的政府能源管理平台的数据管理方法，其特征在于，当***要往MongoDB数据库添加一条能耗明细数据时，先从Redis数据库查到对应企业的信息，并将查询得到企业所属的行业id、区域id添加到所述能耗明细数据中，然后添加到MongoDB数据库；当***从MongoDB数据库查询统计能耗明细数据时，先将所需的能耗明细数据查询出来，再根据查询数据中包含的企业id、区域id或行业id，从Redis数据库查找对应的企业名称、区域名称、行业名称并添加到对应的能耗明细数据中。
6.一种政府能源管理平台的数据管理***，其特征在于，包括MongoDB数据库、Redis数据库和平台***服务程序，
所述MongoDB数据库，用于存储和管理企业能耗数据信息；
所述Redis数据库，用于存储和管理企业基础数据信息；
所述平台***服务程序，用于对所述MongoDB数据库和所述Redis数据库进行数据操作。
7.如权利要求6所述的政府能源管理平台的数据管理***，其特征在于，所述企业基础数据信息包括区域信息、行业信息、企业信息。
8.如权利要求7所述的政府能源管理平台的数据管理***，其特征在于，在Redis数据库中，采用区域信息表来存储区域id、区域名称，采用行业信息表来存储行业id、行业名称，采用企业信息表来存储企业id、存储区域id、行业id和行业名称。
9.如权利要求8所述的政府能源管理平台的数据管理***，其特征在于，所述MongoDB数据库中，采用能耗明细表对所述企业能耗数据信息进行存储，所述企业能耗数据信息包括企业id、行业id、区域id、数据生成时间、工艺段类型、消耗能源类型、能耗数据、企业在该统计时间段全厂总能耗数据中的一种或多种。
10.如权利要求9所述的政府能源管理平台的数据管理***，其特征在于，当***要往MongoDB数据库添加一条能耗明细数据时，所述平台***服务程序先从Redis数据库查到对应企业的信息，并将查询得到企业所属的行业id、区域id添加到所述能耗明细数据中，然后添加到MongoDB数据库；当***从MongoDB数据库查询统计能耗明细数据时，所述平台***服务程序先将所需的能耗明细数据查询出来，再根据查询数据中包含的企业id、区域id或行业id，从Redis数据库查找对应的企业名称、区域名称、行业名称并添加到对应的能耗明细数据中。
CN201811478986.8A 2018-12-05 2018-12-05 一种政府能源管理平台的数据管理方法和*** Pending CN109828994A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811478986.8A CN109828994A (zh) 2018-12-05 2018-12-05 一种政府能源管理平台的数据管理方法和***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811478986.8A CN109828994A (zh) 2018-12-05 2018-12-05 一种政府能源管理平台的数据管理方法和***

Publications (1)

Publication Number Publication Date
CN109828994A true CN109828994A (zh) 2019-05-31

Family

ID=66858669

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811478986.8A Pending CN109828994A (zh) 2018-12-05 2018-12-05 一种政府能源管理平台的数据管理方法和***

Country Status (1)

Country Link
CN (1) CN109828994A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113568939A (zh) * 2021-08-05 2021-10-29 宁畅信息产业(北京)有限公司 能耗监控方法、装置、服务器及计算机可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106294769A (zh) * 2016-08-11 2017-01-04 珠海格力电器股份有限公司 同步工程数据的方法、***和装置
CN106874424A (zh) * 2017-01-25 2017-06-20 杭州淘淘搜科技有限公司 一种基于MongoDB和Redis的网页数据采集处理方法及***

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106294769A (zh) * 2016-08-11 2017-01-04 珠海格力电器股份有限公司 同步工程数据的方法、***和装置
CN106874424A (zh) * 2017-01-25 2017-06-20 杭州淘淘搜科技有限公司 一种基于MongoDB和Redis的网页数据采集处理方法及***

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
闫佼等: "基于消息总线及内存数据库的物联网设备接入云平台", 《微型电脑应用》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113568939A (zh) * 2021-08-05 2021-10-29 宁畅信息产业(北京)有限公司 能耗监控方法、装置、服务器及计算机可读存储介质
CN113568939B (zh) * 2021-08-05 2024-05-24 宁畅信息产业(北京)有限公司 能耗监控方法、装置、服务器及计算机可读存储介质

Similar Documents

Publication Publication Date Title
US10860598B2 (en) Systems and methods for interest-driven business intelligence systems including event-oriented data
US20130110873A1 (en) Method and system for data storage and management
CN102395962B (zh) 对数据库表的哈希和列表组合划分
US20120047107A1 (en) System and method for implementing on demand cloud database
CN106993064A (zh) 一种基于Openstack云平台实现海量数据可伸缩性存储的***及其构建方法与应用
Featherston Cassandra: Principles and application
CN105389367B (zh) 基于Mongo数据库的电网图形多时态多级分布式存储方法
Ma et al. A classification of file placement and replication methods on grids
WO2014030235A1 (ja) 分散型データベースシステム
US20150347622A1 (en) Managing database
CN103455335A (zh) 一种多级分类的Web实现方法
CN113407600B (zh) 一种动态实时同步多源大表数据的增强实时计算方法
CN111723110A (zh) 分布式缓存***及关联查询和更新方法、设备与存储介质
CN114153809A (zh) 基于数据库日志并行实时增量统计的方法
Qi Digital forensics and NoSQL databases
CN107276914A (zh) 基于cmdb的自助资源分配调度的方法
CN109828994A (zh) 一种政府能源管理平台的数据管理方法和***
US10339159B2 (en) Overlay dataset
EP3061011B1 (en) Method for optimizing index, master database node and subscriber database node
CN112330110A (zh) 一种基于MongoDB的教育平台管理***及装置
Suganya et al. Efficient fragmentation and allocation in distributed databases
CN106656592A (zh) 基于角色配置的服务管理方法和装置
CN109753245A (zh) 一种多磁盘负载均衡异步读写调度方法及装置
Luo et al. Data placement algorithm for improving I/O load balance without using popularity information
Krstić et al. Testing the performance of NoSQL databases via the database benchmark tool

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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20190531