WO2020253231A1 - 一种基于收据的数据存储方法、装置及设备 - Google Patents

一种基于收据的数据存储方法、装置及设备 Download PDF

Info

Publication number
WO2020253231A1
WO2020253231A1 PCT/CN2020/071601 CN2020071601W WO2020253231A1 WO 2020253231 A1 WO2020253231 A1 WO 2020253231A1 CN 2020071601 W CN2020071601 W CN 2020071601W WO 2020253231 A1 WO2020253231 A1 WO 2020253231A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
block
record
data record
stored
Prior art date
Application number
PCT/CN2020/071601
Other languages
English (en)
French (fr)
Inventor
张渊
杨新颖
李亿泽
Original Assignee
创新先进技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Priority to US16/815,539 priority Critical patent/US10944549B2/en
Priority to US16/945,162 priority patent/US11005648B2/en
Priority to US16/945,128 priority patent/US10999062B2/en
Publication of WO2020253231A1 publication Critical patent/WO2020253231A1/zh
Priority to US17/195,408 priority patent/US11223471B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • the embodiments of this specification relate to the field of information technology, and in particular to a data storage method, device and equipment based on receipts.
  • data records related to the same business attribute are stored in various data blocks, which makes it difficult to reflect the correlation and continuity between data records .
  • the purpose of the embodiments of the present application is to provide a data storage solution that is beneficial to reflect the correlation between data.
  • a data storage method based on receipts is applied to a centralized database server that stores data in a block chain ledger.
  • the data blocks in the block chain ledger include a block header and a block body.
  • the method includes:
  • the data record to be stored and the receipt record are written into the same block of the blockchain ledger.
  • the embodiment of this specification also provides a data storage device based on receipts, which is applied to a centralized database server that stores data in a block chain ledger.
  • the data blocks in the block chain ledger include block headers and block headers.
  • Body the method includes:
  • the first obtaining module obtains a data record to be stored containing business attributes, and determines the execution information of the data record to be stored;
  • the second acquisition module in the block chain ledger, acquires the previous data record containing the same business attribute
  • a generating module which determines the hash value of the previous data record, and generates a receipt record containing the hash value and execution information
  • the writing module writes the data record to be stored and the receipt record into the same block of the block chain ledger.
  • the hash value of the previous data record under the same business attribute is obtained according to the business attribute in the data record to be stored, and the previous data record is recorded
  • the hash value of the to-be-stored data record into the receipt and write the to-be-stored data record and receipt into the same data block to realize the correlation between user data records, so that you can chain from the stored data block in the future Road-style query or verification improves user experience.
  • Figure 1 is a schematic diagram of the system architecture involved in an embodiment of the specification
  • FIG. 2 is a schematic flowchart of a data storage method based on receipts according to an embodiment of this specification
  • Fig. 3 is a schematic diagram of a method of generating a receipt record provided by an embodiment of the specification
  • FIG. 4 is a schematic diagram of the format of the data block header and the block body provided by the embodiment of the specification;
  • FIG. 5 is a schematic flowchart of a method for creating an index of data records according to an embodiment of this specification
  • FIG. 6 is a schematic structural diagram of a data storage device based on receipts provided by an embodiment of this specification
  • Fig. 7 is a schematic structural diagram of a device for configuring the method of the embodiment of this specification.
  • FIG. 1 is a schematic diagram of a system architecture involved in an embodiment of the specification.
  • an enterprise organization can face multiple users, and each user can query the database server through its corresponding enterprise organization.
  • the organization connected to the database server is a financial product company, and the data record can be the personal user’s financial management records in the financial product company; or the connected organization can be a government department, where the data record is the government department’s Expense details of the managed public project; or, the database server is connected to a hospital, and the data records are patient medical records; or the database server is connected to a third-party payment agency, and the data records can be individual users Payment records through the agency, etc.
  • the embodiment of this specification provides a data storage solution in a block chain ledger to reflect the correlation between data records.
  • Fig. 2 is a schematic flow chart of a data storage method based on receipts provided in an embodiment of this specification, and the flow specifically includes the following steps:
  • S201 Obtain a data record to be stored containing business attributes, and determine execution information of the data record to be stored.
  • the business attribute is generally the only one in the docking organization.
  • the business attribute is based on different business scenarios and can include user name, user ID number, and driver’s license. Number, mobile phone number, unique project number, etc.
  • the data record is the user's consumption record
  • the business attribute at this time is the user ID (including mobile phone number, ID number, user name, etc.), or the user ID is hashed
  • the hash value obtained by the algorithm; or, for government agencies, the data record is the overhead flow of multiple public projects, then the business attribute at this time can be a unique number for each project.
  • the execution information includes the global serial number, time stamp, execution result, etc. of the data to be stored recorded in the blockchain ledger. It is easy to understand that in a centralized database server, since it can be stored without consensus, the execution result of the data record is always successful.
  • S203 Acquire a previous data record containing the same business attribute in the block chain ledger.
  • the database server can obtain business attributes from the designated identification field in the data record to be stored.
  • the specific location and acquisition method of the designated identification field may be negotiated in advance by the database server and the docking organization.
  • the designated identification field can be obtained from the designated offset in the data record, or the start and end positions can be identified by specific characters (for example, the characters OE The beginning of the business attribute ends with the character OF identifier); or, when the data record provided by the docking agency is unstructured data, the docking agency can directly splice the business attributes at the beginning of each data record when uploading.
  • the header the database server can directly obtain the business attributes of each data record from the header.
  • a feasible way is that the database server can traverse the data records from the back to the front of the ledger to obtain the previous data record containing the same business attributes; or, another feasible way
  • the method is to query and obtain the previous data record containing the same business attribute from the pre-established inverted index.
  • the inverted index contains the correspondence between service attributes and location information.
  • the location information includes the block height of the data block where the data record is located and the offset in the data block where it is located. The specific method of establishing and using the inverted index will be detailed below.
  • the previous data record here refers to the data record whose writing time (that is, the block time of the data block in which the data record is located) is closest to the current one in the block chain ledger, because the data block of the block chain ledger Both the height and the block time increase monotonically. Therefore, the previous data record can also refer to the data record with the largest block height of the data block.
  • the previous data record can be a data record that has already been stored, or it can also be a data record to be stored.
  • the server after a data record to be stored is executed, the corresponding execution information needs to be returned to the client.
  • the returned execution information can be returned synchronously or asynchronously.
  • S205 Determine the hash value of the previous data record, and generate a receipt record containing the hash value and execution information.
  • the receipt record can be generated by directly splicing the hash value of the previous data with the data record to be stored, for example, placing the hash value of the previous data at the head or the end of the receipt record to splice the receipt record.
  • FIG. 3 is a schematic diagram of a method of generating a receipt record provided by an embodiment of this specification. It can be seen from the schematic diagram that the previous data record can be traced forward to the original data record based on Pre-hash (the hash of the previous data record).
  • each data record to be stored will have a corresponding receipt record.
  • the corresponding manner may be implemented based on the serial number.
  • the serial number of the data to be stored recorded in the data list is the same as the serial number of the receipt recorded in the receipt list.
  • S207 Write the to-be-stored data record and receipt record into the same block of the blockchain ledger.
  • the data block in the blockchain ledger includes a block header and a block body.
  • the header of the block header is used to store metadata about the data block.
  • the metadata can include, for example, the hash value of the previous data block, the hash value of the own data block, and the root of the Merkel tree of the data record in the own data block. Hence, the root hash value and version number of the receipt tree in the own data block; the block body can be the same as the storage data record list, and the receipt record list corresponding to the data record, etc. Data records and receipt records are in one-to-one correspondence in the same block.
  • FIG. 4 is a schematic diagram of the format of the data block header and the block body provided by the embodiment of this specification.
  • the format of the data block can be customized based on user needs, and it is not limited compared to this solution.
  • the block header of the data block may also include a state array describing the state of the data recording operation, and so on.
  • data blocks are generated in the following ways:
  • the to-be-stored data records generated by the user can be various consumption records of individual users of the client, or can be the business results, intermediate state, and operation records generated by the application server during the execution of business logic based on user instructions.
  • Specific business scenarios can include consumption records, audit logs, supply chains, government supervision records, medical records, and so on.
  • each data record to be stored in the data block to be written is determined, and the hash value of the data block and the Nth data record to be stored are generated. Data blocks.
  • a data block can be generated for a data record to be stored. In this way, the computing and storage capabilities of the server are required to be higher.
  • a more common application method is to store multiple data records to be stored in one data block. Therefore, data blocks are generally generated based on preset conditions.
  • the preset conditions for block formation include: the number of data records to be stored reaches the number threshold, for example, each time a thousand data records to be stored are received, a new data record is generated Data block, write one thousand data records to be stored in the block; or, the time interval from the last block time reaches the time threshold, for example, every 5 minutes, a new data block will be generated within the 5 minutes
  • the received data record to be stored is written into the block.
  • the N here refers to the serial number of the data block.
  • the data block is in the form of a block chain, which is arranged sequentially based on the order of the block time, and has a strong timing characteristic.
  • the block height of the data block increases monotonically based on the sequence of the block time.
  • the block height can be a sequence number, and the block height of the Nth data block is N at this time.
  • the block height can also be generated in other ways.
  • the block time of the data block is determined, and then the block time is converted into integer data using a symmetric encryption algorithm, and the integer data is used as the block height of the data block.
  • the integer here can be a large integer data, for example, a 13-bit large integer. Therefore, since the large integer is obtained by symmetric encryption based on time, when the block time of the data block is required, the block time can be obtained by the same symmetric decryption. For example, for the block time "20xx-01-19 03:14:07.938576", after symmetric encryption, it can be converted to a large integer "1547838847938". Since the integer data increases monotonically with time, "1547838847938" . At this time, it can be used as the block height of the data block to identify the data block.
  • the data block at this time is the initial data block.
  • the current data block (the first data block) can be generated based on the hash value of the previous data block (that is, the N-1th data block). For example, one feasible way is to determine the hash value of each data record to be stored that will be written into the Nth block, and generate a hash value according to the sequence in the block Merkel tree, the root hash value of the Merkel tree and the hash value of the previous data block are spliced together, and the hash algorithm is used again to generate the hash value of the current block.
  • each data block is determined by a hash value, and the hash value of the data block is determined by the content and sequence of the 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. Any modification of the data block (including the modification of the data record content or sequence in the data block) will cause the hash value of the data block calculated during verification and The hash value of the data block is inconsistent when it is generated, which causes the verification to fail, thus realizing the immutability under centralization.
  • the database server can return the hash value of the data record to be stored generated by the user to the client, so that the client can initiate query and verification at any time.
  • the server can return the corresponding data record to be stored and the corresponding receipt record to the client, so that the client can obtain the data to be stored generated by itself The data record, and the hash value of the previous data record. Furthermore, when the client needs it, it can perform further forward query until the first data record written into the ledger generated by the client, and a complete link of data records based on business attributes is obtained. The same principle applies when verifying on the client side.
  • the hash value of the previous data record under the same business attribute is obtained according to the business attribute in the data record to be stored, and the previous data record is recorded
  • the hash value of the to-be-stored data record into the receipt and write the to-be-stored data record and receipt into the same data block to realize the correlation between user data records, so that you can chain from the stored data block in the future Road-style query or verification improves user experience.
  • the data records to be stored are usually stored in multiple data blocks in a distributed manner. Therefore, after the data records to be stored are written into the ledger, a corresponding index can be created for query.
  • FIG. 5 is a schematic flowchart of a method for creating an index for data records according to an embodiment of this specification. The process specifically includes the following steps:
  • S503 Determine the location information of the data recorded in the ledger.
  • a block-chain ledger is composed of multiple data blocks, and at the same time, a data block usually contains multiple data records. Therefore, in the embodiment of this specification, the location information specifically refers to which data block in the ledger is in when a data record is saved, and the offset in the data block.
  • the hash value of the data block is a hash value obtained by hash calculation based on the previous block's hash value and its own data record, which can be used to uniquely and clearly identify a data block.
  • the block height of the first data block is 0, and the block height is increased by 1 for each additional data block; or, the block time of the data block can be converted into a large monotonic increase Integer data (usually 12 to 15 bits) sequence, as the block height of the data block. Therefore, a data block usually has a clear block height.
  • the order of the data records has also been fixed, so the serial number of a data record in the data block is also clear.
  • the serial number can also be used Used to clarify the location information of the data record in the data block in which it is located. That is, the sequence number can also be used to indicate the offset.
  • the address offset of each data record in the data block can also be used to identify the data records in the data block respectively.
  • the address offset of each data record is not the same.
  • the specific format of the data block can be customized (for example, the metadata information and remark information contained in the block header of the data block, the block height of the data block is adopted Format, etc.), in different formats, the content of the location information will be different, which does not constitute a limitation to this solution.
  • S505 Establish a corresponding relationship between the business attribute and the location information, and write an inverted index with the business attribute as the main key.
  • the primary key is the business attribute contained in the data record.
  • the specific writing method is: when the primary key in the index does not contain the business attribute, an index record with the business attribute as the primary key is created in the index table.
  • the location information is written into the index record where the business attribute is located. It should be noted that the writing here is not an overwriting writing, but the location information is added to the value of the index record, and it is stored in the index record alongside other location information.
  • Table 1 is an exemplary index table provided in the embodiment of this specification.
  • the Key is the specific value of the business attribute, and each array in the Value part is a piece of position information.
  • the first part of each array is the block height, and the latter part is the serial number of the data recorded in the data block, passing the block height and serial number That is, a data record can be uniquely determined. It is easy to understand that in the index table, a key can correspond to multiple location information.
  • the business attributes of the data records and the storage location in the ledger are determined, the corresponding relationship between the two is established, and the business attribute is created as the main key. Sort index, without knowing the user's business details, from the index, you can perform corresponding statistics on data records based on business attributes, as well as subsequent query and verification.
  • the previous data record containing the same business attribute when obtaining the previous data record containing the same business attribute, it can be obtained by querying the aforementioned index table. For example, if there is a new record to be stored and its business attribute is "344X0001", the block height of its corresponding data record can be found from the table as 5 and 8. Therefore, it can be based on the block height The location information (8, 22) corresponding to the maximum value of "8" is obtained from the previous data record.
  • the location information of the previous data record can be determined according to the magnitude of the offset. For example, if there is a new record to be stored and its business attribute is "0X123456", the maximum value of the block height corresponding to the business attribute can be queried at this time is 300, and there are two corresponding location information (300, 89), (300,999), at this time, you can determine the position information (300,999) based on the size of the offset to obtain the previous data record.
  • the corresponding location information cannot be queried based on the business attribute in the inverted index, or the data record containing the same business attribute cannot be queried by traversing the ledger. Then, at this time, it can be determined that the business attribute in the ledger is written for the first time, and at this time, the data record to be stored can be determined as the previous data record.
  • the server may also query and obtain the previous data record from unstored data records. For example, the server performs a traversal query on the data records that have not been written in the data block, obtains one or more data records to be stored that contain the same business attribute, sorts the data records according to the time stamp of the received data records, and sets the time interval to the nearest The data record to be stored is determined as the previous data record.
  • the previous data record can be queried from the data block (that is, stored).
  • the embodiment of this specification also provides a data storage device based on receipts, which is applied to a centralized database server that stores data in a block chain ledger.
  • the data blocks in the block chain ledger include block headers and block headers.
  • Fig. 6 is a schematic structural diagram of a receipt-based data storage device provided by an embodiment of this specification, including:
  • the first obtaining module 601 obtains a data record to be stored containing business attributes, and determines the execution information of the data record to be stored;
  • the generating module 605 determines the hash value of the previous data record, and generates a receipt record containing the hash value and execution information;
  • the writing module 607 writes the data record to be stored and the receipt record into the same block of the blockchain ledger.
  • the second acquiring module 603 queries and acquires the location information corresponding to the business attribute from a pre-established inverted index, where the location information includes the block height of the data block where the data record is located, and , The offset in the data block in which it is located; determine the maximum value of the block height in the location information; obtain the previous data record according to the location information corresponding to the maximum value of the block height.
  • the second acquiring module 603 determines that the data record to be stored itself is the previous data record if the retrieval of the location information corresponding to the business attribute fails in the inverted index.
  • the device further includes a data block generation module 609, which obtains at least one data record to be stored and a corresponding receipt record, and determines the hash value of the data record to be stored; when a preset block condition is reached, it is determined For each stored data record and corresponding receipt record in the data block to be written, the Nth data block containing the hash value of the data block and the data record is generated, which specifically includes:
  • the hash value and block height of the initial data block are given based on a preset method
  • the hash value of the Nth data block is determined according to each data record to be stored in the data block to be written and the corresponding receipt record, and the hash value of the N-1 data block, and all The hash value of the Nth data block is written into the header of the Nth data block, and each data record to be stored and the corresponding receipt record are written into the block body of the Nth data block, where the block height of the data block Monotonically increasing based on the order of block time.
  • the preset blocking condition includes: the number of data records to be stored reaches the number threshold; or, the time interval from the last blocking time reaches the time threshold.
  • the device further includes an inverted index establishment device 611, which obtains the business attributes in the data record to be stored; determines the location information of the data record in the ledger, and the location information includes the information of the data block where the data record is located. The block height, and the offset in the data block in which it is located; establishing the corresponding relationship between the business attribute and the location information, and writing the inverted index with the business attribute as the main key.
  • an inverted index establishment device 611 which obtains the business attributes in the data record to be stored; determines the location information of the data record in the ledger, and the location information includes the information of the data block where the data record is located. The block height, and the offset in the data block in which it is located; establishing the corresponding relationship between the business attribute and the location information, and writing the inverted index with the business attribute as the main key.
  • the embodiments of this specification also provide a computer device, which at least includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the data shown in FIG. 2 when the program is executed. Storage method.
  • FIG. 7 shows a more specific hardware structure diagram of a computing device provided by an embodiment of this specification.
  • the device may include a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050.
  • the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040 realize the communication connection between each other within the device through the bus 1050.
  • the processor 1010 may be implemented in a general-purpose CPU (Central Processing Unit, central processing unit), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits for execution related Program to implement the technical solutions provided in the embodiments of this specification.
  • a general-purpose CPU Central Processing Unit, central processing unit
  • microprocessor microprocessor
  • application specific integrated circuit Application Specific Integrated Circuit, ASIC
  • ASIC Application Specific Integrated Circuit
  • the memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory, random access memory), static storage device, dynamic storage device, etc.
  • the memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of the present specification are implemented through software or firmware, related program codes are stored in the memory 1020 and called and executed by the processor 1010.
  • the input/output interface 1030 is used to connect an input/output module to realize information input and output.
  • the input/output/module can be configured in the device as a component (not shown in the figure), or can be connected to the device to provide corresponding functions.
  • the input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and an output device may include a display, a speaker, a vibrator, an indicator light, and the like.
  • the communication interface 1040 is used to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices.
  • the communication module can realize communication through wired means (such as USB, network cable, etc.), or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).
  • the bus 1050 includes a path to transmit information between various components of the device (for example, the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040).
  • the device may also include the necessary equipment for normal operation.
  • the above-mentioned device may also include only the components necessary to implement the solutions of the embodiments of the present specification, rather than all the components shown in the figures.
  • the embodiments of this specification also provide a computer-readable storage medium on which a computer program is stored, and the program is executed by a processor to implement the data storage method shown in FIG. 2.
  • Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology.
  • the information can be computer-readable instructions, data structures, program modules, 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, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • a typical implementation device is a computer.
  • the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种基于收据的数据存储方法、装置及设备。在接收到用户需要存储的数据记录时，根据待存储数据记录中的业务属性，获取同一业务属性下前一数据记录的哈希值，将前一数据记录的哈希值写入待存储数据记录的收据中，并将待存储数据记录和收据写入同一数据块中，实现用户数据记录之间的相互关联。

Description

一种基于收据的数据存储方法、装置及设备 技术领域
本说明书实施例涉及信息技术领域，尤其涉及一种基于收据的数据存储方法、装置及设备。
背景技术
在块链式的账本中，同一业务属性(例如，同一用户名、同一项目名等等)相关的数据记录被分散的存储于各数据块上，难以体现数据记录之间的相关性和连续性。
基于此，需要一种更有利于体现数据之间相关性的数据存储方案。
发明内容
本申请实施例的目的是提供一种有利于体现数据之间相关性的数据存储方案。
为解决上述技术问题，本申请实施例是这样实现的：
一种基于收据的数据存储方法，应用于以块链式账本存储数据的中心化的数据库服务端中，所述块链式账本中的数据块包括块头和块体，所述方法包括：
获取包含业务属性的待存储数据记录，确定所述待存储数据记录的执行信息；
在所述块链式账本中，获取包含同一业务属性的前一数据记录；
确定所述前一数据记录的哈希值，生成包含所述哈希值和执行信息的收据记录；
将所述待存储数据记录和收据记录写入所述块链式账本的同一块体中。
对应的，本说明书实施例还提供一种基于收据的数据存储装置，应用于以块链式账本存储数据的中心化的数据库服务端中，所述块链式账本中的数据块包括块头和块体，所述方法包括：
第一获取模块，获取包含业务属性的待存储数据记录，确定所述待存储数据记录的执行信息；
第二获取模块，在所述块链式账本中，获取包含同一业务属性的前一数据记录；
生成模块，确定所述前一数据记录的哈希值，生成包含所述哈希值和执行信息的收 据记录；
写入模块，将所述待存储数据记录和收据记录写入所述块链式账本的同一块体中。
通过本说明书实施例所提供的方案，在接收到用户需要存储的数据记录时，根据待存储数据记录中的业务属性，获取同一业务属性下前一数据记录的哈希值，将前一数据记录的哈希值写入待存储数据记录的收据中，并将待存储数据记录和收据写入同一数据块中，实现用户数据记录之间的相互关联，从而日后可以从存储的数据块中进行链路式的查询或者验证，提高用户体验。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1为本说明书实施例所涉及的系统架构示意图；
图2是本说明书实施例提供的一种基于收据的数据存储方法的流程示意图；
图3为本说明书实施例所提供的收据记录的生成方式的示意图；
图4为本说明书实施例所提供的数据块块头和块体的格式示意图；
图5为本说明书实施例提供的一种数据记录的索引创建方法的流程示意图；
图6是本说明书实施例提供的一种基于收据的数据存储装置的结构示意图；
图7是用于配置本说明书实施例方法的一种设备的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实 施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
在实际应用中，数据库服务端面向的常常为各种机构，各机构则可以将它们与第三方用户(包括其它机构或者个人)之间所产生的数据记录在数据库服务端进行存储。如图1所示，图1为本说明书实施例所涉及的系统架构示意图。在该示意图中，一个企业机构可以面向多名用户，而每个用户均可以通过其对应的企业机构向数据库服务端进行查询。
例如，数据库服务端对接的机构是某金融产品公司，数据记录可以是个人用户在该金融产品公司的理财记录；或者，对接的机构可以是政府部门，其中的数据记录是政府部门对于该部门所管理的公共项目的开销明细；或者，数据库服务端对接的机构是某个医院，其中的数据记录是病人的病历；或者，数据库服务端对接的机构是第三方支付机构，数据记录可以是个人用户通过该机构的支付记录，等等。
对于用户而言，其数据记录通常是分散式的存储在多个数据块中的。例如，医院对于所有病人的病历记录按照时间产生的顺序，依次上传。则同一用户的不同病历记录可能就被分散的存储于不同的数据块中。基于此，本说明书实施例提供一种块链式账本中的数据存储方案，以体现各数据记录之间的相关性。
以下结合附图，详细说明本说明书各实施例提供的技术方案。如图2所示，图2是本说明书实施例提供的一种基于收据的数据存储方法的流程示意图，该流程具体包括如下步骤：
S201，获取包含业务属性的待存储数据记录，确定所述待存储数据记录的执行信息。
在每个与数据库服务端对接的机构中，所述业务属性在所述对接机构中，一般而言是唯一存在的，业务属性基于不同的业务场景，可以包括用户名、用户身份证号、驾照编号、手机号、项目唯一编号等等。
例如，对于第三方支付机构而言，数据记录是用户的消费记录，此时的业务属性即为用户标识(包括手机号、身份证号、用户名等等)，或者对该用户标识进行哈希算法所得到的哈希值；或者，对于政府机构而言，数据记录为多个公共项目的开销流水，则此时的业务属性可以为每个项目的唯一编号。
所述执行信息包括待存储数据记录在该块链式账本中的全局序列号、时间戳以及执行结果等等。容易理解，在中心化的数据库服务端中，由于无需共识即可存储，从而对于数据记录的执行结果总是成功。
S203，在所述块链式账本中，获取包含同一业务属性的前一数据记录。
具体而言，首先，数据库服务端可以从待存储数据记录中的指定标识字段获取业务属性。
指定标识字段的具体位置以及获取方式可以是数据库服务端和对接机构事先协商。例如，对接机构所提供的数据记录为标准结构化的数据记录时，指定标识字段可以从数据记录中指定偏移量获取，或者由特定字符标识起始位置和结束位置(例如，以字符OE标识业务属性的开头，以字符OF标识结尾)；又或者，对接机构所提供的数据记录为非结构化的数据时，在对接机构上传时可以直接在每条数据记录的开头拼接上包含业务属性的头部，数据库服务端可以直接从头部获取每条数据记录的业务属性。
在确定了业务属性之后，一种可行的方式即为，数据库服务端可以从账本中由后往前对数据记录进行遍历，获取包含同一业务属性的前一数据记录；或者，另一种可行的方式即为，从预先建立的倒排索引中查询获取包含同一业务属性的前一数据记录。
倒排索引中包含了业务属性和位置信息的对应关系，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量。倒排索引的具体建立方式以及使用方式将在下文详述。
此处的前一数据记录指的是在块链式账本中的写入时间(即数据记录所处的数据块的成块时间)距离当前最近的数据记录，由于块链式账本的数据块块高和成块时间都是单调递增，因此，前一数据记录也可以是指所处数据块的块高最大的数据记录。
同时需要说明的是，前一数据记录可以是已经存储好了的数据记录，也可以同样是待存储的数据记录。对于对服务端而言，在一条待存储的数据记录执行完毕以后，则需要将相应的执行信息返回给客户端。返回的执行信息可以是同步返回，也可以是异步返回。
S205，确定所述前一数据记录的哈希值，生成包含所述哈希值和执行信息的收据记录。
收据记录的生成方式可以是直接拼接前一数据的哈希值和待存储的数据记录，例如，将前一数据的哈希值置于收据记录的头部或者尾部，拼接得到收据记录。如图3所示，图3为本说明书实施例所提供的收据记录的生成方式的示意图。由该示意图可以看出，前一数据记录是可以基于Pre-hash(前一数据记录的哈希)一直向前追溯直至最初的数据记录的。
需要说明的是，在本说明书实施例中，每一条待存储的数据记录都会有一条对应的收据记录。在一种实施方式中，对应的方式可以基于序号实现。例如，待存储数据记录在数据列表中的序号和收据记录在收据列表中的序号相同。
S207，将所述待存储数据记录和收据记录写入所述块链式账本的同一块体中。
在本说明书实施例中，块链式账本中的数据块包括块头和块体。
块头中头用于存储关于数据块的元数据，元数据可以包括诸如前一数据块的哈希值，自身数据块的哈希值，自身数据块中的数据记录的默克尔树的根哈希，自身数据块中的收据树的根哈希值，版本号等等；块体中则可以同于存储数据记录列表，以及，数据记录对应的收据记录列表等等。数据记录和收据记录在同一块体中一一对应。
如图4所示，图4为本说明书实施例所提供的数据块块头和块体的格式示意图。在块链式账本中，数据块的格式可以基于用户需求实行自定义，对比本方案不做限定。例如，在一种实施方式中，数据块的块头还可以包含描述数据记录操作状态的状态数组等等。
具体而言，在以块链式账本存储数据的中心化的数据库服务端中，数据块通过如下方式生成：
获取至少一条待存储数据记录和对应的收据记录，确定所述待存储数据记录的哈希值。
用户所产生的待存储数据记录可以是客户端个人用户的各种消费记录，也可以是应用服务器基于用户的指令，在执行业务逻辑时产生的业务结果、中间状态以及操作记录等等。具体的业务场景可以包括消费记录、审计日志、供应链条、政府监管记录、医疗记录等等。
当达到预设的成块条件时，当达到预设的成块条件时，确定待写入数据块中的各待存储数据记录，生成包含数据块的哈希值和待存储数据记录的第N个数据块。
在最细粒度下，可以一条待存储数据记录即生成一个数据块，在这种方式下对于服务端的计算和存储能力都要求较高。
更常见的应用方式为在一个数据块中存储多条待存储数据记录。因此，一般会基于预设条件生成数据块，所述预设的成块条件包括：待存储的数据记录的数量达到数量阈值，例如，每接收到一千条待存储数据记录时，生成一个新数据块，将一千条待存储数 据记录写入块中；或者，距离上一次成块时刻的时间间隔达到时间阈值，例如，每隔5分钟，生成一个新数据块，将在这5分钟内接收到的待存储数据记录写入块中。
此处的N指的是数据块的序号，换言之，在本说明书实施例中，数据块是以块链的形式，基于成块时间的顺序先后排列，具有很强的时序特征。其中，数据块的块高基于成块时间的先后顺序单调递增。块高可以是序号，此时第N个数据块的块高即为N。
块高也可以其它方式生成，例如，确定数据块的成块时间，而后采用对称加密算法将所述成块时间其转换为整型数据，将所述整型数据作为所述数据块的块高，成块时间越早，整型数据越小。具体而言，这里的整型可以是一个大整型数据，例如，一个13位的大整数。从而，由于大整型是基于时间对称加密得到的，从而在需要数据块的成块时间时，可以同样的对称解密获得成块时间。如，对于成块时间“20xx-01-19 03:14:07.938576”，在经过对称加密之后，可以转换为一个大整型“1547838847938”，由于整型数据随时间单调递增，因此，“1547838847938”。此时即可以做为该数据块的块高，用于标识该数据块。
当N＝1时，即此时的数据块为初始数据块。初始数据块的哈希值和块高基于预设方式给定。例如，初始数据块中不包含数据记录，哈希值则为任一给定的哈希值，块高blknum＝0；又例如，初始数据块的生成触发条件与其它数据块的触发条件一致，但是初始数据块的哈希值由对初始数据块中的所有内容取哈希确定。
当N>1时，由于前一数据块的内容和哈希值已经确定，则此时，可以基于前一数据块(即第N－1个数据块)的哈希值生成当前数据块(第N个数据块)的哈希值，例如，一种可行的方式为，确定每一条将要写入第N个块中的待存储数据记录的哈希值，按照在块中的排列顺序，生成一个默克尔树，将默克尔树的根哈希值和前一数据块的哈希值拼接在一起，再次采用哈希算法，生成当前块的哈希值。又例如，还可以按照块中的待存储数据记录的顺序进行拼接并取哈希得到整体数据记录的哈希值，拼接前一数据块的哈希值和整体数据记录的哈希值，并对拼接得到的字串进行哈希运算，生成数据块的哈希值。
通过前述的数据块的生成方式，每一个数据块通过哈希值确定，数据块的哈希值由数据块中的数据记录的内容、顺序以及前一数据块的哈希值决定。用户可以随时基于数据块的哈希值发起验证，对于数据块中任何内容(包括对于数据块中数据记录内容或者顺序的修改)的修改都会造成在验证时计算得到的数据块的哈希值和数据块生成时的哈希值不一致，而导致验证失败，从而实现了中心化下的不可篡改。
在每将一条待存储数据记录写入数据块之后，数据库服务端即可以将用户所产生的待存储数据记录的哈希值返回给客户端，以便客户端随时发起查询和验证。
当用户在查询时，输入相应的哈希值至数据库服务端，服务端即可以返回相应的待存储数据记录以及对应的收据记录至客户端，从而客户端可以从中得到自身所产生的待存储的数据记录，以及前一数据记录的哈希值。进而，在客户端有需要时，还可以进行进一步的往前追溯查询，直至客户端所产生的第一条写入账本的数据记录，得到一条完整的基于业务属性的数据记录的链路。在客户端进行验证时也是类似的原理。
通过本说明书实施例所提供的方案，在接收到用户需要存储的数据记录时，根据待存储数据记录中的业务属性，获取同一业务属性下前一数据记录的哈希值，将前一数据记录的哈希值写入待存储数据记录的收据中，并将待存储数据记录和收据写入同一数据块中，实现用户数据记录之间的相互关联，从而日后可以从存储的数据块中进行链路式的查询或者验证，提高用户体验。
在本说明书实施例中，待存储数据记录通常是分散式的存储在多个数据块中，因此，还可以在待存储数据记录写入账本后，创建相应的索引，以便查询。具体而言，所述索引的创建方式如图5所示，图5为本说明书实施例提供的一种数据记录的索引创建方法的流程示意图，该流程具体包括如下步骤：
S501，获取数据记录中的业务属性。
获取数据记录中的业务属性的方式在前文已经进行了说明，此处不再赘述。
S503，确定所述数据记录在账本中的位置信息。
如前所述，一个块链式的账本由多个数据块组成，同时，一个数据块中通常包含多个数据记录。因此，在本说明书实施例中，所述的位置信息具体指的是一条数据记录被保存时，处于账本中的哪个数据块上，以及，在该数据块中的偏移量。
在本说明书实施例所提供的数据块中，可以有多种方式用来标识不同的数据块，包括数据块的哈希值或者块高。
数据块的哈希值为根据前一区块哈希值和自身数据记录进行哈希计算而得到的哈希值，可以用于唯一、明确地标识一个数据块。在块链式的账本中，通常第一个数据块其块高为0，以后每增加一个数据块，块高加1；或者，还可以将数据块的成块时间转换为一个大的单调递增整型数据(一般为12至15位)序列，作为数据块的块高。因此，一个数据块通常有一个明确的块高。
在一个已经确定的要写入数据库的数据块，其中数据记录的排序也已经固定，因此一个数据记录在该数据块中的序号也是明确的，在数据记录的长度为固定单位时，序号同样可以用于明确该数据记录在其所处的数据块中的位置信息。即，序号同样也可以用于指示偏移量。
同时，在一个数据块中，由于通常包含了多个数据记录，因此，还可以用各数据记录在该数据块中的地址偏移量来分别标识数据块中的数据记录。显而易见，在同一个数据块中，各数据记录的地址偏移量并不相同。
当然，由于在本说明书实施例所提供的方式中，数据块的具体格式是可以自定义的(例如，数据块的块头中所包含的元数据信息和备注信息，数据块的块高所采取的形式等等)，在不同的格式下，位置信息的内容也会有所不同，这并不构成对本方案的限定。
S505，建立所述业务属性和位置信息的对应关系，写入以所述业务属性为主键的倒排索引。
在该索引中，主键是数据记录中所包含的业务属性。具体的写入方式为，当索引中的主键不包含所述业务属性时，在索引表中创建以所述业务属性为主键的索引记录。
当所述索引中的主键包含所述业务属性时，将所述位置信息写入所述业务属性所处的索引记录。需要说明的是，此处的写入不是覆盖性的写入，而是将位置信息添加到该索引记录的值中，与其它位置信息并列存在与该索引记录中。
如表1所示，表1为本说明书实施例所提供的一种示例性索引表。其中Key即为业务属性的具体值，Value部分的每个数组即为一条位置信息，每个数组中的前部分块高，后部分为数据记录在该数据块中的序号，通过块高和序号即可以唯一的确定一条数据记录。容易理解，在索引表中，一个key可以对应于多个位置信息。
表1
Key Value
0X123456 (2,08)，(2,10)，(300,89)，(300,999)
344X0001 (5,01)，(8,22)
…… ……
通过本说明书实施例所提供的方案，对于写入账本的数据记录，确定出数据记录的业务属性，以及在账本中的存储位置，建立起二者的对应关系，创建以业务属性为主键 的倒排索引，不必了解用户的业务详情，从索引中即可以基于业务属性对于数据记录进行相应统计，以及后续的查询和验证。
在一种实施例中，获取包含同一业务属性的前一数据记录时，即可以从前述的索引表中进行查询获取。例如，若有一条新的待存储记录中，其业务属性为“344X0001”，则此时从表中可以查询得到其对应的数据记录所处的块高为5和8，因此，可以根据块高的最大值“8”所对应的位置信息(8,22)获取前一数据记录。
进一步地，如果块高的最大值所对应的位置信息存在多条，则此时，可以根据偏移量的大小来确定前一数据记录的位置信息。例如，若有一条新的待存储记录中，其业务属性为“0X123456”，则此时可以查询得到该业务属性所对应的块高的最大值为300，存在两条对应的位置信息(300,89)，(300,999)，此时，则可以基于偏移量的大小，确定位置信息(300,999)来获取前一数据记录。
在一种实施例中，如果在倒排索引中基于业务属性查询不到相应的位置信息，或者，遍历账本也查询不到包含同一业务属性的数据记录。则，此时可以认定在该账本中，该业务属性为初次写入，则此时，可以将待存储数据记录本身确定为所述前一数据记录。
在一种实施方式中，服务端还可以从未存储的数据记录中查询获取前一数据记录。例如，服务端对于还未写入数据块中的数据记录进行遍历查询，获取包含同一业务属性的一条或者多条待存储的数据记录，根据接收到数据记录的时间戳进行排序，将时间间隔最近的待存储的数据记录确定为前一数据记录。当然，如果在未写入数据块中的数据记录中查询不到包含同一业务属性的数据记录，则可以从数据块中(即已经存储的)查询获取前一数据记录。
对应的，本说明书实施例还提供一种基于收据的数据存储装置，应用于以块链式账本存储数据的中心化的数据库服务端中，所述块链式账本中的数据块包括块头和块体，如图6所示，图6是本说明书实施例提供的一种基于收据的数据存储装置的结构示意图，包括：
第一获取模块601，获取包含业务属性的待存储数据记录，确定所述待存储数据记录的执行信息；
第二获取模块603，在所述块链式账本中，获取包含同一业务属性的前一数据记录；
生成模块605，确定所述前一数据记录的哈希值，生成包含所述哈希值和执行信息的收据记录；
写入模块607，将所述待存储数据记录和收据记录写入所述块链式账本的同一块体中。
进一步地，所述第二获取模块603，从预先建立的倒排索引中查询获取所述业务属性所对应的位置信息，其中，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量；确定所述位置信息中的块高的最大值；根据所述块高的最大值所对应的位置信息获取所述前一数据记录。
进一步地，所述第二获取模块603，若所述倒排索引中查询所述获取所述业务属性所对应的位置信息失败，将所述待存储数据记录本身确定为所述前一数据记录。
进一步地，所述装置还包括数据块生成模块609，获取至少一条待存储数据记录和对应的收据记录，确定所述待存储数据记录的哈希值；当达到预设的成块条件时，确定待写入数据块中的各存储数据记录和对应的收据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
当N>1时，根据待写入数据块中的各待存储数据记录和对应的收据记录，以及第N－1个数据块的哈希值确定第N个数据块的哈希值，将所述第N个数据块哈希值写入第N个数据块的块头，将所述各待存储数据记录和对应的收据记录写入第N个数据块的块体，其中，数据块的块高基于成块时间的先后顺序单调递增。
进一步地，所述预设的成块条件包括：待存储的数据记录数量达到数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
进一步地，所述装置还包括倒排索引建立装置611，获取待存储数据记录中的业务属性；确定所述数据记录在账本中的位置信息，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量；建立所述业务属性和位置信息的对应关系，写入以所述业务属性为主键的倒排索引。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图2所示的数据存储方法。
图7示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总 线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图2所示的数据存储方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存 储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (13)

  1. 一种基于收据的数据存储方法，应用于以块链式账本存储数据的中心化的数据库服务端中，所述块链式账本中的数据块包括块头和块体，所述方法包括：
    获取包含业务属性的待存储数据记录，确定所述待存储数据记录的执行信息；
    在所述块链式账本中，获取包含同一业务属性的前一数据记录；
    确定所述前一数据记录的哈希值，生成包含所述哈希值和执行信息的收据记录；
    将所述待存储数据记录和收据记录写入所述块链式账本的同一块体中。
  2. 如权利要求1所述的方法，获取包含同一业务属性的前一数据记录，包括：
    从预先建立的倒排索引中查询获取所述业务属性所对应的位置信息，其中，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量；
    确定所述位置信息中的块高的最大值；
    根据所述块高的最大值所对应的位置信息获取所述前一数据记录。
  3. 如权利要求2所述的方法，还包括：
    若所述倒排索引中查询所述获取所述业务属性所对应的位置信息失败，将所述待存储数据记录本身确定为所述前一数据记录。
  4. 如权利要求1所述的方法，将所述待存储数据记录和收据记录写入所述块链式账本的同一块体中，包括：
    获取至少一条待存储数据记录和对应的收据记录，确定所述待存储数据记录的哈希值；
    当达到预设的成块条件时，确定待写入数据块中的各存储数据记录和对应的收据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各待存储数据记录和对应的收据记录，以及第N－1个数据块的哈希值确定第N个数据块的哈希值，将所述第N个数据块哈希值写入第N个数据块的块头，将所述各待存储数据记录和对应的收据记录写入第N个数据块的的块体，其中，数据块的块高基于成块时间的先后顺序单调递增。
  5. 如权利要求4所述的方法，所述预设的成块条件包括：
    待存储的数据记录数量达到数量阈值；或者，
    距离上一次成块时刻的时间间隔达到时间阈值。
  6. 如权利要求2所述的方法，所述倒排索引通过如下方式预先建立：
    获取待存储数据记录中的业务属性；
    确定所述数据记录在账本中的位置信息，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量；
    建立所述业务属性和位置信息的对应关系，写入以所述业务属性为主键的倒排索引。
  7. 一种基于收据的数据存储装置，应用于以块链式账本存储数据的中心化的数据库服务端中，所述块链式账本中的数据块包括块头和块体，所述装置包括：
    第一获取模块，获取包含业务属性的待存储数据记录，确定所述待存储数据记录的执行信息；
    第二获取模块，在所述块链式账本中，获取包含同一业务属性的前一数据记录；
    生成模块，确定所述前一数据记录的哈希值，生成包含所述哈希值和执行信息的收据记录；
    写入模块，将所述待存储数据记录和收据记录写入所述块链式账本的同一块体中。
  8. 如权利要求7所述的装置，第二获取模块，从预先建立的倒排索引中查询获取所述业务属性所对应的位置信息，其中，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量；确定所述位置信息中的块高的最大值；根据所述块高的最大值所对应的位置信息获取所述前一数据记录。
  9. 如权利要求8所述的装置，第二获取模块，若所述倒排索引中查询所述获取所述业务属性所对应的位置信息失败，将所述待存储数据记录本身确定为所述前一数据记录。
  10. 如权利要求7所述的装置，还包括数据块生成模块，获取至少一条待存储数据记录和对应的收据记录，确定所述待存储数据记录的哈希值；
    当达到预设的成块条件时，确定待写入数据块中的各存储数据记录和对应的收据记录，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各待存储数据记录和对应的收据记录，以及第N－1个数据块的哈希值确定第N个数据块的哈希值，将所述第N个数据块哈希值写入第N个数据块的块头，将所述各待存储数据记录和对应的收据记录写入第N个数据块的的块体，其中，数据块的块高基于成块时间的先后顺序单调递增。
  11. 如权利要求10所述的装置，所述预设的成块条件包括：待存储的数据记录数量达到数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
  12. 如权利要求8所述的装置，还包括倒排索引建立装置，获取待存储数据记录中的业务属性；确定所述数据记录在账本中的位置信息，所述位置信息包括数据记录所处 的数据块的块高，以及，在所处的数据块中的偏移量；建立所述业务属性和位置信息的对应关系，写入以所述业务属性为主键的倒排索引。
  13. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求1至6任一项所述的方法。
PCT/CN2020/071601 2019-06-20 2020-01-11 一种基于收据的数据存储方法、装置及设备 WO2020253231A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US16/815,539 US10944549B2 (en) 2019-06-20 2020-03-11 Blockchain-type data storage
US16/945,162 US11005648B2 (en) 2019-06-20 2020-07-31 Blockchain-type data storage
US16/945,128 US10999062B2 (en) 2019-06-20 2020-07-31 Blockchain-type data storage
US17/195,408 US11223471B2 (en) 2019-06-20 2021-03-08 Blockchain-type data storage

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910537650.2 2019-06-20
CN201910537650.2A CN110347679B (zh) 2019-06-20 2019-06-20 一种基于收据的数据存储方法、装置及设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/815,539 Continuation US10944549B2 (en) 2019-06-20 2020-03-11 Blockchain-type data storage

Publications (1)

Publication Number Publication Date
WO2020253231A1 true WO2020253231A1 (zh) 2020-12-24

Family

ID=68182516

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/071601 WO2020253231A1 (zh) 2019-06-20 2020-01-11 一种基于收据的数据存储方法、装置及设备

Country Status (2)

Country Link
CN (1) CN110347679B (zh)
WO (1) WO2020253231A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110347679B (zh) * 2019-06-20 2020-08-04 阿里巴巴集团控股有限公司 一种基于收据的数据存储方法、装置及设备
US10944549B2 (en) 2019-06-20 2021-03-09 Advanced New Technologies Co., Ltd. Blockchain-type data storage
CN111046052B (zh) * 2019-11-11 2021-04-06 蚂蚁区块链科技(上海)有限公司 一种数据库中的操作记录存储方法、装置及设备
CN112527828B (zh) * 2020-12-10 2023-03-14 福建新大陆支付技术有限公司 一种税控机税控记录存储方法及检索查询方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106776785A (zh) * 2016-11-24 2017-05-31 腾讯科技（深圳）有限公司 一种数据写入方法及装置和数据处理系统
CN109213797A (zh) * 2018-09-30 2019-01-15 中国联合网络通信集团有限公司 一种区块链的查询方法及装置
CN109902071A (zh) * 2019-01-31 2019-06-18 阿里巴巴集团控股有限公司 业务日志存储方法、系统、装置及设备
CN109902086A (zh) * 2019-01-31 2019-06-18 阿里巴巴集团控股有限公司 一种索引创建方法、装置及设备
CN110347679A (zh) * 2019-06-20 2019-10-18 阿里巴巴集团控股有限公司 一种基于收据的数据存储方法、装置及设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10447480B2 (en) * 2016-12-30 2019-10-15 Guardtime Sa Event verification receipt system and methods
CN109117097B (zh) * 2018-09-05 2020-06-12 深圳正品创想科技有限公司 一种基于区块链的数据存储方法及系统
CN109034851B (zh) * 2018-09-05 2022-03-08 深圳正品创想科技有限公司 基于区块链的商品防伪溯源方法及其装置、区块链节点
CN109471905B (zh) * 2018-11-16 2020-08-25 华东师范大学 一种支持时间范围和属性范围复合查询的区块链索引方法
CN109634959B (zh) * 2018-11-30 2020-12-25 北京瑞卓喜投科技发展有限公司 一种区块索引方法及区块索引装置
CN109727030A (zh) * 2018-12-18 2019-05-07 杭州茂财网络技术有限公司 一种区块链中账户数据存储方法
CN109902125A (zh) * 2018-12-27 2019-06-18 链极智能科技(上海)有限公司 一种基于现有数据库的分布式储存方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106776785A (zh) * 2016-11-24 2017-05-31 腾讯科技（深圳）有限公司 一种数据写入方法及装置和数据处理系统
CN109213797A (zh) * 2018-09-30 2019-01-15 中国联合网络通信集团有限公司 一种区块链的查询方法及装置
CN109902071A (zh) * 2019-01-31 2019-06-18 阿里巴巴集团控股有限公司 业务日志存储方法、系统、装置及设备
CN109902086A (zh) * 2019-01-31 2019-06-18 阿里巴巴集团控股有限公司 一种索引创建方法、装置及设备
CN110347679A (zh) * 2019-06-20 2019-10-18 阿里巴巴集团控股有限公司 一种基于收据的数据存储方法、装置及设备

Also Published As

Publication number Publication date
CN110347679A (zh) 2019-10-18
CN110347679B (zh) 2020-08-04

Similar Documents

Publication Publication Date Title
WO2021073242A1 (zh) 索引创建和数据查询方法、装置及设备
CN110188096B (zh) 一种数据记录的索引创建方法、装置及设备
WO2020253231A1 (zh) 一种基于收据的数据存储方法、装置及设备
WO2020211569A1 (zh) 一种数据记录的索引创建方法
CN110162526B (zh) 一种块链式账本中数据记录的查询方法、装置及设备
WO2020244239A1 (zh) 一种基于业务标识的索引创建方法、装置及设备
WO2021017422A1 (zh) 一种块链式账本中的索引创建方法、装置及设备
CN110162662B (zh) 一种块链式账本中数据记录的验证方法、装置及设备
WO2020233146A1 (zh) 数据操作记录的存储方法、系统、装置及设备
WO2020244237A1 (zh) 一种块链式账本中的验证方法、装置及设备
WO2021073240A1 (zh) 一种块链式账本中的数据存储方法、装置及设备
WO2021057164A1 (zh) 一种块链式账本中的查询方法、装置及设备
WO2021093461A1 (zh) 一种块链式账本中的聚合计算方法、装置及设备
WO2021073241A1 (zh) 一种基于磁盘存储的数据读取方法、装置及设备
US11005648B2 (en) Blockchain-type data storage
WO2021057127A1 (zh) 一种基于多条业务属性的数据存储方法、装置及设备
CN110334094B (zh) 一种基于倒排索引的数据查询方法、系统、装置及设备
WO2020244238A1 (zh) 多层块链式账本的数据存储方法、装置及设备
US11126751B2 (en) Index creation for data records
WO2021093462A1 (zh) 一种数据库中的操作记录存储方法、装置及设备
CN110362570B (zh) 一种数据存储方法、装置及设备
CN111444194B (zh) 一种块链式账本中索引的清除方法、装置及设备
CN110636042B (zh) 一种服务端已验证块高的更新方法、装置及设备
CN111444195B (zh) 一种块链式账本中索引的清除方法、装置及设备
CN112307010B (zh) 一种数据存储方法、装置及设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20827813

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20827813

Country of ref document: EP

Kind code of ref document: A1