WO2023236756A1 - Multi-tenant data database allocation method, and program product and electronic device - Google Patents

Abstract

The present application relates to a multi-tenant data database allocation method, and a program product and an electronic device. The method comprises: acquiring a request for executing an insurance service; on the basis of product information and geographical region information in the request, matching the request with region database information of a product management database; when region database information is matched, acquiring a product configuration rule from a product region database, and acquiring, according to the product configuration rule, data which is required for executing the insurance service; and when the region database information is not matched, acquiring tenant information in the request, and acquiring, from a tenant database, the data which is required for executing the insurance service. In the technical solution of the present application, geographical region information is combined with a database allocation rule, such that the problem of a failure to process an insurance service due to accessing the same database only according to a single multi-tenant database allocation rule can be effectively avoided.

Description

Multi-tenant data sharding methods, program products and electronic equipment

This application requests the priority of the Chinese patent application submitted to the China Patent Office on June 7, 2022, with the application number 202210637186.6 and the application name "Multi-tenant data sub-database method, program product and electronic device", and its entire content has been approved This reference is incorporated into this application.

Technical field

The present application relates to the field of computer technology, and in particular to a multi-tenant data sharding method, program products and electronic equipment.

Background technique

At present, with the improvement of users' security awareness, users are gradually realizing the importance of insurance, and more and more users are joining the ranks of purchasing insurance. Many insurance companies adopt the Software as a Service (SaaS) service model. SaaS service means that the SaaS provider builds all the network infrastructure, software, and hardware operation platforms required for the company's informatization, and is responsible for a series of services such as all early implementation and later maintenance. The company does not need to purchase software and hardware, build a computer room, Recruiting IT personnel allows you to use information systems through the Internet. Since a large number of insurance companies use SaaS services to carry out insurance business, multiple tenant projects are deployed on the SaaS service provider's server, and each tenant project has a corresponding database. For example, the urban medical insurance tenant has a corresponding urban medical insurance tenant database, accident insurance Tenants have corresponding accident insurance tenant databases, etc.

However, due to the large number of users and high concurrency, the connection resources of the database in the server are relatively precious. The existing tenant sharding method cannot change with changes in the business. Users of the same tenant in different regions operate the same tenant database. The data in the database can easily cause performance problems such as increased database load and insufficient number of connections. Simply accessing the corresponding tenant database based on tenant information cannot efficiently handle insurance business. For example, for the urban medical insurance project, if only based on the original tenant sharding method, a large number of users from different regions simultaneously request the server to obtain data in the same tenant database, which will easily cause the database load corresponding to the urban medical insurance to increase and the number of connections to be increased. Insufficient and other performance issues prevent the insurance business from being processed efficiently.

Contents of the invention

In view of this, this application relates to a multi-tenant data sharding method, program product, and electronic device.

In the first aspect, embodiments of the present application provide a multi-tenant data sharding method for a system including a server and a storage device serving as a database, wherein the server is configured with an interception matching module, and the interception matching module includes a data interception module. , regional rule matching module, organizational structure interception module, tenant rule matching module, the above methods include:

The data interception module obtains the request to execute the insurance business;

Based on the product information and geographical area information in the request passed by the data interception module, the regional rule matching module matches the request with the regional database information of the product management database in the database, where the product corresponds to multiple products in the database. Product area database, which includes product configuration rules corresponding to insurance business implementers;

When the regional library information is matched, the regional rule matching module obtains the product configuration rules in the product regional library, and obtains the data required to execute the insurance business according to the product configuration rules;

When the regional library information is not matched, the organizational structure interception module obtains the tenant information in the request; and the tenant rule matching module obtains the tenant information required to execute the insurance business from the tenant library in the database based on the tenant information passed by the organizational structure interception module. The data.

It is understandable that for the same type of insurance, since the geographical areas where policyholders want to insure are different, the corresponding policy data content is different, so different geographical areas can have different databases. The embodiment of the present application provides a multi-tenant data sharding method for a system including a server and a storage device as a database. The data interception module obtains a request to execute insurance business; the regional rule matching module is based on the request passed by the data interception module. The product information and geographical area information in the database are matched with the regional library information of the product management library in the database; in the case of matching the regional library information, the regional rule matching module obtains product configuration rules from the product regional library in the database. , and obtain the data required to execute the insurance business according to the product configuration rules; when the regional library information is not matched, the organizational structure interception module obtains the tenant information in the request; and the tenant rule matching module, based on the organizational structure interception module passed Tenant information obtains the data required to perform insurance business from the tenant library in the database. This method combines geographical area information with the sub-database method. According to the characteristics that the same insurance product can correspond to different regional databases, different regions corresponding to the same product are divided into different databases. In the case of high concurrency, for the same insurance product The product can access different product regional libraries, which improves the single database sub-rule based on tenant information, which can effectively avoid the problem of insurance business processing failure caused by accessing the same database only based on a single tenant sub-database rule, thereby improving the efficiency of the insurance business. processing efficiency.

In a possible implementation of the first aspect above, the product management library in the database may be a lightweight directory access protocol, where the lightweight directory access protocol includes product information and geographical area information corresponding to the product area library in the database. And the name, code name or path address of each product regional library.

It is understandable that the lightweight directory access protocol can be used as a special database that organizes information according to a tree structure and is specially optimized for browsing and searching directories and reading content. The product management library adopts a lightweight directory access protocol. The regional rule matching module can more quickly match the request with the regional library information of the product management library in the database based on the product information and geographical area information in the request passed by the data interception module. match.

In a possible implementation of the above first aspect, matching the request with the regional library information of the product management library in the database includes,

Search the product management library based on the product information and geographical area information to see if the product area library name, code or path address corresponding to the product information and geographical area information is found.

It can be understood that by searching in the product management library based on product information and geographical area information, whether the product area library name, code number or path address corresponding to the product information and geographical area information is found can be quickly, conveniently and effectively The request is matched with the regional library information of the product management library in the database to obtain a matching result.

In a possible implementation of the first aspect above, the regional rule matching module obtains product configuration rules from the product regional library in the database, and obtains data required to execute the insurance business according to the product configuration rules, including,

The regional rule matching module obtains product configuration rules from the specific regional database corresponding to the product regional database in the database through the regional database connection string, and obtains the data required to execute the insurance business based on the product configuration rules.

It can be understood that the regional rule matching module can quickly and efficiently obtain product configuration rules from the product regional library in the database through the regional library connection string, and obtain the data required to execute the insurance business based on the product configuration rules.

In a possible implementation of the first aspect above, the product area library includes product configuration rules corresponding to the insurance business implementer as,

The product area library includes product configuration rules specified by one insurance business implementer or multiple product configuration rules specified by multiple insurance business implementers.

It can be understood that the product area library includes product configuration rules specified by one insurance business implementer or multiple product configuration rules specified by multiple insurance business implementers. Multiple configuration rules are provided for the same insurance product in the same area, so that Regional sub-library rules are more reasonable.

In a possible implementation of the above first aspect, the product information includes a product name or product code.

It can be understood that the product name or product code is a direct and effective element for expressing the product. The product information includes the product name or product code, which helps to match the regional database information in the product management database according to the product information and regional information.

In a possible implementation of the above first aspect, the geographical area information includes the administrative area to which the product is divided or the custom area to which the product is divided based on customization.

It can be understood that the geographical area information includes the administrative area to which the product is divided or the custom area to which the product is divided according to customization, which is conducive to obtaining the product area database in combination with product information, and efficiently accessing it according to the area information in the product management database Corresponding specific regional database.

In a possible implementation of the above first aspect, the regional library information includes product regional library name, code number or path address.

It can be understood that the regional library information, including the specific product regional library name, code or path address, provides multiple representation methods for obtaining the product regional library in the product management library.

In a possible implementation of the first aspect above, the data required to perform insurance business includes,

At least one of the basic element content data on the policy, logical data for generating the policy, querying the status of the insurance business, or reviewing the insurance document.

It can be understood that the data required for executing the insurance business includes at least one of the basic element content data on the policy, executing the policy generation, executing the query of the insurance business status, or executing the logical data for reviewing the insurance document. After obtaining the aforementioned data Finally, insurance business can be effectively processed based on the obtained data.

In a possible implementation of the first aspect above, the database includes,

Product management library, product area library and tenant library.

It can be understood that the database includes a product management library, a product area library and a tenant library, which provide conditions for implementing regional sub-database rules and tenant sub-database rules.

In the second aspect, embodiments of the present application provide a multi-tenant data sharding device, including:

Data receiving module, used to receive data;

Data forwarding module, used to forward data;

The interception matching module is used to intercept data and match the intercepted data with regional sharding rules or tenant sharding rules;

Execution business logic module, used to execute business logic;

And, the interception matching module includes,

A data interception module, used to obtain the first data, where the first data includes product information and geographical area information;

The regional rule matching module is used to match regional sub-library rules based on product information and geographical area information;

The organizational structure interception module is used to obtain the second data, where the second data includes tenant information;

The tenant rule matching module is used to match tenant sharding rules based on tenant information.

It can be understood that the above-mentioned first data is the request data transmitted by the data forwarding module; the above-mentioned second data is the request data transmitted by the regional rule matching module.

It can be understood that the multi-tenant data sharding device provided by the embodiment of the present application includes a data receiving module, a data forwarding module, an interception matching module, and an execution business logic module. The insurance business can be processed through the aforementioned modules, wherein, The regional rule matching module includes multiple sub-modules that implement dynamic sharding rules based on the geographical area information in the request. Each sub-module can effectively implement a multi-tenant data sharding method.

In a third aspect, embodiments of the present application provide a computer-readable storage medium. Instructions are stored on the computer-readable storage medium. When the instructions are executed on an electronic device, the electronic device causes the electronic device to execute the above first aspect and the first aspect. Any multi-tenant data sharding method among various possible implementations.

In the fourth aspect, embodiments of the present application provide a chip device. The chip device includes:

Communication interfaces for inputting and/or outputting information;

A processor, configured to execute a computer executable program, so that the electronic device installed with the chip device executes any one of the multi-tenant data sharding methods of the above-mentioned first aspect and various possible implementations of the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program product, which is characterized in that the computer program product includes instructions, and when the instructions are executed, the above-mentioned first aspect and various possible implementations of the first aspect are implemented. Any multi-tenant data sharding method.

In a sixth aspect, embodiments of the present application provide an electronic device, which is characterized by including:

memory for storing instructions for execution by one or more processors of the electronic device, and

A processor, when the instructions are executed by one or more processors of the electronic device, the processor is configured to execute the instructions stored in the memory to implement the above first aspect and various possibilities of the first aspect. Implement any multi-tenant data sharding method.

Based on the above solution, this application has the following beneficial effects:

The embodiment of the present application provides a multi-tenant data sharding method for a system including a server and a storage device as a database. The data interception module obtains a request to execute insurance business; the regional rule matching module is based on the request passed by the data interception module. The product information and geographical area information in the database are matched with the regional library information of the product management library in the database; in the case of matching the regional library information, the regional rule matching module obtains product configuration rules from the product regional library in the database. , and obtain the data required to execute the insurance business according to the product configuration rules; when the regional library information is not matched, the organizational structure interception module obtains the tenant information in the request; and the tenant rule matching module, based on the organizational structure interception module passed Tenant information obtains the data required to perform insurance business from the tenant library in the database. This method combines geographical area information with the sub-database method. According to the characteristics that the same insurance product can correspond to different regional databases, different regions corresponding to the same product are divided into different databases. In the case of high concurrency, for the same insurance product Products can access different product regional libraries, and the single database sub-database rule based on tenant information has been improved, which can effectively avoid accessing the same database only based on a single tenant sub-database rule, causing insurance The problem of business processing failure is solved, thereby improving the processing efficiency of insurance business. In addition, a multi-tenant data sub-database device is provided. The device has a data receiving module, a data forwarding module, an interception matching module, and an execution business logic module, which can effectively complete the process of processing insurance business. Among them, the regional rule matching module includes a data interception module, a regional rule matching module, an organizational structure interception module, and a tenant rule matching module. Multiple sub-modules implement dynamic sub-database rules based on the product information, geographical area information, or tenant information in the request.

Description of drawings

Figure 1A shows a schematic diagram of an insurance business scenario according to some embodiments of the present application;

Figure 1B shows an unfinished policy interface schematic diagram according to some embodiments of the present application;

Figure 1C shows a schematic diagram of a completed policy interface according to some embodiments of the present application;

Figure 2A shows a schematic structural diagram of a server 200b according to some embodiments of the present application;

Figure 2B shows a schematic structural diagram of an interception matching module 203 according to some embodiments of the present application;

Figure 2C shows a schematic structural diagram of a database 300 according to some embodiments of the present application;

Figure 3 shows a schematic diagram of the interaction process between the interception matching module 203 and each sub-database in the database 300 according to some embodiments of the present application;

Figure 4 shows a flow chart of a multi-tenant data sharding method according to some embodiments of the present application;

Figure 5 shows a schematic diagram of the hardware structure of a server 200b according to some embodiments of the present application.

Detailed ways

Illustrative embodiments of the present application include, but are not limited to, a multi-tenant data sharding method, program products, and electronic devices.

In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions of the embodiments of the present application are further described in detail below by combining the drawings and implementation plans. Obviously, the described embodiments are only some, but not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

The technical solutions of the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

Figure 1A shows an insurance business scenario to which the technical solution of the present application is applicable, according to some embodiments of the present application. As shown in Figure 1A, it includes the policy holder, the user terminal 100 used by the policy holder, the server 200a corresponding to the insurance company, the server 200b corresponding to the SaaS service, and the database 300 deployed on the server 200b. In order to reduce operating costs, insurance companies purchase services from SaaS providers. Therefore, the insurance company only needs to deploy the facilities required for processing insurance business on the server, and then it can process the insurance business by accessing the server 200b.

The user terminal 100 can be connected to the server 200a through the network, and the server 200a can be connected to the server 200b through the network to handle insurance services. For example, the user terminal 100 can communicate with the server 200a through a wireless fidelity (Wireless-Fidelity, Wi-Fi) network, Bluetooth, and other wireless networks, and the server 200a can communicate through a wireless fidelity (Wireless-Fidelity, Wi-Fi) network, Bluetooth, and other wireless networks. Wait for the wireless network to communicate with the server 200b.

Specifically, the user terminal 100 can be installed with the insurance company's client software, such as an insurance application (Application, APP). The policyholder can access the server 200a through the insurance APP installed on the user terminal 100 to purchase the insurance products he or she needs, such as purchasing Urban medical insurance, pension insurance, vehicle insurance, accident insurance, etc.; policyholders can also use the instant messaging APP in the user terminal 100 to scan the QR code corresponding to each insurance to purchase insurance. Handle insurance business.

The server 200a encrypts the data according to the request data sent by the user terminal 100, and then sends the encrypted request data to the server 200b. After receiving the insurance service request, the server 200b identifies the insurance product based on the insurance product tenant information in the request. The specific tenant to which it belongs obtains the stored data in the database 300 corresponding to the tenant in the server 200b according to the tenant sub-database rules, executes the insurance business content, and sends the processed insurance business results to the server 200a, and the server 200a then sends the processed insurance business results to the server 200a. The insurance business result data is decrypted and the final result is sent to the user terminal 100, thereby completing the insurance business processing process.

It is understandable that since the insurance company rents software services provided by the SaaS service provider, the server 200b is deployed with data according to the insurance company's own business needs. The insurance company places the insurance business that needs to be processed using software services on the server 200b for processing according to the business, which reduces the maintenance cost and improves the availability of resources.

For example, the insurance business handled to generate a city medical insurance policy will be introduced in detail. FIG. 1B shows the page 101 of the user terminal 100 when the user applies for insurance. When the user handles the insurance business on the user terminal 100, after filling in the information required for the policy, for example, after filling in the product name, insurable cities, insurance amount and other data as shown in Figure 1b, a policy needs to be generated. The user terminal 100 sends a request to generate a city medical insurance policy to the server 200a; after receiving the request sent by the policy holder through the user terminal 100, the server 200a encrypts the request data, and then sends the encrypted request data to the server 200b; the server 200b After receiving the encrypted request to generate a city medical insurance policy, 200b identifies the tenant to which the city medical insurance product belongs (hereinafter referred to as the "medical insurance tenant"). For example, the medical insurance tenant can be an insurance company. According to the tenant sub-library rules, Obtain the stored data in the medical insurance tenant corresponding sub-database (hereinafter referred to as the "medical insurance tenant database") in the database 300, execute a request to generate an urban medical insurance policy based on the acquired data, and send the generated urban medical insurance policy result. To the server 200a, the server 200a then decrypts the processed insurance business result data according to the corresponding decryption method, and sends the final result to the user terminal 100. It can be understood that the business request for generating a city medical insurance policy is only one of the insurance services set by the insurance company in the server 200b to be processed by the server 200b, and the above is only an example. The insurance business processed by the server 200b can also generate blank policy business according to the insurance request, query the status of the insurance business, review insurance documents, and so on.

However, during the process of insurance business processing, most people perform insurance operations at the same time. Multiple user terminals 100 send insurance requests to the server 200a, and the server 200a then sends the encrypted request data to the server 200b. The server 200b needs to divide the insurance according to the multi-tenant classification. Database rules accessing the same database can easily cause performance problems such as increased database load and insufficient number of connections. This can easily cause policyholders to fail to apply for insurance, which not only wastes connection resources but also affects the processing of insurance business. For example, the user terminal 100 sends a request to generate a city medical insurance policy to the server 200a. After receiving the request sent by the user terminal 100, the server 200a encrypts data related to privacy security and sends the encrypted request data to the server 200b. The server 200b 200b based on the obtained data request and the tenant sub-database rules, determined that the city's medical insurance belongs to the medical insurance tenant. Due to the large number of connections to the medical insurance tenant database, the connection to the medical insurance tenant database failed, and insurance documents could not be generated, which wasted connection resources. , affecting the process of handling urban medical insurance business.

It is understandable that for the same insurance type, the corresponding policy data content will be different due to the different geographical areas where the policy holder wants to insure. For example, for the same type of urban medical insurance, in different cities, the urban medical reimbursement scope and reimbursement ratio, deductible setting, insurance requirements, geographical use requirements and other protection contents are different. For the same urban medical insurance product, the insurance content of urban medical insurance in city A is different from that of urban medical insurance in city B. The coverage content of medical insurance is different. Therefore, insured products and geographical areas can be associated, and the database can be divided according to the correlation between insured products and geographical areas.

To this end, this application proposes a multi-tenant data sharding method. The server 200b matches the insurance product information and geographical area information in the request with the regional sharding rules. If the match is successful, the server 200b obtains the data based on the regional sharding rules. The product configuration rules corresponding to the insurance company and the relevant data required to execute the insurance business corresponding to the product configuration rules execute the insurance business logic; if the match with the regional sub-database rules fails, the tenant information in the request is matched with the tenant sub-database rules. , after the matching is successful, the insurance business logic is executed based on the relevant data for executing the insurance business obtained by the tenant sub-database rules. Among them, insurance products correspond to multiple product regional libraries, and the product regional libraries include product configuration rules corresponding to insurance business implementers.

It is understandable that the above-mentioned geographical areas can be understood as different administrative areas, such as areas divided by provinces, cities, districts, and counties, or they can also be customized geographical areas based on the level of economic development and the number of permanent residents.

It is understandable that since the insurance content of the same insurance product purchased in different regions is different, by combining the insurance product and geographical area information, for the same product in different geographical areas, access to different product area libraries, in the area The product configuration rules related to different insurance companies are obtained from the database, so that in the case of high concurrency, multiple user terminals 100 can access different regional databases for different regions during the process of handling insurance business, which can effectively avoid simply based on A single multi-tenant sub-database rule accesses the same database, causing the problem of users failing to process insurance business, reducing the pressure on a single database, and thus improving the efficiency of insurance business processing.

For example, in the scenario shown in Figure 1A above, the user fills out the policy interface shown in Figure 1B. When the server 200b receives the request to generate urban medical insurance policy data, it obtains the product name and insurable data in the request. city, and match the product name "xx city medical insurance" and the insurable city "Anyang" with the regional sub-database rules. If the match is successful, the urban medical insurance product configuration rules corresponding to the insurance company are obtained in the corresponding regional database in Anyang (hereinafter referred to as the "Anyang database"), as well as the relevant information required to execute the insurance business corresponding to the urban medical insurance product configuration rules. data, and execute business logic based on the obtained data; if the match with the regional sharding rules fails, the tenant information corresponding to the urban medical insurance product in the request will be matched with the tenant sharding rules. After the match is successful, the matching tenant sharding rules will be used. Obtain the data related to generating insurance policies from the medical insurance tenant database, and then execute the business logic of generating medical insurance policies based on the acquired data. After the server 200b executes the business logic of generating medical insurance, it sends the data to the server 200a. The server 200a decrypts the data and then sends it to the user terminal 100. The user terminal 100 displays the insurance document interface 102 as shown in Figure 1C. At this time The insurance document interface cannot be modified.

It is understandable that for the same urban medical insurance business, its insurance services are different in different areas, such as Anyang, Yulin and other cities. When the server 200b receives the information of multiple user terminals 100 in Anyang, Yulin and other places obtained by the server 200a, In the insurance request, the server 200b can obtain the urban medical insurance product configuration rules corresponding to the insurance company in the Anyang database according to the regional sub-database rules, and the relevant data required to execute the insurance business corresponding to the urban medical insurance product configuration rules. According to the obtained The data is executed to generate the urban medical insurance policy business logic; then the urban medical insurance product configuration rules corresponding to the insurance company in the regional database corresponding to Yulin (hereinafter referred to as the "Yulin database") are obtained according to the regional sub-database rules, as well as the urban medical insurance product configuration rules corresponding to the urban medical insurance The product configuration rules correspond to the relevant data required to execute the insurance business, and a city medical insurance policy is generated based on the obtained data. Obtain the data required to execute insurance business logic in different regional databases through insurance requests to improve the efficiency of processing insurance business.

It should be noted that the user terminal 100 in the application scenario shown in FIG. 1A can be any electronic device that can install an insurance company's application program and has a display screen. Server 200a and server 200b may be separate A server can also be a server cluster composed of multiple servers.

In order to facilitate understanding of this solution, the device structure corresponding to the server 200b is first introduced.

As shown in Figure 2A, the server 200b includes a data receiving module 201, a data forwarding module 202, an interception matching module 203, and an execution business logic module 204.

The following is a detailed introduction to the functions of each module in the server 200b and its role in some embodiments of the present application.

Specifically, the data receiving module 201 may be used to receive request data. In some embodiments of the present application, the data receiving module 201 can receive the request data related to the insurance business sent by the server 200a, and send the request data to the data forwarding module 202. For example, the data receiving module 201 receives a message sent by the server 200a. The message includes at least one field of product information related to the insurance business, regional information, or tenant information to which the insurance product belongs.

The data forwarding module 202 may be used to forward request data. In some implementations of this application, the data forwarding module 202 can obtain the request data related to the insurance business sent by the data receiving module 201, filter out the irrelevant data in the request data, and send the filtered request data to the interception matching module. 203.

The interception matching module 203 can be used to intercept data, and match the intercepted data with regional sharding rules or tenant sharding rules. In some embodiments of the present application, the interception matching module 203 can receive the data sent by the data forwarding module 202, and perform regional sub-library rule matching based on the product information and geographical area information in the request data. If the matching is successful, the obtained data will be matched. The result data is sent to the execution business logic module 204; if the matching fails, the tenant information in the request is obtained, the tenant sharding rules are matched according to the tenant information, and the result data obtained by matching is sent to the execution business logic module 204.

It is understandable that the corresponding sharding strategy is matched based on the geographical area information or tenant information in the obtained request, which improves the original single tenant sharding method, so that under high concurrency conditions, for the same insurance product, due to Adopt a regional sub-database strategy to access different sub-databases to avoid the problem of failure to obtain data when accessing the same policy database, thereby improving the efficiency of processing insurance business. It can be understood that in some implementations, the interception matching module 203 may be a chained multi-interceptor.

The business logic execution module 204 is used to execute business logic. In some embodiments of the present application, the business execution logic module 204 can receive the insurance business data successfully matched by the interception matching module 203 and execute the insurance business. For example, execute the business of generating insurance documents, reviewing insurance documents, querying the status of insurance business, etc.

In order to more clearly explain the way in which the interception matching module 203 matches the sub-database rules, the specific functional modules that the interception matching module 203 may include and each sub-database included in the database 300 in some embodiments of the present application will be introduced first.

As shown in Figure 2B, the interception matching module 203 may include a data interception module 203a, a regional rule matching module 203b, an organizational structure interception module 203c, and a tenant rule matching module 203d.

The data interception module 203a obtains the request data forwarded by the data forwarding module 202, and sends the request data to the regional rule matching module 203b. It can be understood that in some implementations, the data interception module 203a may be a data interceptor.

The regional rule matching module 203b can receive the request data sent by the data interception module 203a, and first searches the product management library in the database 300 according to the product information and regional information in the request data. If the product corresponding to the product is found in the product management library, For specific regional library information, search the product regional library in the database 300 based on the regional library information to obtain the product configuration rules corresponding to the product regional library and the insurance business implementer and the data corresponding to the product configuration rules. If the match is successful, If the specific area corresponding to the product is not found in the product management library, then the match fail.

The organizational structure interception module 203c obtains the request data sent by the area rule matching module 203b, obtains the tenant information according to the request data, and sends the tenant information to the tenant rule matching module 203d. The tenant information may be information about insurance products or insurance companies corresponding to the insurance products. It can be understood that in some implementations, the organizational structure interception module 203c can be an organizational structure interceptor.

The tenant rule matching module 203d receives the data sent by the organizational structure interception module 203c, matches the tenant information in the acquired data in the tenant library in the database 300, and obtains the execution business logic data or policy data of the insurance business corresponding to the tenant. , sending the searched data to the execution business logic module 204.

As shown in FIG. 2C , the database 300 includes a product management database 301 , a product area database 302 and a tenant database 303 .

It can be understood that each sub-database in the database 300 can be a relational database or a lightweight directory access protocol (Lightweight Directory Access Protocol, LDAP). Among them, LDAP can be used as a special database that organizes information according to a tree structure. It is specially optimized for browsing and searching directories and reading content. It is a hierarchical database with very good data reading capabilities. Reading data from a relational database is an order of magnitude faster.

The LDAP directory stores record items in the form of a series of "attribute pairs". Each record item includes an attribute type and an attribute value. For example, the product management database 301 may be an LDAP database, and the regional database information stored in the product management database 301 may be insurance product information, regional information, and the name, code, or path address of the product regional database corresponding to the product regional database 302. Specifically, the attributes of the record items in the product management library 301 can be customized with product name attributes, region attributes, specific product regional library names, codes, or path address attributes corresponding to specific regional libraries, and corresponding attribute values are obtained according to the attributes.

Specifically, the product management database 301 includes information about each product and multiple regional libraries corresponding to each product, such as product regional library names, codes, or path addresses. For example, if the product is K insurance product, then the product is sold in cities A, B, and C. There will be the A city library name, code or regional library path address corresponding to the K insurance product, and the B city library name, corresponding to the K insurance product. Code name or regional library path address, C city library name, code name or product regional library path address corresponding to the K insurance product, etc. Each of the multiple products will have multiple corresponding regional libraries. For example, for urban medical insurance products that can be sold in multiple cities such as Yulin and Anyang, the product matching database 301 may include the database names, codes or path addresses corresponding to the urban medical insurance products in Yulin, Anyang and other places.

The product area database 302 includes multiple area databases corresponding to products, and each sub-database in the product area database corresponds to the name or path address of the product area database obtained from the product management database. For example, for K insurance products, each sub-database includes the A city library corresponding to K insurance product or the path address corresponding to A city library, the B city library corresponding to K insurance product or the path address corresponding to B city library, the K insurance product corresponding C city library or the path address corresponding to the C city library, etc. For example, for urban medical insurance products, there are multiple corresponding product regional libraries, including Weihai library, Yulin library, Anyang library and other regional libraries. Each product area library includes product configuration rules corresponding to insurance business implementers. One product area library may include product configuration rules corresponding to multiple different insurance companies. Specifically, multiple product configuration rules specified by an insurance company or A product configuration rule stipulated by one insurance company or a product configuration rule stipulated by multiple insurance companies, etc. There are no restrictions on specific circumstances. For example, the Yulin library includes urban medical insurance product configuration rules set by multiple insurance companies.

The tenant library 303 includes multiple tenant libraries, such as A tenant library, B tenant library, C tenant library, etc. Each tenant library can store the data required for the same product of the same insurance company, or can store multiple products of the same insurance company. data required for the product. For example, tenant database 303 may include a city health insurance tenant database.

It can be understood that the structural diagram shown in the above server 200b is only a schematic. In some other embodiments, corresponding modules can be added or deleted on this basis, and the specific structure is not required here. For example, it may also include a user management module, a user configuration module, a policy management module, etc. Each sub-database of the database included in the above-mentioned database 300 is only an example. In other embodiments, corresponding sub-databases can also be added or reduced on this basis, and the specific structure is not required here.

In order to better understand the interaction process between the interception matching module 203 and each sub-database in the database 300 in the process of matching regional sub-database rules or tenant sub-database rules in the solution of this application. Taking the execution of insurance business as an example to generate a policy, the following describes the interaction process between each sub-module in the interception matching module 203 and each sub-database in the database 300. Figure 3 shows the specific interaction process, including the following steps:

S301: The data interception module 203a intercepts the request to generate a policy.

It can be understood that the requests to generate insurance policies intercepted by the data interception module 203a include information that can characterize insurance products, policyholders' information, insurable geographical area information, product sales channels, etc., which will not be described in detail here.

It is understandable that product information can include product code or name, and the geographical area information that can be insured can be different administrative regions, such as areas divided by provinces, cities, districts, and counties, or it can also be based on economic development level, resident status, etc. Geographic areas divided into customizable populations. Among them, product information and insurable cities can be identified by numbers, letters, etc. after being encrypted by the server 200a. The specific identification method is not specified.

For example, the data interception module 203a intercepts a request to generate a city medical insurance policy. The request includes information that can characterize the city's medical insurance product, policyholder information, and insurable city information.

S302: The data interception module 203a sends a policy generation request to the regional rule matching module 203b.

For example, the data interception module 203a sends a request to generate a city medical insurance policy to the regional rule matching module 203b.

S303: The regional rule matching module 203b obtains product information and geographical area information according to the request data.

For example, the regional rule matching module 203b obtains the code of the city medical insurance product as 01 and the identifier of the insurable city Anyang as AY based on the obtained request to generate a city medical insurance policy.

S304: The regional rule matching module 203b sends a request to obtain the specific regional database information corresponding to the product to the product management database 301.

It can be understood that in some embodiments, the regional rule matching module 203b may be configured to match regional rules through a specific domain language, that is, a consensus language.

For example, rule {rule name = 'regional sub-library rule'

Get data through {get data in product area library}}

It can be understood that the above-mentioned matching with regional rule libraries is just an example, and more implementation methods may be included in some other embodiments.

It is understandable that in the process of matching regional database rules, specific regional database information needs to be obtained. The regional rule matching module 203b sends a request to obtain the specific regional database information corresponding to the product to the product management database 301 based on the obtained product information and geographical area information. The request may include obtaining the name, code or path of the product regional database corresponding to the insurance product. Address and other information.

For example, the regional rule matching module 203b sends the city medical insurance product code 01 to the product management library 301, the insurable city Anyang is identified as AY, and the product area corresponding to the product in the product management library 301 Library name, code or path address.

S305: Whether the product management database 301 can match the regional database information. If yes, proceed to step 314; if not, proceed to step 306.

In some embodiments, the product management database 301 searches in the database based on the product information and geographical area information obtained in the request, and checks whether there is regional database information corresponding to the product and geographical area information in the database. If yes, proceed to step 314 to obtain the specific regional database information corresponding to the product; if not, proceed to step 306 to return a regional branch database rule matching failure message.

For example, the product management database 301 checks whether there is a regional database corresponding to the insurance product code 01 and the insurable city Anyang AY in the database based on the city medical insurance product code 01 and the insurable city Anyang AY obtained in the request. If yes, proceed to step 314 to obtain the specific regional library name, code or path address corresponding to the product; if not, proceed to step 306 to return a regional sub-library matching failure message.

S306: The product management library 301 sends a message that there is no matching regional library information to the regional rule matching module 203b.

In some embodiments, if there is no corresponding regional library information in the product management library 301, a message that there is no matching regional library information is sent to the regional rule matching module 203b.

For example, the product management database 301 does not match the regional database name, code or path address corresponding to the product code 01 and the insurable city Anyang City AY in the database, and sends a message that there is no matching regional database information to the regional rule matching module 203b. .

S307: The regional rule matching module 203b sends a request to generate a policy to the organizational structure interception module 203c.

In some embodiments, the regional rule matching module 203b receives the message sent by the product management library 301 that there is no matching regional library information, determines that the matching of regional sub-library rules fails, and then sends a request to generate a policy to the organizational structure interception module 203c.

For example, the regional rule matching module 203b receives the message sent by the product management library 301 that there is no matching regional library information, determines that the matching of regional sub-database rules fails, and sends a request to generate a city medical insurance policy to the organizational structure interception module 203c.

S308: The organizational structure interception module 203c sends a request to generate a policy to the tenant rule matching module 203d, where the request includes tenant information.

In some embodiments, after the organizational structure interception module 203c obtains the request to generate a policy sent by the regional rule matching module 203b, it obtains the tenant information in the request data and sends the tenant information to the tenant rule matching module 203d. Among them, the tenant information can include the tenant name or code, etc., and the representation method can be numbers, letters, or other characters, etc., and there is no specific limit here. The tenant's name and code may be the name or code of the insurance company corresponding to the insurance product, etc.

For example, after the organizational structure interception module 203c obtains the request to generate a city medical insurance policy sent by the regional rule matching module 203b, it obtains the city's medical insurance tenant information based on the request data, and sends the medical insurance tenant information to the tenant rule matching module 203d. Among them, the tenant name corresponding to the urban medical insurance product tenant database can be HMB tenant.

S309: The tenant rule matching module 203d obtains a request to generate a policy.

It can be understood that the tenant rule matching module 203d obtains the request to generate a policy sent by the organizational structure interception module 203c.

For example, the tenant rule matching module 203d obtains the generated city medical insurance sent by the organizational structure interception module 203c. Policy Request.

S310: The tenant rule matching module 203d sends a request to the tenant library 303 to obtain the data required to generate the policy in the corresponding tenant library.

It can be understood that in some embodiments, the tenant rule matching module 203d may specify matching with tenant sub-library rules through a specific domain language, that is, a consensus language.

For example, rule {rule name = 'tenant sub-database rule'

Get data in tenant library through {}}

It can be understood that the above-mentioned sharding rules with tenants are only an example, and more implementation methods may be included in some other embodiments.

It can be understood that the tenant rule matching module 203d sends a request to the tenant library 303 to obtain the data required to generate the policy in the corresponding tenant library according to the tenant information in the request.

For example, the tenant rule matching module 203d sends a request to the tenant library 303 to obtain the data required to generate a city medical insurance policy in the HMB tenant library according to the city medical insurance tenant information in the request.

S311: The tenant database 303 obtains the data required to generate the policy.

In some embodiments, the tenant database 303 searches the corresponding tenant database for data required to generate a policy based on the acquired tenant information. It can be understood that the data required to generate the policy may include the basic elements of the policy and the logical data to generate the policy.

For example, the tenant database 303 searches the HMB tenant database for data required to generate a city medical insurance policy based on the tenant information.

S312: The tenant database 303 sends the data required to generate a policy to the tenant rule matching module 203d.

In some embodiments, after the tenant library 303 searches the corresponding tenant library for the data required to generate the policy, it sends the obtained data to the tenant rule matching module 203d.

For example, after the tenant database 303 searches the HMB tenant database for data required to generate a city medical insurance policy, it sends the acquired data to the tenant rule matching module 203d.

S313: The tenant rule matching module 203d determines that the tenant sub-database rule is successfully matched.

In some embodiments, after obtaining the data, the tenant rule matching module 203d determines that the tenant sub-database rule is successfully matched.

S314: The product management database 301 obtains specific regional database information corresponding to the product.

In some embodiments, the product management library 301 searches the database for corresponding regional library information based on product information and geographical area information. It can be understood that the corresponding regional library information may include the name, code or path address of the product regional library corresponding to the insurance product and geographical area information. The specific representation method may be numbers, letters, etc., which are not specifically limited here.

For example, the product management database 301 searches for the city medical product code 01 in the database, the insurable city Anyang city identifier is AY, and the corresponding product area database name in the product management database 301 is Anyang database.

S315: The product management library 301 sends the specific regional library information corresponding to the product to the regional rule matching module 203b.

For example, the product management database 301 sends the urban medical insurance product corresponding to the regional database where policy data can be obtained and generated to the regional rule matching module 203b. The regional database is the Anyang database.

S316: The regional rule matching module 203b sends a request to the product regional database 302 to obtain the product configuration rules in the corresponding product regional database, and obtain the data required to generate the policy according to the product configuration rules.

In some embodiments, after obtaining the regional library information corresponding to the insurance product, the regional rule matching module 203b sends it to the product regional library 302 to obtain the product configuration rules in the corresponding product regional library, and obtains the requirements for executing the policy generation according to the product configuration rules. Data requests. Among them, one product area library may include product configuration rules corresponding to multiple different insurance companies; specifically, multiple product configuration rules stipulated by one insurance company or one product configuration rule stipulated by one insurance company or multiple product configuration rules stipulated by multiple insurance companies. A product configuration rule, etc., there are no restrictions on specific circumstances.

For example, after the regional rule matching module 203b obtains the product regional library corresponding to the urban medical insurance product as the Anyang library, it sends it to the product regional library 302 through the regional library connection string. In the Anyang library, the urban medical insurance product configuration rules are obtained and based on The product configuration rule obtains a request to perform the data required to generate a city health insurance policy.

S317: The product area database 302 obtains product configuration rules, and obtains data required to generate a policy according to the product configuration rules.

In some embodiments, the product area library 302 searches in the corresponding area library according to the request, obtains product configuration rules, and obtains data required to generate a policy according to the product configuration rules.

For example, the product area database 302 searches the Anyang database according to the area database connection string in the request, obtains the urban medical insurance product configuration rules, and obtains the data required to generate the urban medical insurance policy according to the product configuration rules.

S318: The product area database 302 sends the obtained product configuration rules to the area rule matching module 203b, as well as the data corresponding to the product configuration rules required to execute the policy generation.

In some embodiments, after acquiring the product configuration rules and generating the data required for the insurance policy according to the execution corresponding to the product configuration rules, the product regional database 302 sends the acquired product configuration rules and the corresponding product configuration rules to the regional rule matching module 203b. The corresponding execution generates the data required for the policy.

For example, after acquiring the urban medical insurance product configuration rules and the data required to generate urban medical insurance policies according to the product configuration rules, the product regional database 302 sends the acquired urban medical insurance product configuration rules to the regional rule matching module 203b, and Data required to generate urban medical insurance policies corresponding to product configuration rules.

S319: The regional rule matching module 203b determines that the regional sub-library rules are successfully matched.

In some embodiments, after obtaining the data, the regional rule matching module 203b determines that the regional sub-database rules are successfully matched.

For example, after obtaining relevant data for generating urban medical insurance policies, the regional rule matching module 203b determines that the regional sub-database rules are successfully matched.

It can be understood that the execution order of the above steps S301 to S319 is just an example. In other embodiments, other execution orders can also be adopted, and some steps can also be split or combined, which is not limited here.

It is understandable that in addition to generating insurance policies through the above-mentioned insurance business processing, it can also be used for insurance business such as reviewing insurance documents, querying insurance business status, online claims settlement, surrender, etc. The specific insurance business processed is not required here.

According to the scenario shown in Figure 1 above, Figure 4 shows a flow chart of using the server 200b as the execution subject to execute the multi-tenant data sharding method in the embodiment of the present application. The specific process includes the following steps:

S401: Obtain a request to perform relevant insurance business.

In some embodiments, the user terminal 100 sends a request to perform relevant insurance services to the server 200a; after receiving the request sent by the user terminal 100, the server 200a encrypts the request data and converts the encrypted request Sent to the server 200b; the server 200b obtains the request to execute the relevant insurance business. It can be understood that executing relevant insurance business may include generating insurance policies, calculating premiums, querying the current insurance business status, reviewing insurance documents, surrendering insurance, and online claims settlement, etc.

For example, the user terminal 100 sends a request to generate a city medical insurance policy to the server 200a; after receiving the request sent by the user through the user terminal 100, the server 200a encrypts the request data and sends the encrypted request to the server 200b; the server 200b Gets a request to execute a city health insurance policy.

It can be understood that in some implementations, as shown in the device diagram of FIG. 2A , the data receiving module 201 obtains a request for executing relevant insurance services sent by the server 200a. The data forwarding module 202 filters the data in the request.

S402: Based on the product information and geographical area information in the request data, determine whether it successfully matches the regional sub-library rules. If the judgment result is yes, go to step S404; if the judgment result is no, go to step S403.

In some embodiments, after the server 200b obtains the request to execute the relevant insurance business, it obtains the product information and geographical area information data in the request data, and matches the insurance product information and specific geographical area information in the database 300 to determine whether it contains the The product area library corresponding to the specific location area. If there is a corresponding product area library, the product configuration rules are searched in the corresponding product area library, and the data required to execute the policy generation is obtained according to the product configuration rules, and the regional classification is determined. If the library rule is successfully matched, step S404 is entered; if there is no regional library corresponding to the specific location area, it is determined that the match with the regional sub-library rule fails, and step S403 is entered.

For example, after the server 200b obtains and executes a request to generate a city medical insurance policy, it obtains the city medical insurance product information and insurable city information data in the request data, and searches in the database 300 based on the insurance product information and insurable cities to see whether there is a The product and the regional library corresponding to the insurable city. If the corresponding regional library exists, the urban medical insurance product configuration rules are searched in the corresponding regional library, and the data required to execute and generate the policy are obtained according to the urban medical insurance product configuration rules. , it is determined that the matching with the regional sub-library rules is successful; if there is no regional database corresponding to the product and insurable city, it is determined that the matching with the regional sub-library rules fails.

It can be understood that in some implementations, as shown in the module diagrams of Figures 2A and 2B, the data forwarding module 202 filters the obtained request data and sends it to the interception matching module 203, and the regional rules in the interception matching module 203 match. Module 203b determines whether the match with the regional sub-database rules is successful based on the product information and geographical area information in the request data. If the judgment result is yes, go to step S404; if the judgment result is no, go to step S403.

S403: Match the tenant information in the request data with the tenant sharding rules.

In some embodiments, the server 200b determines that the match with the regional sharding rules fails based on the product information and geographical area information in the request data, and then matches the tenant sharding rules based on the tenant information in the request data, that is, based on the tenant information in the request data, the server 200b The tenant information is searched and matched in each tenant database to obtain the data required to perform relevant insurance business.

For example, based on the city medical insurance product information and insurable cities in the request data, the server 200b determines that the match with the regional sub-database rules fails, and then matches the tenant sub-database rules based on the medical insurance tenant information in the request data, that is, based on the request data The tenant information in each tenant database is matched and searched to obtain the data required to execute the city's medical insurance policy and the logical data for executing the business.

It can be understood that in some implementations, as shown in the structure diagram of Figure 2B, the organizational structure interception module 203c in the interception matching module 203 obtains the tenant information in the request data, and the tenant rule matching module 203b matches the tenant based on the tenant information. The sharding rules match.

S404: Execute the insurance business logic based on the successfully matched sub-database rules.

In some embodiments, if the successfully matched sub-database rule is a regional sub-database rule, the insurance business logic is executed based on the data required to execute the insurance business obtained by the regional sub-database rule; if the successfully matched sub-database rule is a tenant sub-database rule, According to the database rules, the insurance business logic is executed based on the data required to execute the insurance business obtained from the tenant sub-database rules. Among them, the data required to execute the insurance business includes at least one of the basic element content data on the policy, logical data for generating the policy, querying the status of the insurance business, or executing the review of the insurance document.

For example, if the successfully matched sharding rule is a regional sharding rule, the business logic for generating a policy will be executed based on the data required to generate a city medical insurance policy obtained from the regional sharding rule; if the successfully matched sharding rule is a tenant sharding rule, Database rules, then execute the business logic of generating the policy based on the data required to generate urban medical insurance policies obtained from the tenant sub-database rules.

It can be understood that in some implementations, as shown in the structure diagram of FIG. 2A , the execution business logic module 204 executes insurance business logic.

It can be understood that the execution order of the above-mentioned steps S401 to S404 is just an example. In other embodiments, other execution orders can also be adopted, and some steps can also be split or combined, which is not limited here.

In order to facilitate understanding of the technical solutions implemented in this application, the hardware structure of the server 200b is introduced below.

Further, FIG. 5 shows a schematic structural diagram of a server 200b according to some embodiments of the present application. As shown in Figure 5, the server 200b used to execute the multi-tenant data sharding method shown in Figure 4 provided by this application may include one or more processors 201, system memory 202, non-volatile memory (Non -Volatile Memory (NVM) 203, input/output (I/O) device 204, communication interface 205 and for coupling the processor 201, system memory 202, non-volatile memory 203, communication interface 204 and input/output ( System control logic 206 for I/O device 205.

Wherein: the processor 201 may include one or more single-core or multi-core processors. In some embodiments, processor 201 may include any combination of general-purpose processors and special-purpose processors (eg, graphics processors, applications processors, baseband processors, etc.). In some embodiments, the processor 201 can be configured to match the regional sharding rules based on the product information and geographical area information in the request data. If the matching fails, match the tenant sharding rules based on the tenant information in the request data. , execute the insurance business logic based on the matching results of the sub-library rules.

The system memory 202 is a volatile memory, such as random access memory (Random-Access Memory, RAM), double data rate synchronous dynamic random access memory (Double Data Rate Synchronous Dynamic Random Access Memory, DDR SDRAM), etc. The system memory is used to temporarily store data and/or instructions. For example, in some embodiments, the system memory 202 can be used to store the above-mentioned executable program for implementing the multi-tenant data sharding method.

Non-volatile memory 203 may include one or more tangible, non-transitory computer-readable media for storing data and/or instructions. In some embodiments, the non-volatile memory 203 may include any suitable non-volatile memory such as flash memory and/or any suitable non-volatile storage device, such as a hard disk drive (Hard Disk Drive, HDD), optical disk ( Compact Disc (CD), Digital Versatile Disc (DVD), Solid-State Drive (SSD), etc. In some embodiments, the non-volatile memory 203 may also be a removable storage medium, such as a Secure Digital (Secure Digital, SD) memory card, etc.

In particular, system memory 202 and non-volatile memory 203 may include temporary and permanent copies of instructions 207, respectively. Instructions 207 may include, when executed by at least one of the processors 201, causing the server 200 to implement the present application. Please provide program instructions for the multi-tenant data sharding method in each embodiment.

Input/output (I/O) device 204 may include a user interface that enables a user to interact with server 200b. For example, in some embodiments, the input/output (I/O) device 204 may include an output device such as a display for displaying the software system used in the server 200b, and may also include an input device such as a keyboard, mouse, and touch screen. The maintenance personnel of the server 200b can interact with the server 200b through the user interface and input devices such as keyboard, mouse, and touch screen.

Communication interface 205 may include a transceiver for providing a wired or wireless communication interface for server 200b to communicate with any other suitable device over one or more networks. In some embodiments, the communication interface 205 can be integrated with other components of the server 200b. For example, the communication interface 205 can be integrated with the processor 201. In some embodiments, server 200b may communicate with other devices through communication interface 205.

System control logic 206 may include any suitable interface controller to provide any suitable interface to other modules of server 200b. For example, in some embodiments, system control logic 206 may include one or more memory controllers to provide an interface to system memory 202 and non-volatile memory 203 .

In some embodiments, at least one of the processors 201 may be packaged with logic for one or more controllers of the system control logic 206 to form a system in package (SiP). In other embodiments, at least one of the processors 201 may also be integrated on the same chip with the logic of one or more controllers for the system control logic 206 to form a system-on-chip (SoC). ).

It can be understood that the server 200b can be any electronic device capable of executing the multi-tenant data sharding method provided by this application, including but not limited to computers, servers, tablets, handheld computers, etc., which are not limited in the embodiments of this application.

It can be understood that the structure of the server 200b shown in the embodiment of this application does not constitute a specific limitation on the server 200b. In other embodiments of the present application, the server 200b may include more or less components than shown in the figures, or some components may be combined, or some components may be separated, or may be arranged differently. The components illustrated may be implemented in hardware, software, or a combination of software and hardware.

Various embodiments of the mechanisms disclosed in this application may be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of the present application may be implemented as a computer program or program code executing on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and/or storage elements) , at least one input device and at least one output device.

Program code may be applied to input instructions to perform the functions described herein and to generate output information. Output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any processor having a processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor. system.

Program code may be implemented in a high-level procedural language or an object-oriented programming language to communicate with the processing system. When necessary, assembly language or machine language can also be used to implement program code. In fact, the mechanisms described in this application are not limited to the scope of any particular programming language. In either case, the language may be a compiled or interpreted language.

In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried on or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be operated by one or more processors Read and execute. For example, Instructions may be distributed over a network or through other computer-readable media. Thus, machine-readable media may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including, but not limited to, floppy disks, optical disks, optical disks, read-only memories (CD-ROMs), magnetic Optical disc, Read Only Memory (ROM), Random Access Memory (RAM), Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Memory Read memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), magnetic or optical card, flash memory, or used to use the Internet to transmit information through electrical, optical, acoustic or other forms of propagation signals (for example, carrier waves, infrared signals, digital signals etc.) tangible machine-readable storage. Thus, machine-readable media includes any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, computer).

In the drawings, some structural or methodological features may be shown in specific arrangements and/or orders. However, it should be understood that such specific arrangement and/or ordering may not be required. Rather, in some embodiments, the features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of structural or methodological features in a particular figure is not meant to imply that such features are required in all embodiments, and in some embodiments these features may not be included or may be combined with other features.

It should be noted that each unit/module mentioned in each device embodiment of this application is a logical unit/module. Physically, a logical unit/module can be a physical unit/module, or it can be a physical unit/module. Part of the module can also be implemented as a combination of multiple physical units/modules. The physical implementation of these logical units/modules is not the most important. The combination of functions implemented by these logical units/modules is what solves the problem of this application. Key technical issues raised. In addition, in order to highlight the innovative part of this application, the above-mentioned equipment embodiments of this application do not introduce units/modules that are not closely related to solving the technical problems raised by this application. This does not mean that the above-mentioned equipment embodiments do not exist. Other units/modules.

It should be noted that in the examples and descriptions of this patent, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply There is no such actual relationship or sequence between these entities or operations. Furthermore, the terms "comprises," "comprises," or any other variations thereof are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that includes a list of elements includes not only those elements, but also those not expressly listed other elements, or elements inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a" does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element.

Although the present application has been illustrated and described with reference to certain preferred embodiments thereof, it will be understood by those of ordinary skill in the art that various changes may be made in form and detail without departing from the present invention. The spirit and scope of the application.

Claims (15)

1. A multi-tenant data sharding method for a system including a server and a storage device as a database, wherein the server is configured with an interception matching module, and the interception matching module includes a data interception module, a regional rule matching module, The organizational structure interception module and the tenant rule matching module are characterized in that the method includes:

   The data interception module obtains a request to execute insurance business;

   The regional rule matching module matches the request with the regional library information of the product management library in the database based on the product information and geographical area information in the request passed by the data interception module, where the product corresponds to the A plurality of product area libraries in the database, the product area library includes product configuration rules corresponding to insurance business implementers;

   In the case of matching the regional library information, the regional rule matching module obtains the product configuration rules in the product regional library, and obtains the data required to execute the insurance business according to the product configuration rules;

   If the regional library information is not matched, the organizational structure interception module obtains the tenant information in the request; and the tenant rule matching module, based on the tenant information passed by the organizational structure interception module, The data required for executing insurance business is obtained from the tenant library in the database.
2. The method according to claim 1, characterized in that the product management library in the database can be a lightweight directory access protocol, wherein the lightweight directory access protocol includes a product management library corresponding to the product area library in the database. Product information, geographical area information, and the name, code or path address of each product area library.
3. The method according to claim 2, wherein matching the request with regional library information of the product management library in the database includes:

   Search the product management library based on the product information and the geographical area information to determine whether the specific product area library name, code or path address corresponding to the product information and geographical area information is found.
4. The method according to claim 1 or 3, characterized in that the regional rule matching module obtains the product configuration rules from the product regional library in the database, and obtains the requirements for executing the insurance business according to the product configuration rules. The required data includes,

   The regional rule matching module obtains the product configuration rules in the specific regional library corresponding to the product regional library in the database through the regional library connection string, and obtains the data required to execute the insurance business according to the product configuration rules. .
5. The method according to claim 1, characterized in that the product area library includes product configuration rules corresponding to insurance business implementers:

   The product area library includes one product configuration rule specified by the insurance business implementer or multiple product configuration rules specified by multiple insurance business implementers.
6. The method of claim 1, wherein the product information includes product name or product code.
7. The method according to claim 6, wherein the geographical area information includes an administrative area to which the product is divided or a custom area to which the product is divided according to a customization.
8. The method according to claim 7, characterized in that the regional library information includes product regional library name, code number or path address.
9. The method according to claim 7 or 8, characterized in that the data required for executing insurance business includes:

   At least one of the basic element content data on the policy, logical data for generating the policy, querying the status of the insurance business, or reviewing the insurance document.
10. The method according to claim 1, characterized in that the database includes:

    The product management library, the product area library and the tenant library.
11. A multi-tenant data sharding device, characterized by:

    Data receiving module, used to receive data;

    Data forwarding module, used to forward data;

    The interception matching module is used to intercept data and match the intercepted data with regional sharding rules or tenant sharding rules;

    Execution business logic module, used to execute business logic;

    And, the interception matching module includes,

    A data interception module, used to obtain first data, where the first data includes product information and geographical area information;

    A regional rule matching module, used to match regional sub-library rules based on the product information and geographical area information;

    The organizational structure interception module is used to obtain second data, where the second data includes tenant information;

    A tenant rule matching module is used to match tenant sharding rules based on the tenant information.
12. A computer-readable storage medium, characterized in that instructions are stored on the computer-readable storage medium, and when the instructions are executed on an electronic device, the electronic device causes the electronic device to execute any one of claims 1-10. Multi-tenant data sharding method.
13. A chip device, characterized in that the chip device includes:

    Communication interfaces for inputting and/or outputting information;

    A processor, configured to execute a computer executable program, so that the electronic device installed with the chip device executes the multi-tenant data sharding method according to any one of claims 1-10.
14. A computer program product, characterized in that the computer program product includes instructions, and when the instructions are executed, the multi-tenant data sharding method according to any one of claims 1-10 is implemented.
15. An electronic device, characterized by including:

    memory for storing instructions for execution by one or more processors of the electronic device, and

    A processor, when the instructions are executed by one or more processors of the electronic device, the processor is configured to execute instructions stored in the memory to implement any one of claims 1-10 Multi-tenant data sharding method.