Data storage method, server, and storage medium

Abstract

An embodiment of the present application discloses a data storage method. The method includes: writing status data into a real-time status data table, writing non-status data into a non-status data table, adding the latest status data of the real-time status data table to a non-real-time status data table, performing a hashing operation on the newly added data in the non-status database and adding the operation result to a summary table of the non-status database. The embodiment of the present application adopts a dual-database architecture, which ensures the stability of non-status data and provides a basis for non-tamperability. The status data is periodically transferred to the non-status database in the form of new records to become non-real-time status data, retaining the data change history, which is crucial for data integrity and auditability. The embodiment of the present application adopts a summary table to periodically record the summary of the newly added data in the non-status database, so as to improve the non-tampering effect.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of data storage, and in particular, to a data storage method, a server, and a storage medium. Background Art

[0002] In the digital information age, data has become the core asset of various organizations and enterprises. As a key tool for data storage and management, the performance and security of databases are of crucial importance. However, traditional databases face many challenges in terms of data immutability, integrity, auditability, as well as concurrent and read-write performance.

[0003] In terms of data immutability, traditional databases usually lack effective mechanisms to ensure that data cannot be tampered with once stored. Due to the limitations of data storage structures and access controls, internal personnel or attackers with certain permissions may maliciously modify the data in the database, and such modifications are often difficult to trace and detect. This may bring serious consequences to some scenarios with high requirements for data authenticity and integrity, such as financial transaction records and medical record files.

[0004] In terms of data integrity, although traditional databases have some constraint mechanisms, such as primary key constraints and foreign key constraints, these mechanisms mainly verify the format and relevance of data and cannot fundamentally ensure that data is not tampered with during storage and transmission. Once the data is attacked externally or there are internal incorrect operations, the integrity of the data may be damaged, thereby affecting the accuracy of business decisions and analyses based on this data.

[0005] Auditability is also a weak link in traditional databases. When problems occur with the data, it is very difficult to quickly and accurately trace the change history of the data, the personnel who made the changes, and the reasons for the changes. Although traditional logging methods can record some operations, for complex database operations and large-scale data changes, the management and analysis of logs become extremely difficult and cannot meet the requirements of efficient auditing.

[0006] In terms of concurrent and read-write performance, as the amount of data continues to grow and the business complexity increases, traditional databases often struggle to handle high-concurrency read-write requests. For example, relational databases are prone to lock contention problems when dealing with a large number of concurrent transactions, resulting in low transaction processing efficiency and a significant decline in read-write performance. This not only affects the user experience but also limits the expansion and operational efficiency of enterprise businesses.

[0007] Although the emergence of blockchain technology provides good solutions in terms of data immutability, rights confirmation, traceability, and auditing, it also has some limitations. The data processing method of blockchain is relatively complex, and its performance is far inferior to that of traditional databases when performing operations such as join queries and efficient reading and writing, which traditional databases are good at. Moreover, the architecture design of blockchain makes it consume huge storage and computing resources when dealing with large-scale data, making it difficult to meet some business scenarios with high requirements for real-time performance.

[0008] Some business scenarios require real-time recording of the latest status of users. Usually, the database of the server corresponding to the business scenario is a relational database. The real-time status data is saved on the relational database, and the server receives the status change information sent by the client and records the latest status of the user in the relational database.

[0009] The data or records in traditional relational databases can be updated or deleted. People can modify, update, or delete the real-time status data or records on the relational database, resulting in some key records being rewritten continuously, historical information being lost, and the system losing its traceability ability. When data tampering occurs, it becomes difficult to trace which data has been tampered with. Even more seriously, at some critical moments, it becomes impossible to restore the original data, which has become a major pain point in such applications.

[0010] In summary, neither the existing traditional databases nor the blockchain data structure can well meet the requirements of both data immutability, integrity, auditability, and high concurrent and reading / writing performance. Therefore, there is an urgent need for a new technical solution that can enhance the immutability ability of traditional databases on the basis of traditional databases while improving concurrent and reading / writing performance to adapt to the increasingly complex and diverse business needs. Summary of the Invention

[0011] An object of an embodiment of the present application is to provide a data storage method, a server, and a storage medium to improve the technical problem that data in related technologies is easily tampered with.

[0012] In a first aspect, an embodiment of the present application provides a data storage method, which is applied to a server and includes: obtaining user data, parsing status data and non-status data from the user data, where the status data is data that is updated in real time, and the non-status data is data other than the status data in the user data. A preset status database is configured with a real-time status data table, and a preset non-status database is configured with a non-status data table, a non-real-time status data table, and a summary table. The status database is a database that supports the functions of addition, deletion, query, and modification, and the non-status database is a database that only supports the functions of query and addition. Writing the status data into the real-time status data table, writing the non-status data into the non-status data table, regularly responding to a status data persistence event, and writing the latest status data saved in the real-time status data table as a first new record into the non-real-time status data table of the non-status database. Regularly responding to a data non-tampering event, performing a hashing operation on the new data saved in the non-status database to obtain a first operation result, where the new data is data that has been newly added since the last regular data non-tampering event. If the current data non-tampering event is the first data non-tampering event, the new data is all the current data in the non-status database. Generating a second new record based on the first operation result and writing the second new record into the summary table of the non-status database.

[0013] Optionally, performing a hashing operation on the new data saved in the non-status database to obtain a first operation result includes: screening a target data table containing the new data in the non-status database, where the target data table is one of the non-status data table, the non-real-time status data table, and the summary table; forming a set of data tables to be hashed by all the target data tables; and performing a hashing operation on each target data table in the set of data tables to be hashed to obtain a first operation result corresponding to each target data table.

[0014] Optionally, performing a hashing operation on each target data table in the set of data tables to be hashed to obtain a first operation result corresponding to each target data table includes: obtaining the new data in the target data table; putting the new data into a pre-hashing data set; concatenating the data in the pre-hashing data set into a pre-hashing string; and performing a hashing operation on the pre-hashing string to obtain a first operation result corresponding to each target data table.

[0015] Optionally, the pre-hashing data set further includes the previous result of the hashing operation on the target data table in the summary table; correspondingly, concatenating the data in the pre-hashing data set into a pre-hashing string includes: concatenating the data in the pre-hashing data set with the previous result into a pre-hashing string.

[0016] Optionally, the information identifier of the last piece of historical information is included in the most recent record of the summary table regarding the target data table, where the last piece of historical information is the last piece of information included during the non-tampering event in the target data table, and the most recent record is a record whose time is before the second newly added record. Obtaining the newly added data in the target data table includes: collecting the information arranged after the last piece of historical information in the target data table based on the information identifier of the last piece of historical information to obtain the newly added data.

[0017] Optionally, generating the second newly added record based on the first operation result includes: determining the table name identifier of the target data table, where the table name identifier is used to identify the target data table; and forming the second newly added record regarding the target data table by combining the first operation result and the table name identifier.

[0018] Optionally, determining the table name identifier of the target data table includes: obtaining the table name of the target data table; and performing desensitization processing on the table name of the target data table to obtain the table name identifier.

[0019] Optionally, the newly added data includes multiple pieces of newly added information arranged in chronological order. Forming the second newly added record regarding the target data table by combining the first operation result and the identifier includes: finding the last piece of newly added information from the newly added data; and forming the second newly added record regarding the target data table by combining the first operation result, the table name identifier, and the last piece of newly added information.

[0020] Optionally, the method further includes: publicly announcing the summary table in real time.

[0021] Optionally, the method further includes: periodically responding to the summary on-chain event, performing a hashing operation on the new summary data in the summary table stored in the non-state database to obtain a second operation result; and writing the second operation result into the blockchain, where the new summary data is the newly added summary data since the last periodic summary on-chain event, and if this event is the first event, the new summary data is all the current data in the summary table.

[0022] In a second aspect, an embodiment of the present application provides a server, including a memory and a processor, the memory is connected to the processor, and the processor is configured to execute one or more computer programs stored in the memory. When the processor executes the one or more computer programs, the server implements the above data storage method.

[0023] In a third aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to execute the above data storage method.

[0024] The embodiments of the present application can achieve the following technical effects: The embodiments of the present application clearly classify the data to be stored in the database into status data and non-status data, so that data with different characteristics can be adapted to different storage and management methods, which is the basis for realizing immutability. The embodiments of the present application adopt a dual-database architecture, where the status database is used to store status data and the non-status database is used to store non-status data. In terms of operation permission settings, the status database supports regular addition, deletion, query, and modification operations to meet the needs of frequent updates of status data. The non-status database only supports addition and query operations and prohibits deletion and modification operations, thus ensuring the stability of non-status data and providing a basis for immutability. Status data is periodically transferred to the non-status database as new records to become non-real-time status data, retaining the data change history, which is crucial for data integrity and auditability. The embodiments of the present application adopt a summary table to periodically record summaries of the new data in the non-status database, which can improve the immutability effect. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] To more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments of the present application. Obviously, the drawings in the following description are only some embodiments of the present application, and those of ordinary skill in the art can obtain other drawings without creative efforts based on these drawings.

[0026] Figure 1 It is a schematic structural diagram of a data storage system provided by an embodiment of the present application;

[0027] Figure 2 It is a schematic flowchart of a data storage method provided by an embodiment of the present application;

[0028] Figure 3 It is a schematic diagram of a data storage scenario provided by an embodiment of the present application;

[0029] Figure 4 It is a schematic structural diagram of a data storage device provided by an embodiment of the present application;

[0030] Figure 5 It is a schematic structural diagram of a server provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] In order to make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts shall fall within the protection scope of the present application.

[0032] It should be noted that if there is no conflict, the various features in the embodiments of the present application can be combined with each other and all fall within the protection scope of the present application. In addition, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from the module division in the device or the flowchart. Furthermore, the terms "first", "second", "third", etc. used in the present application do not limit the data and the execution order, but are only used to distinguish the same items or similar items with basically the same functions and effects.

[0033] Hereinafter, an embodiment of the present application provides a data storage system. Please refer to Figure 1 , the data storage system 100 includes an electronic device 11 and a server 12, and the electronic device 11 is communicatively connected to the server 12.

[0034] The electronic device 11 is installed with an application APP. After the user starts the application APP on the electronic device 11 and completes relevant operations on the interaction interface provided by the application APP, the application APP sends user data to the server 12 through the electronic device 11. The server 12 stores the user data by using the data storage method provided in each of the following embodiments.

[0035] Hereinafter, an embodiment of the present application provides a data storage method, which is applied to the server. Please refer to Figure 2 , the data storage method includes steps S21 to S28.

[0036] Step S21, obtain user data.

[0037] The user data is the data sent by the client to the server. For example, the client sends integral data, daily consumption data, user login data, etc. to the server.

[0038] Step S22, parse status data and non-status data from the user data.

[0039] The status data is the data that is updated in real time. Among them, the real-time update frequency can be customized by the designer according to business requirements. For example, the status data is the inventory quantity of goods in an e-commerce system, the real-time status of an order, etc., and the real-time update frequency is 1 second or 2 seconds or when an update event arrives, etc.

[0040] Non-status data refers to the data in user data excluding status data. Generally, non-status data is data that does not change within a preset time period or system data, etc. For example, non-status data includes the basic information of a commodity, the fixed information at the time of user registration, etc.

[0041] For another example, when a user plays an online game, the client sends user data to the server. The user data consists of the following types of data: user information (nickname, avatar, etc.), score data, equipment acquisition data, current equipment bonus data, player position coordinates, task challenge data, player resource status, and so on. The user's own information, such as nickname and avatar, is usually fixed within a period of time. Therefore, the server does not update the user information in real time. In the embodiments of the present application, such data is regarded as non-status data. Usually, a player needs to complete certain tasks or meet certain trigger conditions to obtain equipment in the game. Similarly, when a player challenges a task, effort and time are also required, which is not a high-frequency event. Moreover, for the fairness of the game, a traceable record needs to be provided at any time for auditing to prevent cheating. In the embodiments of the present application, such data is also regarded as non-status data. On the other hand, score data, current equipment bonus data, player position coordinates, player resource status, etc. usually record a certain current real-time status. Due to various factors, the frequency of update and reading may be very high, and it is necessary to update in real time and provide accurate perception to the player in real time. Therefore, in the embodiments of the present application, such data is regarded as status data.

[0042] The status database is a database that supports functions of addition, deletion, query, and modification. The status database is configured with a real-time status data table, which is used to record status data. It can be understood that the number of real-time status data tables can be one or more than two. Different types of real-time status data tables are used to record status data of different business types.

[0043] The non-status database is a database that only supports addition and query functions. The non-status database is configured with non-status data tables, non-real-time status data tables, and summary tables. It can be understood that the number of non-status data tables can be one or more than two. Different types of non-status data tables are used to record non-status data of different business types. The number of non-real-time status data tables can be the same as or different from the number of real-time status data tables. The non-real-time status data tables can correspond to the real-time status data tables in terms of data structure, or can be redesigned to optimize storage or support other purposes, or can be missing or partially missing. The number of summary tables can be one or more than two, usually one. When there are more than two, different rules can be used to configure each summary table to store summary data of different business types; when there is only one, different rules can be used to use custom fields to distinguish and store summary data records of different business types, such as the "table name" field. The fields of the summary table usually contain record identifiers, record timestamps, and record values. In addition, new fields can be added according to specific needs to optimize the usage effect.

[0044] The embodiments of the present application clearly classify the data that needs to be stored in the database into status data and non-status data. This classification method is the basis for all subsequent improvement measures, and can adopt more appropriate storage and management strategies according to the characteristics of different types of data.

[0045] The embodiments of the present application adopt a method of storing data in two databases. The status database is specifically used to store status data, while the non-status database is responsible for storing non-status data. In terms of operation permission settings, the status database supports regular addition, deletion, query, and modification operations to meet the needs of frequent updates of status data. The non-status database only supports addition and query operations, and deletion and modification operations are prohibited, thus ensuring the stability of non-status data and providing a common rule basis for non-tampering.

[0046] It should be noted that the common rule here refers to the common specification to be followed in accordance with the embodiments of the present application. Those who violate this specification will become a special minority and will be detected and falsified by the functional mechanism formed by the embodiments of the present application.

[0047] Step S23, write the status data into the real-time status data table.

[0048] The real-time status data table is used to record the real-time status of the recognized content. For example, when recording the status data with the user as the recognition object, there is one record corresponding to one user's status data. The server can assign an id to each record as the unique identifier of the record. In the above embodiment with the user as the recognition object, the server needs to assign a unique identifier to the user, and there should be no duplicate users in the record set of the real-time status data table. When the user generates corresponding status data, if there is no record for the user before, the server will add a new record for the user after the current last record. When there is already a record for the user, the server will update the value of the record on the existing record instead of adding a new record. The server can also update other information that may need to be updated. Please refer to Table 1:

[0049] Table 1: playerStatus

[0050]

[0051] Table 1 demonstrates an embodiment of a real-time status data table. Its table name is playerStatus, and there are three fields in the table: id, name, and status. Among them, id is the unique identifier of the record, status is the value of the record, and name is the unique identifier of the user. The data in the field with the unique identifier attribute cannot have duplicate records. This setting here can ensure that each user has a definite real-time status.

[0052] Step S24, write the non-status data into the non-status data table.

[0053] The non-status data table is used to record non-status data. Please refer to Table 2:

[0054] Table 2: Player

[0055]

[0056] Table 2 demonstrates an embodiment of a non-status data table. Under the solution of the embodiment of the present application, the operation rules of only allowing addition and query and not allowing deletion and modification need to be followed. Therefore, if there is a second data write for the same user, a new record must be added instead of updating the old record.

[0057] The table name of the data table in Table 2 is Player. There are four fields in the table: id, name, data, and timestamp. Among them, id is the unique identifier of the record; data is the value of the record; name is the user's name and is not a unique identifier; non-status data tables usually contain a timestamp field to form traceability. As can be seen from Table 2, for User A, there are two records with ids 0 and 2 respectively, and the data values of the records are different, indicating that the user has updated the avatar, with an interval of about 7 days; for User B, there are two records with ids 1 and 4 respectively, and the data values of the records are different, indicating that the user has updated the nickname, with an interval of about 3 months; for User C, there are two records with ids 3 and 5 respectively, and the data values of the records are different, indicating that the user has updated the avatar, with an interval of about 10 months. In this demonstration, the function of traceability is demonstrated.

[0058] Step S25, regularly respond to the status data persistence event, and write the latest status data saved in the real-time status data table as the first new record into the non-real-time status data table of the non-status database.

[0059] In some embodiments, to improve the performance of high-frequency updates and simple numerical queries, the status database usually uses a NOSQL type of in-memory database. To prevent data loss in this type of database when the computer powers off, the data needs to be transferred to a more durable medium. The status data persistence event is an event that transfers and solidifies the status data to a persistent storage device (such as a hard disk). Note that the transfer described in the embodiments of the present application does not involve the part of deleting the original data, but is a backup storage operation. The server triggers the status data persistence event according to a preset transfer time interval, and the transfer time interval can be 6 hours or 24 hours or 7 days or any other time interval.

[0060] The latest status data is the data in the real-time status data table. The meaning of "latest" is to illustrate that the data version at this time is in the latest position on the time line. Since the data in the real-time status data table is always the latest data at that time, there is no need to make a special selection in actual operation, and only need to transfer it on the spot.

[0061] When the data is transferred to the non-real-time status data table of the non-status database, the data structure may change because the unique identification restriction on a certain identification content will be removed. As shown in Table 3, continuing the scenario of the previous Table 1, in the non-real-time status data table, the field of the user name no longer has a uniqueness restriction, which means that the user can have multiple records in this table. In fact, the user not only appears repeatedly, but also in an infinite loop mode; in a more optimized embodiment solution, some users who have not had relevant information updates recently may be skipped.

[0062] Table 3: PlayerStatus

[0063]

[0064] The embodiment demonstrated in Table 3 is a non-real-time status data table in a non-status database, named PlayerStatus, which serves as the corresponding persistent transfer table for Table 1. As can be seen from Table 3, the data records generated by the latest round of persistent events will appear at the bottom of the data table. To facilitate subsequent work, such as traceability and auditing, this type of non-real-time status data table also includes a timestamp field.

[0065] As mentioned above, the non-status data stored in the non-status database is not updated in real time, while the status data stored in the status database is updated in real time. To record the historical status data of the real-time status data table, the embodiment of the present application periodically transfers the latest status data of the real-time status data table to the non-real-time status data table, which can reduce the high-frequency access to the non-status database and improve the data read and write efficiency.

[0066] Step S26, regularly respond to the data immutability event, perform a hashing operation on the newly added data stored in the non-status database, and obtain the first operation result.

[0067] The data immutability event is an event for performing immutability processing on the newly added data in the non-status database. The server triggers the data immutability operation event at a preset frequency. For example, every 24 hours or 7 days, the server performs the data immutability operation.

[0068] In this embodiment, the newly added data is the data newly added after the previous regular data immutability event. If the current data immutability event is the first data immutability event, the newly added data is all the current data.

[0069] In some embodiments, the newly added data may include old data that has been included in previous immutability events, which does not affect the effectiveness of the overall method framework.

[0070] Generally, the newly added data in the non-status database mainly comes from the business data of the non-status data table and the non-real-time status data table (business data refers to data that does not come from the data generated for implementing the embodiments of the present application, such as the data in the summary table), and a small amount comes from the new records generated by the immutability event in the summary table. In special cases, when there is no newly added data in both the non-status data table and the non-real-time status data table, the summary table may or may not generate new records, depending on whether the preset rules of the data immutability event allow the newly added data to form records.

[0071] New records in the non-status database. For the non-status data table, compared with Table 2, in the embodiments of the present application, non-status data of User Ding, User Wu, and User Jia are newly added to the non-status data table, resulting in Table 4.

[0072] Table 4: Player

[0073]

[0074] In Table 3 and Table 4, the newly added data part is distinguished by italic font style.

[0075] In the embodiments of the present application, the hashing operation is used to reduce the amount of large data and retain its specificity for storage and later differentiation.

[0076] In some embodiments, obtaining the first operation result by performing a hashing operation on the newly added data stored in the non-status database includes the following steps: combining all the latest data of the non-status data table and the non-real-time status data table, and the newly added records generated when the summary table performed the non-tampering operation last time to obtain combined data, and performing a hashing operation on the combined data to obtain the first operation result. For example, in the embodiments of the present application, the italic-style data in Table 3, the italic-style data in Table 4, and the previous record in the summary table are combined to obtain combined data, and a hashing operation is performed on the combined data based on the hash algorithm to obtain the first operation result.

[0077] In some other embodiments, the hashing operation is processed separately for each data table. Obtaining the first operation result by performing a hashing operation on the newly added data stored in the non-status database includes the following steps: screening the target data tables containing the newly added data in the non-status database, where the target data table is one of the non-status data table, the non-real-time status data table, and the summary table, forming a set of data tables to be hashed with all the target data tables, and performing a hashing operation on each target data table in the set of data tables to be hashed to obtain the first operation result corresponding to each target data table.

[0078] For example, the non-status database is configured with a first non-status data table Player, a second non-status data table F2, a third non-status data table F3, a first non-real-time status data table X1, a second non-real-time status data table PlayerStatus, a third non-real-time status data table X3, and a summary table Digest.

[0079] Compared with the previous record operation, there is the addition of the latest non-status data in both the first non-status data table Player and the second non-status data table F2. There is no addition of the latest non-status data in the third non-status data table F3. There is the addition of the latest status data in both the second non-real-time status data table PlayerStatus and the third non-real-time status data table X3. There is no addition of the latest status data in the first non-real-time status data table X1.

[0080] Therefore, the first non-status data table Player, the second non-status data table F2, the second non-real-time status data table PlayerStatus, and the third non-real-time status data table X3 are all target data tables.

[0081] In addition, since there is the addition of the latest status data in the first non-status data table Player, the second non-status data table F2, the second non-real-time status data table PlayerStatus, and the third non-real-time status data table X3, and the second new records corresponding to the first non-status data table Player, the second non-status data table F2, the second non-real-time status data table PlayerStatus, and the third non-real-time status data table X3 are all written into the summary table Digest, there is also new data in the summary table Digest. The new data in the summary table Digest is the second new records corresponding to the first non-status data table Player, the second non-status data table F2, the second non-real-time status data table PlayerStatus, and the third non-real-time status data table X3. Therefore, the summary table Digest is also a target data table.

[0082] Therefore, the first non-status data table Player, the second non-status data table F2, the second non-real-time status data table PlayerStatus, the third non-real-time status data table X3, and the summary table Digest are all target data tables.

[0083] In the embodiment of the present application, the first non-status data table Player, the second non-status data table F2, the second non-real-time status data table PlayerStatus, and the third non-real-time status data table X3 are added to the set of data tables to be hashed. Therefore, the set of data tables to be hashed Q = {Player, F2, PlayerStatus, X3, Digest}.

[0084] The embodiments of the present application sequentially perform hash operation processing on the first non-status data table Player, the second non-status data table F2, the second non-real-time status data table PlayerStatus, the third non-real-time status data table X3, and the digest table Digest, respectively, to obtain the first operation result corresponding to the first non-status data table Player, the first operation result corresponding to the second non-status data table F2, the first operation result corresponding to the second non-real-time status data table PlayerStatus, the first operation result corresponding to the third non-real-time status data table X3, and the first operation result corresponding to the digest table Digest.

[0085] The digest table includes a record identifier, a record timestamp, and record content. The record identifier is the record id (unique identifier) and is used to identify the current record. The record timestamp is the time when the current record is written into the digest table, and the record content is the first operation result corresponding to the target data table.

[0086] The embodiments of the present application sequentially generate a new record for each target data table in the digest table. The record id is automatically generated by the preset rule for adding new records in the database, usually the numerical value of the previous id is incremented by 1, and the first operation result and the record timestamp of the target data table are written into the corresponding fields of the new record.

[0087] Table 5: Digest

[0088]

[0089] As shown in the digest table embodiment in Table 5, the table name is Digest, id is the field name of the record unique identifier, and the record id is stored here; hash is the field name of the record content, and the first operation result is stored here; created is the field name of the record timestamp, and the exact time at this moment is stored here. In addition, in the scenario of this embodiment, there is also a table field that stores the name of the target data table as the table name identifier. This identifier has no uniqueness restriction because records will be generated cyclically for each target data table.

[0090] It can be understood that in Table 5, the record ids from 0 to 67 are all historical records of the digest table. For the sake of brief display, Table 5 does not show the records with record ids from 0 to 67, but only shows the latest records with record ids from 68 to 72. Among them, record 68 is the record corresponding to the first non-status data table Player, record 69 is the record corresponding to the second non-status data table F2, record 70 is the record corresponding to the second non-real-time status data table PlayerStatus, record 71 is the record corresponding to the third non-real-time status data table X3, and record 72 is the record corresponding to the digest table Digest.

[0091] The embodiments of the present application generate a first operation result for each target data table, and lock and make each target data table non-tamperable, which is beneficial to more accurately and reliably tracking the tampering changes of each target data table subsequently, thereby improving the auditability of the target data table.

[0092] Performing a hashing operation process on each target data table in the hash data table set to obtain a first operation result corresponding to each target data table includes the following steps: obtaining the newly added data in the target data table, putting the newly added data into the pre-hash data set, splicing the data in the pre-hash data set into a pre-hash string, and performing a hashing operation on the pre-hash string to obtain a first operation result corresponding to each target data table.

[0093] For example, referring to Table 3, the newly added data in the target data table PlayerStatus in this embodiment includes the first data with id = 3, the second data with id = 4, and the third data with id = 5.

[0094] The embodiments of the present application put the first data D1, the second data D2, and the third data D3 into the pre-hash data set W, and splice the data in the pre-hash data set W into a pre-hash string Sn according to a preset rule. For example, splicing D1 + D2 + D3 in sequence into the pre-hash string Sn, or splicing D2 + D1 + D3 in sequence into the pre-hash string Sn, or splicing D3 + D2 + D1 in sequence into the pre-hash string Sn, etc. The embodiments of the present application perform a hashing operation on the pre-hash string Sn to obtain a first operation result corresponding to the target data table.

[0095] In some embodiments, the pre-hash data set further includes the previous result of the previous hashing operation on the target data table in the summary table. Correspondingly, splicing the data in the pre-hash data set into a pre-hash string includes the following steps: splicing the data in the pre-hash data set with the previous result into a pre-hash string.

[0096] For example, the pre-hash data set W includes the first data D1, the second data D2, the third data D3, and the previous result H01. Splicing the data in the pre-hash data set W into a pre-hash string Sn according to a preset rule, that is, Sn = D1 + D2 + D2 + H01. The embodiments of the present application perform a hashing operation on the pre-hash string to obtain a first operation result corresponding to each target data table.

[0097] In some embodiments, the information identifier of the last piece of historical information is included in the most recent record of the summary table regarding the target data table. The last piece of historical information is the last piece of information included in the target data table during the non-tamperable event, and the most recent record is the record in the summary table whose time is before the second newly added record, as shown in Table 6:

[0098] Table 6: Digest

[0099]

[0100] As shown in Table 6, the digest table, with the table name Hash and the LRID being the information identifier of the last historical information.

[0101] Obtaining the newly added data in the target data table includes the following steps: Based on the information identifier of the last historical information, collect the information arranged after the last historical information in the target data table to obtain the newly added data. For example, referring to Table 3 and Table 6, the most recent record in the digest table Digest regarding the target data table PlayerStatus is the record with id = 70. When the last historical information in the newly added data was the data of User C with id = 2 during the last non-tampering event in the target data table PlayerStatus, the value of the LRID field in record 70 of the digest table is 2. In the embodiments of the present application, the information identifier of the last historical information corresponding to each target data table is added to the digest table, which is beneficial for quickly identifying the newly added data in the target data table and improving the data storage efficiency.

[0102] Step S27, generating a second newly added record based on the first operation result.

[0103] Generating a second newly added record based on the first operation result includes the following steps: Determine the table name identifier of the target data table, where the table name identifier is used to identify the target data table, and form a second newly added record regarding the target data table by combining the first operation result with the table name identifier.

[0104] Determining the table name identifier of the target data table includes the following steps: Obtain the table name of the target data table, and perform desensitization processing on the table name of the target data table to obtain the table name identifier. In the embodiments of the present application, by performing desensitization processing on the table name of the target data table, for example, converting the table name Player to F1, converting the table name PlayerStatus to X2, converting the table name Digest to Z0, etc., referring to the differences between Table 6 and Table 7, users cannot distinguish which part of the content belongs to the target data table through the digest table, thus improving the privacy of the content of the target data table recorded in the digest table.

[0105] The newly added data includes multiple newly added information arranged in chronological order. Combining the first operation result with the identifier to form a second newly added record regarding the target data table includes the following steps: Find the last newly added information from the newly added data, and form a second newly added record regarding the target data table by combining the first operation result, the table name identifier, and the last newly added information.

[0106] Please refer to Table 6. In the records of the non-status data table Player (F1) in the Digest of the embodiments of the present application, retrieve the most recent record, that is, the record with id = 68. Based on the last piece of historical information, that is, the value of LRID is 5, return to the non-status data table Player (F1) and query the record with id = 5. Based on the records after this record, determine that the information with id = 6, id = 7, and id = 8 are all newly added data. Then, generate a new first operation result based on the information with id = 6, id = 7, and id = 8. Among them, the id of the last record, 8, is the value of the LRID field of the new record written into the Digest table. Update Table 6 to obtain Table 7 as shown below:

[0107] Table 7: Digest

[0108]

[0109] As shown in Table 7, the Digest table, with the table name Digest, after the desensitization process of the table name field as described above, the embodiments of the present application generate a new first operation result Hash6 based on the information with id = 6, id = 7, and id = 8. Among them, the information identifier LRID of the last piece of historical information in this non-tamperable event is 8.

[0110] Step S28, write the second newly added record into the Digest table of the non-status database.

[0111] As shown in Table 7, write the new first operation result Hash6 into the hash field of the second newly added record, write 8 into the information identifier LRID field of the last newly added information, write the timestamp T6 into the timestamp field created, write the desensitized non-status data table name F1 into the table field. The system automatically assigns a new id = 73 as the record id of the second newly added record, and write this second newly added record into the Digest table of the non-status database.

[0112] It can be understood that data non-tamperability is one of the core improvements of the embodiments of the present application. The non-status database will regularly perform non-tamperable operations on newly added data, which includes a Digest table for recording each non-tamperable operation. As described above, the embodiments of the present application perform a hash digest calculation on the newly added data after the last operation together with the Digest recorded in the last operation, and then record the calculation result together with the timestamp and the new id into the Digest table.

[0113] To further optimize security and management convenience, new data can be recorded separately for each data table, including the data tables storing non-real-time status data, the data tables storing non-status data, and the summary table itself. At this time, the records in the summary table will also include the table name identifiers of the data tables being recorded. Moreover, for greater security, relevant data can be desensitized first to avoid the leakage of sensitive information.

[0114] In some embodiments, the method further includes the following steps: publishing the summary table in real time. To ensure immutability, the content of the summary table in the embodiments of the present application is published online in real time to form a distributed record. This distributed record method makes it extremely difficult for any party to tamper with the data because the tampering behavior requires modifying the data on multiple distributed nodes simultaneously, greatly increasing the cost and difficulty of tampering.

[0115] In some embodiments, the method further includes the following steps: periodically responding to the summary on-chain event, performing a hashing operation on the new summary data in the summary table stored in the non-status database to obtain a second operation result, and writing the second operation result into the blockchain. The new summary data is the newly added summary data since the last periodic summary on-chain event. If this event is the first event, the new summary data is all the current data in the summary table.

[0116] In the embodiments of the present application, the summary table can be periodically uploaded to the blockchain. By leveraging the immutable feature of the blockchain itself, the difficulty of data tampering is further enhanced, ensuring data security.

[0117] To elaborate in detail on the data storage method provided by the embodiments of the present application, the following will be described in detail in conjunction with Figure 3 as follows:

[0118] Please refer to Figure 3 , the server is configured with a status database 31 and a non-status database 32. The status database 31 is configured with a first real-time status data table Y1, a second real-time status data table Y2, and a third real-time status data table Y3. The non-status database is configured with a first non-status data table F1, a second non-status data table F2, a third non-status data table F3, a first non-real-time status data table X1, a second non-real-time status data table X2, a third non-real-time status data table X3, and a summary table Z0. The first real-time status data table Y1 corresponds to the first non-real-time status data table X1, the second real-time status data table Y2 corresponds to the second non-real-time status data table X2, and the third real-time status data table Y3 corresponds to the third non-real-time status data table X3.

[0119] ① The server writes the first latest non-status data into the first non-status data table F1, writes the second latest non-status data into the second non-status data table F2, and writes the third latest non-status data into the third non-status data table F3.

[0120] ② When the server responds to the first state data persistence event 33, it writes the first latest state data saved in the first real-time state data table Y1 as the first new record into the first non-real-time state data table X1.

[0121] When the server responds to the second state data persistence event 34, it writes the second latest state data saved in the second real-time state data table Y2 as the first new record into the second non-real-time state data table X2.

[0122] When the server responds to the third state data persistence event 35, it writes the third latest state data saved in the third real-time state data table Y3 as the first new record into the third non-real-time state data table X3.

[0123] ③ When the server responds to the first data non-tampering event 36, it performs a hashing operation on the new data saved in the first non-real-time state data table X1 to obtain a first operation result, generates a second new record 37 based on the first operation result, and writes the second new record 37 into the digest table Z0.

[0124] When the server responds to the second data non-tampering event 38, it performs a hashing operation on the new data saved in the second non-real-time state data table X2 to obtain a first operation result, generates a second new record 39 based on the first operation result, and writes the second new record 39 into the digest table Z0.

[0125] When the server responds to the third data non-tampering event 310, it performs a hashing operation on the new data saved in the third non-real-time state data table X3 to obtain a first operation result, generates a second new record 311 based on the first operation result, and writes the second new record 311 into the digest table Z0.

[0126] When the server responds to the fourth data non-tampering event 312, it performs a hashing operation on the new data saved in the first non-state data table F1 to obtain a first operation result, generates a second new record 313 based on the first operation result, and writes the second new record 313 into the digest table Z0.

[0127] When the server responds to the fifth data non-tampering event 314, it performs a hashing operation on the new data saved in the second non-state data table F2 to obtain a first operation result, generates a second new record 315 based on the first operation result, and writes the second new record 315 into the digest table Z0.

[0128] The server responds to the sixth data non-tampering event 316, performs a hashing operation on the newly added data stored in the third non-state data table F3 to obtain a first operation result, generates a second new record 317 based on the first operation result, and writes the second new record 317 into the summary table Z0.

[0129] The server responds to the seventh data non-tampering event 318, performs a hashing operation on the newly added data stored in the summary table Z0 to obtain a first operation result, generates a second new record 319 based on the first operation result, and writes the second new record 319 into the summary table Z0.

[0130] Through the above series of improvement measures, the embodiments of the present application not only add the non-tampering ability to the traditional database, realizing the same data right confirmation, traceability, auditing and natural credibility as the blockchain, but also retain the highly developed data processing capabilities of traditional databases such as relational databases, such as joining tables for query, efficient reading and writing, etc. Moreover, due to the separation of state data and other data and the adoption of an append-only query design, the parallel processing transaction ability and reading and writing efficiency of relational databases are significantly improved, effectively solving the problems existing in traditional databases in many aspects.

[0131] In order to elaborate in detail on the data storage method provided by the embodiments of the present application, the embodiments of the present application implement the improvement of the traditional database in combination with the specific steps and methods of the following examples to achieve the goals of enhancing the non-tampering ability, improving data integrity and auditability, and optimizing concurrency and reading and writing performance, specifically as follows:

[0132] ① Data classification and database initialization

[0133] a. When the system starts, the data classification module is initialized. When user data enters the storage process, the data classification module determines the data type of the user data according to preset rules. For example, in the e-commerce business scenario, order status (such as pending payment, paid, shipped, etc.), real-time sales volume of goods, etc. will be determined as state data; while product name, description, merchant information, etc. are classified as non-state data.

[0134] b. At the same time, the state database and the non-state database are initialized. The state database is configured to support addition, deletion, query, and modification operations, while the non-state database is set to only support addition and query operations, restricting the deletion and modification permissions of non-state data at the database level.

[0135] ② State data processing flow

[0136] c. During the daily business operation, the status data is updated in real time in the status database. For example, in an online shopping mall system, when a new order is generated, the "pending payment" status record of the order is added to the status database; when the user completes the payment, the order status is updated to "paid", and the corresponding record in the status database is modified.

[0137] d. The status database transfers the status data to the non-status database in the form of new records according to the set time period (such as every hour, every day, etc., and the specific period can be flexibly adjusted according to business requirements). For example, at 2:00 am every day, the system will add the latest status of all orders with status updates within the previous day as non-real-time status data to the non-status database.

[0138] ③ Non-status data processing flow

[0139] e. Non-status data is directly stored in the non-status database when it is generated. For example, the merchant information submitted when a new merchant joins the platform is directly saved to the non-status database. Since the non-status database only supports addition and query operations, the entered data cannot be directly modified or deleted. When the existing merchant information changes, the system will add new records to the relevant non-status data tables in the non-status database.

[0140] f. The non-status database periodically (such as at regular time intervals or when a certain data volume is reached) performs an immutability operation on the newly added data. Taking the product information table (i.e., the target data table) of an e-commerce platform as an example, assume that an immutability operation is performed every time 100 pieces of product information are newly added. The system will obtain the 100 pieces of product information data newly added after the last operation, as well as the digest value recorded in the digest table during the last operation, and perform a hash digest calculation together (a mature hash algorithm such as SHA-256 can be selected). After calculating the new hash value (i.e., the first operation result), a unique new record identifier is generated, and the timestamp of the current operation is recorded. The new hash value, timestamp, new record identifier, and the table name identifier of the product information table are recorded in the digest table together.

[0141] ④ Digest table management and distributed guarantee

[0142] g. When the digest table records each immutability operation, in addition to the information mentioned above, it records the relevant information for different types of target data tables (the data tables storing non-real-time status data, the data tables storing non-status data, and the digest table itself) respectively. For example, for the order status change table storing non-real-time status data, the digest table will clearly identify the target data table when recording its relevant operation information.

[0143] h. The content of the abstract table is published online in real time, which can be achieved by building a distributed server network. Each distributed node synchronizes the information of the abstract table in real time to ensure data consistency and wide dissemination. For example, server nodes are deployed in multiple regions around the world, and each node can obtain and store the latest content of the abstract table in real time.

[0144] i. To further strengthen the immutability, the abstract table can be chained on the blockchain according to a set time period (such as weekly, monthly, etc.). Select a suitable blockchain platform (such as a consortium blockchain, etc., selected according to the business requirements for privacy and performance), encapsulate the abstract data of the abstract table according to the format and rules of the blockchain, add it to the blocks of the blockchain, and utilize the consensus mechanism and encryption technology of the blockchain to ensure the immutability of the data.

[0145] ⑤ Data query process

[0146] j. When a query request is initiated, the system first determines the type of data to be queried. If it is status data, the query is directly performed in the status database. For example, to query the real-time status of a current order, the result can be quickly obtained from the status database.

[0147] k. If the data to be queried is non-status data or non-real-time status data, the query operation is performed in the non-status database. Since the non-status database only supports addition and query and the data has immutability, the query operation is more efficient and stable. For example, to query the historical price record of a certain commodity (non-real-time status data) or the basic information of a commodity (non-status data), the result can be quickly returned from the non-status database.

[0148] Through the above specific implementation manners, each module and process cooperate closely to achieve an overall improvement in the traditional database in terms of immutability, data integrity, auditability, and concurrent and read / write performance.

[0149] Based on the discussions of the above various embodiments, the embodiments of the present application at least have the following distinguishing points:

[0150] 1) Data classification strategy: Accurately distinguishing status data from non-status data is the cornerstone of the entire solution. This classification enables data with different characteristics to adapt to different storage and management methods, which is a prerequisite for achieving goals such as immutability and performance optimization.

[0151] 2) Dual database architecture and operation permission setting: The separate design of the status database and the non-status database, and the respectively granted permissions of addition, deletion, query, modification and only addition and query, ensure the stability and immutability of the data from the architectural level, and at the same time improve the concurrent processing ability.

[0152] 3) State record persistence mechanism: State data is periodically transferred and stored as new records in a non-state database to become non-real-time state data, retaining the data change history, which is crucial for data integrity and audibility.

[0153] 4) Data non-tampering process: The non-tampering operation of the non-state database on newly added data, including steps such as calculating a new hash value in combination with the previous digest, timestamp, and new record identifier into the digest table, is the core process for achieving data non-tampering.

[0154] 5) Digest table management and distributed guarantee: The digest table details the non-tampering operation information, which is publicly announced in real time on the network and periodically uploaded to the blockchain, strengthening data non-tampering and ensuring data security.

[0155] 6) Performance optimization means: Using NoSQL key-value pair in-memory databases such as Redis to improve the performance of the state database, further optimizing the overall read and write performance.

[0156] 7) Data classification and dual-database construction method: Covering the classification determination rules for state data and non-state data, as well as the initialization and configuration methods of the state database and non-state database, preventing others from adopting similar data classification and database construction strategies without authorization.

[0157] 8) State data processing process: Including the update method of state data in the state database, as well as the specific steps and time period settings for periodically transferring and storing it as non-real-time state data to the non-state database, protecting this process from being copied.

[0158] 9) Non-tampering operation of non-state data: The complete operation process from selecting newly added data, calculating the hash value in combination with the previous digest, to recording in the digest table, preventing others from using the same non-tampering implementation means.

[0159] 10) Digest table management and the mechanism of combining distribution and blockchain: Including the composition of the information recorded in the digest table, the real-time publication method, as well as the process and cycle settings for uploading to the blockchain, protecting this management and guarantee mechanism from being imitated.

[0160] 11) Performance optimization implementation method: The specific integration method of using a NoSQL in-memory database (such as Redis) to improve the performance of the state database, data caching strategy, etc., preventing others from using similar performance optimization means without permission.

[0161] The dual-database collaborative management solution proposed in the embodiments of this application brings significant beneficial effects to database applications from multiple dimensions, specifically as follows:

[0162] In terms of data security and integrity:

[0163] A. Enhancement of tamper - proof ability: By storing non - state data in a non - state database that only supports addition and query operations, and regularly performing tamper - proof processing on the newly added data, combined with means such as summary table records, distributed publication, and blockchain uploading, a multi - level data tamper - proof guarantee system is constructed. This makes it almost impossible for critical data in the database to be maliciously tampered with once recorded, greatly enhancing the security and credibility of the data. For example, in the scenario of financial transaction records, after each transaction data is stored as non - state data, its integrity and authenticity can be effectively guaranteed in the long term, preventing financial risks caused by data tampering.

[0164] B. Improvement of data integrity and auditability: State data is regularly transferred and stored as non - real - time state data, and updated in the form of new records, retaining a complete historical track of data changes. Combining with the summary table to record detailed information of each tamper - proof operation, including timestamps, data table identifiers, etc., enables precise tracing of every change of the data when auditing is required, clearly identifying key information such as the change time and the data tables involved, providing strong support for data compliance review and problem troubleshooting.

[0165] C. Enhancement of concurrent processing ability: Data is divided into state data and non - state data and stored in databases with different characteristics respectively, reducing resource competition during data operations. The state database focuses on processing frequently updated state data, and the non - state database processes relatively static non - state data. This separation method enables the database to allocate resources more efficiently when processing concurrent transactions, reducing the occurrence of lock contention. For example, in a high - concurrency e - commerce promotion activity, the update of order status (state data) and the query of basic product information (non - state data) can be carried out simultaneously and efficiently without interference, significantly enhancing the system's processing ability in high - concurrency scenarios.

[0166] D. Improvement in read and write performance: Non-state databases only support addition and query operations. Their data structures and operation logics are relatively simple, which provides a more efficient execution environment for query operations. At the same time, the centralized management of state data and optimized update strategies in state databases also make the read and write operations of state data smoother. In addition, NoSQL key-value pair in-memory databases such as Redis can be used to further enhance the performance of state databases. Redis is based on in-memory storage and has extremely high read and write speeds. For state data that is frequently updated and queried, using Redis as part of the state database can cache hot data in it, greatly reducing disk I / O operations, thus significantly improving the read and write performance of state data. For example, in scenarios such as real-time statistics of the number of online users and real-time sales volume of goods, leveraging the fast read and write capabilities of Redis can quickly respond to data update and query requests, bringing a qualitative leap to the overall performance of the system. This way of combining relational databases with NoSQL in-memory databases gives full play to the advantages of both, comprehensively improving the read and write performance of the database and providing users with a faster data access experience.

[0167] F. Combining the advantages of traditional databases and blockchain: The present invention not only retains the powerful capabilities of traditional databases such as relational databases in data processing, such as complex joined table queries and efficient data read and write, but also integrates the characteristics of blockchain technology in data immutability, rights confirmation, and traceability. This combination enables the database system to not only meet the requirements of daily business for data processing efficiency but also reach a high standard in terms of data security and credibility, and is applicable to various business scenarios with strict data requirements, such as the medical and government affairs fields.

[0168] G. Good scalability: Whether it is a state database or a non-state database, their architecture designs have good scalability. As the volume of business data grows, the system performance can be easily expanded by adding server nodes, optimizing the storage structure, etc. At the same time, the distributed storage of summary tables and the blockchain on-chain mechanism can also be flexibly adjusted and expanded according to business needs to adapt to business development of different scales.

[0169] In summary, through innovative designs and technology integrations, the embodiments of this application have brought significant improvements in multiple aspects to traditional databases, providing more powerful, secure, and efficient support for various business systems that rely on databases.

[0170] It should be noted that in the above various embodiments, there is not necessarily a certain sequence among the above steps. Those of ordinary skill in the art can understand according to the descriptions of the embodiments of this application that in different embodiments, the above steps can have different execution sequences, that is, they can be executed in parallel or exchanged, etc.

[0171] As another aspect of the embodiments of the present application, the embodiments of the present application provide a data storage device. Among them, the data storage device may be a software module, and the software module includes a number of instructions stored in a memory. A processor can access the memory and call the instructions for execution to complete the data storage methods described in the above various embodiments.

[0172] In some embodiments, the data storage device can also be built by hardware devices. For example, the data storage device can be built by one or more than two chips, and each chip can work in coordination with each other to complete the data storage methods described in the above various embodiments. For another example, the data storage device can also be built by various logic devices, such as being built by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a single-chip microcomputer, an ARM (Acorn RISC Machine), or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination of these components.

[0173] Please refer to Figure 4 , the data storage device 400 includes: a data acquisition module 41, a data parsing module 42, a first writing module 43, a second writing module 44, a first adding module 45, an operation module 46, a second adding module 47, and a digest update module 48.

[0174] The data acquisition module 41 is used to acquire user data. The data parsing module 42 is used to parse status data and non-status data from the user data. The status data is data that is updated in real time, and the non-status data is the data in the user data excluding the status data. The preset status database is configured with a real-time status data table, and the preset non-status database is configured with a non-status data table, a non-real-time status data table, and a summary table. The status database is a database that supports functions of addition, deletion, query, and modification, and the non-status database is a database that only supports functions of query and addition. The first writing module 43 is used to write the status data into the real-time status data table. The second writing module 44 is used to write the non-status data into the non-status data table. The first adding module 45 is used to periodically respond to the status data persistence event, and write the latest status data saved in the real-time status data table as the first added record into the non-real-time status data table of the non-status database. The operation module 46 is used to periodically respond to the data non-tampering event, perform a hashing operation on the newly added data saved in the non-status database to obtain a first operation result. The newly added data is the data that has been newly added since the last periodic data non-tampering event. If the current data non-tampering event is the first data non-tampering event, the newly added data is all the current data in the non-status database. The second adding module 47 is used to generate a second added record based on the first operation result. The summary update module 48 is used to write the second added record into the summary table of the non-status database.

[0175] In some embodiments, the operation module 46 is specifically configured to: screen a target data table containing newly added data in the non-status database. The target data table is one of the non-status data table, the non-real-time status data table, and the summary table. Form a set of data tables to be hashed with all the target data tables, and perform a hashing operation on each target data table in the set of data tables to be hashed to obtain a first operation result corresponding to each target data table.

[0176] In some embodiments, the operation module 46 is further specifically configured to: obtain the newly added data in the target data table, put the newly added data into a pre-hashing data set, splice the data in the pre-hashing data set into a pre-hashing string, and perform a hashing operation on the pre-hashing string to obtain a first operation result corresponding to each target data table.

[0177] In some embodiments, the pre-hashing data set further includes the previous result of the hashing operation on the target data table in the summary table. Correspondingly, the operation module 46 is further specifically configured to: splice the data in the pre-hashing data set with the previous result into a pre-hashing string.

[0178] In some embodiments, the information identifier of the last piece of historical information is included in the most recent record of the summary table regarding the target data table. The last piece of historical information is the last piece of information included during the non-tampering event in the target data table. The most recent record is a record whose time is before the second newly added record. The operation module 46 is further specifically configured to: collect the information arranged after the last piece of historical information in the target data table based on the information identifier of the last piece of historical information, and obtain newly added data.

[0179] In some embodiments, the second newly added module 47 is specifically configured to: determine the table name identifier of the target data table, where the table name identifier is used to identify the target data table, and form a second newly added record regarding the target data table by combining the first operation result and the table name identifier.

[0180] In some embodiments, the second newly added module 47 is further specifically configured to: obtain the table name of the target data table, perform a desensitization process on the table name of the target data table, and obtain the table name identifier.

[0181] In some embodiments, the newly added data includes multiple pieces of newly added information arranged in chronological order. The second newly added module 47 is further specifically configured to: find the last piece of newly added information from the newly added data, and form a second newly added record regarding the target data table by combining the first operation result, the table name identifier, and the last piece of newly added information.

[0182] In some embodiments, the second newly added module 47 is further specifically configured to: publicly announce the summary table in real time.

[0183] In some embodiments, the second newly added module 47 is further specifically configured to: periodically respond to the summary on-chain event, perform a hashing operation on the new summary data in the summary table stored in the non-state database to obtain a second operation result, and write the second operation result into the blockchain. The new summary data is the newly added summary data since the last periodic summary on-chain event. If this event is the first event, the new summary data is all the current data in the summary table.

[0184] It should be noted that the above data storage device can execute the data storage method provided by the embodiments of the present application, and has the corresponding functional modules and beneficial effects for executing the method. For the technical details not described in detail in the embodiments of the data storage device, reference can be made to the data storage method provided by the embodiments of the present application.

[0185] See Figure 5 , Figure 5A schematic structural diagram of a server provided by an embodiment of the present application. The server 500 includes one or more processors 51 and a memory 52. The memory 52 is connected to one or more processors 51, for example, connected to the processor through a bus.

[0186] The processor 51 is configured to support the server to execute the corresponding functions in the methods of the above method embodiments. The processor may be a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof. The above hardware chip may be an application specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0187] The memory 52 is used to store program codes and the like. The memory may include volatile memory (VM), such as random access memory (RAM); the memory may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); the memory may further include a combination of the above types of memories.

[0188] The memory 52 can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the data storage method in the embodiment of the present application. The processor executes various functional applications and data processing of the data storage method and the data storage device by running the non-volatile software programs, instructions, and modules stored in the memory, that is, implements the functions of the various modules or units of the data storage method and the data storage device provided by the above method embodiments.

[0189] The memory 52 may include a program storage area and a data storage area. The program storage area may store an operating system and application programs required for at least one function. The data storage area may store data created according to the use of the data storage device, etc. In some embodiments, the memory may optionally include a memory remotely provided with respect to the processor, and these remote memories may be connected to the data storage device through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0190] The one or more modules are stored in the memory and, when executed by the one or more processors, execute the data storage method in any of the above method embodiments. For example, the method steps described in the above method embodiments are executed to implement the functions of the modules described in the above apparatus embodiments.

[0191] The embodiments of the present application further provide a computer-readable storage medium storing a computer program, where the computer program includes program instructions, and the program instructions, when executed by a computer, cause the computer to execute the method as described in the foregoing embodiments.

[0192] Those of ordinary skill in the art can understand that all or part of the processes in the above method embodiments can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it may include the processes of the above method embodiments. Among them, the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0193] The above disclosure is only for the preferred embodiments of the present application. Of course, the scope of the rights of the present application cannot be limited thereby. Therefore, equivalent changes made according to the claims of the present application still fall within the scope covered by the present application.

Claims

1. A data storage method, applied to a server, characterized in that, Including: Obtaining user data; Parsing status data and non-status data from the user data, where the status data is data updated in real time, and the non-status data is data in the user data except for the status data. A preset status database is configured with a real-time status data table, and a preset non-status database is configured with a non-status data table, a non-real-time status data table, and a summary table. The status database is a database that supports functions of addition, deletion, query, and modification, and the non-status database is a database that only supports query and addition functions; Writing the status data into the real-time status data table; Writing the non-status data into the non-status data table; Regularly responding to the status data persistence event, and writing the latest status data saved in the real-time status data table as a first new record into the non-real-time status data table of the non-status database; Regularly responding to the data immutability event, performing a hashing operation on the new data saved in the non-status database to obtain a first operation result. The new data is data that has been newly added since the last regular response to the data immutability event. If the current data immutability event is the first data immutability event, the new data is all the current data in the non-status database; Generating a second new record based on the first operation result; Writing the second new record into the summary table of the non-status database.

2. The data storage method according to claim 1, wherein The performing a hashing operation on the new data saved in the non-status database to obtain a first operation result includes: Filtering a target data table containing new data in the non-status database, where the target data table is one of the non-status data table, the non-real-time status data table, and the summary table; Forming all the target data tables into a set of data tables to be hashed; Performing a hashing operation on each target data table in the set of data tables to be hashed to obtain a first operation result corresponding to each target data table.

3. The data storage method according to claim 2, characterized in that, The performing a hashing operation on each target data table in the set of data tables to be hashed to obtain a first operation result corresponding to each target data table includes: Obtaining the new data in the target data table; Putting the new data into a pre-hashing data set; Concatenating the data in the pre-hashing data set into a pre-hashing string; Performing a hashing operation on the pre-hashing string to obtain a first operation result corresponding to each target data table.

4. The method according to claim 3, wherein The pre-hashing data set further includes the previous result of the hashing operation on the target data table in the summary table; Correspondingly, the concatenating the data in the pre-hashing data set into a pre-hashing string includes: concatenating the data in the pre-hashing data set with the previous result into a pre-hashing string.

5. The method according to claim 3, characterized in that The information identifier of the last piece of historical information is included in the most recent record of the summary table regarding the target data table. The last piece of historical information is the last piece of information included in the target data table when the data immutability event is performed. The most recent record is a record whose time is before the second new record. The obtaining the new data in the target data table includes: Based on the information identifier of the last piece of historical information, collect the information arranged after the last piece of historical information in the target data table to obtain new data.

6. The data storage method according to claim 2, wherein The generating the second new record based on the first operation result includes: Determine the table name identifier of the target data table, where the table name identifier is used to identify the target data table; Combine the first operation result and the table name identifier to form a second new record regarding the target data table.

7. The data storage method according to claim 6, wherein The determining the table name identifier of the target data table includes: Obtain the table name of the target data table; Perform desensitization processing on the table name of the target data table to obtain the table name identifier.

8. The data storage method according to claim 6, wherein The new data includes multiple pieces of new information arranged in chronological order. The combining the first operation result and the identifier to form a second new record regarding the target data table includes: Find the last piece of new information from the new data; Combine the first operation result, the table name identifier, and the last piece of new information to form a second new record regarding the target data table.

9. The method according to any one of claims 1 to 8, characterized in that It further includes: Publish the summary table in real time.

10. The method according to any one of claims 1 to 8, characterized in that, It further includes: Regularly respond to the summary on-chain event, perform a hashing operation on the new summary data in the summary table stored in the non-state database to obtain a second operation result; Write the second operation result into the blockchain. The new summary data is the newly added summary data since the last regular response to the summary on-chain event. If this summary on-chain event is the first summary on-chain event, the new summary data is all the current data in the summary table.

11. A server, characterized in that, It includes a memory and a processor, the memory is connected to the processor, and the processor is used to execute one or more computer programs stored in the memory. When the processor executes the one or more computer programs, the server implements the data storage method according to any one of claims 1-10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program includes program instructions, and when the program instructions are executed by the processor, the processor executes the data storage method according to any one of claims 1-10.

Images