Primary key generation method and electronic device

Abstract

The application relates to a primary key generation method and an electronic device, and belongs to the technical field of databases. The method comprises the following steps: when storage processing is performed, a first identification sequence is generated based on current system timestamp information processing; a second identification sequence is generated based on creation date information processing of obtained to-be-stored data records; and splicing processing is performed based on the first identification sequence and the second identification sequence, and a third identification sequence obtained through the processing is taken as a primary key of the to-be-stored data records. According to the technical scheme, the generated primary key contains timestamp information and creation date information of the data records. The primary key generated in this way can guarantee the global uniqueness and global monotonicity of the primary key, and can extract sharding information for table sharding according to dates from the primary key, so that in a database application scenario of time storage and table sharding, the sharding table can be accurately positioned when the primary key is queried.

Description

Technical Field

[0001] This application belongs to the field of database technology, specifically relating to a primary key generation method and electronic device. Background Technology

[0002] As businesses rapidly expand, the amount of data in a single table in the database gradually increases, leading to slower access performance and becoming a system bottleneck. To address this, methods such as read / write separation, high-performance SDD disks, SQL optimization, parameter tuning, historical data archiving, and data heterogeneity can improve performance to some extent. However, with the growth of business, the limitations of single-machine processing capacity and the B+tree indexing algorithm in databases will eventually reach the limit of the amount of data that a single machine, single database, and single table can handle, reaching the read / write performance bottleneck.

[0003] In related technologies, to address the issue of reduced database read / write performance due to excessively large amounts of data in a single table, table partitioning can be employed. This involves splitting a single table into several smaller tables based on specific rules, thereby reducing the data volume of each individual table and improving database performance. In this approach, after partitioning the original table, routing rules need to be specified. These rules determine which table the current data is written to, allowing for direct location of the partitioned table for fast querying without scanning every single table, significantly improving query efficiency. These routing rules typically consist of a sharding key and the partitioning logic.

[0004] One common sharding logic is to shard data by time dimension, such as by month, week, day, or even hour. In this case, a creation time (create_time) field of type date and time is added to the table as the ShardingKey. After sharding by the create_time field, the table name will include the month sharding information, such as XXX_202101, XXX_202202, XXX_202203. Data generated in different months will be written to the corresponding table name suffix according to the routing strategy. When querying data, if the query condition includes the create_time field, the sharding routing rules can be used to directly locate the table shard containing the data, thus avoiding scanning all table shards. When there is no create_time field as a query condition, every table shard needs to be queried, which will result in very poor query efficiency.

[0005] However, in some application scenarios, besides querying data within a certain time range based on the `create_time` field, it is also common to frequently query a specific piece of data precisely based on the primary key (the unique ID of a data record in the table). In these cases, the creation time of this data is usually unknown, so using only the primary key as a query condition will lead to scanning all table shards. If there are few table shards, query efficiency can be guaranteed; if there are many table shards, query efficiency will be very poor. In other words, in time-sharded database application scenarios, there is a problem of low query efficiency when querying using the primary key.

[0006] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0007] To overcome at least some of the problems existing in related technologies, this application provides a primary key generation method and electronic device, which includes time information when generating the primary key based on specific configuration, in order to solve the problem of low efficiency in query-related operations using the primary key in time-sharded database application scenarios.

[0008] To achieve the above objectives, this application adopts the following technical solution:

[0009] Firstly,

[0010] This application provides a primary key generation method, which includes:

[0011] During the inbound process, the first identifier sequence is generated based on the current system timestamp information;

[0012] And based on the creation date information of the acquired data records to be added to the database, a second identifier sequence is generated;

[0013] The first and second identifier sequences are concatenated, and the resulting third identifier sequence is used as the primary key of the data record to be added to the database.

[0014] Optionally, the step of generating the first identifier sequence based on the current system timestamp information includes:

[0015] Obtain data representing the current system timestamp information, and update the current timestamp variable with the data;

[0016] If the system time has not been rolled back, then determine whether a millisecond switch has occurred.

[0017] In the event of a millisecond-level switch, the auto-incrementing sequence number variable is reset, and the previously obtained timestamp variable is updated with the current timestamp variable's value; otherwise, the auto-incrementing sequence number variable is incremented by one, and the previously obtained timestamp variable is updated with the current timestamp variable's value.

[0018] Optionally, the step of generating the first identifier sequence based on the current system timestamp information further includes:

[0019] After updating the previously obtained timestamp variable with the current timestamp variable value, the current timestamp variable value is compressed to obtain the compressed timestamp value.

[0020] Based on the compressed timestamp value and the value of the auto-incrementing sequence number variable, a first identifier sequence consisting of multiple binary digits is generated by concatenating them.

[0021] The compressed timestamp value occupies a first number of units digits in the first identifier sequence, and the value of the sequence number variable occupies a second number of units digits in the first identifier sequence.

[0022] Optionally, the compression of the current timestamp variable specifically involves:

[0023] The difference between the current timestamp variable and the value representing the timestamp information of the reference time node is calculated, and the difference is used as the compressed timestamp value.

[0024] Optionally, the step of generating a second identifier sequence based on the creation date information of the acquired data records to be added to the database includes:

[0025] From the system business log, obtain the first value representing the creation year information of the data record to be added to the database and the second value representing the creation month information of the data record to be added to the database. Based on the first value and the second value, concatenate them to generate a second identifier sequence consisting of multiple binary numbers.

[0026] The first value occupies the third unit digit of the second identifier sequence, and the second value occupies the fourth digit of the second identifier sequence.

[0027] Optionally, the primary key generation method is applied to a server cluster;

[0028] The process of splicing the first identifier sequence and the second identifier sequence also includes splicing the numerical value representing the identifier information of the actual processing server into the third identifier sequence.

[0029] Optionally, the third identifier sequence is a 64-bit binary sequence, and the first bit of the third identifier sequence is a positive or negative bit;

[0030] The first number is 36, the second number is 10, the third number is 7, and the value representing the actual processing server identification information is a 6-bit binary number.

[0031] Optionally, if the value of the current timestamp variable is greater than or equal to the value of the last timestamp variable obtained, it is determined that no system rollback has occurred.

[0032] The determination of whether a millisecond switch has occurred specifically involves:

[0033] The current timestamp variable is compared with the last obtained timestamp variable. If the value of the current timestamp variable is equal to the value of the last obtained timestamp variable, it is determined that no millisecond switch has occurred. If the value of the current timestamp variable is greater than the value of the last obtained timestamp variable, it is determined that a millisecond switch has occurred.

[0034] Optionally, it also includes:

[0035] In the event of a system time rollback, the generation process is aborted and an error message is output.

[0036] And after incrementing the auto-incrementing sequence number variable, check whether the auto-incrementing sequence number has overflowed.

[0037] If no overflow occurs, execute the step of updating the previously obtained timestamp variable with the current timestamp variable, and then proceed with subsequent steps.

[0038] Otherwise, repeatedly acquire data representing the current system timestamp information and compare it with the current timestamp variable until the comparison result represents the system time advancing by at least 1 millisecond. Then, update the current timestamp variable with the data representing the current system timestamp information acquired at this moment. After that, execute the step of updating the previously acquired timestamp variable with the value of the current timestamp variable and subsequent steps.

[0039] Secondly,

[0040] This application provides an electronic device, including:

[0041] Memory, on which executable programs are stored;

[0042] A processor for executing the executable program in the memory to implement the steps of the method described above.

[0043] The application employs the above technical solution and has at least the following beneficial effects:

[0044] In the technical solution for generating primary keys in this application, during the data entry process, a first identifier sequence is generated based on the current system timestamp information; and a second identifier sequence is generated based on the creation date information of the data record to be entered; the first and second identifier sequences are concatenated, and the resulting third identifier sequence is used as the primary key of the data record to be entered. In this technical solution, the primary key generated in this way includes timestamp information and the creation date information of the data record. This method ensures both global uniqueness and global monotonicity of the primary key, and also allows for the extraction of sharding information based on date from the primary key. Therefore, in time-sharded database applications, it enables efficient and accurate location of sharded tables when querying based on the primary key.

[0045] Other advantages, objectives, and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from an examination of the following, or may be learned from the practice of the invention. Attached Figure Description

[0046] The accompanying drawings are used to provide a further understanding of the technical solutions of this application or the prior art, and constitute a part of the specification. The drawings illustrating embodiments of this application, together with the embodiments of this application, are used to explain the technical solutions of this application, but do not constitute a limitation on the technical solutions of this application.

[0047] Figure 1 This is a flowchart illustrating a primary key generation method in one embodiment of this application;

[0048] Figure 2 This is a schematic diagram of the process for generating the first identifier sequence in one embodiment of this application;

[0049] Figure 3 This is a schematic diagram of the process for generating the first identifier sequence in one embodiment of this application;

[0050] Figure 4 This is a schematic diagram illustrating the structure for generating a primary key in one embodiment of this application;

[0051] Figure 5 This is a schematic diagram illustrating the process of a primary key generation method in one embodiment of this application;

[0052] Figure 6 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] As described in the background section, one common sharding logic is to shard data by time dimension, such as by month, week, day, or even hour. In this case, a creation time (create_time) field of type date and time is added to the table as the Sharding Key. After sharding by the create_time field, the table name will include the month sharding information, such as XXX_202101, XXX_202202, XXX_202203. Data generated in different months will be written to the table with the corresponding table name suffix according to the routing strategy. When querying data, if the query condition includes the create_time field, the sharding routing rules can be used to directly locate the table shard where the data is located, thus avoiding scanning all table shards. When there is no create_time field as a query condition, it is necessary to query every table shard, which will result in very poor query efficiency.

[0055] However, in some application scenarios, besides querying data within a certain time range based on the `create_time` field, it is also common to frequently query a specific piece of data precisely based on the primary key (the unique ID of a data record in the table). In these cases, the creation time of this data is usually unknown, so using only the primary key as a query condition will lead to scanning all table shards. If there are few table shards, query efficiency can be guaranteed; if there are many table shards, query efficiency will be very poor. In other words, in time-sharded database application scenarios, there is a problem of low query efficiency when querying using the primary key.

[0056] To help understand the technical problem raised in this application, the following example is provided:

[0057] For example, there is an order table named "order", and the main fields of the table structure are shown in Table 1 below:

[0058] Table 1

[0059]

[0060] The `order` table generates 20 million orders every month. To prevent the `order` table from becoming too large, it is partitioned by month. The sharding key uses the "order time" field. The current time is July 2022. The names of the partitioned tables are shown in Table 2 below:

[0061] Table 2

[0062] Table partitioning illustrate Table creation time order_202205 Historical Monthly Table (May) Segmentation Created in April order_202206 Historical Monthly Table (June) Segmentation Created in May order_202207 July table sharding for the current month Created in June order_202208 Next month's August table sharding Created in July

[0063] For querying the order table, there is a business scenario like this: "Query the list of orders for which returns were requested on July 7th, and then process the returns after approval."

[0064] The original SQL query for retrieving the list of orders with return requests submitted on July 7th is as follows:

[0065] SELECT “order id”, “order status”, “order time” FROM order

[0066] WHERE

[0067] Order time >= "2022-07-07 00:00:00"

[0068] AND "Order Time" <= "2022-07-07 23:59:59"

[0069] AND "Order Status" = "Request Return"

[0070] The time range given by the "order time" field in the SQL query conditions allows us to locate the table sharded as order_202207. Querying this table retrieves the list of orders for which returns were requested on July 7th. The SQL query can then be rewritten as follows:

[0071] SELECT “order id”, “order status”, “order time” FROM order_202207

[0072] WHERE

[0073] Order time >= "2022-07-07 00:00:00"

[0074] AND "Order Time" <= "2022-07-07 23:59:59"

[0075] AND "Order Status" = "Request Return"

[0076] Then we use the primary key field "order_id" of the orders in the retrieved list to query the details of a specific order. There are generally two implementation methods, as follows:

[0077] Option 1, following the normal business logic, the original query SQL is as follows:

[0078] SELECT * FROM ORDER

[0079] WHERE

[0080] "Order id"=="XXXXXXXXXXXXXXX"

[0081] The "order id" field alone is insufficient to determine which table shard this record resides on. The only way to find it is by scanning all table shards for order_202205, order_202206, order_202207, and order_202208. In this case, the query SQL will be rewritten by the table sharding component into the following five SQL statements:

[0082] SELECT * FROM order_202205

[0083] WHERE

[0084] "Order id"=="XXXXXXXXXXXXXXX"

[0085] SELECT * FROM order_202206

[0086] WHERE

[0087] "Order id"=="XXXXXXXXXXXXXXX";

[0088] SELECT * FROM order_202207

[0089] WHERE

[0090] "Order id"=="XXXXXXXXXXXXXXX";

[0091] SELECT * FROM order_202208

[0092] WHERE

[0093] "Order id"=="XXXXXXXXXXXXXXX";

[0094] Finally, the results from these five SQL queries are merged. If there are many sharded tables, the number of SQL queries will also increase, leading to low query efficiency.

[0095] Option 2: To accurately locate table shards, add an "order time" field as a query condition. The original query SQL is as follows:

[0096] SELECT * FROM order

[0097] WHERE

[0098] "Order id"=="XXXXXXXXXXXXXXX"

[0099] AND "Order Time" >= "2022-07-07 00:00:00"

[0100] AND "Order Time" <= "2022-07-07 23:59:59"

[0101] At this point, by using the "order time" field, we can accurately locate the table shard order_202207, and then find this record using the "order ID". The query SQL will then be rewritten by the table sharding component as follows:

[0102] SELECT * FROM order_202207

[0103] WHERE

[0104] "Order id"=="XXXXXXXXXXXXXXX"

[0105] AND "Order Time" >= "2022-07-07 00:00:00"

[0106] AND "Order Time" <= "2022-07-07 23:59:59"

[0107] Compared to Option 2, Option 1 has lower query efficiency, but only requires passing the primary key; Option 2 has higher query efficiency, but in addition to passing the primary key, it also requires passing the "order time" field specifically for scenarios with table partitioning. If no special processing is required for table partitioning, under normal circumstances, only the primary key needs to be used for querying, and the "order time" field does not need to be passed.

[0108] To allow business users to focus solely on business logic without needing to worry about the SQL syntax after table partitioning, this application proposes a technical solution that specially handles the primary key generation algorithm, allowing the primary key to include date information. This eliminates the need to pass a "time" field, enabling the table sharding component to retrieve the year and month sharding information from the primary key, accurately locating the table shard and improving query efficiency.

[0109] In one embodiment, such as Figure 1As shown, the primary key generation method proposed in this application includes the following steps:

[0110] Step S110: During the data entry process, a first identifier sequence is generated based on the current system timestamp information;

[0111] It is easy to understand that the primary key needs to guarantee global uniqueness and global monotonicity (in order to ensure the performance of the B+Tree index algorithm). Based on this consideration, this application generates a first identifier sequence based on the current system timestamp information during the data entry process, which serves as one of the bases for subsequent primary key generation.

[0112] Step S120: Generate a second identifier sequence based on the creation date information of the data records to be added to the database;

[0113] In this step, the creation date information of the data record is introduced and processed to generate a second identifier sequence, which serves as one of the bases for subsequent primary key generation.

[0114] Finally, step S130 is performed, where the obtained first and second identifier sequences are concatenated, and the resulting third identifier sequence is used as the primary key of the data record to be added to the database.

[0115] In the technical solution of this application, the primary key generated by a specific processing method includes timestamp information and the creation date information of the data record. The primary key generated in this way can not only guarantee the global uniqueness and global monotonicity of the primary key ID, but also extract the sharding information of the table sharding by date from the primary key. Thus, in the database application scenario of time-based database sharding, it can realize efficient and accurate location of the sharded table when querying by primary key.

[0116] To facilitate understanding of the technical solution of this application, another embodiment will be used to describe the technical solution of this application below.

[0117] In this embodiment, similar to the embodiments described above, the primary key generation method proposed in this application also includes:

[0118] During the inbound process, the first identifier sequence is generated based on the current system timestamp information;

[0119] Specifically, in this embodiment, such as Figure 2 As shown, the first identifier sequence is generated based on the current system timestamp information, including:

[0120] Step 1: Obtain data representing the current system timestamp information, and use this data to update the current timestamp variable (for example, the current timestamp variable is represented by curTimestamp). The statement in the algorithm implementation is curTimestamp = System.currentTimeMillis().

[0121] Next, proceed to step 2 to determine if a system time rollback has occurred. If no system time rollback has occurred, proceed to step 3 to determine if a millisecond switch has occurred.

[0122] In the event of a millisecond-level switch, proceed to step 4 to reset the auto-incrementing sequence number variable (for example, denoted as `sequence`). The algorithm implementation in step 4 uses the statement `sequence = 0`. Then, the previously obtained timestamp variable is updated with the current timestamp variable's value (corresponding to...). Figure 2 In step 6, the last obtained timestamp variable is represented by lastTimestamp. The algorithm implementation for step 6 is lastTimestamp = curTimestamp.

[0123] Otherwise, proceed to step 5 (i.e., no millisecond switching branch occurs), increment the auto-incrementing sequence number variable by one, and the algorithm implementation corresponding to step 5 is sequence = sequence + 1. Then, proceed to step 6, update the previously obtained timestamp variable with the current timestamp variable value.

[0124] It is easy to understand that the auto-incrementing sequence number here is to further refine the distinction of the smallest granularity of time (1 millisecond in this embodiment), that is, multiple data records can be further distinguished within the same millisecond (the specific upper limit of the number is related to the overflow value of the auto-incrementing sequence number variable).

[0125] In this embodiment, such as Figure 2 As shown, the process of generating the first identifier sequence based on the current system timestamp information also includes:

[0126] After updating the previously obtained timestamp variable with the current timestamp variable value (i.e., after step 6), step 7 is performed to compress the value of the current timestamp variable to obtain the compressed timestamp value.

[0127] As will be readily understood by those skilled in the art, a timestamp generally refers to the total number of milliseconds from 00:00:00 GMT on January 1, 1970 to the present. In this application, to ensure that the overall data length of the generated primary key meets the data type requirements (such as a 64-bit long integer), the value of the current timestamp variable (the millisecond count) is compressed. Specifically, in this embodiment, the compression method is as follows:

[0128] The difference between the current timestamp variable and the value representing the timestamp information of the reference time node is calculated, and the difference is used as the compressed timestamp value.

[0129] For example, if the base time is 00:00 on January 1, 2022 (it's easy to understand that this time can be adjusted based on the year the system initially started running), its corresponding timestamp is 1640966400000. The compressed timestamp value is represented by `compressTimestamp`, and during the algorithm execution, `curTimestamp` = 1658221716329 (corresponding to 17:08:36 on July 19, 2022).

[0130] compressTimestamp = 1658221716329 - 1640966400000 = 17255316329. This value is significantly reduced compared to the original timestamp value, allowing it to be represented using a shorter data length.

[0131] Continue back Figure 2 After step 7, proceed to step 8, which uses the compressed timestamp value and the value of the auto-incrementing sequence number variable to concatenate and generate a first identifier sequence consisting of multiple binary digits.

[0132] The compressed timestamp value here occupies the first unit digit (e.g., 36 bits) of the first identifier sequence, and the value of the sequence number variable occupies the second unit digit (e.g., 10 bits) of the first identifier sequence.

[0133] Here, we will further explain the system callback judgment in step 2 and the millisecond switching judgment in step 3 in this embodiment:

[0134] In this application, system rollback refers to a situation where the system clock is called back. Since the uniqueness of the primary key generated in this application is related to the timestamp, the uniqueness cannot be guaranteed in the case of system rollback. Therefore, it is necessary to determine whether to perform system rollback. Specifically, in this embodiment, the determination method is as follows:

[0135] The current timestamp variable is compared with the previously acquired timestamp variable. If the current timestamp variable is greater than or equal to the previously acquired timestamp variable, it is determined that no system time rollback has occurred; otherwise, it is determined that a system time rollback has occurred, and execution is performed. Figure 2 In step A, the generation process is aborted and an error message is output.

[0136] Based on the preceding description of the auto-incrementing sequence number, it is easy to understand that the millisecond switching determination in this application is a prerequisite for implementing this further subdivision mechanism. In this embodiment, the determination of whether a millisecond switching has occurred is specifically as follows:

[0137] The current timestamp variable is compared with the last obtained timestamp variable. If the value of the current timestamp variable is equal to the value of the last obtained timestamp variable, it is determined that no millisecond switch has occurred. If the value of the current timestamp variable is greater than the value of the last obtained timestamp variable, it is determined that a millisecond switch has occurred.

[0138] Furthermore, to ensure the completeness of the generation method, the overflow problem of the auto-incrementing sequence number variable also needs to be considered. For example, such as... Figure 3 As shown, after the auto-incrementing sequence number variable is incremented and updated, i.e. after step 5, overflow judgment and related steps are performed (corresponding to...). Figure 3 Step B), which includes:

[0139] To determine whether the auto-incrementing sequence number has overflowed, for example, if the auto-incrementing sequence number is configured as a 10-bit binary number in the first sequence, its maximum value is 1024. Here, the auto-incrementing sequence number variable is compared with 1024. If it is less than 1024, it is determined that there is no overflow; otherwise, it is determined that an overflow has occurred.

[0140] If no overflow occurs, the steps to update the previously obtained timestamp variable with the current timestamp variable and subsequent steps (i.e., step 6 and subsequent steps) are executed.

[0141] Otherwise, repeatedly acquire data representing the current system timestamp information and compare it with the current timestamp variable until the comparison result represents the system time advancing by at least 1 millisecond. Then, update the current timestamp variable with the data representing the current system timestamp information acquired at this moment. After that, execute the step of updating the previously acquired timestamp variable with the value of the current timestamp variable and the subsequent steps (step 6 and subsequent steps).

[0142] In addition, it should be noted that, in order to improve processing efficiency and ensure the uniqueness of the primary key, the steps of updating the previously obtained timestamp variable with the current timestamp variable and the steps before that are processed in the process of generating the first identifier sequence, are handled in a multi-threaded locking manner.

[0143] Similarly, this embodiment also includes a step of generating a second identifier sequence based on the creation date information of the acquired data records to be added to the database. Specifically, this step includes:

[0144] From the system business log, obtain the first value representing the creation year information of the data record to be added to the database, and obtain the second value representing the creation month information of the data record to be added to the database. Based on the first value and the second value, concatenate them to generate a second identifier sequence consisting of multiple binary numbers.

[0145] In this sequence, the first value occupies the last digit of the third number in the second identifier sequence (e.g., 7 digits), and the second value occupies 4 digits in the second identifier sequence, thus representing the months from January to December.

[0146] In this embodiment, the first and second identifier sequences are concatenated, and the resulting third identifier sequence is used as the primary key of the data record to be added to the database.

[0147] Furthermore, in a specific implementation scenario, the primary key generation method is applied to a server cluster; correspondingly, in the process of concatenating the first and second identifier sequences, the method also includes concatenating the value representing the actual server identifier information (such as the server instance ID) into the third identifier sequence to ensure the global uniqueness of the generated primary key.

[0148] Specifically, in this scenario, such as Figure 4 As shown, the final generated third identifier sequence of the primary key is a 64-bit binary sequence, where the first bit of the third identifier sequence is the positive or negative bit, and this bit is fixed at 0 to indicate positive;

[0149] The third number is 7, meaning the value of the creation year information occupies 7 digits, which can represent 128 years. For example, if the 2nd to 8th digits in the third sequence are in the base time node of 2022, then the system can continue to generate distributed IDs until 2022 + 127 = 2149 years.

[0150] As mentioned above, the numerical value for creating monthly information occupies 4 digits and can identify 12 months, such as the 9th to 12th digits in the third sequence;

[0151] The first number is 36, meaning the compressed timestamp value occupies 36 bits. For example, in the 13th to 48th bits of the third sequence, a 36-bit timestamp can support 68,719,476,736 milliseconds without overflowing within 2 years.

[0152] The numerical value representing the actual processing server identification information is a 6-bit binary number, that is, it occupies 6 bits. For example, in the 49th to 54th bits of the third sequence, its value ranges from 0 to 63, which can identify 64 servers.

[0153] The second number is 10, meaning the value of the sequence number variable occupies 10 positions, such as the 55th to 64th positions in the third sequence. This means it can identify 1024 IDs, or in other words, it can generate 1024 IDs within one millisecond.

[0154] In this specific application scenario, the generation method supports a server cluster of 64 units, can be used for 128 years, generates 1024 IDs per millisecond per machine, and ensures that the IDs generated by each server are unique.

[0155] In practice, a scheduled task can be used to calculate the timestamp of 00:00 on January 1st of the current year and store it in the local cache as a value representing the timestamp information of the baseline time node. The timestamp is updated every certain period of time (such as 1 minute). In this way, there is no need to worry about the problem of abnormal operation caused by untimely acquisition when the new year crosses over.

[0156] In this application, a primary key (or distributed ID) with the above-described structure is generated. The distributed ID is a 64-bit long integer. The ID is divided into multiple segments, incorporating the table's sharding year and month time information, a simplified timestamp, the server instance ID, and an auto-incrementing sequence to ensure the generation of a monotonically increasing and non-repeating long integer sequence number. The primary key ID generated in this way can guarantee the global uniqueness and global monotonicity of the primary key ID, and can also extract the sharding information of the table sharded by year and month. When querying based on the primary key ID, the sharded table can be accurately located.

[0157] Figure 5 The diagram shown is an example illustration of the primary key generation method in one embodiment of this application. Figure 5 The method flow shown has been described in the previous embodiments and will not be repeated here. Figure 5 It should be noted that the steps after the start are for initializing or simulating some basic parameters of the algorithm, such as setting lastTimestamp to -1, and simulating date to 2022-7-19 16:35:27.

[0158] Figure 6 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application, as shown below. Figure 6 As shown, the electronic device 400 includes:

[0159] Memory 401, on which an executable program is stored;

[0160] Processor 402 is used to execute the executable program in memory 401 to implement the steps of the above method.

[0161] Regarding the electronic device 400 in the above embodiments, the specific manner in which its processor 402 executes the program in the memory 401 has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0162] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for generating primary keys, characterized in that, include: During the inbound process, the first identifier sequence is generated based on the current system timestamp information; And based on the creation date information of the acquired data records to be added to the database, a second identifier sequence is generated; The first and second identifier sequences are concatenated, and the resulting third identifier sequence is used as the primary key of the data record to be added to the database. The process of generating the first identifier sequence based on the current system timestamp information includes: Obtain data representing the current system timestamp information, and update the current timestamp variable with the data; If the system time has not been rolled back, then determine whether a millisecond switch has occurred. In the event of a millisecond-level switch, the auto-incrementing sequence number variable is reset, and the previously obtained timestamp variable is updated with the current timestamp variable value; otherwise, the auto-incrementing sequence number variable is incremented by one, and the previously obtained timestamp variable is updated with the current timestamp variable value. The process of generating the first identifier sequence based on the current system timestamp information further includes: After updating the previously obtained timestamp variable with the current timestamp variable value, the current timestamp variable value is compressed to obtain the compressed timestamp value. Based on the compressed timestamp value and the value of the auto-incrementing sequence number variable, a first identifier sequence consisting of multiple binary digits is generated by concatenating them. Wherein, the compressed timestamp value occupies a first number of units digits in the first identifier sequence, and the value of the sequence number variable occupies a second number of units digits in the first identifier sequence; The process of generating a second identifier sequence based on the creation date information of the acquired data records to be added to the database includes: From the system business log, obtain the first value representing the creation year information of the data record to be added to the database and the second value representing the creation month information of the data record to be added to the database. Based on the first value and the second value, concatenate them to generate a second identifier sequence consisting of multiple binary numbers. The first value occupies the third unit digit of the second identifier sequence, and the second value occupies the fourth digit of the second identifier sequence.

2. The primary key generation method according to claim 1, characterized in that, The compression process for the current timestamp variable specifically involves: The difference between the current timestamp variable and the value representing the timestamp information of the reference time node is calculated, and the difference is used as the compressed timestamp value.

3. The primary key generation method according to claim 1, characterized in that, The primary key generation method is applied to a server cluster; The process of splicing the first identifier sequence and the second identifier sequence also includes splicing the numerical value representing the identifier information of the actual processing server into the third identifier sequence.

4. The primary key generation method according to claim 3, characterized in that, The third identifier sequence is a 64-bit binary sequence, and the first bit of the third identifier sequence is the positive or negative bit; The first number is 36, the second number is 10, the third number is 7, and the value representing the actual processing server identification information is a 6-bit binary number.

5. The primary key generation method according to claim 1, characterized in that, If the value of the current timestamp variable is greater than or equal to the value of the last timestamp variable, it is determined that no system rollback has occurred. The determination of whether a millisecond switch has occurred specifically involves: The current timestamp variable is compared with the last obtained timestamp variable. If the value of the current timestamp variable is equal to the value of the last obtained timestamp variable, it is determined that no millisecond switch has occurred. If the value of the current timestamp variable is greater than the value of the last obtained timestamp variable, it is determined that a millisecond switch has occurred.

6. The primary key generation method according to claim 1, characterized in that, It also includes, In the event of a system time rollback, the generation process is aborted and an error message is output. And after incrementing the auto-incrementing sequence number variable, check whether the auto-incrementing sequence number has overflowed. If no overflow occurs, execute the step of updating the previously obtained timestamp variable with the current timestamp variable, and then proceed with subsequent steps. Otherwise, repeatedly acquire data representing the current system timestamp information and compare it with the current timestamp variable until the comparison result represents the system time advancing by at least 1 millisecond. Then, update the current timestamp variable with the data representing the current system timestamp information acquired at this moment. After that, execute the step of updating the previously acquired timestamp variable with the value of the current timestamp variable and subsequent steps.

7. An electronic device, characterized in that, include: Memory, on which executable programs are stored; A processor for executing the executable program in the memory to implement the steps of the method according to any one of claims 1-6.

Images