WO2020215799A1 - 基于日志分析的MongoDB数据迁移监控方法及装置 - Google Patents
基于日志分析的MongoDB数据迁移监控方法及装置 Download PDFInfo
- Publication number
- WO2020215799A1 WO2020215799A1 PCT/CN2019/130542 CN2019130542W WO2020215799A1 WO 2020215799 A1 WO2020215799 A1 WO 2020215799A1 CN 2019130542 W CN2019130542 W CN 2019130542W WO 2020215799 A1 WO2020215799 A1 WO 2020215799A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- migration
- mongodb
- server
- information
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/1734—Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/214—Database migration support
Definitions
- the present invention relates to the technical field of electronic information, in particular to a MongoDB data migration monitoring method and device based on log analysis.
- MongoDB supports two storage methods: shard storage and Replica Set storage of data in the cluster.
- the main purpose of replica set storage is to use the master-slave mode for automatic failure recovery, while shard storage is to divide the key-value interval into different server storage without overlapping, and improve read and write throughput.
- Mongodb will start the data migration module to perform data block migration to ensure that the amount of data stored on each server is approximately the same.
- the fragmentation and migration process may bring a lot of redundant overhead.
- the embodiment of the present invention provides a MongoDB data migration monitoring method and device based on log analysis, so as to at least solve the technical problem of redundancy overhead in the existing MongoDB data fragmentation and migration process.
- a MongoDB data migration monitoring method based on log analysis includes the following steps:
- the MongoDB sharded cluster contains three components: Shard, Mongos, and Config server;
- the data migration route is divided into different stages, and the key value interval of the data blocks in each stage is drawn in proportional order.
- the MongoDB data migration monitoring method also includes:
- the cumulative sum of the data volume of the secondary data migration in the MongoDB sharded cluster data is transfer size, and the calculation formula is:
- Mongos can obtain the changelog collection data on the Config server, and the transfer size can be obtained by traversing the changelog collection data.
- the changelog collection data is stored in the form of a dictionary; clonedBytes represents the accumulated bytes of the data volume.
- This log record is obtained from the data block migration server, including data block key information, migration server, migration server, subordinate collection name, and copy data volume information;
- This log record is obtained from the data block migration receiving server, and contains data block key information, move-out server, move-in server, subordinate collection name, and success information.
- This log record is obtained from the data block migration receiving server, and contains data block key information, move-out server, move-in server, subordinate set name, and success information;
- shardCollection.start This log record is executed and created by mongos, and specifies the shard server where the initial data block MinKey and MaxKey are located;
- the log record is obtained from the shard server that performs the split, and includes the data block information before the fragmentation, the data block information after the fragmentation, the collection name, and the shard server information where the data block is located.
- the key value range of the initial data block and the shard server information are obtained from shardCollection.start. After that, all data blocks are split from existing data blocks, obtained from multi-split, and data block migration information is obtained from moveChunks. Get from from.
- a MongoDB data migration monitoring device based on log analysis including:
- the cluster building unit is used to build a MongoDB sharded cluster.
- the MongoDB sharded cluster includes three components: Shard, Mongos and Config server;
- the threshold unit is used to accumulate the data volume of the secondary data migration in the MongoDB sharded cluster data and stay within the preset threshold range;
- the information acquisition unit is used to acquire the dynamic split and migration information of historical data blocks in the MongoDB sharded cluster
- the key value interval dividing unit is used to divide the data migration route into different stages based on the successful migration of historical data blocks, and draw the data block key value interval of each stage in a proportional order.
- a storage medium storing a program file that can implement any of the above-mentioned log analysis-based MongoDB data migration monitoring methods.
- a processor which is used to run a program, where any one of the above-mentioned MongoDB data migration monitoring methods based on log analysis is executed when the program is running.
- the MongoDB data migration monitoring method and device based on log analysis in the embodiment of the present invention utilize the log data in the MongoDB configuration server, observe the current distribution and past distribution migration of data blocks between different servers, and define write amplification estimates
- Figure 1 is a flow chart of the MongoDB data migration monitoring method based on log analysis of the present invention
- Figure 2 is a preferred flow chart of the MongoDB data migration monitoring method based on log analysis of the present invention
- FIG. 3 is a schematic diagram of the data block splitting and migration process in the MongoDB data migration monitoring method based on log analysis of the present invention
- Figure 4 is a block diagram of the MongoDB data migration monitoring device based on log analysis of the present invention
- Figure 5 is a preferred module diagram of the MongoDB data migration monitoring device based on log analysis of the present invention.
- the present invention proposes a scheme for accurately extracting data block migration information from log files, which can be used to measure whether the data migration strategy, split mechanism, and key value design are reasonable.
- the MongoDB sharded cluster consists of three components: Shard, Mongos and Configserver:
- Mongos is responsible for providing cluster access interfaces, ensuring cluster consistency, and correctly routing user requests to the corresponding Shard. At the same time, Mongos provides the user command line tool mongos shell, through which we can obtain a small amount of statistical information about the database and data collection. Part of the data in the database comes from shell commands.
- the Shard is responsible for storing data, and the data is stored and migrated in the Shard cluster in the form of chunks.
- Config server saves all metadata of the Shard cluster, and Mongos connects to Config server to obtain metadata information.
- the metadata information includes the log set changelog and chunks set.
- the changelog set stores database changes, and the chunks set stores all current data block information.
- MongoDB's built-in monitoring tool mongostat can display the time taken to perform operations and cache hits; the web monitoring tool MMS (MongoDB Monitoring Service) provided on the MongoDB official website can detect hardware event.
- MMS MongoDB Monitoring Service
- Most of the existing technologies aimed at improving the performance of nosql databases such as MongoDB take insertion, query time cost, and storage cost as indicators, and there is no further data migration analysis.
- the technical scheme of the present invention can measure whether the current database migration and configuration are reasonable, and can visually observe the historical key value interval distribution, data block splitting, and data block migration between different servers in the fragmented cluster.
- a MongoDB data migration monitoring method based on log analysis includes the following steps:
- the MongoDB sharded cluster includes three components: Shard, Mongos, and Config server;
- S102 The accumulated sum of the data amount of the secondary data migration in the MongoDB sharded cluster data is within a preset threshold range, that is, the smaller the accumulated sum of data, the better;
- the MongoDB data migration monitoring method based on log analysis of the present invention utilizes log data in the MongoDB configuration server, observes the existing distribution and past distribution migration of data blocks between different servers, and defines write amplification estimation formulas to evaluate split and migration
- the strategy is good or bad, helping the MongoDB database to better pre-divide and allocate resources. Compared with traditional observation methods, it is not interfered by other factors, and the results are more accurate by using historical diary data.
- the results are intuitive, showing the performance of the sharded database through formula indicators or visual evaluation, and can intuitively reflect whether the data migration strategy, splitting mechanism, and key value design are reasonable.
- the MongoDB data migration monitoring method method further includes:
- S105 Fill the data block with different colors for the key value interval of the data block in each stage to represent different servers, and visualize the splitting and migration process of the data block of the entire data set.
- Balanced overhead calculation method use transfersize to represent the cumulative sum of the data volume of the secondary data migration under the guidance of the balance component. While the data blocks are distributed as evenly as possible in the sharded cluster, the smaller the network transmission resource overhead of data migration, the better. Define the following formula:
- the transfer size can be obtained by traversing the changelog collection, Mongos can obtain the changelog data on the Config server, and clonedeBytes represents the accumulated bytes of the data volume.
- the data is saved in dictionary form:
- the "what" attribute represents the type of operation. There are mainly two types of operations used in the calculation of the write zoom ratio:
- “MoveChunks.commit” This log record is obtained from the data block migration server, including data block key information, migration server, migration server, subordinate collection name, copy data volume and other information.
- “MoveChunks.from” This log record is obtained from the data block migration receiving server, and contains data block key value information, moving out server, moving in server, subordinate collection name, and success or failure information.
- the transfer size is the cumulative sum of the amount of copied data confirmed by moveChunks.from in the history record.
- Visualization method of historical data block split migration Use the chunks set on the Config server to depict the distribution of the current data block cluster, and obtain the dynamic split and migration of historical data blocks from the Changelog.
- “MoveChunks.from” This log record is obtained from the data block migration receiving server, and contains data block key value information, moving out server, moving in server, subordinate collection name, and success or failure information.
- the transfer size is the cumulative sum of the amount of copied data confirmed by moveChunks.from in the history record.
- multi-split The log record is obtained from the shard server performing the split, and contains information such as the data block information before the fragmentation, the data block information after the fragmentation, the collection name, and the shard server where the data block is located.
- the data migration route is divided into different stages, and the key value interval of the data block in each stage is drawn in proportional order, and the data blocks are filled with different colors to represent different shard servers, which is visualized
- the division and migration process of the data block of the entire data collection The key value range of the initial data block and the shard server information are obtained from "shardCollection.start”. After that, all data blocks are split from existing data blocks, so they are all obtained from "multi-split", and data blocks are migrated. The information is obtained from "moveChunks.from”.
- FIG. 3 there are intervals between different data blocks.
- the length of the data block is proportional to the key value interval responsible for storage.
- Green, purple, and blue respectively represent different servers where the data block is located (shard000 is blue, shard001 is Green, shard002 is purple). Except for stage0 to stage1, which is caused by the first split of the data block, new stages after that are caused by data migration.
- a MongoDB data migration monitoring device based on log analysis including:
- the cluster building unit 201 is used to build a MongoDB sharded cluster.
- the MongoDB sharded cluster includes three components: Shard, Mongos, and Config server;
- the threshold unit 202 is configured to accumulate the data amount of the secondary data migration in the MongoDB sharded cluster data and fall within a preset threshold range;
- the information acquiring unit 203 is configured to acquire dynamic split and migration information of historical data blocks in the MongoDB sharded cluster;
- the key value interval dividing unit 204 is configured to divide the data migration route into different stages based on the successful migration of historical data blocks, and draw the data block key value interval of each stage in a proportional order.
- the MongoDB data migration monitoring device based on log analysis in the embodiment of the present invention utilizes the log data in the MongoDB configuration server, observes the current distribution and past distribution migration of data blocks between different servers, and defines write amplification estimation formula evaluation
- the split and migration strategy is good or bad, helping the MongoDB database to better pre-divide and allocate resources. Compared with traditional observation methods, it is not interfered by other factors, and the results are more accurate by using historical diary data.
- the results are intuitive, showing the performance of the sharded database through formula indicators or visual evaluation, and can intuitively reflect whether the data migration strategy, split mechanism, and key value design are reasonable.
- the device further includes:
- the color filling unit 205 is used to fill the data block with different colors for different servers in the key value interval of the data block at each stage, and visualize the splitting and migration process of the data block of the entire data set.
- a storage medium storing a program file that can implement any of the above-mentioned log analysis-based MongoDB data migration monitoring methods.
- a processor which is used to run a program, where any one of the above-mentioned MongoDB data migration monitoring methods based on log analysis is executed when the program is running.
- the disclosed technical content can be implemented in other ways.
- the system embodiment described above is only illustrative.
- the division of units may be a logical function division, and there may be other divisions in actual implementation.
- multiple units or components may be combined or integrated into Another system, or some features can be ignored, or not implemented.
- the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of units or modules, and may be in electrical or other forms.
- the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or may be distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
- the functional units in the various embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
- the above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.
- the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
- the technical solution of the present invention essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , Including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods in the various embodiments of the present invention.
- the aforementioned storage media include: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program code .
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
Claims (10)
- 一种基于日志分析的MongoDB数据迁移监控方法,其特征在于,包括以下步骤:搭建一个MongoDB分片集群,所述MongoDB分片集群包含Shard、Mongos和Config server3种组件;将所述MongoDB分片集群数据中二次数据迁移的数据量累加和处于预设阈值范围内;获取所述MongoDB分片集群中历史数据块动态分裂与迁移信息;以历史数据块发生成功迁移为界,将数据迁移路线分为不同的阶段,并将每个阶段的数据块键值区间按照比例顺序画出。
- 根据权利要求1所述的MongoDB数据迁移监控方法,其特征在于,所述MongoDB数据迁移监控方法还包括:将每个阶段的数据块键值区间用不同颜色代表不同的服务器填充数据块。
- 根据权利要求1所述的MongoDB数据迁移监控方法,其特征在于,所述MongoDB分片集群数据中二次数据迁移的数据量累加和为transfer size,其计算公式为:transfer size=∑clonedBytes;Mongos获取Config server上的changelog集合数据,transfer size通过遍历changelog集合数据获取,changelog集合数据以字典形式保存;clonedBytes代表数据量累加字节。
- 根据权利要求1所述的MongoDB数据迁移监控方法,其特征在于,所述MongoDB分片集群数据中二次数据迁移的数据量累加计算中采用两种操作类型:moveChunks.commit:该日志记录从数据块迁出服务器获取,包含有数据块键值信息、迁出服务器、迁入服务器、从属集合名称、拷贝数据量信息;moveChunks.from:该日志记录从数据块迁移接收服务器获取,包含有数据块键值信息、迁出服务器、迁入服务器、从属集合名称、是否成功信息。
- 根据权利要求1所述的MongoDB数据迁移监控方法,其特征在于,利用Config server上的chunks集合,描绘当前数据块集群中的分布情况,从所述MongoDB分片集群的Changelog集合数据中获取历史数据块动态分裂与迁移信息。
- 根据权利要求5所述的MongoDB数据迁移监控方法,其特征在于,从所述MongoDB分片集群的Changelog集合数据中获取历史数据块动态分裂与迁移信息过程中采用三种操作类型:moveChunks.from:该日志记录从数据块迁移接收服务器获取,包含有数据块键值信息、迁出服务器、迁入服务器、从属集合名称、是否成功信息;shardCollection.start:该日志记录由mongos执行创建,指定了初始数据块MinKey、MaxKey所在shard服务器;multi-split:该日志记录从执行分裂的shard服务器获取,包含分片前数据块信息、分片后数据块信息、集合名称、数据块所在shard服务器信息。
- 根据权利要求6所述的MongoDB数据迁移监控方法,其特征在于,初始数据块的键值区间和所在shard服务器信息从shardCollection.start中获取,之后所有数据块都由已存在数据块分裂而来,从multi-split中获取,数据块迁移信息从moveChunks.from中获取。
- 一种基于日志分析的MongoDB数据迁移监控装置,其特征在于,包括:集群搭建单元,用于搭建一个MongoDB分片集群,所述MongoDB分片集群包含Shard、Mongos和Config server3种组件;阈值单元,用于将所述MongoDB分片集群数据中二次数据迁移的数据量累加和处于预设阈值范围内;信息获取单元,用于获取所述MongoDB分片集群中历史数据块动态分裂与迁移信息;键值区间划分单元,用于以历史数据块发生成功迁移为界,将数据迁移路线分为不同的阶段,并将每个阶段的数据块键值区间按照比例顺序画出。
- 一种存储介质,其特征在于,所述存储介质存储有能够实现权利要求1至7中任意一项所述基于日志分析的MongoDB数据迁移监控方法的程序文件。
- 一种处理器,其特征在于,所述处理器用于运行程序,其中,所述程序运行时执行权利要求1至7中任意一项所述的基于日志分析的MongoDB数据迁移监控方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910331821.6A CN110147353B (zh) | 2019-04-24 | 2019-04-24 | 基于日志分析的MongoDB数据迁移监控方法及装置 |
CN201910331821.6 | 2019-04-24 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020215799A1 true WO2020215799A1 (zh) | 2020-10-29 |
Family
ID=67594373
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2019/130542 WO2020215799A1 (zh) | 2019-04-24 | 2019-12-31 | 基于日志分析的MongoDB数据迁移监控方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN110147353B (zh) |
WO (1) | WO2020215799A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113806046A (zh) * | 2021-09-15 | 2021-12-17 | 武汉虹信技术服务有限责任公司 | 一种基于线程池的任务调度系统 |
CN114202365A (zh) * | 2021-12-15 | 2022-03-18 | 广东电力信息科技有限公司 | 一种基于电力行业营销系统实时数据的监控方法 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110147353B (zh) * | 2019-04-24 | 2022-04-26 | 深圳先进技术研究院 | 基于日志分析的MongoDB数据迁移监控方法及装置 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100161565A1 (en) * | 2008-12-18 | 2010-06-24 | Electronics And Telecommunications Research Institute | Cluster data management system and method for data restoration using shared redo log in cluster data management system |
CN102917072A (zh) * | 2012-10-31 | 2013-02-06 | 北京奇虎科技有限公司 | 用于数据服务器集群之间进行数据迁移的设备、系统及方法 |
CN102930062A (zh) * | 2012-11-30 | 2013-02-13 | 南京富士通南大软件技术有限公司 | 一种数据库快速水平扩展的方法 |
CN106126543A (zh) * | 2016-06-15 | 2016-11-16 | 清华大学 | 一种关系型数据库到MongoDB的模型转换和数据迁移方法 |
CN109145121A (zh) * | 2018-07-16 | 2019-01-04 | 浙江大学 | 一种时变图数据的快速存储查询方法 |
CN110147353A (zh) * | 2019-04-24 | 2019-08-20 | 深圳先进技术研究院 | 基于日志分析的MongoDB数据迁移监控方法及装置 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2624146A4 (en) * | 2012-03-29 | 2013-12-18 | Huawei Tech Co Ltd | DATA BLOCK PROCESSING SYSTEM AND SYSTEM, FRONT END DISPLAY DEVICE AND BACK END PROCESSING DEVICE |
CN103259843B (zh) * | 2013-03-22 | 2018-06-05 | 嘉兴安尚云信软件有限公司 | 一个智能化PaaS云计算平台系统 |
CN106777225B (zh) * | 2016-12-26 | 2021-04-06 | 腾讯科技(深圳)有限公司 | 一种数据的迁移方法和系统 |
CN108241555B (zh) * | 2016-12-26 | 2022-03-01 | 阿里巴巴集团控股有限公司 | 一种分布式数据库的备份、恢复方法、装置和服务器 |
CN107343021A (zh) * | 2017-05-22 | 2017-11-10 | 国网安徽省电力公司信息通信分公司 | 国网云中应用的一种基于大数据的日志管理系统 |
US11269822B2 (en) * | 2017-10-09 | 2022-03-08 | Sap Se | Generation of automated data migration model |
CN108664580A (zh) * | 2018-05-04 | 2018-10-16 | 西安邮电大学 | 一种MongoDB数据库中细粒度的负载均衡方法及系统 |
CN108959525A (zh) * | 2018-06-28 | 2018-12-07 | 郑州云海信息技术有限公司 | 一种冷热数据可视化方法、系统、设备及计算机存储介质 |
CN109344153B (zh) * | 2018-08-22 | 2023-12-05 | 中国平安人寿保险股份有限公司 | 业务数据的处理方法及终端设备 |
-
2019
- 2019-04-24 CN CN201910331821.6A patent/CN110147353B/zh active Active
- 2019-12-31 WO PCT/CN2019/130542 patent/WO2020215799A1/zh active Application Filing
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100161565A1 (en) * | 2008-12-18 | 2010-06-24 | Electronics And Telecommunications Research Institute | Cluster data management system and method for data restoration using shared redo log in cluster data management system |
CN102917072A (zh) * | 2012-10-31 | 2013-02-06 | 北京奇虎科技有限公司 | 用于数据服务器集群之间进行数据迁移的设备、系统及方法 |
CN102930062A (zh) * | 2012-11-30 | 2013-02-13 | 南京富士通南大软件技术有限公司 | 一种数据库快速水平扩展的方法 |
CN106126543A (zh) * | 2016-06-15 | 2016-11-16 | 清华大学 | 一种关系型数据库到MongoDB的模型转换和数据迁移方法 |
CN109145121A (zh) * | 2018-07-16 | 2019-01-04 | 浙江大学 | 一种时变图数据的快速存储查询方法 |
CN110147353A (zh) * | 2019-04-24 | 2019-08-20 | 深圳先进技术研究院 | 基于日志分析的MongoDB数据迁移监控方法及装置 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113806046A (zh) * | 2021-09-15 | 2021-12-17 | 武汉虹信技术服务有限责任公司 | 一种基于线程池的任务调度系统 |
CN114202365A (zh) * | 2021-12-15 | 2022-03-18 | 广东电力信息科技有限公司 | 一种基于电力行业营销系统实时数据的监控方法 |
Also Published As
Publication number | Publication date |
---|---|
CN110147353A (zh) | 2019-08-20 |
CN110147353B (zh) | 2022-04-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2020215799A1 (zh) | 基于日志分析的MongoDB数据迁移监控方法及装置 | |
US11645183B1 (en) | User interface for correlation of virtual machine information and storage information | |
US10031671B2 (en) | Method, apparatus, and system for calculating identification threshold to distinguish cold data and hot data | |
US10229129B2 (en) | Method and apparatus for managing time series database | |
JP5123641B2 (ja) | 性能履歴の管理方法および性能履歴の管理システム | |
US9507807B1 (en) | Meta file system for big data | |
CN108536761A (zh) | 报表数据查询方法及服务器 | |
CN109656958B (zh) | 数据查询方法以及系统 | |
US20100153431A1 (en) | Alert triggered statistics collections | |
DE112013000650B4 (de) | Datenzwischenspeicherungsbereich | |
EP2380090B1 (en) | Data integrity in a database environment through background synchronization | |
CN103714004A (zh) | Jvm在线内存泄露分析方法及系统 | |
CN101986655A (zh) | 存储网络及该存储网络的数据读写方法 | |
CN107145432A (zh) | 一种建立模型数据库的方法以及客户端 | |
US20090313312A1 (en) | Method of Enhancing De-Duplication Impact by Preferential Selection of Master Copy to be Retained | |
CN104022913B (zh) | 用于数据集群的测试方法和装置 | |
JP6633642B2 (ja) | 分散データベースにおけるデータブロックを処理する方法およびデバイス | |
CN113448491B (zh) | 存储系统的数据迁移 | |
US20150286661A1 (en) | Database capacity estimation for database sizing | |
CN105786877B (zh) | 一种数据存储方法、系统及查询方法 | |
CN110457626A (zh) | 一种异常访问请求筛选方法及装置 | |
JPWO2019168599A5 (zh) | ||
US20130332465A1 (en) | Database management device and database management method | |
CN113934713A (zh) | 一种订单数据索引方法、系统、计算机设备以及存储介质 | |
CN110134698A (zh) | 数据管理方法及相关产品 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 19925867 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 19925867 Country of ref document: EP Kind code of ref document: A1 |
|
32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 180322) |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 19925867 Country of ref document: EP Kind code of ref document: A1 |