Sub-table data access method and system based on dynamic table name processing and application

Abstract

The invention provides a sub-table data access method, system and application based on dynamic table name processing. The method comprises the following steps: performing registration association on a sub-table factor of a service table and a corresponding processor; after a data access request is initiated, the service implementation layer transmits the request to the table name processing layer, analyzes table division request parameters from the data access request, and transmits the table division parameters to the table division processor; calculating a table division factor through a table division processor; the table name processing layer generates a sub-table name according to the sub-table factor and the main name of the service table; generating SQL statements according to the table names of the sub-tables, and executing the SQL statements by a database to obtain a query result; and returning to the client to complete the data access process. According to the scheme, decoupling of the sub-table rules and the service codes can be achieved, sub-table data access logic is greatly simplified, sub-table operation is more standard and ordered by constructing a unified framework, the convenience of change of the sub-table rules is greatly improved, and efficient, flexible and stable support is brought to data management and application.

Description

Technical Field

[0001] This application relates to the field of data management. Specifically, it relates to a method, system, and application for accessing sharded data based on dynamic table name processing. Background Art

[0002] In today's digital age, the amount of data has shown an explosive growth, and the database sharding technology has become a key means to optimize database performance and improve data management efficiency. With the increase in business complexity, the traditional database sharding methods have gradually exposed many problems, posing challenges to system development, maintenance, and performance.

[0003] In the existing database sharding implementations, the sharding rules are often directly written in the business code. For example, hard-coding the table name suffix in the SQL statement, this way tightly binds the sharding rules with the business logic. Once the sharding rules need to be modified, a large amount of business code must be adjusted, which not only increases the workload of developers but also easily introduces new errors, resulting in high system maintenance costs. Moreover, this coupling relationship also limits the flexibility of the sharding rules and is difficult to quickly adapt to the changes and developments of the business.

[0004] When the data volume is large and the sharding situation is complex, the sharded data access logic becomes extremely cumbersome. Developers need to manually handle operations such as calculating sharding factors, concatenating table names, and routing data. These operations are not only error-prone but also very difficult during the debugging process.

[0005] In addition, many systems lack unified framework support when performing sharding. Each project or even each module may adopt different sharding methods, resulting in serious duplication of labor during the development process. Developers need to re-design and implement sharding logic for each sharding scenario, wasting a lot of time and effort.

[0006] In summary, the existing database sharding technologies have many defects and cannot meet the growing business needs and complex application scenarios. Therefore, a new data access method is needed to solve these problems. Summary of the Invention

[0007] Based on the problems existing in the prior art, this application provides a method, system, and application for accessing sharded data based on dynamic table name processing. The specific solutions are as follows:

[0008] In the first part, this application proposes a method for accessing sharded data based on dynamic table name processing, including:

[0009] Call the processor factory to register and associate each sharding factor of the business table with the corresponding processor;

[0010] After the client initiates a data access request to the preset service implementation layer, the data access process is triggered;

[0011] The data access request is passed to the preset table name processing layer through the service implementation layer. The table name processing layer parses the sub-table request parameters from the data access request and passes the sub-table parameters to a pre-determined sub-table processor;

[0012] The sub-table processor calculates a sub-table factor according to the sub-table request parameters and preset sub-table rules, and returns the sub-table factor to the table name processing layer;

[0013] The table name processing layer generates a sub-table name according to the sub-table factor and the main name of the business table, and returns the sub-table name to the service implementation layer;

[0014] A corresponding SQL statement is generated according to the sub-table name and passed to the preset database. The database executes the SQL statement to obtain a query result and returns it to the service implementation layer;

[0015] The service implementation layer returns the query result to the client to complete the data access process.

[0016] In some specific embodiments, the sub-table processor includes a single-factor processor or a multi-factor processor;

[0017] The single-factor processor is used to process a single sub-table factor, and the multi-factor processor is used to process multiple sub-table factors.

[0018] In some specific embodiments, the process of determining the sub-table processor specifically includes:

[0019] Parse the type of sub-table factor involved in the sub-table request parameters;

[0020] If only a single type of sub-table factor is involved in the sub-table request parameters, select the single-factor processor as the sub-table processor; if the sub-table request parameters involve multiple types of sub-table factors, select the multi-factor processor as the sub-table processor.

[0021] In some specific embodiments, business data and business requirements for the business data are determined in advance;

[0022] When the business data is sub-divided into each business table, if the business requirements require sub-dividing the business data by integrating multiple sub-table factors, select the multi-factor processor as the sub-table processor; if the business requirements only sub-divide according to a single sub-table factor, select the single-factor processor as the sub-table processor.

[0023] In some specific embodiments, it further includes:

[0024] After the data access process is completed, the cache data including the partitioning factors generated during the access process is cleaned up by the partitioning table processor.

[0025] In some specific embodiments, the multi-factor processor determines the primary sub-table parameter and the secondary sub-table parameter of the sub-table request parameter according to a preset rule, and first processes the primary sub-table parameter to obtain the primary sub-table factor, and then processes the secondary sub-table parameter to obtain the secondary sub-table factor;

[0026] The table name processing layer generates table sub-parameters by integrating the main table sub-factor, the secondary table sub-factor and the main name of the business table.

[0027] In the second part, this application proposes a sub-table data access system based on dynamic table name processing, including

[0028] An association unit, used to call the processor factory to register and associate each sub-table factor of the business table with the corresponding processor;

[0029] The access unit is used to trigger the data access process when the client initiates a data access request to the preset service implementation layer;

[0030] A parsing unit, used to transfer the data access request to a preset table name processing layer through the service implementation layer, and the table name processing layer parses the sub-table request parameters from the data access request and transfers the sub-table parameters to a predetermined sub-table processor;

[0031] A factor calculation unit, configured to calculate a table partitioning factor according to the table partitioning request parameter and a preset table partitioning rule through the table partitioning processor, and return the table partitioning factor to the table name processing layer;

[0032] A table name calculation unit, used to generate a sub-table name according to the sub-table factor and the main name of the business table through the table name processing layer, and return the sub-table name to the service implementation layer;

[0033] A query unit, used for generating a corresponding SQL statement according to the sub-table name and transmitting the statement to a preset database, wherein the database executes the SQL statement to obtain the query result and returns the result to the service implementation layer;

[0034] The output unit is used to return the query result to the client through the service implementation layer to complete the data access process.

[0035] In some specific embodiments, the table partitioning processor includes a single factor processor or a multi-factor processor;

[0036] The single factor processor is used to process a single table factor, and the multi-factor processor is used to process multiple table factors.

[0037] In the third part, the present application proposes a computer device, which includes:

[0038] One or more processors;

[0039] A memory for storing one or more programs;

[0040] When the one or more programs are executed by the one or more processors, the one or more processors implement the sharded data access method based on dynamic table names described in any one of the first part.

[0041] In the fourth part, the present application proposes a computer program product, including executable instructions, which when executed by a processor, implement the sharded data access method based on dynamic table names described in any one of the first part.

[0042] Advantageous effects: The present application proposes a sharded data access method, system and application based on dynamic table name processing, effectively solving the problems existing in the prior art, such as the coupling of sharding rules and business code, complex sharded data access logic, lack of a unified framework, and difficulty in changing sharding rules. The sharding rules are decoupled from the business code, greatly reducing the maintenance cost and improving the scalability of the system. It supports diversified sharding strategies and can easily handle both simple single-factor sharding scenarios and complex multi-factor sharding scenarios, ensuring that the system can adapt to the changes and developments of different business scenarios and improving the versatility and applicability of the system. The entire sharded data access process has a unified process and specification, enabling developers to avoid designing complex data access logics separately for each sharding scenario. Developers only need to develop according to the established interface specifications, reducing the workload of repeated development and improving the development efficiency. When business requirements change, developers can quickly reconfigure the association relationship between sharding factors and processors in the processor factory to achieve dynamic adjustment of sharding rules. This configurable design avoids the problem of large-scale code modification required for changing sharding rules in the traditional way, reduces the time and labor costs required for changes, improves the response speed and flexibility of the system, and enables the system to better adapt to the constantly changing business environment.

[0043] To make the above objects, features, and advantages of the present application more obvious and understandable, the following specifically gives preferred embodiments and cooperates with the attached drawings for detailed description as follows. Description of the Drawings

[0044] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0045] Figure 1 It is a flowchart of the method for accessing data in a table partition of the present application;

[0046] Figure 2 It is a schematic diagram of the principle of the sub-table data access method of the present application;

[0047] Figure 3 It is a schematic diagram of the module of the table data access system of this application.

[0048] Figure numerals: 1 - association unit; 2 - access unit; 3 - parsing unit; 4 - factor calculation unit; 5 - table name calculation unit; 6 - query unit; 7 - output unit. DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0050] This application proposes a method for accessing sub-table data based on dynamic table name processing, which effectively solves the problems existing in the prior art, such as coupling of sub-table rules with business codes, complex logic of sub-table data access, lack of a unified framework, and difficulty in changing sub-table rules. Figure 1 The principle is shown in the attached Figure 2 The specific plan is as follows:

[0051] A method for accessing data from a partitioned table based on dynamic table name processing includes the following steps:

[0052] 101. Call the processor factory to register and associate each sub-table factor of the business table with the corresponding processor;

[0053] 102. When the client initiates a data access request to the preset service implementation layer, the data access process is triggered;

[0054] 103. Pass the data access request to the preset table name processing layer through the service implementation layer. The table name processing layer parses the sub-table request parameters from the data access request and passes the sub-table parameters to the pre-determined sub-table processor;

[0055] 104. The sub-table processor calculates the sub-table factor according to the sub-table request parameters and the preset sub-table rule, and returns the sub-table factor to the table name processing layer;

[0056] 105. The table name processing layer generates the sub-table name according to the sub-table factor and the main name of the business table, and returns the sub-table name to the service implementation layer;

[0057] 106. Generate the corresponding SQL statement according to the sub-table name and pass it to the preset database. The database executes the SQL statement to obtain the query result and returns it to the service implementation layer;

[0058] 107. The service implementation layer returns the query result to the client to complete the data access process.

[0059] The sub-table data access method based on dynamic table name processing in this application shows significant technical effects in aspects such as the relationship between the sub-table rule and the business code, the flexibility of the sub-table strategy, the development cost, and the convenience of adjusting the sub-table rule.

[0060] In step 101, the processor factory is a component that manages the sub-table processor. The sub-table factor is the key factor determining data sub-table, such as cpid and songid in the song table. This step establishes the mapping relationship between the sub-table factor of the business table and the corresponding processor (single-factor or multi-factor processor) through the processor factory. Through the registration and association of the sub-table factor and the processor by the processor factory, the decoupling of the sub-table rule and the business code is realized, and the maintenance difficulty is reduced. The business code does not need to pay attention to the sub-table details, and the sub-table logic is concentrated in the processor. When the sub-table rule changes, such as changing from single-factor sub-table to multi-factor sub-table, only the registration and association need to be adjusted in the processor factory, and there is no need to modify the business code, which is convenient for maintenance and extension.

[0061] Suppose in a music platform system, the expected data volume of the song table is huge and needs to be stored in sub-tables. Initially, the system uses single-factor sub-tabling by songid, registers the song table and the corresponding single-factor processor (such as SongIdTableHandler) in the processor factory for association. The association information may be similar to Map<Class<?>, TableNameHandler>, where the key is the Java class corresponding to the song table and the value is an instance of SongIdTableHandler. Later, as the business develops, it is necessary to consider both cpid and songid for multi-factor sub-tabling. At this time, only need to re-register in the processor factory, associate the song table with the new multi-factor processor (such as CpSongTableHandler), and the part of the business code for querying songs does not need to be modified.

[0062] As the starting point of the entire data access process, step 102 initiates a series of subsequent operations. It provides a unified service entry for the client, enabling the client to be unaware of the complex sub-table data access details inside the system and only need to initiate requests according to the specified interface format, improving the usability and interactivity of the system.

[0063] The client is the end that initiates data requests, which can be the application interface used by users (such as a music APP) or the call interface of other systems. The preset service implementation layer is a component on the server side specifically used to process client requests. It receives the data access requests sent by the client, such as requests for querying specific song information. For example, in a music APP, when a user clicks to view the details of a certain song, the APP, as the client, sends a query request to the preset service implementation layer of the server, and the request contains the relevant identifiers (such as songid) of the song to be queried. After receiving this request, the service implementation layer starts to prepare the subsequent data processing process.

[0064] Step 103 realizes the preprocessing and distribution of request parameters. The table name processing layer centrally processes the complex sub-table parameter parsing work, ensuring that the sub-table processor receives the sorted and available sub-table parameters, enabling the sub-table processor to focus on calculating sub-table factors based on these parameters, improving the efficiency and accuracy of the entire sub-table data access process.

[0065] The table name processing layer is a module specifically responsible for processing operations related to sharded table names. It extracts the parameters for sharding from the received data access requests. For example, in the sharding of the song table, it may extract cpid and songid. The pre-determined sharding processor is determined based on the association relationships registered in the processor factory before, and is used to process these sharding parameters. For example, the service implementation layer passes a song query request with songid being 957 and cpid being 3 to the table name processing layer. The table name processing layer parses out the two sharding request parameters, songid and cpid, from the request. Since the song table has been registered and associated with the multi-factor processor in the processor factory before, the table name processing layer passes these two parameters to the multi-factor processor.

[0066] Step 104 calculates the sharding factors through an independent sharding processor, achieving the encapsulation and reuse of the sharding logic. Different sharding scenarios can use different sharding processors, and the sharding rules inside the processor are easy to modify and expand. For example, in the sharding of the song table, the multi-factor processor can process complex multi-dimensional sharding logic to meet the requirements of data storage and query in different business scenarios. The sharding processor calculates based on the received sharding request parameters (such as songid and cpid) and the pre-set sharding rules (for example, cpid is not modulo-calculated, and songid is modulo-calculated by 10) to obtain the sharding factors. The sharding factors are the key calculation results used to determine which specific sharded table the data is stored in. After the calculation is completed, the sharding processor returns these sharding factors to the table name processing layer.

[0067] For example, after TableHandler receives the parameters with songid being 957 and cpid being 3, according to the pre-set sharding rules, cpid is directly used as the main factor, and songid is modulo-calculated by 10, that is, 957 % 10 = 7. So the calculated sharding factors are 3 and 7, and these two sharding factors are returned to the table name processing layer.

[0068] Step 105 converts the sharding factors into specific sharded table names that can be used for database operations. This step ensures the accuracy and consistency of the generation of sharded table names, enabling subsequent database queries to accurately locate the sharded table storing the target data. The table name processing layer uses the received sharding factors (such as 3 and 7) and the main name of the business table (for example, the main name of the song table is tbl_song) to generate the actual sharded table name (such as tbl_song_3_7) according to a certain naming rule. After generating the table name, it is returned to the service implementation layer for subsequent database operations.

[0069] Step 106 implements the function of querying data from the sub-table. The efficient data retrieval capability of the database is utilized to accurately obtain the data requested by the client. By passing the SQL statement to the database for execution, the advantages of the database in data management and query are fully utilized, and the accuracy and efficiency of data query are guaranteed. According to the generated sub-table name (such as tbl_song_3_7) and the query conditions in the original data access request (such as querying the song information with songid 957 and cpid 3), the corresponding SQL statement is generated (such as select id, name, cpid from tbl_song_3_7 where cpid=3andid=957). The preset database is where the data is stored. It receives and executes this SQL statement, and then returns the query result to the service implementation layer.

[0070] For example, the service implementation layer generates the SQL statement selectid,name,cpid from tbl_song_3_7where cpid=3and id=957 according to the sub-table name tbl_song_3_7 and the query conditions, and sends it to the MySQL database. After the database executes the statement, it finds the data that meets the conditions from the tbl_song_3_7 table and returns the result (such as Song(id=957,name="某歌曲名",cpid=3)) to the service implementation layer.

[0071] Step 107 presents the final result of the data access to the user to meet the data needs of the client. The service implementation layer acts as a data transmission bridge between the client and the database, ensuring that the data is accurately transmitted to the client, improving the user experience, and completing the data service function of the system. After receiving the query results returned by the database, the service implementation layer encapsulates these results in a certain format and returns them to the client that initiated the request, thereby completing the closed-loop operation of the entire data access. After receiving the data, the client displays the detailed information of the song on the interface so that the user can view it.

[0072] In some specific embodiments, the sub - table processor includes a single - factor processor or a multi - factor processor; the single - factor processor is used to process a single sub - table factor, and the multi - factor processor is used to process multiple sub - table factors. There are two types of sub - table processors. These two types of processors are divided according to the different numbers of sub - table factors processed. In actual application scenarios, the complexity of data sub - tabling varies. By distinguishing these two types of processors, different sub - table requirements can be more flexibly met. This provides a clear basis for subsequently selecting an appropriate sub - table processor according to different business scenarios, enhancing the operability and adaptability of the technical solution. In actual applications, developers can quickly determine whether to use a single - factor processor or a multi - factor processor according to business requirements and data characteristics, improving development efficiency and reducing development costs.

[0073] The single - factor processor is mainly for scenarios where the sub - tabling operation can be completed by relying on only one sub - table factor. In a simple business scenario, assume a small music platform with a relatively small amount of song data. It only needs to sub - table and store data according to the song ID. At this time, a single - factor processor can be used, taking the song ID as the only sub - table factor. The single - factor processor distributes song data with different IDs to the corresponding sub - tables according to pre - set rules, such as taking the modulus of the song ID. Such a design makes the logic clear and the processing efficient when dealing with simple sub - tabling scenarios, avoiding complex multi - factor calculations and processing procedures.

[0074] When the sub - tabling operation needs to consider multiple factors comprehensively, a multi - factor processor is used. In a large - scale music platform, the amount of song data is huge and the business requirements are complex. To better manage the data, not only the song ID but also the content provider ID (cpid) needs to be considered for sub - tabling. The multi - factor processor can perform sub - tabling processing according to the relationship between multiple sub - table factors (such as cpid and songid) and pre - set complex rules. It processes these factors in a certain order, such as first processing the main factor cpid and then the secondary factor songid, and generates corresponding sub - table identifiers according to the calculation results of different factors, thereby determining the specific sub - table where the data should be stored. This type of processor is suitable for complex sub - tabling scenarios, can meet multi - dimensional sub - table requirements, and improve the refinement of data management and the effect of system performance optimization.

[0075] In some specific embodiments, the process of determining the sub - table processor specifically includes: analyzing the types of sub - table factors involved in the sub - table request parameters; if only a single type of sub - table factor is involved in the sub - table request parameters, select the single - factor processor as the sub - table processor; if multiple types of sub - table factors are involved in the sub - table request parameters, select the multi - factor processor as the sub - table processor.

[0076] After receiving a data access request, extract and identify the factor types for sub - table division from the request. For example, in the scenario of sub - table division of a song table, the request parameters may contain cpid (content provider ID) and songid (song ID), which are the sub - table factors. The parsing process is to clarify the existence and nature of these factors. When the parsing result shows that there is only one sub - table factor in the request, select a single - factor processor that specifically processes a single sub - table factor. For example, if the request is for data query based only on songid, then select a single - factor processor to handle this sub - table operation. If the request contains multiple different sub - table factors, such as both cpid and songid, then a multi - factor processor is needed to comprehensively process these factors. The multi - factor processor can perform complex sub - table calculations according to the relationships between different factors and preset rules.

[0077] In a simple sub - table scenario, using a single - factor processor can simplify the processing logic and improve processing efficiency. The single - factor processor focuses on processing a single factor, avoiding unnecessary complex calculations, making the sub - table operation more direct and efficient. For complex multi - dimensional sub - table requirements, the multi - factor processor can accurately determine the sub - table where the data should be stored based on multiple sub - table factors, meeting the refined requirements of the business for data management, and enhancing the performance of the system and the rationality of data storage.

[0078] In addition, the sub - table processor can also be selected from the perspectives of business requirements and business data. In some specific embodiments, the business data and the business requirements for the business data are determined in advance; when dividing the business data into each business table, if the business requirements need to divide the business data by integrating multiple sub - table factors, then select a multi - factor processor as the sub - table processor; if the business requirements only divide the table according to a single sub - table factor, then select a single - factor processor as the sub - table processor.

[0079] Before performing the sub - table operation, it is necessary to clarify the data content involved in the business and the specific requirements of the business for this data. For example, in a music platform, the business data includes song information, singer information, play records, etc., and the business requirements may include quickly querying songs of a specific content provider, counting the play volume of different singers, etc. This is a prerequisite for selecting an appropriate sub - table processor. Only by clearly understanding the business data and requirements can a reasonable sub - table strategy be formulated according to the actual situation and a matching sub - table processor be selected.

[0080] When the business requirements are relatively complex and multiple factors need to be considered simultaneously for data sharding, such as considering both cpid and songid to manage song data, a multi-factor processor should be selected. The multi-factor processor can handle the complex relationships between multiple sharding factors and achieve more accurate data sharding. Through the multi-factor processor, sharding factors can be flexibly combined according to different business requirements, improving the efficiency of data storage and query, enabling the system to better adapt to business development, and meeting the data management and query requirements in complex business scenarios.

[0081] If the business requirements are relatively simple and only one sharding factor is needed to meet the requirements of data sharding and query, such as sharding only according to songid, then a single-factor processor is selected. In simple business scenarios, the single-factor processor can simplify the sharding process, reduce system complexity and development costs. At the same time, due to the simple processing logic, it can also improve the speed and stability of data processing.

[0082] In some specific embodiments, it further includes: after the data access process is completed, the sharding processor clears the cache data including sharding factors generated during the access process. After the entire data access operation is completed, the system will automatically trigger the cache cleaning mechanism to ensure that the cache space is released in a timely manner, avoiding the redundancy of cache data and the retention of expired data. Timely clearing of cache data can prevent the cache space from being occupied by useless data and ensure that the cache always operates efficiently. For example, in a high-concurrency data access scenario, if the cache is not cleared in a timely manner, the cache may be filled with a large amount of expired sharding factor data, resulting in the inability to quickly obtain valid cache during subsequent data access, thereby increasing the calculation time of sharding factors and affecting system performance. By clearing the cache, space is reserved for new cache data, enabling the cache to continuously provide fast data support for subsequent data access and improving the overall response speed of the system.

[0083] In some specific embodiments, the multi-factor processor determines the primary sharding parameter and secondary sharding parameter of the sharding request parameter according to a preset rule, first processes the primary sharding parameter to obtain the primary sharding factor, and then processes the secondary sharding parameter to obtain the secondary sharding factor; the table name processing layer generates the sharding parameter by integrating the primary sharding factor, secondary sharding factor and the primary name of the business table.

[0084] By specifying the processing order of the main sub - table parameters and the secondary sub - table parameters, the multi - factor processor can handle complex sub - table logics. In actual business scenarios, different sub - table factors may have different importance and functions for data partitioning and management. For example, in the sub - table of the song table, the content provider ID (cpid) is used as the main sub - table parameter, and the song ID (songid) is used as the secondary sub - table parameter. First, the data is initially partitioned according to cpid, so that the data of different content providers can be stored separately, facilitating independent management and statistics of the data of different content providers. Then, further subdivision is carried out according to songid, enabling more detailed sub - table division by song ID within the data set of each content provider, improving the efficiency of data query and management. This hierarchical processing method enables the multi - factor processor to meet the precise requirements for data sub - table in complex business scenarios.

[0085] Processing the main sub - table parameters and the secondary sub - table parameters in sequence according to the preset rules can ensure the rationality and standardization of the sub - table process. Among them, the preset rules can be determined in advance by technical personnel or determined according to the weights of the factors. Since the processing order and rules are fixed, whether in the data storage or query process, the system can operate according to a unified standard. This helps to avoid data storage errors or query failures caused by chaotic sub - table logics. For example, when generating the sub - table name, the unified processing order and rules can ensure the consistency of the sub - table name generation, making it easier for developers and maintainers to understand and manage the sub - table structure.

[0086] For example, in the sub - table scenario of the song table, assume that the preset rules stipulate that cpid is the main sub - table parameter and songid is the secondary sub - table parameter. When a query request is received, where cpid = 3 and songid = 5678, the multi - factor processor first processes cpid. Assume that the processing method is to directly use the value of cpid as the main sub - table factor, and the main sub - table factor is obtained as 3. Then, songid is processed. Assume that it is processed by taking the modulus of 10, and the secondary sub - table factor is obtained as 8 (5678 % 10 = 8). The table name processing layer combines the main name of the business table "tbl_song" to generate the final sub - table name "tbl_song_3_8".

[0087] Exemplarily, for a single - factor processor:

[0088] Register the sub - table factor: The code associates the id of the java class Song with the processor TenModTableHandler when the service starts.

[0089] Initiate a data access request: At this time, the web page request calls to query the song with song ID 957, and it calls the database processing layer.

[0090] Obtain sub-table parameters: At this time, the internal process will automatically start assembling the sub-table parameters

[0091] Obtain sub-table factor: Pass in 957, calculate the current sub-table factor 957 % 10 = 7. The first access within this request will be cached (query and then update operation. When updating, it will not recalculate but directly return 7)

[0092] Return sub-table factor: 7

[0093] Return sub-table parameter tbl_song_7

[0094] mybatisPlus generates and executes the SQL select id, name, cpid from tbl_song_7 where id = 957

[0095] Return result Song

[0096] Exemplarily, for the multi-factor processor:

[0097] Code implementation: Content provider song sub-table handler CpSongTableHandler

[0098] Register sub-table factor: The code associates the cpid and id of the java class Song with the handler CpSongTableHandler when the service starts

[0099] Initiate a data access request: At this time, the web request calls the query for the song with cpid = 3 and song id = 957, and it calls the database processing layer

[0100] Obtain sub-table parameters: At this time, the internal process will automatically start assembling the sub-table parameters

[0101] Obtain sub-table factor: Pass in 3 and 957, calculate the current sub-table factors 3 and 957 % 10 = 7. The first access within this request will be cached (query and then update operation. When updating, it will not recalculate but directly return 3, 7)

[0102] Return sub-table factor: 3, 7

[0103] Return sub-table parameter tbl_song_3_7

[0104] mybatisPlus generates and executes the SQL select id, name, cpid from tbl_song_7 where cpid = 3 and id = 957

[0105] Return result Song

[0106] A sub-table data access system based on dynamic table name processing, with modules as Figure 3As shown, including:

[0107] The association unit 1 is used to call the processor factory to register and associate each sub-table factor of the business table with the corresponding processor;

[0108] Access unit 2, used to trigger the data access process when the client initiates a data access request to the preset service implementation layer;

[0109] The parsing unit 3 is used to transmit the data access request to the preset table name processing layer through the service implementation layer, and the table name processing layer parses the sub-table request parameters from the data access request and transmits the sub-table parameters to the predetermined sub-table processor;

[0110] The factor calculation unit 4 is used to calculate the table partitioning factor according to the table partitioning request parameters and the preset table partitioning rules through the table partitioning processor, and return the table partitioning factor to the table name processing layer;

[0111] A table name calculation unit 5, used to generate a sub-table name according to the sub-table factor and the main name of the business table through the table name processing layer, and return the sub-table name to the service implementation layer;

[0112] Query unit 6, used to generate corresponding SQL statements according to the sub-table names and pass them to the preset database, and the database executes the SQL statements to obtain the query results and returns them to the service implementation layer;

[0113] The output unit 7 is used to return the query result to the client through the service implementation layer to complete the data access process.

[0114] In some specific embodiments, the table splitting processor includes a single factor processor or a multi-factor processor; the single factor processor is used to process a single table splitting factor, and the multi-factor processor is used to process multiple table splitting factors.

[0115] The present application provides a computer program product, which includes computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes a method for accessing data in a partitioned table based on dynamic table name processing. A method for accessing data in a partitioned table based on dynamic table name processing is applied to a computer program product for easy execution.

[0116] The present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the steps of the method for accessing data in a partitioned table based on dynamic table name processing as described above are implemented.

[0117] The computer storage medium of the present application can adopt any combination of one or more computer-readable media. The computer-readable media can be computer-readable signal media or computer-readable storage media. The computer-readable storage media can be, for example, but not limited to: electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or components, or any combination of the above. More specific examples (non-exhaustive list) of the computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, the computer-readable storage media can be any tangible medium that contains or stores a program, and this program can be used by or in combination with an instruction execution system, device, or component. The present application applies a sub-table data access method based on dynamic table name processing to a computer-readable storage medium, on which a computer program is stored. When this program is executed by a processor, it implements the steps of the clothing simulation method provided by the present application, which is simple, fast, easy to store, and not easily lost.

[0118] The present application proposes a sub-table data access method, system, and application based on dynamic table name processing. Through multi-level security mode configuration, dynamic adjustment mechanism, personalized protection, and comprehensive environmental perception ability, it significantly improves the security and user experience of intelligent terminals. It can not only effectively prevent unauthorized access and malicious behaviors, but also provide flexible and accurate security protection according to the actual needs of users, ensuring that the device can obtain the best security guarantee in various application scenarios.

[0119] Those of ordinary skill in the art should understand that the above-mentioned modules of the present application can be implemented by a general computing system. They can be concentrated on a single computing system or distributed on a network composed of multiple computing systems. Optionally, they can be implemented with program codes executable by a computer system, so that they can be stored in a storage system and executed by the computing system, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module for implementation. In this way, the present application is not limited to any specific combination of hardware and software.

[0120] Note that the above is only the preferred embodiment of the present application and the applied technical principles. Those skilled in the art will understand that the present application is not limited to the specific embodiments here, and various obvious changes, re-adjustments and substitutions can be made by those skilled in the art without departing from the protection scope of the present application. Therefore, although the present application has been described in more detail through the above embodiments, the present application is not limited to the above embodiments only. Without departing from the concept of the present application, more other equivalent embodiments can be included, and the scope of the present application is determined by the scope of the appended claims.

[0121] The above discloses only several specific implementation scenarios of the present application. However, the present application is not limited thereto, and any changes that can be thought of by those skilled in the art should fall within the protection scope of the present application.

Claims

1. A method for accessing sharded data based on dynamic table name processing, characterized in that include: Call the processor factory to register and associate each sub-table factor of the business table with the corresponding processor; When the client initiates a data access request to the preset service implementation layer, the data access process is triggered; The data access request is transmitted to a preset table name processing layer through the service implementation layer, and the table name processing layer parses the sub-table request parameters from the data access request and transmits the sub-table parameters to a predetermined sub-table processor; The table partitioning processor calculates the table partitioning factor according to the table partitioning request parameter and the preset table partitioning rule, and returns the table partitioning factor to the table name processing layer; Generate a sub-table name according to the sub-table factor and the main name of the business table through the table name processing layer, and return the sub-table name to the service implementation layer; Generate a corresponding SQL statement according to the sub-table name and pass it to a preset database, the database executes the SQL statement to obtain the query result and returns it to the service implementation layer; The query results are returned to the client through the service implementation layer, completing the data access process.

2. The sub-table data access method according to claim 1, wherein The sub-table processor includes a single factor processor or a multi-factor processor; The single factor processor is used to process a single table factor, and the multi-factor processor is used to process multiple table factors.

3. The sub-table data access method according to claim 2, wherein The determination process of the sub-table processor specifically includes: Parsing the type of table partitioning factor involved in the table partitioning request parameter; If the table sharding request parameters only involve a single type of table sharding factor, a single factor processor is selected as the table sharding processor; if the table sharding request parameters involve multiple types of table sharding factors, a multi-factor processor is selected as the table sharding processor.

4. The sub-table data access method according to claim 2, characterized in that Predetermine business data and business requirements for business data; When the business data is divided into individual business tables, if the business demand requires the business data to be divided into tables based on multiple division factors, a multi-factor processor is selected as the division processor; if the business demand requires the table to be divided only based on a single division factor, a single-factor processor is selected as the division processor.

5. The method for accessing sub-table data according to claim 1, characterized in that, Also includes: After the data access process is completed, the cache data including the partitioning factors generated during the access process is cleaned up by the partitioning table processor.

6. The sub-table data access method according to claim 1, characterized in that The multi-factor processor determines the primary sub-table parameter and the secondary sub-table parameter of the sub-table request parameter according to a preset rule, and first processes the primary sub-table parameter to obtain the primary sub-table factor, and then processes the secondary sub-table parameter to obtain the secondary sub-table factor; The table name processing layer generates table sub-parameters by integrating the main table sub-factor, the secondary table sub-factor and the main name of the business table.

7. A sharded data access system based on dynamic table name processing, characterized in that include An association unit, used to call the processor factory to register and associate each sub-table factor of the business table with the corresponding processor; The access unit is used to trigger the data access process when the client initiates a data access request to the preset service implementation layer; A parsing unit, used to transfer the data access request to a preset table name processing layer through the service implementation layer, and the table name processing layer parses the sub-table request parameters from the data access request and transfers the sub-table parameters to a predetermined sub-table processor; A factor calculation unit, configured to calculate a sharding factor according to the sharding request parameters and a preset sharding rule by the sharding table processor, and return the sharding factor to the table name processing layer; A table name calculation unit, configured to generate a sharding table name according to the sharding factor and the main name of the business table by the table name processing layer, and return the sharding table name to the service implementation layer; A query unit, configured to generate a corresponding SQL statement according to the sharding table name and transfer it to a preset database, and the database executes the SQL statement to obtain a query result and return it to the service implementation layer; An output unit, configured to return the query result to the client through the service implementation layer to complete the data access process.

8. The sub-table data access system according to claim 7, characterized in that, The sharding table processor includes a single-factor processor or a multi-factor processor; The single-factor processor is used to process a single sharding factor, and the multi-factor processor is used to process multiple sharding factors.

9. A computer device, characterized in that, The computer device includes: One or more processors; A memory, configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the sharding data access method based on dynamic table name processing according to any one of claims 1-6.

10. A computer program product, characterized in that, Including executable instructions, which are used to implement the sharding data access method based on dynamic table name processing according to any one of claims 1-6 when being executed by a processor.

Images