Design for improving concurrency capability of NoSQL (Not Only Structured Query Language) non-relational database under multi-core architecture

Abstract

The invention discloses a design for improving the concurrency capability of an NoSQL non-relational database under a multi-core architecture, and belongs to the field of database system architectures. Multiple threads of the Sudis make full use of the multi-core advantage, different thread pool configurations can be carried out according to different cpu, the Sudis is divided into multiple thread pools, the thread pools can not interfere with one another, the performance of the Sudis is improved, long connection can be established between a user and the Sudis, the long connection exists in the form of clients in the Sudis, each client has a unique ID, and the service life of the user is prolonged. The method comprises the steps that a client side sends a request to a receiving thread for processing, the request of the Sudis is divided into processing of one key or multiple keys, when a single key is processed, calculation distribution is directly carried out, all the requests of the key are distributed to the same thread for processing, locking is not needed, multi-thread locking expenses are saved, aggressive distribution processing is carried out on the multiple keys in sequence, and the processing efficiency is greatly improved. And after the last thread finishes key processing, results are summarized, so that the performance of the whole system is improved.

Description

Technical Field

[0001] The present invention relates to the field of database system architecture, and in particular to a design for improving the concurrency capability of a NoSQL non-relational database under a multi-core architecture. Background Art

[0002] In modern computer systems, multi-core architectures are increasingly used. A thread is the smallest unit of scheduling in an operating system. It is an entity in a process and is responsible for executing a section of code in the process. In the existing database system architecture, a single thread is used to execute commands, which has the advantages of simple programming and avoiding resource competition.

[0003] However, when using a single thread, since each task must be executed in sequence, in some cases, tasks may wait, resulting in longer system response time and lower efficiency. In addition, the multi-core architecture cannot be fully utilized. The single-thread model cannot fully utilize the parallel processing capabilities of multi-core processors. At the same time, all tasks are executed in one thread. Once the thread fails, the entire system will be affected. The performance of the entire system is average.

[0004] The present invention is used for a thread pool management module of a Sudis distributed high-speed cache database system 2.0 product. Summary of the invention

[0005] The main purpose of the present invention is to provide a design for improving the concurrency capability of NoSQL non-relational databases under a multi-core architecture, which can effectively solve the problems in the background technology.

[0006] To achieve the above object, the technical solution adopted by the present invention is: A design for improving the concurrency capability of a NoSQL non-relational database under a multi-core architecture includes a user and sudis. The sudis consists of a receiving thread pool, a processing thread pool and a sending thread pool. The user's sending end is connected to the receiving thread pool, and the user's receiving end is connected to the sending thread pool.

[0007] Preferably, the receiving thread pool is composed of a set of N receiving threads, and the receiving thread pool is used to receive requests sent by users, parse the requests, and generate internal requests to hand over to the processing thread pool.

[0008] Preferably, the processing thread pool includes N processing threads. The processing thread pool accesses the database according to the request content to realize the reading and writing of data, and sends the processing result to the sending thread pool.

[0009] Preferably, the receiving thread pool is composed of N receiving threads, and the receiving thread pool replies the request result to the user.

[0010] Preferably, each thread pool in the sudis can not interfere with each other, reduce thread switching overhead, and improve its own performance.

[0011] Preferably, a long connection is established between the user and sudis, and this long connection exists in sudis in the form of a client, and each client has a unique ID.

[0012] Compared with the prior art, the present invention has the following beneficial effects: the design of improving the concurrency capability of NoSQL non-relational database under the multi-core architecture, the multi-threading of Sudis fully utilizes the multi-core advantage, and different thread pool configurations can be performed according to different CPUs, Sudis is divided into multiple thread pools, which can be more convenient to bind the core, so that each thread pool can not interfere with each other, reduce thread switching overhead, and improve its own performance, and a long connection will be established between the user and Sudis, and this long connection will exist in the form of a client in Sudis, each client has a unique ID, and this client will be handed over to a receiving thread for processing, and the new connection will be assigned to the thread in the receiving thread pool in a roundrobin form. Sudis's request is divided into processing one key or multiple keys. When a single key is used, the calculation and allocation are directly performed, and all requests for this key are assigned to the same thread for processing, without locking, saving multi-thread locking overhead, and for multiple keys, the aggressive distribution processing is performed in sequence, and the results are summarized after the last thread completes the key processing, thereby improving the performance of the entire system. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 A schematic diagram of a design for improving the concurrency capability of a NoSQL non-relational database under a multi-core architecture of the present invention; Figure 2 This is a schematic diagram of a key for a design of improving the concurrency capability of a NoSQL non-relational database under a multi-core architecture of the present invention; Figure 3 This is a schematic diagram of multiple keys in a design for improving the concurrency capability of a NoSQL non-relational database under a multi-core architecture of the present invention. DETAILED DESCRIPTION

[0014] In order to make the technical means, creative features, objectives and effects achieved by the present invention easy to understand, the present invention is further explained below in conjunction with specific implementation methods.

[0015] like Figure 1-3As shown in the figure, a design for improving the concurrency capability of NoSQL non-relational database under a multi-core architecture includes users and sudis. Sudis consists of a receiving thread pool, a processing thread pool and a sending thread pool. The sending end of the user is connected to the receiving thread pool, and the receiving end of the user is connected to the sending thread pool. The receiving thread pool is composed of a collection of N receiving threads. The receiving thread pool is used to receive requests sent by users, parse the requests, generate internal requests and hand them over to the processing thread pool. The processing thread pool includes N processing threads. The processing thread pool accesses the database according to the request content, realizes data reading and writing, and hands the processing results to the sending thread pool. The receiving thread pool consists of N receiving threads, and the receiving thread pool replies the request results to the user.

[0016] Through the above embodiments, each thread pool in sudis can not interfere with each other, reduce thread switching overhead, and improve its own performance. A long connection is established between the user and sudis, and this long connection exists in the form of a client in sudis, and each client has a unique ID.

[0017] When making a request to the database system architecture, a long connection is established between the user and sudis. The long connection exists in sudis as a client and is processed according to the number of request keys of sudis. After the user sends the request, the request is input to the receiving thread in the receiving thread pool and distributed according to the number of keys. When there is only one key in the request, the hash value of the key is calculated and the processing thread is allocated using the hash. All requests for this key will be dispatched to the same thread for processing. During this processing, no locking is required, saving the multi-thread locking overhead. The processing thread will dispatch the sending thread according to the client ID and hand over the processing result to the sending thread in the sending thread pool for processing. The final result is delivered to the user through the sending thread.

[0018] When there are multiple keys in a request, the first key of the request is first dispatched to a thread according to the processing method for one key. The thread processes the key. For the remaining keys, the thread will perform a secondary dispatch and dispatch them to the key thread for processing according to the key hash. After the last thread completes the key processing, it will summarize all the processing results of the request, and then hash the request results according to the client ID to send the request results to the sending thread pool for processing. The sending thread can then feedback the corresponding information to the user.

[0019] It should be noted that Sudis's multi-threading fully utilizes the advantages of multi-cores, and different thread pool configurations can be made according to different CPUs. Sudis is divided into multiple thread pools, which can be more convenient to bind cores, so that each thread pool can not interfere with each other, reduce thread switching overhead, and improve its own performance. A long connection will be established between the user and sudis. This long connection will exist in the form of a client in sudis. Each client has a unique ID, and this client will be handed over to a receiving thread for processing. New connections will be assigned to threads in the receiving thread pool in a roundrobin manner. Sudis's requests are divided into processing one key or multiple keys. For a single key, the calculation and allocation are directly performed. All requests for this key are assigned to the same thread for processing. No locking is required, saving multi-thread locking overhead. For multiple keys, the processing is performed in sequence in an aggressive manner. After the last thread completes the key processing, the results are summarized, which improves the performance of the entire system.

[0020] The above shows and describes the basic principles and main features of the present invention and the advantages of the present invention. It should be understood by those skilled in the art that the present invention is not limited to the above embodiments. The above embodiments and descriptions are only for explaining the principles of the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention to be protected. The scope of protection of the present invention is defined by the attached claims and their equivalents.

Claims

1. A design for improving the concurrency capability of a NoSQL non-relational database in a multi-core architecture, characterized by: It includes users and sudis, wherein sudis consists of a receiving thread pool, a processing thread pool and a sending thread pool, the sending end of the user is connected to the receiving thread pool, and the receiving end of the user is connected to the sending thread pool.

2. According to the design of improving the concurrency capability of NoSQL non-relational database under a multi-core architecture according to claim 1, it is characterized by: The receiving thread pool is composed of N receiving threads. The receiving thread pool is used to receive requests sent by users, parse the requests, generate internal requests and hand them over to the processing thread pool.

3. The design for improving the concurrency capability of NoSQL non-relational databases under a multi-core architecture according to claim 2 is characterized by: The processing thread pool includes N processing threads. The processing thread pool accesses the database according to the request content to realize the reading and writing of data, and sends the processing result to the sending thread pool.

4. The design for improving the concurrency capability of NoSQL non-relational databases under a multi-core architecture according to claim 3 is characterized by: The receiving thread pool is composed of N receiving threads, and the receiving thread pool replies the request result to the user.

5. The design for improving the concurrency capability of NoSQL non-relational databases under a multi-core architecture according to claim 4 is characterized by: Each thread pool in the sudis can not interfere with each other, reduce thread switching overhead, and improve its own performance.

6. The design for improving the concurrency capability of NoSQL non-relational databases under a multi-core architecture according to claim 5 is characterized by: A persistent connection is established between the user and sudis. This persistent connection exists in sudis as a client, and each client has a unique ID.

Images