CN109902086A

CN109902086A - A kind of index creation method, device and equipment

Info

Publication number: CN109902086A
Application number: CN201910100160.6A
Authority: CN
Inventors: 杨新颖
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-01-31
Filing date: 2019-01-31
Publication date: 2019-06-18
Anticipated expiration: 2039-01-31
Also published as: CN109902086B

Abstract

Disclose a kind of index creation method, device and equipment.Under the scene for carrying out the storage of centralization to data record in a manner of data block chain in service side, the cryptographic Hash of the data block determined in each data block comprising the cryptographic Hash by last data block and the data record for itself being included, the provider of data service can not easily make a change the data of storage.At this point, the concordance list for accepting timing by creation about data record in data block, can improve user experience in order to which data record is inquired and traced to the source.

Description

Index creation method, device and equipment

Technical Field

The embodiment of the specification relates to the technical field of information, in particular to an index creating method, an index creating device and index creating equipment.

Background

When the block chain type account book is used for storing data, one data block often comprises a plurality of data records, and the sequence of the data records is difficult to see by a common block chain type account book. When the data records are stored in a centralized manner in the server, there are often some associations between the data records received by the server and the order in which the data records are received. For example, the user's consumption record, or the server's operation record on a certain data or account based on the user's instruction, etc., the different acceptance orders often result in different results.

In view of this, there is a need for an index that can reflect the timing of acceptance of data records by a centralized server.

Disclosure of Invention

To solve the problem that the existing block chain type account book does not pay attention to the sequence of data records, and to achieve the purpose of improving user experience in centralized data storage, embodiments of the present specification provide an index creation method, apparatus, and device, where the method is applied to a centralized database service provider that stores data in multiple data blocks, and specifically includes:

selecting any data block, and determining a blocking time stamp of the selected data block, a sequence number of each data record in the selected data block and a hash value of each data record;

removing the last designated digit in the blocking timestamp aiming at any data record, writing the corresponding sorting serial number into the blocking timestamp, and generating the blocking timestamp containing the sorting serial number;

establishing a second index table containing the corresponding relation between the blocking timestamps of the sequencing sequence numbers and the hash values of the data records according to the sequence of the sequencing sequence numbers;

the data block comprises at least one data record except for the initial data block, each data block comprises a hash value of a previous data block and a hash value of a data block determined by the data record contained in the data block, and the block height of the data block is monotonically increased based on the sequence of the blocking time.

Correspondingly, the present specification further provides an index creating apparatus, which is applied in a centralized database service provider that stores data by a plurality of data blocks, and the apparatus includes:

the determining module is used for selecting any data block, and determining the blocking time stamp of the selected data block, the sequencing serial number of each data record in the selected data block and the hash value of each data record;

the writing module removes the last designated digit in the blocking timestamp aiming at any data record, writes the corresponding sorting serial number in the blocking timestamp and generates a blocking timestamp containing the sorting serial number;

the second index establishing module is used for establishing a second index table containing the corresponding relation between the blocking timestamps of the sequencing sequence numbers and the hash values of the data records according to the sequence of the sequencing sequence numbers;

In a scenario where a server performs centralized storage on data records in a data block chain manner, each data block includes a hash value of a previous data block and a hash value of its own data block determined by the data record included in itself, and a provider of a data service cannot easily change stored data. At this time, by creating the index table about the acceptance time sequence of the data records in the data block, the data records can be conveniently queried and traced, and the user experience is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of embodiments of the invention.

In addition, any one of the embodiments in the present specification is not required to achieve all of the effects described above.

Drawings

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present specification, and other drawings can be obtained by those skilled in the art according to the drawings.

FIG. 1 is a schematic diagram of a system architecture involved in the current art;

FIG. 2 is a flowchart illustrating an index creation method provided by an embodiment of the present specification;

FIG. 3 is a flow diagram of an exemplary partial purge provided by embodiments of the present disclosure;

FIG. 4 is a schematic diagram of a process for constructing a suppressed data record according to an embodiment of the present description;

FIG. 5 is a schematic diagram of another system architecture referred to in embodiments of the present description;

fig. 6 is a schematic structural diagram of an index creating apparatus provided in an embodiment of the present specification;

FIG. 7 is a more specific hardware architecture diagram of a computing device provided by embodiments of the present specification;

fig. 8 is a schematic diagram of a specific generation of a time service certificate according to an embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the embodiments of the present specification, the technical solutions in the embodiments of the present specification will be described in detail below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the embodiments given herein are intended to be within the scope of protection.

It should be noted that, in the current server architecture, the database server may be a client individual user directly interfaced with the server, or may be a client individual user interfaced with some application servers, and the database server interfaces with the application server. As shown in fig. 1, fig. 1 is a schematic diagram of a system architecture involved in the prior art.

Thus, in this specification embodiment, when the user is an application server, the database service provider may be the database server shown in fig. 1; when the user is a client-side individual user, the database service provider may be a server side entity including an application server and a database server. In any case, the storage of the data is completed at the database service provider, and the operation (including adding, deleting, checking and the like) on the data is also performed at the database service provider based on the instruction of the user, the user data and the operation result on the data are stored at the database service provider, and the data cannot be stored locally or on other devices of the user. In other words, the database service provider in the present specification provides data services in a centralized form.

The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings. As shown in fig. 2, fig. 2 is a schematic flowchart of an index creating method provided in an embodiment of this specification, where the flowchart specifically includes the following steps:

s201, selecting any data block, and determining a blocking time stamp of the selected data block, a sequence number of each data record in the selected data block, and a hash value of each data record.

In the embodiment of the present specification, each data block includes a unique corresponding hash value, and the hash value is determined by the hash value of the previous data block and the data record included in the data block, so as to form a chained storage mode including a plurality of data blocks. The data block comprises at least one data record except the initial data block, and the block height of the data block is monotonically increased based on the sequence of the blocking time.

When the data block is blocked, the blocking time of the data block can be confirmed and the data block is written into the data block. Therefore, for any data block, the blocking time for obtaining the data block can be directly inquired from the data block.

For data records in a data block, if there is a receiving timestamp in the data records in the block, for example, a server gives a receiving timestamp when receiving the data records, the data records may be sorted according to the receiving timestamp, and a sorting sequence number is assigned to each data record; or the sequence numbers may be assigned directly in the order in which the data records were received and reset after blocking so that the sequence numbers are assigned partially within the next data block. The hash value of the data record can be calculated at any time according to the content of the data record.

S203, removing the last designated digit in the blocking timestamp aiming at any data record, writing the corresponding sorting serial number, and generating the blocking timestamp containing the sorting serial number.

For example, if the blocking timestamp of a data block is "20 xx-01-1903: 14: 07.938576", then the last specified number of bits (assuming that the specified number of bits is 3 bits) may be erased and the sequence number of each data record in the data block written. When the sequence number of one data record is "001", the generated blocking time stamp including the sorting sequence number is "20 xx-01-1903: 14: 07.938001" for the data record.

The number of bits specified is generally related to how many data records can be written in a data block. For example, assuming that there are generally no more than 999 data records within a data block, the sequence number of the data record is generally "001" to "999", and it can be satisfied if the specified number of bits is 3, and the effective number of bits of the blocking time at this time can still be satisfied to the millisecond level, which can satisfy the normal requirement.

S205, according to the sequence of the sorting sequence numbers, a second index table containing the corresponding relation between the blocking time stamp of the sorting sequence number and the hash value of the data record is established.

In addition, a designated sorting order number that is not assigned to a data record may be added to the index to store a correspondence between a block time stamp and a block height of a data block, and the index may be written. For example, assuming that the sequence number of a data record generally starts with "001", sequence number "000" may be used to store the block height of a data block. As shown in table 2, table 2 is a second index table related to data records provided in the embodiments of the present specification. In table 2, the last three bits of the blocking time on the left side (assuming that the number of data records stored in one block does not exceed 1000) are used to store the sequence number of the data record.

TABLE 2

20xx-01-19 03:14:07.938000	Blkheight
		20xx-01-19 03:14:07.938001	Hash1
20xx-01-19 03:14:07.938002	Hash2
		20xx-01-19 03:14:07.938003	Hash3
20xx-01-19 03:14:07.938004	……

In this embodiment, the hash value of the data record may be read directly, and the block height of the data block may be identified by a specified sequence number (i.e., 000 in table 2), although a few time significands are sacrificed.

The index creation may be performed immediately at the time of block output or asynchronously. The index itself may be used for some lookup or statistical operations, for example, to count the number of data records in a certain time period, so as to avoid performing traversal counting from the data block, which is more convenient.

All the data blocks are traversed, and corresponding data records in all the data blocks are written into the index table, so that the finished index table corresponding to all the user data can be obtained. In the index table, each data record has both the blocking time of the written block (the blocking time of each data record in the same block is the same) and the sequence accepted by the service party, so that some data records with sequential relevance can be conveniently inquired and traced based on the index table, and the user experience is improved.

In the centralized database service provider according to the embodiment of the present specification, the data block is generated in advance by:

and receiving the data records to be stored, and determining the hash value of each data record. The data records to be stored here may be various consumption records of individual users of the client, and also may be business results, intermediate states, operation records, and the like generated by the application server when executing business logic based on instructions of the users. Specific business scenarios may include consumption records, audit logs, supply chains, government regulatory records, medical records, and the like.

And when the preset blocking condition is reached, determining each data record to be written into the data block, and generating the Nth data block containing the hash value of the data block and the data record. And, in an optional manner, the data block may further include a blocking time.

The preset blocking condition comprises the following steps: when the number of data records to be stored reaches a number threshold, for example, a new data block is generated every time one thousand data records are received, and one thousand data records are written into the block; alternatively, a time interval from the last blocking time reaches a time threshold, e.g., every 5 minutes, a new data block is generated, and the data records received within the 5 minutes are written into the block.

N here refers to a sequence number of the data block, that is, in the embodiment of the present specification, the data block is arranged in a block chain manner, and is arranged in sequence based on the blocking time, so that the data block has a strong timing characteristic. The block height of the data block is monotonically increased based on the sequence of the blocking time. The block height may be a sequence number, and at this time, the block height of the nth data block is N; the block height may also be generated in other ways.

When N is 1, the data block at this time is the initial data block. The hash value and the block height of the initial data block are given based on a preset mode. For example, the initial data block does not contain data records, the hash value is any given hash value, and the block height blknum is 0; for another example, the trigger condition for generation of the initial data block is consistent with the trigger conditions of other data blocks, but the hash value of the initial data block is determined by hashing all of the contents in the initial data block.

When N >1, since the content and hash value of the previous data block have already been determined, at this time, the hash value of the current data block (nth data block) may be generated based on the hash value of the previous data block (i.e., nth-1 data block), for example, one possible way is to determine the hash value of each data record to be written into the nth data block, generate a mercker tree in the order of arrangement in the blocks, concatenate the root hash value of the mercker tree with the hash value of the previous data block, and generate the hash value of the current block again using the hash algorithm. For example, the hash value of the data block may be generated by concatenating the data records in the order of the data records in the block and hashing the concatenated data records to obtain the hash value of the entire data record, concatenating the hash value of the previous data block and the hash value of the entire data record, and performing a hash operation on the concatenated string.

By the above-mentioned manner of generating data blocks, each data block is determined by a hash value, and the hash value of the data block is determined by the content and the sequence of data records in the data block and the hash value of the previous data block. The user can initiate verification based on the hash value of the data block at any time, and modification of any content in the data block (including modification of data record content or sequence in the data block) can cause inconsistency between the hash value of the data block calculated during verification and the hash value generated during data block generation, so that verification failure is caused, and centralized non-tampering is realized.

After the data record is stored, some relevant index information may also be re-established, e.g., because the data record is stored in the data block, there is no hash value for the data record. Therefore, in order to conveniently find any data record, an index which takes the hash value of the data record as a key, and takes the block height of the data block where the data record is located and the offset of the data record in the data block as values can be established and stored. Therefore, the data records can be inquired more conveniently. It should be noted that the creation of the index information may be performed asynchronously with respect to the chunking, and the index information may be sent to the user for backup, so that the user may also conveniently query or verify any data record according to the index.

In the query process, the block height of the data block where the data record is located, the offset of the data record in the data block where the data record is located, or the data record plaintext may be queried based on the hash value input by the user, or the block height of the data block corresponding to the hash value of the obtained data block may be queried, and the query result may be returned.

The specific query mode can be realized by a query instruction. The query instruction includes the hash value to be queried input by the user. The hash value here may be a hash value of a data record or a hash value of a data block, and the database service provider may perform traversal query on the data block or perform query on a pre-established index.

The following exemplifies several query modes provided by the embodiments of the present specification:

firstly, inputting a hash value of a data block, and returning all data plaintexts in the data block; or, the hash value of the data record is input, and the plaintext of the data record is returned, specifically, the hash value may be input and the plaintext of the data record may be returned by using a query instruction SELEC T (khash, & v), and when the service side receives the corresponding query instruction, the service side executes the foregoing query logic based on the hash value to return the result.

Secondly, inputting a hash value of a data record, returning a block height of a data block where the data record is located, and an offset in the data block, which can be specifically implemented by using a query instruction SELECT (khush, & v, FULL);

thirdly, inputting the hash value of the data block and returning the block height according to the block hash. In particular, it may be implemented using a query instruction SELECT (khush, & v, BLK).

Of course, there may be a case where the user inputs a hash value and the server cannot query the corresponding result. For example, if the user inputs a hash value corresponding to a data record and the server side cannot inquire the result, the user may reasonably suspect that the data record corresponding to the hash value has been changed, possibly tampered, or possibly lost.

In the query process, the query needs to be performed depending on the hash value of the data record or the hash value of the data block. In other words, each data record needs to have a corresponding data record hash. Therefore, when the user needs to store data, a specific data record can be added through a special adding instruction for adding the data record, the server side determines the hash value of the data record to be added, and returns the hash value of the data record and the block hash of the block where the data record is located to the user; and storing the data record to be added in a local cache so as to write the data record into a new data block when a preset blocking condition is met. Therefore, the user can inquire the data record according to the hash when needing to inquire. The following are exemplary instructions for adding records provided by embodiments of the present specification:

APPEND (v, & khush): and adding the data record and returning the hash value of the data record.

Further, in the storage process, the service side may also provide a signature of the corresponding service platform, specifically including the following ways: encrypting the data record by adopting a server private key to generate a private key signature of the server on the data record; and returning the private key signature and the hash value of the data record to the user so that the user can decrypt the private key signature by using the corresponding public key for verification. So that the user can confirm that the hash value is recognized by the service party. Specifically, the user may request the service party to provide the signature in an add instruction, and the following is an exemplary instruction provided in this specification to return a signed add record:

and (v, & khush, CERT) returning the hash value corresponding to the data record and returning the signature certificate of the service party.

Of course, in other types of database operations provided by embodiments of the present specification, such as querying, purging, verifying, and suppressing, among other database operations, the server-side signed certificate may also be included in the returned result.

In addition to the query, the user may also actively initiate verification on a plurality of data blocks already existing in the database, specifically, the user may initiate a verification instruction, where the verification instruction specifies which data blocks need to be verified through a parameter, for example, one data block may be specified through a hash value or a block height, and whether the verification is correct is initiated on a plurality of data blocks before or after the data block; or, a data record is designated by the hash value, and whether the data record exists in the database is verified. The result of the verification is a "present" or "absent" and a "correct" or "incorrect" such metadata. The following exemplary provides several confirmation methods provided by the embodiments of the present specification:

first, a hash value is input, a data block is determined from the hash value, and verification is performed on the data block to obtain a verification result, which may be implemented by a verification instruction VERIFY ('khush', & v).

Secondly, inputting a hash value, determining a corresponding data block from the hash value or determining a data block where a data record corresponding to the hash value is located, and verifying from the determined data block to an initial data block, specifically, by a verification instruction VERIFY ('khush', & v, -1), generally speaking, the initial block height is "0" or "1", and therefore, -1 may also be other values lower than the initial block height.

Thirdly, inputting a hash value, determining a corresponding data block according to the hash value, and verifying a specified number of data blocks from the determined data block onward, which can be specifically implemented by a verification instruction VERIFY ('khush', & v, blknum).

Fourthly, inputting the block height and the number to be verified, and verifying the specified number of data blocks from the data block corresponding to the block height in the past, specifically, the verification can be realized by a verification instruction VERIFY (blkh, & v, blknum).

The result returned during verification is a "yes" or "no" metadata, and as mentioned above, the service provider may also add the signature of the service provider during this process, and the generation manner of the signature is described above. Specifically, a parameter "CERT" representing a signature of the service party may be added at the end of any verification instruction, for example: VERIFY ('khush', & v, blknum, CERT), with a server signature in the returned result.

In another embodiment, if the content of the data block further includes a timestamp of the data block or a timestamp of the data record, or the database server further generates an index in advance, for example, an index of a block height and a block timestamp, an index of a hash value and a record timestamp of the data record, or an index of a hash value and a block time of the data block, etc., when the data block is blocked, the server may further provide a corresponding time query manner, that is, the server may query the corresponding block height or hash value from the data block or the index by the time value, or query the corresponding time value by the hash value or the block height, and the following exemplarily lists several time-based query manners provided by the embodiments of this specification:

first, inputting a block height, and querying a blocking TIME of a data block corresponding to the block height, which may be specifically implemented by a TIME query instruction TIME (blknum, & v).

Secondly, inputting a hash value, and returning a timestamp corresponding to the hash value, where the hash value may be a hash value of a data block or a hash value of a data record, and specifically, the hash value may be implemented by a TIME query instruction TIME ('khush', & v).

Third, entering a time value, returning the block height of the last data block before the time value, or returning the hash value of the last data record before the time value and the block height of the data block where the data record is located, may be specifically implemented by the time query instruction LTIME ('timestamp', & v).

In this embodiment of the present specification, if the user no longer needs the service, the entire clearing of data may be performed before the service is ended. For example, the user enters the ledger ID and the server clears the ledger, for example, by a clear command pull (lgid), or the user also enters a time period, the server first archives the ledger, and after the time period, the server clears the ledger, for example, by a clear command pull (lgid).

And as the data of the user is continuously increased, the storage space is more and more occupied, or some long-time historical data are no longer valuable to the user, the database server can also perform corresponding partial clearing on the data block based on the requirement of the user. Partial purging may be performed on a block high or time point basis.

For example, the user specifies the book ID and the block height, and the server determines that all data blocks before the block height are data blocks that need to be cleared based on the block height, and then clears the data blocks that are determined to need to be cleared, which may be implemented by a clear command PURGE (lgid, d-a, blkbound).

For another example, the user specifies the book ID and the time point, the server determines the last generated data block before the time point based on the time point, determines the data blocks generated before the data block as the data blocks that need to be cleared, and then clears the data blocks that are determined to need to be cleared, which may be implemented by a clear command PURGE (i, d-a, 'timestamp').

Before the partial removal is performed, because the hash value of the first data block of the removed data block chain is generated based on the hash value of the previous data block, at this time, a pseudo initial data block needs to be generated, and the hash value of the pseudo initial data block is equal to the hash value of the determined last data block needing to be removed, so that errors can be avoided when verification is performed later. The hash value of the last data block may be obtained by querying from a pre-established index, or may be obtained by sequentially calculating from the initial data block, or by querying from the data block.

The content of the newly generated pseudo initial data block may be empty, and some corresponding remarks may be recorded, for example, the time of generation, and the like. However, the content of the pseudo-initial data block is independent of the hash value of the pseudo-initial data block. And the server may also sign the pseudo-initial data block.

In addition, partially purged data is typically backed up for the user. Based on this, during the process of partial clearing by the user, verification for confirming that the data needing partial clearing is needed can be inserted. Fig. 3 is a schematic flow chart of an exemplary partial purge provided by an embodiment of the present disclosure, as shown in fig. 3. In the schematic diagram, the user inputs the time point, and specifically, the generation time of the data block closest to the time point may be obtained by first querying, then the block height of the data block corresponding to the generation time is obtained, the pseudo initial data block is generated and signed, and then the partial clearing operation is performed.

In practical applications, some data (referred to herein as sensitive data) once written into a data block can have deleterious consequences. For example, company a uploads data with a data record with a leaf XX, a gender male and a id number of 123456, and the id number of the data record reveals user privacy and needs to be concealed.

Since the modification or cleaning of any data record in the solution provided by the embodiment of the present specification can cause the verification of other data blocks to be erroneous, the embodiment of the present specification also provides a method for hiding sensitive data, and specifically, the core technical means is to replace the data record in which the information to be hidden in the data block is located with the hash value of the data record. In this way, disclosure of the sensitive information can be stopped without disturbing smooth operation of the data block system.

Specifically, the user may directly specify the position of the information to be concealed, or in practical applications, the user may issue a concealed information instruction carrying the position information. The position information here includes the block height of the data block, the offset of the data record in the block height, the offset of the information to be suppressed in the data record, the length of the information to be suppressed, and so on.

For example, an exemplary suppress information instruction may be DELETE (blkhight, txoff), under which a data record corresponding to a specified block height blkhight and a specified offset txoff is suppressed;

as another example, another exemplary suppress information instruction may be DELETE (blkhight, txoff, offset, length), under which a data record is determined by the block height blkhight and the offset txoff, and information determined by the length of the beginning at the offset specified in the data record is suppressed.

The information obtained by replacing or removing the hidden information is no longer used as a data record, and may be called remark information. In the process of hiding information, a feasible way is to determine a hash value of a data record in which the information to be hidden is located, splice a preset front marker character to the head of the hash value, splice a preset rear marker character to the tail of the hash value, splice remark information to the tail of the rear marker character, and then determine data formed by splicing the front marker character, the transaction hash, the rear marker character and the remark information as the hidden data record. Fig. 4 is a schematic diagram of a process for constructing a suppressed data record according to an embodiment of the present disclosure, as shown in fig. 4.

The front marker character and the rear marker character can be specified according to actual needs. For example, the front marker character may be "0E" and the rear marker character may be "0F". The role of the pre-marker character described above is that when the data record needs to be read at a later time for verification, then the pre-marker character reveals information to the node: "the storage location stores not the plaintext content of the data record, but the hash value of the data record". At this time, the hash value can be directly read for verification. When the corresponding remark information needs to be read, the reading can be started from the rear marker character "0F", and after the sensitive information is concealed, the content in the remark information can be basically the same as the content of the data record before the concealment or can be completely empty (namely, the content of the whole data record is completely concealed).

In addition, it should be noted that the hiding of the history data record is a relatively strict operation. It often symbolizes the disclosure of some information that triggers laws and regulations or violates morals, and also often concludes that mandatory processing of information is required after adjustment or trial by multiple parties. Therefore, when performing the above-mentioned clearing operation, one possible way is to: the clear operation requires a certain signature weight.

For example, for an operation instruction issued by a general user, the background default signature weight is 30, the signature weight useful for a service party or other transaction systems is 60, the signature weight for a state enforcement agency issuing an operation instruction such as a court is 120, and the signature weight required for a clearing operation is preset to be 100. The execution weight of an operation may be the sum of the signature weights of the participants, and in general, the participants may be set not to exceed 2. In this embodiment, at least two digital signatures of authorities (e.g., a transaction system side and a database server side) associated with the data records are required to be performed. That is, the database server can perform clearing only after the transaction system side initiates a clearing instruction and signs and the database server side receives the clearing instruction and signs. And the clearing instruction initiated by the end user cannot be executed even if the database service side performs signature authorization because the signature weight is not enough.

Further, the database server may also provide other database service modes, such as:

during the filing period, retrieving the user data book, which is realized by retrieving an instruction record (lgid), wherein the book refers to a set containing all data blocks;

returning the block height of the current last data block, which is realized by an instruction GETHEIGHT (& v);

return user ledger ID, by instruction GETLEDGER (& v), and so on.

In addition, it should be noted that, in the above description, various operation instructions are provided to implement the database service method provided by the present application. However, the form of the operation instruction is not limited to the form proposed in the embodiments of the present specification, and in practice, the form of the operation instruction for data may be various, and only the service mode proposed in the present application may be implemented. And the query instruction only provides an external form convenient for user operation, and the execution mode of the query instruction is still dependent on the execution mode corresponding to each instruction when the server receives the instruction and executes the instruction.

Further, after generating the data blocks, the server may also give a corresponding timestamp for each block. For example, a national time service center interface is introduced, and the block is output by adopting a credible timestamp when the block is output. Thus, the index can be built depending on the time stamp.

In one embodiment, for any data block, if there is a receiving timestamp in the data record in the block, the data records may be sorted according to the receiving timestamp, and each data record is assigned a sorting sequence number; or the sequence numbers may be assigned directly in the order in which the data records were received and reset after blocking so that the sequence numbers are assigned partially within the next data block.

After the sequence number is determined, the sequence number and the hash value may be concatenated according to the determined hash value of each data record. Specifically, a substring with a specified length may be added to the head or the tail of the hash value to place a sequence number, generate a time-series hash string of the data record, and then establish a first index table containing a correspondence between a blocking timestamp of the data block and the time-series hash string of the data record according to the sequence of the sorted sequence numbers. As shown in table 1, table 1 is a first index table related to data records provided in the embodiments of the present specification. In table 1, the first 6 bits of the hash value of the data record have inserted a corresponding sequence number string, where "0 x" is used to identify the next sequence number, where "0001" is the sequence number, "hash 1" is the hash value of the first piece of data in the data block, and the time on the left side is the blocking time of the data block. In this manner, the significand of the timestamp is fully retained.

TABLE 1

20xx-01-19 03:14:07.938576	0x0001Hash1
		20xx-01-19 03:14:07.938576	0x0002Hash2
20xx-01-19 03:14:07.938576	0x0003Hash3
		20xx-01-19 03:14:07.938576	……

In addition, when data is stored using a block-chained ledger, one ledger usually includes a plurality of data blocks in succession. In practical applications, the data blocks are often numbered using natural sequence numbers. For example, the initial data block has a block height of 1, and each subsequent data block is added with a block height of 1. Based on this, the embodiments of the present specification further provide a block height creating method, specifically, a blocking time of a data block is determined, then a symmetric encryption algorithm is adopted to convert the blocking time into integer data, the integer data is used as the block height of the data block, and the earlier the blocking time is, the smaller the integer data is.

Specifically, the integer here may be a large integer data, for example, a 13-bit large integer. Thus, since the large integer is obtained based on time symmetric encryption, when the blocking time of the data block is needed, the blocking time can be obtained by the same symmetric decryption.

For example, for a chunk time "20 xx-01-1903: 14: 07.938576", after symmetric encryption, it can be converted to a large integer "1547838847938", which is "1547838847938" because the integer data monotonically increases over time. The block height of the data block can be used to identify the data block. In this specification, the block height is monotonically increased based on the blocking time, so that even if large integer data is used, the order between them is still from small to large, reflecting the order between the data blocks. For example, if the blocking time of the next data block is "20 xx-01-1903: 16: 07.235125", it can be converted into another larger large integer "1547838848125" by using a preset symmetric encryption algorithm.

Based on this, the sequence numbers of the service logs in the data block can be determined as in the foregoing manner, the block heights and the sequence numbers are spliced, the time sequence information of the service logs including the block heights and the sequence numbers is generated, and a third index table of the hash values and the time sequence information of the service logs is established. As shown in table 3, table 3 is a third index table provided in the examples of the present specification. In this table, the large integer on the left side is timing information including a block height and a sequence number, the block height being obtained based on time symmetric encryption. In the case of blocking time accurate to the millisecond level, the third index introduces 3 decimal digits after the block height to identify the sequence number (i.e. defining a block threshold of 999), so the assumption of throughput is in the order of millions, and any practical trading scenario can be satisfied. If the throughput is higher, more decimal systems are introduced to identify the sequence numbers after the block height.

TABLE 3

In a practical application scenario, the database service provider involved in the embodiments of the present specification may also provide corresponding services for the corresponding database. As shown in fig. 5, fig. 5 is a schematic diagram of another system architecture involved in an embodiment of the present specification, including a database base service provider and a database enhanced service provider. For example, MySQL, PostgreSQL, MongoDB, etc. are basic service providers of databases, and these database systems can provide basic services for business systems, such as adding, deleting, modifying, etc. Meanwhile, the data base service providers and the data base service providers store corresponding business operation logs for the operations locally, and the business operation logs record operation records of the data base service providers for the business data. The system for providing further services for the database basic service provider is the database enhanced service provider Ledger server provided by the embodiment of the specification.

Based on this, the present specification embodiments also provide a way that can provide further enhanced services for database base service providers. Specifically, after the service operation logs are generated by the databases such as MySQL, PostgreSQL, MongoDB, and the like, the service operation logs generated by the databases may be sent to the legger. Because the service operation logs are all provided with the generation time stamps, the Ledger system can sort, block and store the service operation logs according to the generation time stamps. Thus, each database can further manage its own system operation log based on the aforementioned operation mode. When the database basic service provider generates the system operation log, the database basic service provider does not need to immediately send the system operation log to the Ledger system, and the database basic service provider can be an asynchronous sending process.

Each database basic service provider can send the service operation log to the Ledger system in a clear text mode. "plaintext" herein means that the service operation log sent by each database can be understood or partially understood by the Ledger system. For example, a certain database and the Ledger system make the Ledger system know the operation type, the operation service object, and the like in the service operation log by formulating a communication protocol in advance, so that the Ledger system can further perform blocking according to the operation type or the operation target object when blocking, so as to perform better management on each database system. In this way, if each database needs to perform query or statistics on itself (for example, statistics on how many times the data of which service object is cleared), it may only need to send an instruction, and a specific statistics or query process may be completed at the end of the legger system.

Of course, each database basic service provider may also send the service operation log to the legger system in a "ciphertext" manner. The "ciphertext" refers to the fact that the Ledger system cannot understand the service operation logs sent by the databases. In this way, each database can only read or clear the stored service operation log to the Ledger system, and the specific query or statistical work needs to be performed locally at the database basic service provider after reading the data.

In one implementation scenario, for example, where the data records are cost information about a business, the data records need to be audited. When a new account book is manufactured by preventing a false-forging time stamp by combining an enterprise and a service party, time service authentication of data blocks to some authoritative time justice institutions is an indispensable technical means. The time fairness institution may be, for example, a national time service center, or an authoritative time certification institution permitted by the national time service center. Here, the time service authentication is: a signature associated with the time-fairness authority is obtained, where the signature includes a trusted timestamp issued by the time-fairness authority corresponding to the block of data requiring authentication.

Specifically, the server first determines a segment of account book that needs time service authentication from the generated and stored data blocks, wherein the segment of account book at least should contain one data block or multiple data blocks with high continuity. The determined mode can be specified based on user operation, for example, a user initiates a time service instruction, and the instruction comprises an initial block height and a block number which need to be subjected to time service authentication; or the server side can automatically perform the operation based on the preset business logic without the specification of the user.

For example, from the finest granularity, each data block may be requested for a time service. In this way, the root hash of the merkel tree is the block hash value of the data block, and the method can protect the authenticity of the ledger (i.e. each data block) to the greatest extent. Due to the high block output frequency of the data blocks, the cost overhead is high for both the time service center and the service party. An optional mode is that a certain time service preset condition is set, and when the certain time service preset condition is met, a time service request is initiated. When the newly generated data blocks are all considered to be data blocks to be subjected to time service authentication, the time service preset condition may be: and the data blocks to be subjected to time service authentication reach a quantity threshold value, or the time interval from the last time service authentication reaches a time threshold value.

The specific time service authentication mode is that the block hashes of the data blocks to be time service authenticated are connected in series according to the sequence of block height, and the merkel trees corresponding to the data blocks are generated based on the block hashes of the data blocks, so that the root hashes of the merkel trees are confirmed. And, the information related to the data block to be time-granted authenticated includes, for example, information such as the starting block height, the ending block height, or the number of data blocks. And then sending the root hash of the Mercker tree and the related information of the data block to a time fairness mechanism. The time justice organization receives the information, namely, a trusted timestamp is given, digital signature authentication is carried out on the trusted timestamp, a time service certificate containing the trusted timestamp and a digital signature is generated, the time service certificate can also contain the related information of the data block, and the digital signature mode is only conventional private key encryption and public key decryption.

Thus, the server may receive a series of trusted timestamps containing a time fair authority signature, each trusted timestamp corresponding to a segment of the ledger, and may know unambiguously which segment of the data block based on the relevant information. The server can perform corresponding management and verification based on the trusted timestamp. For example, when a certain account book needs to be audited, the server may give a time certificate that a corresponding data block in the account book includes a trusted timestamp of a time justice authority and a signature, and recalculate the tacher root hash according to related information included in the time certificate, so that it can be confirmed that the data block corresponding to the certificate is unlikely to be forged in the future, and the server and the served party can be effectively prevented from jointly manufacturing the account book including the false timestamp to avoid corresponding audit. Fig. 8 is a schematic diagram of a specific generation of a time service certificate according to an embodiment of the present disclosure, as shown in fig. 8.

Correspondingly, an embodiment of the present specification further provides an index creating apparatus, which is applied to a centralized database service provider that stores data by multiple data blocks, as shown in fig. 6, where fig. 6 is a schematic structural diagram of an index creating apparatus provided in an embodiment of the present specification, and includes:

the determining module 601 selects any data block, and determines a blocking timestamp of the selected data block, a sequence number of each data record in the selected data block, and a hash value of each data record;

a write-in module 603 configured to remove a last designated digit in the blocking timestamp, write in a corresponding sorting sequence number, and generate a blocking timestamp including the sorting sequence number for any data record;

the second index creating module 605 creates a second index table containing the correspondence between the blocking timestamps of the sorting sequence numbers and the hash values of the data records according to the sequence of the sorting sequence numbers.

Further, the apparatus further comprises:

the receiving module 607 is configured to receive data records to be stored, and determine hash values of the data records;

the generating module 609, when a preset blocking condition is reached, determines each data record to be written into the data block, and generates an nth data block including the hash value of the data block and the data record, specifically including:

when N is 1, the hash value and the block height of the initial data block are given based on a preset mode;

and when N is greater than 1, determining the hash value of the Nth data block according to the hash values of the data records and the (N-1) th data block to be written into the data block, and generating the Nth data block comprising the hash value of the Nth data block, the data records and the blocking time of the data block, wherein the block height of the data block is monotonically increased based on the sequence of the blocking time.

Further, the preset blocking condition includes: the number of data records to be stored reaches a number threshold; alternatively, the time interval from the last chunking time reaches a time threshold.

Further, the determining module performs sorting according to the receiving time stamp of each data record, and determines a sorting sequence number of each data record in the selected data block; alternatively, the sort sequence number that has been assigned when the data record was received is obtained.

Further, the apparatus further includes an adding module 611, which adds a correspondence between a blocking timestamp containing the designated sorting order number and a block height of the data block in the second index table.

Further, the apparatus further includes a first index creating module 613, which splices the corresponding sorting sequence number of any data record and the hash value of the data record to generate a time sequence hash string of the data record; and establishing a first index table containing the corresponding relation between the blocking time stamp of the data block and the time sequence hash character string of the data record according to the sequence of the sequencing sequence numbers.

Embodiments of the present specification further provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the index creation method shown in fig. 2 when executing the program.

Fig. 7 is a more specific hardware structure diagram of a computing device provided in an embodiment of the present specification, where the device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.

The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.

The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

Bus 1050 includes a path that transfers information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.

It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.

Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, where the computer program is executed by a processor to implement the index creation method shown in fig. 2.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

From the above description of the embodiments, it is clear to those skilled in the art that the embodiments of the present disclosure can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the embodiments of the present specification may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.

The systems, methods, modules or units described in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the method embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to the partial description of the method embodiment for relevant points. The above-described method embodiments are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present specification. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The foregoing is only a specific embodiment of the embodiments of the present disclosure, and it should be noted that, for those skilled in the art, a plurality of modifications and decorations can be made without departing from the principle of the embodiments of the present disclosure, and these modifications and decorations should also be regarded as the protection scope of the embodiments of the present disclosure.

Claims

1. An index creation method applied to a centralized database service provider that stores data by a plurality of data blocks, the method comprising:

2. The method of claim 1, wherein at the centralized database service provider, the data chunks are pre-generated by:

receiving data records to be stored, and determining hash values of the data records;

when a preset blocking condition is reached, determining each data record to be written into the data block, and generating an nth data block containing the hash value of the data block and the data record, specifically comprising:

3. The method of claim 2, the preset blocking condition comprising:

the number of data records to be stored reaches a number threshold; or,

the time interval from the last blocking instant reaches a time threshold.

4. The method of claim 1, determining the sorting order number of each data record in the selected data block, comprising:

sorting according to the receiving time stamp of each data record, and determining the sorting sequence number of each data record in the selected data block; or,

the assigned sorting order number is obtained when the data record is received.

5. The method of claim 1, further comprising:

and adding a corresponding relation between a blocking timestamp containing a specified sorting sequence number and the block height of the data block in the second index table.

6. The method of claim 1, further comprising:

for any data record, splicing the corresponding sorting serial number and the hash value of the data record to generate a time sequence hash character string of the data record;

and establishing a first index table containing the corresponding relation between the blocking time stamp of the data block and the time sequence hash character string of the data record according to the sequence of the sequencing sequence numbers.

7. An index creation apparatus for use in a centralized database service provider that stores data via a plurality of data blocks, the apparatus comprising:

8. The apparatus of claim 7, further comprising:

the receiving module is used for receiving the data records to be stored and determining the hash value of each data record;

the generating module, when a preset blocking condition is reached, determines each data record to be written into the data block, and generates an nth data block including a hash value of the data block and the data record, specifically including:

9. The apparatus of claim 8, the preset blocking condition comprising:

the number of data records to be stored reaches a number threshold; or,

the time interval from the last blocking instant reaches a time threshold.

10. The apparatus of claim 7, wherein the determining module determines the sequence number of each data record in the selected data block by sorting according to the receiving time stamp of each data record; alternatively, the sort sequence number that has been assigned when the data record was received is obtained.

11. The apparatus of claim 7, further comprising an adding module that adds a correspondence between a blocking timestamp containing a specified sort order number and a block height of a data block in the second index table.

12. The apparatus according to claim 7, further comprising a first index creating module, for any data record, concatenating the corresponding sorting sequence number and the hash value of the data record, and generating a time-series hash string of the data record; and establishing a first index table containing the corresponding relation between the blocking time stamp of the data block and the time sequence hash character string of the data record according to the sequence of the sequencing sequence numbers.

13. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 6 when executing the program.