WO2021017646A1 - 一种业务请求消息发送方法、分布式数据库架构及计算机可读存储介质 - Google Patents

一种业务请求消息发送方法、分布式数据库架构及计算机可读存储介质 Download PDF

Info

Publication number
WO2021017646A1
WO2021017646A1 PCT/CN2020/094941 CN2020094941W WO2021017646A1 WO 2021017646 A1 WO2021017646 A1 WO 2021017646A1 CN 2020094941 W CN2020094941 W CN 2020094941W WO 2021017646 A1 WO2021017646 A1 WO 2021017646A1
Authority
WO
WIPO (PCT)
Prior art keywords
storage unit
computing nodes
service request
storage
node
Prior art date
Application number
PCT/CN2020/094941
Other languages
English (en)
French (fr)
Inventor
随建
卢勤元
张玲东
景雯雯
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to US17/628,775 priority Critical patent/US11824924B2/en
Priority to EP20847973.3A priority patent/EP4002146A4/en
Publication of WO2021017646A1 publication Critical patent/WO2021017646A1/zh

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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
    • 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • 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/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Definitions

  • the embodiments of the present invention relate to the field of distributed databases, and more specifically, to a method for sending service request messages, a distributed database architecture, and a computer-readable storage medium.
  • the method for sending service request messages, the distributed database architecture, and the computer-readable storage medium provided by the embodiments of the present invention solve one of the technical problems in the related technology at least to a certain extent, including the amount of business data and the client With the continuous increase in the number of concurrency, the back-end links generated are beyond imagination, increasing the difficulty of maintenance.
  • the embodiment of the present invention provides a method for sending a service request message, which is applied to a distributed database.
  • the sending of the service request message includes: receiving a service request message; and sending the service request message to the N-layer computing node In the corresponding storage unit, the N is an integer and is greater than or equal to 2. The closer the storage unit is, the greater the number of computing nodes.
  • the embodiment of the present invention also provides a distributed database architecture.
  • the distributed database architecture includes: N layers of computing nodes, where N is an integer and greater than or equal to 2, and the closer the storage unit is to the layer, the greater the number of computing nodes. Many; when the service request message is received, it is sent to the corresponding storage unit through the N-layer computing node.
  • An embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program, and the computer program is used to execute the foregoing method for sending a service request message.
  • FIG. 1 is a schematic diagram of the basic flow of a method for sending a service request message according to Embodiment 1 of the present invention
  • FIG. 2 is a schematic diagram of a three-layer computing node provided by Embodiment 1 of the present invention.
  • FIG. 3 is a schematic diagram of a two-layer computing node provided by Embodiment 1 of the present invention.
  • Embodiment 4 is a schematic diagram of a storage cluster provided by Embodiment 1 of the present invention.
  • FIG. 5 is a schematic diagram of a three-layer computing node sending a service request message according to Embodiment 2 of the present invention.
  • FIG. 6 is a schematic diagram of a two-layer computing node sending a service request message according to Embodiment 3 of the present invention.
  • FIG. 7 is a schematic diagram of adding a storage node according to Embodiment 4 of the present invention.
  • FIG. 8 is a schematic diagram of deleting a storage node according to Embodiment 4 of the present invention.
  • a method for sending a service request message is provided.
  • the received service request message is sent to the corresponding storage unit through N-layer computing nodes, where N is an integer and is greater than or equal to 2.
  • N is an integer and is greater than or equal to 2.
  • S101 Receive a service request message.
  • S102 Send the service request message to the corresponding storage unit via N-layer computing nodes, where N is an integer and greater than or equal to 2. The closer the storage unit is, the greater the number of computing nodes.
  • the message agent node is responsible for SQL optimization, SQL routing, load balancing of lower-level nodes, and dispatching of distributed transactions.
  • Storage cluster A collection of storage nodes in a distributed database.
  • Business databases are regularly distributed on storage nodes in the storage cluster.
  • Storage unit A sub-collection under a storage cluster.
  • the storage unit contains multiple storage nodes.
  • Storage nodes DB nodes in distributed databases, which can be relational databases such as Mysql, Oracle, and PostgreSQL.
  • the computing nodes in this embodiment are divided into at least two layers, that is, the computing nodes are divided into at least two layers, where the closer to the layer where the storage unit is located, the greater the number of computing nodes, that is, the formed computing nodes of each layer The whole is "pyramid" type.
  • the computing nodes are three-tier
  • the first-tier computing nodes can also be called top-level computing nodes
  • the second-tier computing nodes can also be called middle-tier computing nodes
  • the third layer The computing node close to the storage unit can also be called the bottom computing node.
  • the number of top computing nodes is 1
  • the number of middle computing nodes is 3
  • the number of bottom computing nodes is 6
  • the top computing node is connected to all middle computing nodes.
  • a connection is established between the computing nodes of the layer and the computing nodes of the middle layer are connected with the computing nodes of the underlying layer.
  • the first layer of computing nodes can also be called top-level computing nodes, and the second layer of computing nodes close to the storage unit can also be called bottom-level computing nodes.
  • the number of top-level computing nodes is 2
  • the number of bottom-level computing nodes is 4, and the top-level computing nodes are connected to all bottom-level computing nodes.
  • N 3 or 2.
  • the number of layers of computing nodes N can be determined according to the amount of service data and the number of concurrent clients.
  • the service request message before sending the service request message to the corresponding storage unit through the N-layer computing node, it further includes:
  • the storage cluster is divided into at least two storage units, and each storage unit contains at least one storage node.
  • Storage unit 1 contains 3 storage nodes
  • storage unit 2 contains 2 storage units
  • Node storage unit 3 contains 1 storage node.
  • the number of storage units that the storage cluster is divided into and the number of storage nodes included in each storage unit can be flexibly adjusted according to specific business data volumes.
  • the addition/deletion (capacity expansion/reduction) of each storage node does not affect each other, so that the addition/deletion (capacity expansion/reduction) of each storage node Content) is easier to implement, capacity changes are more flexible, and maintenance costs are reduced to a certain extent.
  • the computing node closest to the storage unit is called the bottom computing node, where the bottom computing node is used to manage and maintain each storage node in the storage unit connected to it, so there is no need to separately target
  • Each storage node in the management storage unit is equipped with a management and maintenance module.
  • each storage node in the storage unit connected to it can be saved, and the cost is saved because each storage unit connected to each computing node With fewer storage nodes, it is also easy to implement management and maintenance.
  • the computing nodes of each layer except the bottom-layer computing node can all implement the load balancing function.
  • the top-level computing node can be connected to any one of the next-level computing nodes. According to the busy concurrency of the business, multiple top-level computing nodes can be activated, and multiple top-level computing nodes are independent (without dependence) and equal to each other (shared). Metadata information), the top-level computing node has a load balancing function (also can integrate a third-party load balancing module).
  • the middle-level computing nodes can be divided by regions.
  • the computing nodes between regions are independent and not equal to each other (there are some differences in metadata information).
  • the intermediate computing node is connected to the computing node of the next layer, not to any computing node of the next layer.
  • the middle layer can have multiple layers, and the rules for dividing the area are the same.
  • the middle layer computing node also has a load balancing function (or Integrate third-party load balancing modules).
  • the underlying computing node only connects to a single storage unit, and the computing nodes between the storage units are independent and not equal to each other (there are some differences in metadata information).
  • Each storage unit can have multiple underlying computing nodes, which are independent and equal to each other. Since the top-level computing nodes and the middle-level computing nodes have load balancing functions, and the bottom-level computing nodes are only connected to a single storage unit, the link pressure shared by the bottom-level computing nodes is greatly reduced.
  • the computing nodes of each N layer may respectively adopt the same distribution strategy.
  • the computing nodes on the first, second, and third tiers all use distribution strategy 1, or the computing nodes on the first, second, and third tiers all use distribution strategy 2, or on the first tier.
  • the second and third layer computing nodes all adopt the distribution strategy3.
  • the computing nodes of each N layer may also adopt different distribution strategies. For example, computing nodes in the first layer adopt distribution strategy 1, computing nodes in the second layer adopt distribution strategy 2, and computing nodes in the third layer adopt distribution strategy 3.
  • the distribution strategy in this embodiment includes at least one of a hash distribution strategy, a range distribution strategy, an enumerated list distribution strategy, and a duplicate distribution strategy. It is worth noting that here are just a few common distribution strategies, which can be flexibly adjusted according to specific needs in actual applications.
  • the service request message sending method sends the service request message to the corresponding storage unit through N-layer computing nodes when receiving the service request message, where N is an integer and greater than or equal to 2, the closer to the storage The greater the number of computing nodes in the layer where the unit is located; at least to a certain extent, one of the technical problems in the related technology is solved, including the back-end link generated as the volume of business data and the number of concurrent clients continue to increase It has exceeded imagination, increasing the difficulty of maintenance.
  • the computing nodes are layered (at least two layers), and the storage cluster is divided into multiple (at least two) storage units (each storage unit contains at least A storage node), and then through “link load balancing”, the number of back-end links of each computing node is greatly reduced, and finally through “each layer of computing node uses its own distribution strategy”, the service request message is sent to
  • the corresponding storage node avoids the phenomenon of too many back-end links of the same computing node that are difficult to maintain, which greatly improves the maintainability of the back-end links of the computing node, and greatly reduces the difficulty of maintenance.
  • a process in which a distributed database architecture includes a three-tier computing node for sending a service request message is taken as an example for description, as shown in FIG. 5.
  • the computing nodes are divided into three layers.
  • the top-level computing nodes can be connected to all middle-tier computing nodes.
  • the middle-tier computing nodes are divided into two regions. It should be understood that the middle-tier computing nodes can be divided into multiple regions.
  • the middle-tier computing nodes in the region are peer-to-peer, and the bottom-tier computing nodes can only connect to a single storage unit.
  • the storage cluster is divided into K storage units, each storage unit includes M storage nodes, K is an integer greater than or equal to 2, and M is an integer greater than or equal to 1.
  • the top-level computing node 1 receives 4000 concurrent requests from the client 1.
  • the top-level computing node 1 is connected to two peer-to-peer middle-tier computing nodes in area 1, using load balancing, each with 2000 links; at the same time, the top-level computing node 1 can also be connected to the middle-tier computing nodes in other regions
  • the connection establishment of nodes, such as the mid-level computing node in area 2 is the same as the establishment connection of area 1.
  • the top-level computing node 1 is connected to two peer-to-peer middle-tier computing nodes in area 1.
  • One middle-tier computing node can establish a connection with 1600 links, and the other middle-tier computing node Layer computing nodes can be connected to 2400 links. In practical applications, they can be flexibly adjusted according to specific needs and distribution strategies.
  • the middle-tier computing node in area 1 is connected to two peer-to-peer bottom computing nodes, and the method of load balancing is also adopted, each with 1000 links; the bottom computing node can only be connected to a single storage unit.
  • the first middle-tier computing node in area 1 is connected to two peer-to-peer bottom-tier computing nodes.
  • One bottom-tier computing node can establish a connection with 600 links, and the other
  • the underlying computing node can build up to 1000 links. In actual applications, it can be flexibly adjusted according to specific needs and distribution strategies.
  • the bottom-level computing node is connected to all storage nodes in the storage unit, and the number of back-end links is 1000*M (the links from other middle-level computing nodes are not calculated).
  • the number of back-end links is 4000*M*K.
  • the number of back-end links of multi-layer computing nodes is greatly reduced, thereby reducing the cost of link "recycling-rebuilding" and solving the problem of the bottleneck of the number of computing node links.
  • the multi-layer computing node structure is more flexible.
  • the number of computing node layers can be adjusted according to the number of storage nodes.
  • the number of computing node layers ranges from [2, N], where N is an integer greater than or equal to 2.
  • a process in which a distributed database architecture includes two-tier computing nodes for sending a service request message is taken as an example for description, as shown in FIG. 6.
  • the computing nodes are divided into two layers.
  • the two top-level computing nodes are relatively independent and equal to each other, and can be connected to all bottom-level computing nodes;
  • the storage cluster is divided into K storage units, each storage unit includes M storage nodes, K is an integer greater than or equal to 2, and M is an integer greater than or equal to 1.
  • K is an integer greater than or equal to 2
  • M is an integer greater than or equal to 1.
  • the bottom-level computing node on storage unit 1 and the bottom-level computing node on storage unit K are not equal to each other, and there are some differences in metadata (the difference: the former is bound to storage unit 1 and the latter is bound to storage unit 2);
  • the bottom-level computing node is only connected to a single storage unit.
  • the number of back-end links of a single bottom-level computing node in the figure is reduced by K times (2 top-level computing
  • the nodes divide the client links equally and converge to each bottom computing node. That is, the number of front-end links of each bottom computing node is equal to the number of client links, but the storage cluster is divided into K storage units. A single storage unit is connected, so the back-end link is reduced by K times.
  • the storage node When the amount of business data decreases, the storage node needs to be deleted, which only needs to be deleted in the appropriate storage unit.
  • a "storage node 2" has been deleted from the storage unit 1 (the deleted “storage node 2" is shown in dashed lines to facilitate observation of business data changes).
  • "storage node 2" is deleted, business data migration/reorganization only needs to be in storage unit 1, and other storage units do not involve data migration/reorganization, which greatly reduces the cost of deleting storage nodes in many scenarios.
  • the implementation of the present invention provides a distributed database architecture, where the distributed database architecture includes N layers of computing nodes, where N is an integer and greater than or equal to 2. The closer the storage unit is, the more computing nodes there are.
  • N is an integer and greater than or equal to 2.
  • the computing nodes in this embodiment are divided into at least two layers, that is, the computing nodes are divided into at least two layers, where the closer the storage unit is, the greater the number of computing nodes, that is, the number of computing nodes is " "Pyramid” style.
  • the computing nodes are divided into three layers.
  • the first layer of computing nodes can also be called top-level computing nodes
  • the second layer of computing nodes can also be called middle-tier computing nodes
  • the third The number of layer computing nodes close to the storage unit can also be called the bottom layer computing node.
  • the number of top layer computing nodes is 1
  • the number of middle layer computing nodes is 3
  • the number of bottom layer computing nodes is 6,
  • the number of top computing nodes is 6.
  • the middle-tier computing node is connected, and the middle-tier computing node is connected to the underlying computing node.
  • the computing nodes are divided into two layers.
  • the first-tier computing nodes can also be called top-level computing nodes, and the second-tier computing nodes close to the storage unit can also be called bottom-level computing nodes.
  • the number of top-level computing nodes is 2
  • the number of bottom-level computing nodes is 4, and the top-level computing nodes are connected to all bottom-level computing nodes.
  • N 3 or 2.
  • the number of layers of computing nodes N can be determined according to the amount of service data and the number of concurrent clients.
  • the storage cluster includes at least two storage units, and each storage unit includes at least one storage node.
  • Storage unit 1 contains 3 storage nodes
  • storage unit 2 contains 2 storage nodes
  • the storage unit 3 contains 1 storage node.
  • the number of storage units that the storage cluster is divided into and the number of storage nodes included in each storage unit can be flexibly adjusted according to specific business data volumes.
  • the addition/deletion (capacity expansion/reduction) of each storage node does not affect each other, so that the addition/deletion (capacity expansion/reduction) of each storage node Content) is easier to implement, capacity changes are more flexible, and maintenance costs are reduced to a certain extent.
  • the computing node closest to the storage unit is called the bottom computing node, where the bottom computing node is used to manage and maintain each storage node in the storage unit connected to it, so there is no need to separately target
  • Each storage node in the management storage unit is equipped with a management and maintenance module.
  • each storage node in the storage unit connected to it can be saved, and the cost is saved because each storage unit connected to each computing node With fewer storage nodes, it is also easy to implement management and maintenance.
  • the computing nodes of each layer except the bottom-layer computing node can all implement the load balancing function.
  • the top-level computing node can be connected to any one of the next-level computing nodes. According to the busy concurrency of the business, multiple top-level computing nodes can be activated, and multiple top-level computing nodes are independent (without dependence) and equal to each other (shared). Metadata information), the top-level computing node has a load balancing function (also can integrate a third-party load balancing module).
  • the middle-level computing nodes can be divided by regions.
  • the computing nodes between regions are independent and not equal to each other (there are some differences in metadata information).
  • the intermediate computing node is connected to the computing node of the next layer, not to any computing node of the next layer.
  • the middle layer can have multiple layers, and the rules for dividing the area are the same.
  • the middle layer computing node also has a load balancing function (or Integrate third-party load balancing modules).
  • the underlying computing node only connects to a single storage unit, and the computing nodes between the storage units are independent and not equal to each other (there are some differences in metadata information).
  • Each storage unit can have multiple underlying computing nodes, which are independent and equal to each other. Since the top-level computing nodes and the middle-level computing nodes have load balancing functions, and the bottom-level computing nodes are only connected to a single storage unit, the link pressure shared by the bottom-level computing nodes is greatly reduced.
  • the computing nodes of each N layer may respectively adopt the same distribution strategy.
  • the computing nodes on the first, second, and third tiers all use distribution strategy 1, or the computing nodes on the first, second, and third tiers all use distribution strategy 2, or on the first tier.
  • the second and third layer computing nodes all adopt the distribution strategy3.
  • the computing nodes of each N layer may also adopt different distribution strategies. For example, computing nodes in the first layer adopt distribution strategy 1, computing nodes in the second layer adopt distribution strategy 2, and computing nodes in the third layer adopt distribution strategy 3.
  • the distribution strategy in this embodiment includes at least one of a hash distribution strategy, a range distribution strategy, an enumerated list distribution strategy, and a duplicate distribution strategy. It is worth noting that here are just a few common distribution strategies, which can be flexibly adjusted according to specific needs in actual applications.
  • the embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program, and the computer program is used to execute the foregoing method for sending a service request message.
  • the distributed database architecture provided by the embodiment of the present invention includes N-layer computing nodes, where N is an integer and greater than or equal to 2.
  • N is an integer and greater than or equal to 2.
  • the N-layer calculation is performed The node is sent to the corresponding storage unit; at least to a certain extent, the technical problems in the related technology are solved, including the continuous increase in the amount of business data and the number of concurrent clients, and the resulting back-end links are beyond imagination. The problem of difficulty in maintenance is great.
  • the computing nodes are layered (at least two layers), and the storage cluster is divided into multiple (at least two) storage units (each storage unit contains at least one Storage node), and then through "link load balancing", the number of back-end links of each computing node is greatly reduced, and finally through "each layer of computing node uses its own distribution strategy", the service request message is sent to the corresponding
  • the storage node avoids the phenomenon that too many back-end links of the same computing node are difficult to maintain, which greatly improves the maintainability of the back-end links of the computing node, and greatly reduces the maintenance difficulty.
  • the service request message sending method and distributed database architecture provided by the embodiment of the present invention send the service request message to the corresponding storage unit through N-layer computing nodes when receiving the service request message, where N is an integer and greater than or equal to 2.
  • N is an integer and greater than or equal to 2.
  • the functional modules/units in the system, and the device can be implemented as software (which can be implemented by program code executable by a computing device) , Firmware, hardware and their appropriate combination.
  • the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may consist of several physical components. The components are executed cooperatively.
  • Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit .
  • the computer-readable medium may include computer storage Medium (or non-transitory medium) and communication medium (or temporary medium).
  • computer storage medium includes volatile and non-volatile memory implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Sexual, removable and non-removable media.
  • communication media usually contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as carrier waves or other transmission mechanisms, and may include any information delivery media . Therefore, the present invention is not limited to any specific combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种业务请求消息发送方法、分布式数据库架构及计算机可读存储介质，其中的方法包括：接收业务请求消息(S101)，将业务请求消息经过N层计算节点发送到对应的存储单元中，其中N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多(S102)。

Description

一种业务请求消息发送方法、分布式数据库架构及计算机可读存储介质
相关申请的交叉引用
本申请基于申请号为201910690727.X、申请日为2019年07月29日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本发明实施例涉及分布式数据库领域，更具体地说，涉及一种业务请求消息发送方法、分布式数据库架构及计算机可读存储介质。
背景技术
目前，分布式数据库的计算节点只有一层，其需要与所有存储节点都能建连，明显的，当计算节点与所有存储节点都建连时，后端链路数太多。例如，分布式组网中有40个存储节点，某个计算节点接收到来自客户端的1000个并发任务(业务请求消息)，那么该计算节点就可能需要创建40*1000个后端链路，且这40*1000个链路存在利用不充分现象(业务一般都是以随机读写操作为主，同一时刻部分存储节点可能不繁忙，连接池可能就会回收链路，下一个时刻被回收的链路可能就需要重新创建)，此时即使有连接池的存在(连接池的回收与新建也很增添时延)，计算节点维护这些链路也已经比较吃力。
随着网络业务的拓展，业务数据量和客户端并发数会持续升高，很可能会发展到400个存储节点，单计算节点接收到10000个并发，那么该计算节点就可能需要创建400*10000＝400万个后端链路。可见，随着业务数据量和客户端并发数的持续升高，产生的后端链路已超出想象，加大了维护难度。
发明内容
本发明实施例提供的业务请求消息发送方法、分布式数据库架构及计算机可读存储介质，至少在一定程度上解决相关技术中的技术问题之一，包括相关技术中随着业务数据量和客户端并发数的持续升高，产生的后端链路已超出想象，加大了维护难度的问题。
有鉴于此，本发明实施例提供了一种业务请求消息发送方法，应用于分布式数据库，所述业务请求消息发送包括：接收业务请求消息；将所述业务请求消息经过N层计算节点发送到对应的存储单元中，所述N为整数且大于等于2，越接近所述存储单元所在层的计算节点的个数越多。
本发明实施例还提供了一种分布式数据库架构，所述分布式数据库架构包括：N层计算节点，所述N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多；当接收到业务请求消息时经过N层计算节点发送到对应的存储单元中。
本发明实施例还提供了一种计算机可读存储介质，其存储有计算机程序，所述计算机程序用于执行上述的业务请求消息发送方法。
本发明其他特征和相应的有益效果在说明书的后面部分进行阐述说明，且应当理解，至少部分有益效果从本发明说明书中的记载变的显而易见。
附图说明
下面将结合附图及实施例对本发明作进一步说明，附图中：
图1为本发明实施例一提供的一种业务请求消息发送方法的基本流程示意图；
图2为本发明实施例一提供的一种三层计算节点的示意图；
图3为本发明实施例一提供的一种两层计算节点的示意图；
图4为本发明实施例一提供的一种存储集群的示意图；
图5为本发明实施例二提供的一种三层计算节点进行业务请求消息发送的示意图；
图6为本发明实施例三提供的一种两层计算节点进行业务请求消息发送的示意图；
图7为本发明实施例四提供的一种添加存储节点的示意图；
图8为本发明实施例四提供的一种删除存储节点的示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
实施例一
为了至少在一定程度上解决相关技术中的技术问题之一，包括随着业务数据量和客户端并发数的持续升高，产生的后端链路已超出想象，加大了维护难度的问题，在本发明实施例中提供了一种业务请求消息发送方法，通过接收业务请求消息，进而将接收到的业务请求消息经过N层计算节点发送到对应的存储单元中，其中N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多；请参见图1所示，如图1为本实施例提供的业务请求消息发送方法的基本流程示意图。
S101：接收业务请求消息。
S102：将业务请求消息经过N层计算节点发送到对应的存储单元中，N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多。
首先对本实施例中的各术语进行说明：
计算节点：消息代理节点，负责SQL优化、SQL路由、下级节点的负载均衡、分布式事务的调度等。
存储集群：分布式数据库中存储节点的合集，业务数据库有规则的分布在存储集群中的存储节点上。
存储单元：存储集群下的子集合，存储单元中包含多个存储节点。
存储节点：分布式数据库中的DB节点，可以是Mysql、Oracle、PostgreSQL等关系型数据库。
应当理解的是，本实施例中的计算节点分为至少两层，即划分计算节点为至少两层，其中越接近存储单元所在层的计算节点的个数越多，即形成的各层计算节点整体为“金字塔”式。
在一些示例中，请参见图2所示，计算节点为三层，第一层计算节点又可称之为顶层计算节点，第二层计算节点又可称之为中间层计算节点，第三层计算节点接近存储单元又可称之为底层计算节点，其中，顶层计算节点的个数为1，中间层计算节点的个数为3，底层计算节点的个数为6，顶层计算节点与所有中间层计算节点建连，中间层计算节点与所属底层计算节点建连。
在一些示例中，请参见图3所示，计算节点为两层，第一层计算节点又可称之为顶层计算节点，第二层计算节点接近存储单元又可称之为底层计算节点，其中，顶层计算节点的个数为2，底层计算节点的个数为4，顶层计算节点与所有底层计算节点建连。
值得注意的是，本发明并不局限于N为3或2，在实际应用中，可根据业务数据量和客户端并发数确定计算节点的层数N。
在本实施例一些示例中，将业务请求消息经过N层计算节点发送到对应的存储单元中之前，还包括：
将存储集群划分为至少两个存储单元，各个存储单元中包含至少一个存储节点。
例如请参见图4所示，设将存储集群划分为3个存储单元，分别为存储单元1、存储单元2以及存储单元3，其中存储单元1包含3个存储节点，存储单元2包含2个存储节点，存储单元3包含1个存储节点。
值得注意的是，在实际应用中，将存储集群划分为的存储单元的个数以及各个存储单元中包含的存储节点的个数可根据具体业务数据量做灵活调整。
应当理解的是，当将存储集群划分为至少两个存储单元后，各个存储节点的增/删(扩容/缩容)之间互不影响，从而使得各个存储节点的增/删(扩容/缩容)更易实施，容量变 动更为灵活且在一定程度上减低了维护成本。
在本实施例的一些示例中，与存储单元最接近的计算节点称之为底层计算节点，其中底层计算节点用于管理和维护与之相连的存储单元中的各存储节点，因此无需再单独针对管理存储单元中的各存储节点设置管理和维护模块，通过底层计算节点便可实现对与之相连的存储单元中的各存储节点，节约成本，且由于与各个计算节点相连的存储单元中的各存储节点较少，也便于实施管理和维护。
在本实施例的一些示例中，除底层计算节点之外的其他各层的计算节点均能实现负载均衡功能。
其中，顶层计算节点可以与下一层任意一个计算节点建连，根据业务并发繁忙情况，可以启用多个顶层计算节点，多个顶层计算节点之间相互独立(无依赖)、相互对等(共享元数据信息)，顶层计算节点拥有负载均衡功能(也可以集成第三方负载均衡模块)。
其中，中间层计算节点可按区域划分，区域之间的计算节点相互独立、相互不对等(元数据信息存在部分差异)，每个区域内的计算节点可以有多个，区域内的计算节点相互独立、相互对等。中间计算节点与下一层所属的计算节点建连，并非跟下一层任意的计算节点建连，中间层可以有多层，划分区域规则相同，中间层计算节点也拥有负载均衡功能(也可以集成第三方负载均衡模块)。
应当理解的是，底层计算节点只对接单个存储单元，存储单元之间的计算节点相互独立、相互不对等(元数据信息存在部分差异)。每个存储单元上可以有多个底层计算节点，这些计算节点相互独立、相互对等。由于顶层计算节点和中间层计算节点都有负载均衡功能，且底层计算节点只与单个存储单元建连，所以最底层计算节点分担到的链路压力就减小了很多。
在本实施例的一些示例中，各N层的计算节点可以分别采用相同的分发策略。例如，在第一层、第二层、第三层的计算节点均采用分发策略1，或在第一层、第二层、第三层的计算节点均采用分发策略2，或在第一层、第二层、第三层的计算节点均采用分发策略3。
在本实施例的一些示例中，各N层的计算节点也可以分别采用不同的分发策略。例如，在第一层的计算节点采用分发策略1，在第二层的计算节点采用分发策略2，在第三层的计算节点采用分发策略3。
在本实施例的一些示例中，本实施例中的分发策略包括哈希hash分发策略、范围range分发策略、枚举list分发策略、复制duplicate分发策略中的至少一种。值得注意的是，这里所列举的只是几种常见的分发策略，在实际应用中，可根据具体需求做灵活调整。
本发明实施例提供的业务请求消息发送方法，通过接在收业务请求消息时，将业务请求消息经过N层计算节点发送到对应的存储单元中，其中N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多；至少在一定程度上解决了相关技术中的技术问题之一，包括随着业务数据量和客户端并发数的持续升高，产生的后端链路已超出想象，加大了维护难度的问题。也即本发明实施例提供的业务请求消息发送方法，首先是将计算节点分层(至少两层)，且将存储集群划分成多个(至少两个)存储单元(每个存储单元中包含至少一个存储节点)，然后通过“链路负载均衡”，使每个计算节点的后端链路数都大幅减少，最后通过“每层计算节点各自使用自己的分发策略”，将业务请求消息发送到对应的存储节点，避免了同一计算节点的后端链路太多，难以维护的现象发生，在极大程度上提升了计算节点后端链路的可维护性，大大降低了维护难度。
实施例二
在本发明实施例中以分布式数据库架构包括三层计算节点进行业务请求消息发送的过程为例进行说明，请参见图5所示。
其中，计算节点划分为三层，顶层计算节点可以与所有中间层计算节点建连，中间层计算节点又划分了两个区域，应当理解的是，中间层计算节点可划分为多个区域，同一区域内的中间层计算节点对等，底层计算节点只能对接单个存储单元。
其中，存储集群划分为K个存储单元，各个存储单元中包含M个存储节点，K为大于等于2的整数，M为大于等于1的整数。
下文以一种具体的链路分压机制进行说明：
1、顶层计算节点1接收到来自客户端1的4000并发请求。
应当理解的是，客户端可以有多个，顶层计算节点也可以有多个。
2、顶层计算节点1与区域1中的两个对等中间层计算节点建连，采用负载均衡的方式，每个建连2000链路；同时顶层计算节点1还可以与其他区域的中间层计算节点建连，例如区域2的中间层计算节点，模式同区域1的建连。
应当理解的是，在本实施例的一些示例中，顶层计算节点1与区域1中的两个对等中间层计算节点建连，其中一个中间层计算节点可建连1600链路，另一个中间层计算节点可建连2400链路，在实际应用中，可根据具体需求以及分发策略做灵活调整。
3、区域1的中间层计算节点与两个对等底层计算节点建连，也采用负载均衡的方式，每个建连1000链路；底层计算节点只能与单个存储单元建连。
应当理解的是，在本实施例的一些示例中，区域1中的第一个中间层计算节点与两个对等底层计算节点建连，其中一个底层计算节点可建连600链路，另一个底层计算节点可 建连1000链路，在实际应用中，可根据具体需求以及分发策略做灵活调整。
4、底层计算节点与存储单元中的所有存储节点建连，后端链路数为1000*M(未计算其他中间层计算节点过来的链路)。
如果采用现有方式顶层计算节点直接对接所有存储节点，后端链路数就是4000*M*K。
可见，本发明实施例提供的业务请求消息发送方法具有以下有益效果：
1、多层计算节点后端链路数大幅度减少，从而减少了链路“回收-重建”的消耗，解决了计算节点链路数承载瓶颈的问题。
2、多层计算节点结构更灵活，可以根据存储节点数量调整计算节点层数，计算节点层数范围[2，N]，N为大于等于2的整数。
3、将存储集群划分为多个存储单元后，存储单元的维护成本更低，容量变动更灵活。
实施例三
在本发明实施例中以分布式数据库架构包括两层计算节点进行业务请求消息发送的过程为例进行说明，请参见图6所示。
其中，计算节点划分为两层，两个顶层计算节点相对独立、相互对等，且都能与所有底层计算节点建连；
其中，存储集群划分为K个存储单元，各个存储单元中包含M个存储节点，K为大于等于2的整数，M为大于等于1的整数。存储单元1上的底层计算节点与存储单元K上的底层计算节点相互不对等，元数据存在部分差异(差异点：前者绑定了存储单元1，后者绑定了存储单元2)；
底层计算节点只与单个存储单元建连，根据图中节点数示例，与单个计算节点直接对接所有存储节点相比，图中单个底层计算节点后端链路数缩减了K倍(2个顶层计算节点平分客户端链路，又汇聚到每个底层计算节点，即每个底层计算节点前端链路数等于客户端链路数，但存储集群被划分成了K个存储单元，底层计算节点只与单个存储单元建连，所以后端链路缩减了K倍。)
实施例四
在本发明实施例中以添加、删除存储节点的过程为例进行说明。
当业务数据量增加时，需要增加存储节点，只需要在适当的存储单元中添加。如图7所示，在存储单元1中增加了一个“new存储节点”。其中，增加了“new存储节点”，业务数据的迁移/重组只需要在存储单元1内，其他存储单元不涉及数据迁移/重组，在很多场景下大幅度减小了增加存储节点的成本。
当业务数据量减少时，需要删除存储节点，只需要在适当的存储单元中删除。如图8 所示，在存储单元1中删除了一个“存储节点2”(删除的“存储节点2”以虚线所示，便于观察业务数据变化)。其中，删除了“存储节点2”，业务数据的迁移/重组只需要在存储单元1内，其他存储单元不涉及数据迁移/重组，在很多场景下大幅度减小了删除存储节点的成本。
实施例五
为了至少解决相关技术中的技术问题之一，包括随着业务数据量和客户端并发数的持续升高，产生的后端链路已超出想象，加大了维护难度的问题，在本发明实施例中提供一种分布式数据库架构，其中分布式数据库架构包括N层计算节点，N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多，当接收到业务请求消息时经过N层计算节点发送到对应的存储单元中。
应当理解的是，本实施例中的计算节点分为至少两层，即划分计算节点为至少两层，其中越接近存储单元所在层的计算节点的个数越多，即计算节点层数为“金字塔”式。
在一些示例中，同样参见图2所示，计算节点划分为三层，第一层计算节点又可称之为顶层计算节点，第二层计算节点又可称之为中间层计算节点，第三层计算节点接近存储单元又可称之为底层计算节点，其中，顶层计算节点的个数为1，中间层计算节点的个数为3，底层计算节点的个数为6，顶层计算节点与所有中间层计算节点建连，中间层计算节点与所属底层计算节点建连。
在一些示例中，同样参见图3所示，计算节点划分为两层，第一层计算节点又可称之为顶层计算节点，第二层计算节点接近存储单元又可称之为底层计算节点，其中，顶层计算节点的个数为2，底层计算节点的个数为4，顶层计算节点与所有底层计算节点建连。
值得注意的是，本发明并不局限于N为3或2，在实际应用中，可根据业务数据量和客户端并发数确定计算节点的层数N。
在本实施例一些示例中，存储集群包括至少两个存储单元，各个存储单元中包含至少一个存储节点。
例如同样参见图4所示，设将存储集群包括3个存储单元，分别为存储单元1、存储单元2以及存储单元3，其中存储单元1包含3个存储节点，存储单元2包含2个存储节点，存储单元3包含1个存储节点。
值得注意的是，在实际应用中，将存储集群划分为的存储单元的个数以及各个存储单元中包含的存储节点的个数可根据具体业务数据量做灵活调整。
应当理解的是，当将存储集群划分为至少两个存储单元后，各个存储节点的增/删(扩容/缩容)之间互不影响，从而使得各个存储节点的增/删(扩容/缩容)更易实施，容量变 动更为灵活且在一定程度上减低了维护成本。
在本实施例的一些示例中，与存储单元最接近的计算节点称之为底层计算节点，其中底层计算节点用于管理和维护与之相连的存储单元中的各存储节点，因此无需再单独针对管理存储单元中的各存储节点设置管理和维护模块，通过底层计算节点便可实现对与之相连的存储单元中的各存储节点，节约成本，且由于与各个计算节点相连的存储单元中的各存储节点较少，也便于实施管理和维护。
在本实施例的一些示例中，除底层计算节点之外的其他各层的计算节点均能实现负载均衡功能。
其中，顶层计算节点可以与下一层任意一个计算节点建连，根据业务并发繁忙情况，可以启用多个顶层计算节点，多个顶层计算节点之间相互独立(无依赖)、相互对等(共享元数据信息)，顶层计算节点拥有负载均衡功能(也可以集成第三方负载均衡模块)。
其中，中间层计算节点可按区域划分，区域之间的计算节点相互独立、相互不对等(元数据信息存在部分差异)，每个区域内的计算节点可以有多个，区域内的计算节点相互独立、相互对等。中间计算节点与下一层所属的计算节点建连，并非跟下一层任意的计算节点建连，中间层可以有多层，划分区域规则相同，中间层计算节点也拥有负载均衡功能(也可以集成第三方负载均衡模块)。
应当理解的是，底层计算节点只对接单个存储单元，存储单元之间的计算节点相互独立、相互不对等(元数据信息存在部分差异)。每个存储单元上可以有多个底层计算节点，这些计算节点相互独立、相互对等。由于顶层计算节点和中间层计算节点都有负载均衡功能，且底层计算节点只与单个存储单元建连，所以最底层计算节点分担到的链路压力就减小了很多。
在本实施例的一些示例中，各N层的计算节点可以分别采用相同的分发策略。例如，在第一层、第二层、第三层的计算节点均采用分发策略1，或在第一层、第二层、第三层的计算节点均采用分发策略2，或在第一层、第二层、第三层的计算节点均采用分发策略3。
在本实施例的一些示例中，各N层的计算节点也可以分别采用不同的分发策略。例如，在第一层的计算节点采用分发策略1，在第二层的计算节点采用分发策略2，在第三层的计算节点采用分发策略3。
在本实施例的一些示例中，本实施例中的分发策略包括哈希hash分发策略、范围range分发策略、枚举list分发策略、复制duplicate分发策略中的至少一种。值得注意的是，这里所列举的只是几种常见的分发策略，在实际应用中，可根据具体需求做灵活调整。
本发明实施例还提供了一种计算机可读存储介质，其存储有计算机程序，该计算机程序用于执行上述的业务请求消息发送方法。
本发明实施例提供的分布式数据库架构包括N层计算节点，N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多，当接收到业务请求消息时经过N层计算节点发送到对应的存储单元中；至少在一定程度上解决了相关技术中的技术问题，包括随着业务数据量和客户端并发数的持续升高，产生的后端链路已超出想象，加大了维护难度的问题。也即本发明实施例提供的分布式数据库架构，首先是将计算节点分层(至少两层)，且将存储集群划分成多个(至少两个)存储单元(每个存储单元中包含至少一个存储节点)，然后通过“链路负载均衡”，使每个计算节点的后端链路数都大幅减少，最后通过“每层计算节点各自使用自己的分发策略”，将业务请求消息发送到对应的存储节点，避免了同一计算节点的后端链路太多，难以维护的现象发生，在极大程度上提升了计算节点后端链路的可维护性，大大降低了维护难度。
本发明实施例提供的业务请求消息发送方法及分布式数据库架构，通过接在收业务请求消息时，将业务请求消息经过N层计算节点发送到对应的存储单元中，其中N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多；解决了相关技术中随着业务数据量和客户端并发数的持续升高，产生的后端链路已超出想象，加大了维护难度的问题。也即本发明实施例提供的业务请求消息发送方法及分布式数据库架构，通过N层计算节点(金字塔式)依次将业务请求消息发送至对应的存储节点，一层一层的减小计算节点的后端链路，避免了同一计算节点的后端链路太多，难以维护的现象发生。
显然，本领域的技术人员应该明白，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的程序代码来实现)、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读 指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。所以，本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (11)

  1. 一种业务请求消息发送方法，应用于分布式数据库，包括：
    接收业务请求消息；
    将所述业务请求消息经过N层计算节点发送到对应的存储单元中，所述N为整数且大于等于2，越接近所述存储单元所在层的计算节点的个数越多。
  2. 如权利要求1所述的业务请求消息发送方法，其中，所述将业务请求消息经过N层计算节点发送到对应的存储单元中之前，还包括：
    将存储集群划分为至少两个存储单元，各个存储单元中包含至少一个存储节点。
  3. 如权利要求2所述的业务请求消息发送方法，其中，与所述存储单元最接近的计算节点为底层计算节点，所述底层计算节点用于管理和维护与之相连的存储单元中的各存储节点。
  4. 如权利要求3所述的业务请求消息发送方法，其中，除所述底层计算节点之外的其他各层的计算节点均能实现负载均衡功能。
  5. 如权利要求1-4任一项所述的业务请求消息发送方法，其中，所述各N层的计算节点分别采用相同的分发策略，或，所述各N层的计算节点分别采用不同的分发策略。
  6. 如权利要求5所述的业务请求消息发送方法，其中，所述分发策略包括哈希分发策略、范围分发策略、枚举分发策略、复制分发策略中的至少一种。
  7. 一种分布式数据库架构，包括：
    N层计算节点，所述N为整数且大于等于2，越接近存储单元所在层的计算节点的个数越多；
    当接收到业务请求消息时经过N层计算节点发送到对应的存储单元中。
  8. 如权利要求7所述的分布式数据库架构，其中，所述分布式数据库架构还包括：至少两个存储单元，各个存储单元中包含至少一个存储节点。
  9. 如权利要求8所述的分布式数据库架构，其中，与所述存储单元最接近的计算节点为底层计算节点，所述底层计算节点用于管理和维护与之相连的存储单元中的各存储节点。
  10. 如权利要求9所述的分布式数据库架构，其中，除所述底层计算节点之外的其他各层的计算节点均能实现负载均衡功能。
  11. 一种计算机可读存储介质，其存储有计算机程序，所述计算机程序用于执行权利要求1-6任一项所述的业务请求消息发送方法。
PCT/CN2020/094941 2019-07-29 2020-06-08 一种业务请求消息发送方法、分布式数据库架构及计算机可读存储介质 WO2021017646A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/628,775 US11824924B2 (en) 2019-07-29 2020-06-08 Service request message sending method, distributed database architecture and computer readable storage medium
EP20847973.3A EP4002146A4 (en) 2019-07-29 2020-06-08 METHOD OF SENDING A SERVICE REQUEST MESSAGE, DISTRIBUTED DATABASE ARCHITECTURE AND COMPUTER READABLE STORAGE MEDIA

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910690727.X 2019-07-29
CN201910690727.XA CN112307113A (zh) 2019-07-29 2019-07-29 一种业务请求消息发送方法及分布式数据库架构

Publications (1)

Publication Number Publication Date
WO2021017646A1 true WO2021017646A1 (zh) 2021-02-04

Family

ID=74230080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/094941 WO2021017646A1 (zh) 2019-07-29 2020-06-08 一种业务请求消息发送方法、分布式数据库架构及计算机可读存储介质

Country Status (4)

Country Link
US (1) US11824924B2 (zh)
EP (1) EP4002146A4 (zh)
CN (1) CN112307113A (zh)
WO (1) WO2021017646A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113114568B (zh) * 2021-04-08 2023-01-03 易谷网络科技股份有限公司 路由处理方法和路由服务器

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105608144A (zh) * 2015-12-17 2016-05-25 山东鲁能软件技术有限公司 一种基于多层模型迭代的大数据分析平台装置及方法
CN105975378A (zh) * 2016-05-11 2016-09-28 国网江苏省电力公司 一种面向超级计算机的分布式层次化自主监控管理系统
US20160314409A1 (en) * 2015-04-23 2016-10-27 General Electric Company Method and system for real time production optimization based on equipment life
CN110018817A (zh) * 2018-01-05 2019-07-16 中兴通讯股份有限公司 数据的分布式运行方法及装置、存储介质及处理器

Family Cites Families (122)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8209696B2 (en) 2006-02-13 2012-06-26 Teradata Us, Inc. Method and system for load balancing a distributed database
US8352495B2 (en) * 2009-12-15 2013-01-08 Chalklabs, Llc Distributed platform for network analysis
CN101930472A (zh) * 2010-09-09 2010-12-29 南京中兴特种软件有限责任公司 一种支持分布式数据库基于并行查询的方法
US11275509B1 (en) * 2010-09-15 2022-03-15 Pure Storage, Inc. Intelligently sizing high latency I/O requests in a storage environment
EP2740055A4 (en) * 2011-08-01 2015-09-09 Tagged Inc SYSTEMS AND METHOD FOR ASYNCHRONOUS DISTRIBUTED DATABASE MANAGEMENT
CN102546782B (zh) * 2011-12-28 2015-04-29 北京奇虎科技有限公司 一种分布式系统及其数据操作方法
US11032259B1 (en) * 2012-09-26 2021-06-08 Pure Storage, Inc. Data protection in a storage system
CN102955845B (zh) * 2012-10-23 2015-11-25 北京亿赞普网络技术有限公司 数据访问方法、装置与分布式数据库系统
US10908835B1 (en) * 2013-01-10 2021-02-02 Pure Storage, Inc. Reversing deletion of a virtual machine
US11128448B1 (en) * 2013-11-06 2021-09-21 Pure Storage, Inc. Quorum-aware secret sharing
US10620830B2 (en) * 2013-12-18 2020-04-14 Amazon Technologies, Inc. Reconciling volumelets in volume cohorts
US10037340B2 (en) 2014-01-21 2018-07-31 Red Hat, Inc. Tiered distributed storage policies
US11503031B1 (en) * 2015-05-29 2022-11-15 Pure Storage, Inc. Storage array access control from cloud-based user authorization and authentication
US11294588B1 (en) * 2015-08-24 2022-04-05 Pure Storage, Inc. Placing data within a storage device
US11360844B1 (en) * 2015-10-23 2022-06-14 Pure Storage, Inc. Recovery of a container storage provider
US10514978B1 (en) * 2015-10-23 2019-12-24 Pure Storage, Inc. Automatic deployment of corrective measures for storage arrays
US11112990B1 (en) * 2016-04-27 2021-09-07 Pure Storage, Inc. Managing storage device evacuation
US10303390B1 (en) * 2016-05-02 2019-05-28 Pure Storage, Inc. Resolving fingerprint collisions in flash storage system
CN106096038A (zh) * 2016-06-28 2016-11-09 浪潮软件股份有限公司 一种云计算架构下的分布式数据库架构
CN106250566A (zh) * 2016-08-31 2016-12-21 天津南大通用数据技术股份有限公司 一种分布式数据库及其数据运算的管理方法
US11531577B1 (en) * 2016-09-07 2022-12-20 Pure Storage, Inc. Temporarily limiting access to a storage device
US11481261B1 (en) * 2016-09-07 2022-10-25 Pure Storage, Inc. Preventing extended latency in a storage system
US10671439B1 (en) * 2016-09-07 2020-06-02 Pure Storage, Inc. Workload planning with quality-of-service (‘QOS’) integration
US10756816B1 (en) * 2016-10-04 2020-08-25 Pure Storage, Inc. Optimized fibre channel and non-volatile memory express access
US10230544B1 (en) * 2016-11-23 2019-03-12 Pure Storage, Inc. Efficient data forwarding in a networked device
US11461273B1 (en) * 2016-12-20 2022-10-04 Pure Storage, Inc. Modifying storage distribution in a storage system that includes one or more storage devices
CN108268210B (zh) * 2016-12-30 2022-03-08 中移(苏州)软件技术有限公司 一种信息处理方法、计算节点及存储节点
US11340800B1 (en) * 2017-01-19 2022-05-24 Pure Storage, Inc. Content masking in a storage system
US10454810B1 (en) * 2017-03-10 2019-10-22 Pure Storage, Inc. Managing host definitions across a plurality of storage systems
US10521344B1 (en) * 2017-03-10 2019-12-31 Pure Storage, Inc. Servicing input/output (‘I/O’) operations directed to a dataset that is synchronized across a plurality of storage systems
US11089105B1 (en) * 2017-12-14 2021-08-10 Pure Storage, Inc. Synchronously replicating datasets in cloud-based storage systems
US11169727B1 (en) * 2017-03-10 2021-11-09 Pure Storage, Inc. Synchronous replication between storage systems with virtualized storage
US10528488B1 (en) * 2017-03-30 2020-01-07 Pure Storage, Inc. Efficient name coding
US11016667B1 (en) * 2017-04-05 2021-05-25 Pure Storage, Inc. Efficient mapping for LUNs in storage memory with holes in address space
US10459664B1 (en) * 2017-04-10 2019-10-29 Pure Storage, Inc. Virtualized copy-by-reference
US10516645B1 (en) * 2017-04-27 2019-12-24 Pure Storage, Inc. Address resolution broadcasting in a networked device
US11467913B1 (en) * 2017-06-07 2022-10-11 Pure Storage, Inc. Snapshots with crash consistency in a storage system
US11422731B1 (en) * 2017-06-12 2022-08-23 Pure Storage, Inc. Metadata-based replication of a dataset
US10884636B1 (en) * 2017-06-12 2021-01-05 Pure Storage, Inc. Presenting workload performance in a storage system
US11016824B1 (en) * 2017-06-12 2021-05-25 Pure Storage, Inc. Event identification with out-of-order reporting in a cloud-based environment
US11340939B1 (en) * 2017-06-12 2022-05-24 Pure Storage, Inc. Application-aware analytics for storage systems
US11442669B1 (en) * 2018-03-15 2022-09-13 Pure Storage, Inc. Orchestrating a virtual storage system
US11210133B1 (en) * 2017-06-12 2021-12-28 Pure Storage, Inc. Workload mobility between disparate execution environments
US10425473B1 (en) * 2017-07-03 2019-09-24 Pure Storage, Inc. Stateful connection reset in a storage cluster with a stateless load balancer
US11477280B1 (en) * 2017-07-26 2022-10-18 Pure Storage, Inc. Integrating cloud storage services
US10402266B1 (en) * 2017-07-31 2019-09-03 Pure Storage, Inc. Redundant array of independent disks in a direct-mapped flash storage system
US10776202B1 (en) * 2017-09-22 2020-09-15 Pure Storage, Inc. Drive, blade, or data shard decommission via RAID geometry shrinkage
US10789211B1 (en) * 2017-10-04 2020-09-29 Pure Storage, Inc. Feature-based deduplication
US11455168B1 (en) * 2017-10-19 2022-09-27 Pure Storage, Inc. Batch building for deep learning training workloads
US10671435B1 (en) * 2017-10-19 2020-06-02 Pure Storage, Inc. Data transformation caching in an artificial intelligence infrastructure
US10452444B1 (en) * 2017-10-19 2019-10-22 Pure Storage, Inc. Storage system with compute resources and shared storage resources
US11494692B1 (en) * 2018-03-26 2022-11-08 Pure Storage, Inc. Hyperscale artificial intelligence and machine learning infrastructure
US10545687B1 (en) * 2017-10-31 2020-01-28 Pure Storage, Inc. Data rebuild when changing erase block sizes during drive replacement
US11024390B1 (en) * 2017-10-31 2021-06-01 Pure Storage, Inc. Overlapping RAID groups
US10496330B1 (en) * 2017-10-31 2019-12-03 Pure Storage, Inc. Using flash storage devices with different sized erase blocks
US10467107B1 (en) * 2017-11-01 2019-11-05 Pure Storage, Inc. Maintaining metadata resiliency among storage device failures
US10671494B1 (en) * 2017-11-01 2020-06-02 Pure Storage, Inc. Consistent selection of replicated datasets during storage system recovery
US10817392B1 (en) * 2017-11-01 2020-10-27 Pure Storage, Inc. Ensuring resiliency to storage device failures in a storage system that includes a plurality of storage devices
US10484174B1 (en) * 2017-11-01 2019-11-19 Pure Storage, Inc. Protecting an encryption key for data stored in a storage system that includes a plurality of storage devices
US10509581B1 (en) * 2017-11-01 2019-12-17 Pure Storage, Inc. Maintaining write consistency in a multi-threaded storage system
US10990566B1 (en) * 2017-11-20 2021-04-27 Pure Storage, Inc. Persistent file locks in a storage system
US10929226B1 (en) * 2017-11-21 2021-02-23 Pure Storage, Inc. Providing for increased flexibility for large scale parity
US10990282B1 (en) * 2017-11-28 2021-04-27 Pure Storage, Inc. Hybrid data tiering with cloud storage
US10795598B1 (en) * 2017-12-07 2020-10-06 Pure Storage, Inc. Volume migration for storage systems synchronously replicating a dataset
US10719265B1 (en) * 2017-12-08 2020-07-21 Pure Storage, Inc. Centralized, quorum-aware handling of device reservation requests in a storage system
CN108282514B (zh) * 2017-12-12 2020-11-27 北京奇艺世纪科技有限公司 一种分布式业务建立方法及装置
US11036677B1 (en) * 2017-12-14 2021-06-15 Pure Storage, Inc. Replicated data integrity
US10970395B1 (en) * 2018-01-18 2021-04-06 Pure Storage, Inc Security threat monitoring for a storage system
US11010233B1 (en) * 2018-01-18 2021-05-18 Pure Storage, Inc Hardware-based system monitoring
US10976948B1 (en) * 2018-01-31 2021-04-13 Pure Storage, Inc. Cluster expansion mechanism
US10733053B1 (en) * 2018-01-31 2020-08-04 Pure Storage, Inc. Disaster recovery for high-bandwidth distributed archives
US11036596B1 (en) * 2018-02-18 2021-06-15 Pure Storage, Inc. System for delaying acknowledgements on open NAND locations until durability has been confirmed
US11494109B1 (en) * 2018-02-22 2022-11-08 Pure Storage, Inc. Erase block trimming for heterogenous flash memory storage devices
US10521151B1 (en) * 2018-03-05 2019-12-31 Pure Storage, Inc. Determining effective space utilization in a storage system
US10942650B1 (en) * 2018-03-05 2021-03-09 Pure Storage, Inc. Reporting capacity utilization in a storage system
US11150834B1 (en) * 2018-03-05 2021-10-19 Pure Storage, Inc. Determining storage consumption in a storage system
US10296258B1 (en) * 2018-03-09 2019-05-21 Pure Storage, Inc. Offloading data storage to a decentralized storage network
US11048590B1 (en) * 2018-03-15 2021-06-29 Pure Storage, Inc. Data consistency during recovery in a cloud-based storage system
US10917471B1 (en) * 2018-03-15 2021-02-09 Pure Storage, Inc. Active membership in a cloud-based storage system
US11288138B1 (en) * 2018-03-15 2022-03-29 Pure Storage, Inc. Recovery from a system fault in a cloud-based storage system
US11210009B1 (en) * 2018-03-15 2021-12-28 Pure Storage, Inc. Staging data in a cloud-based storage system
US10924548B1 (en) * 2018-03-15 2021-02-16 Pure Storage, Inc. Symmetric storage using a cloud-based storage system
US11095706B1 (en) * 2018-03-21 2021-08-17 Pure Storage, Inc. Secure cloud-based storage system management
US11171950B1 (en) * 2018-03-21 2021-11-09 Pure Storage, Inc. Secure cloud-based storage system management
US10838833B1 (en) * 2018-03-26 2020-11-17 Pure Storage, Inc. Providing for high availability in a data analytics pipeline without replicas
US11392553B1 (en) * 2018-04-24 2022-07-19 Pure Storage, Inc. Remote data management
US11436344B1 (en) * 2018-04-24 2022-09-06 Pure Storage, Inc. Secure encryption in deduplication cluster
US10931450B1 (en) * 2018-04-27 2021-02-23 Pure Storage, Inc. Distributed, lock-free 2-phase commit of secret shares using multiple stateless controllers
US10678433B1 (en) * 2018-04-27 2020-06-09 Pure Storage, Inc. Resource-preserving system upgrade
US10310760B1 (en) * 2018-05-21 2019-06-04 Pure Storage, Inc. Layering communication fabric protocols
US10678436B1 (en) * 2018-05-29 2020-06-09 Pure Storage, Inc. Using a PID controller to opportunistically compress more data during garbage collection
US10776046B1 (en) * 2018-06-08 2020-09-15 Pure Storage, Inc. Optimized non-uniform memory access
US11281577B1 (en) * 2018-06-19 2022-03-22 Pure Storage, Inc. Garbage collection tuning for low drive wear
CN108920552B (zh) * 2018-06-19 2022-04-29 浙江工业大学 一种面向多源大数据流的分布式索引方法
US11416298B1 (en) * 2018-07-20 2022-08-16 Pure Storage, Inc. Providing application-specific storage by a storage system
US11403000B1 (en) * 2018-07-20 2022-08-02 Pure Storage, Inc. Resiliency in a cloud-based storage system
US11146564B1 (en) * 2018-07-24 2021-10-12 Pure Storage, Inc. Login authentication in a cloud storage platform
US10454498B1 (en) * 2018-10-18 2019-10-22 Pure Storage, Inc. Fully pipelined hardware engine design for fast and efficient inline lossless data compression
US10671302B1 (en) * 2018-10-26 2020-06-02 Pure Storage, Inc. Applying a rate limit across a plurality of storage systems
US11526405B1 (en) * 2018-11-18 2022-12-13 Pure Storage, Inc. Cloud-based disaster recovery
US11340837B1 (en) * 2018-11-18 2022-05-24 Pure Storage, Inc. Storage system management via a remote console
US10963189B1 (en) * 2018-11-18 2021-03-30 Pure Storage, Inc. Coalescing write operations in a cloud-based storage system
US10936191B1 (en) * 2018-12-05 2021-03-02 Pure Storage, Inc. Access control for a computing system
US11144358B1 (en) * 2018-12-06 2021-10-12 Pure Storage, Inc. Asynchronous arbitration of shared resources
US11003369B1 (en) * 2019-01-14 2021-05-11 Pure Storage, Inc. Performing a tune-up procedure on a storage device during a boot process
US11194473B1 (en) * 2019-01-23 2021-12-07 Pure Storage, Inc. Programming frequently read data to low latency portions of a solid-state storage array
US11042452B1 (en) * 2019-03-20 2021-06-22 Pure Storage, Inc. Storage system data recovery using data recovery as a service
US11221778B1 (en) * 2019-04-02 2022-01-11 Pure Storage, Inc. Preparing data for deduplication
US10990480B1 (en) * 2019-04-05 2021-04-27 Pure Storage, Inc. Performance of RAID rebuild operations by a storage group controller of a storage system
US11068162B1 (en) * 2019-04-09 2021-07-20 Pure Storage, Inc. Storage management in a cloud data store
US11327676B1 (en) * 2019-07-18 2022-05-10 Pure Storage, Inc. Predictive data streaming in a virtual storage system
US11487715B1 (en) * 2019-07-18 2022-11-01 Pure Storage, Inc. Resiliency in a cloud-based storage system
US11093139B1 (en) * 2019-07-18 2021-08-17 Pure Storage, Inc. Durably storing data within a virtual storage system
US11086713B1 (en) * 2019-07-23 2021-08-10 Pure Storage, Inc. Optimized end-to-end integrity storage system
US11086553B1 (en) * 2019-08-28 2021-08-10 Pure Storage, Inc. Tiering duplicated objects in a cloud-based object store
US11360689B1 (en) * 2019-09-13 2022-06-14 Pure Storage, Inc. Cloning a tracking copy of replica data
US11520907B1 (en) * 2019-11-22 2022-12-06 Pure Storage, Inc. Storage system snapshot retention based on encrypted data
US11321006B1 (en) * 2020-03-25 2022-05-03 Pure Storage, Inc. Data loss prevention during transitions from a replication source
US11301152B1 (en) * 2020-04-06 2022-04-12 Pure Storage, Inc. Intelligently moving data between storage systems
US11431488B1 (en) * 2020-06-08 2022-08-30 Pure Storage, Inc. Protecting local key generation using a remote key management service
US11442652B1 (en) * 2020-07-23 2022-09-13 Pure Storage, Inc. Replication handling during storage system transportation
US11397545B1 (en) * 2021-01-20 2022-07-26 Pure Storage, Inc. Emulating persistent reservations in a cloud-based storage system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160314409A1 (en) * 2015-04-23 2016-10-27 General Electric Company Method and system for real time production optimization based on equipment life
CN105608144A (zh) * 2015-12-17 2016-05-25 山东鲁能软件技术有限公司 一种基于多层模型迭代的大数据分析平台装置及方法
CN105975378A (zh) * 2016-05-11 2016-09-28 国网江苏省电力公司 一种面向超级计算机的分布式层次化自主监控管理系统
CN110018817A (zh) * 2018-01-05 2019-07-16 中兴通讯股份有限公司 数据的分布式运行方法及装置、存储介质及处理器

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4002146A4 *

Also Published As

Publication number Publication date
EP4002146A4 (en) 2022-09-07
US11824924B2 (en) 2023-11-21
US20220286498A1 (en) 2022-09-08
CN112307113A (zh) 2021-02-02
EP4002146A1 (en) 2022-05-25

Similar Documents

Publication Publication Date Title
CN111480154B (zh) 批量数据摄取的方法、系统和介质
US8930316B2 (en) System and method for providing partition persistent state consistency in a distributed data grid
US9367600B2 (en) Policy-based storage structure distribution
US11074017B2 (en) Log-structured storage systems
US9767178B2 (en) Multi-instance redo apply
US8484417B2 (en) Location updates for a distributed data store
CN102855294B (zh) 一种智能哈希数据布局方法、集群存储系统及其方法
US11347651B2 (en) Cache warming: agility for a stateful service
US20120246206A1 (en) File server system and storage control method
EP2954424B1 (en) Method, device, and system for peer-to-peer data replication and method, device, and system for master node switching
WO2017016336A1 (zh) 数据处理及查询方法、装置
KR20130086373A (ko) 데이터 기억 시스템에 대한 엔드포인트 캐싱
US8090683B2 (en) Managing workflow communication in a distributed storage system
CN101916289A (zh) 支持海量小文件和动态备份数的数字图书馆存储系统的构建方法
CN103631894A (zh) 一种基于hdfs的动态副本管理方法
CN107018172A (zh) 用于在分布式缓存存储器中自适应分区的系统和方法
CN106095589A (zh) 一种分配分区的方法、装置及系统
WO2021017646A1 (zh) 一种业务请求消息发送方法、分布式数据库架构及计算机可读存储介质
CN103441918A (zh) 一种自组织集群服务器系统及其自组织方法
CN105677761A (zh) 一种数据切分的方法及系统
CN107590257A (zh) 一种数据库管理方法及装置
US20200272335A1 (en) Data storage system with separate interfaces for bulk data ingestion and data access
CN104410531A (zh) 冗余的系统架构方法
WO2020259191A1 (zh) 一种数据中心节点分配方法、装置、系统及计算机设备
US20230418827A1 (en) Processing multi-column streams during query execution via a database system

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: 20847973

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020847973

Country of ref document: EP

Effective date: 20220215