WO2021057127A1 - 一种基于多条业务属性的数据存储方法、装置及设备 - Google Patents

一种基于多条业务属性的数据存储方法、装置及设备 Download PDF

Info

Publication number
WO2021057127A1
WO2021057127A1 PCT/CN2020/097532 CN2020097532W WO2021057127A1 WO 2021057127 A1 WO2021057127 A1 WO 2021057127A1 CN 2020097532 W CN2020097532 W CN 2020097532W WO 2021057127 A1 WO2021057127 A1 WO 2021057127A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
block
data record
data block
record
Prior art date
Application number
PCT/CN2020/097532
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 支付宝(杭州)信息技术有限公司
Publication of WO2021057127A1 publication Critical patent/WO2021057127A1/zh

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/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures

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 multiple business attributes.
  • a centralized database server uses a block-chained ledger to provide services to the outside world
  • users' data records often have multiple business attributes. For example, a user has created a piece of music with a combination of rock, blues, and reggae styles. When the user uploaded the work to the database server for storage, he also marked these styles.
  • the purpose of the embodiments of the present application is to provide a data storage solution based on multiple business attributes in a centralized blockchain ledger.
  • a data storage method based on multiple business attributes is applied to a centralized database service provider that stores data through a block chain ledger, and the method includes:
  • any data record in the Nth data block multiple business attributes of the data record are obtained, the corresponding relationship between each business attribute and the data record is established respectively, and the index with each business attribute as the main key is written.
  • the embodiment of this specification also provides a data storage device based on multiple business attributes, which is applied to a centralized database service provider that stores data through a block chain ledger, and the device includes:
  • the receiving module receives the data record to be stored sent by the client, where the data record contains multiple pieces of business attributes and business data;
  • the determining module determines the hash value of the data record, and sends the hash value to the client;
  • the data block generation module when the preset block condition is reached, determines each data record to be written in the data block, and generates the Nth data block containing the hash value of the data block and the data record;
  • the index writing module for any data record in the Nth data block, obtains multiple business attributes of the data record, respectively establishes the corresponding relationship between each business attribute and the data record, and writes each business attribute as The index of the primary key.
  • the business attributes of the data records are respectively determined, and the corresponding relationship between the business attributes and the data records is established for any business attribute.
  • any one of the embodiments of the present specification does not need to achieve all the above-mentioned effects.
  • FIG. 1 is a schematic flowchart of a data storage method based on multiple business attributes provided by an embodiment of this specification
  • FIG. 2 is a schematic diagram of a block header of a data block provided by an embodiment of this specification
  • FIG. 3 is a schematic diagram of the structure of a data record provided by an embodiment of the specification.
  • FIG. 4 is a schematic structural diagram of a data storage device based on multiple business attributes according to an embodiment of this specification
  • Fig. 5 is a schematic structural diagram of a device for configuring the method of the embodiment of this specification.
  • Figure 1 is a schematic flow diagram of a data storage method based on multiple business attributes provided by an embodiment of this specification, which is applied to a centralized database service provider that stores data through a block chain ledger.
  • the flow is specific Including the following steps:
  • S101 Receive a to-be-stored data record sent by a client, where the data record contains multiple pieces of business attributes and business data.
  • the data records to be stored here can be various consumption records and original works of individual users on the client side, or they can be business results, intermediate states, and operation records generated when the application server executes business logic based on user instructions. Wait. Specific business scenarios can include consumption records, audit logs, work deposit certificates, supply chains, government supervision records, medical records, and so on.
  • business attributes are based on different business scenarios and can take many forms.
  • business attributes can include user name, user ID number, driver's license number, mobile phone number, project unique number, and so on.
  • the business data is the user's consumption record, and 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.
  • a data record may contain multiple business attributes.
  • a user has created a piece of music with a combination of rock, blues, and reggae styles.
  • the user can then mark the business attributes through the corresponding operating instructions.
  • the user enters APPEND (CLUE_INFO, SET, ⁇ rock, blues, Reggae ⁇ , txbody), where "CLUE_INFO, SET, ⁇ rock, blues, Reggae ⁇ " indicates that the business attribute in this data record contains "rock , Blues, Reggae” set, "txbody” is the user's original music (that is, the user's business data).
  • the client can generate a data record containing multiple business attributes and business data according to the instruction. For example, you can directly splice business attribute collections and business data to generate data records. Among them, the designated field (for example, head or tail) of the data record is used to store a set of business attributes.
  • the client can also send the business attribute set and business data to the database server at the same time, and the database server then generates a data record containing multiple business attributes and business data.
  • FIG. 3 is a schematic diagram of the structure of a data record provided by an embodiment of this specification.
  • S103 Determine the hash value of the data record, and send the hash value to the client.
  • the calculation method of the hash value is the conventional calculation method, which will not be repeated here.
  • the user can verify or query according to the returned hash value to prove that the database server has not tampered with the business data.
  • S105 When a preset block forming condition is reached, determine each data record to be written in the data block, and generate an Nth data block including the hash value of the data block and the data record.
  • the preset blocking conditions include: the number of data records to be stored reaches the number threshold, for example, every time one thousand data records are received, a new data block is generated and one thousand data records are written into the block; or , The time interval from the last block formation time reaches the time threshold, for example, every 5 minutes, a new data block is generated, and the data records received within these 5 minutes are written into the block.
  • N 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 strong timing characteristics.
  • 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, at this time the block height of the Nth data block is N; the block height can also be generated in other ways.
  • 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, a feasible way is to determine the hash value of each data record to be written in the Nth block, and generate a Merck according to the order in the block.
  • 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.
  • the specific verification method includes recalculating the hash value of the data record itself and the hash value of the data block in which it is located, and comparing it with the locally stored hash value.
  • the data block generated in the above manner may include two parts: a block header and a block body.
  • the block body can be used to store the plaintext of the data record, or the hash value of the data record, etc.; the block header can be used to store metadata about the data block, for example, the version number of the ledger, the hash of the previous data block Value, the root hash value of the Merkel tree composed of data records in the own data block, the hash value of the own data block, the state array used to record the operated state of the data record, and so on.
  • FIG. 2 is a schematic diagram of a block header of a data block provided by an embodiment of this specification.
  • each data block is determined by a hash value, and the hash value of the data block is determined by the content and order of the data records in the data block and the hash value of the previous data block.
  • the user can initiate integrity 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 result in the hash of the data block calculated during verification. The value is inconsistent with the hash value when the data block is generated, which leads to verification failure, thus realizing non-tampering under centralization.
  • Integrity verification includes the integrity verification of a data block, that is, the Merkel tree is reconstructed according to the hash value of the data record in the data block, the root hash value of the Merkel tree is calculated, and the Merkel tree is The root hash value and the hash value of the previous data block are recalculated for the hash value of the data block, and the consistency is compared with the hash value of the data block saved in advance.
  • Integrity verification can also include integrity verification for several consecutive data blocks, that is, recalculating the data block based on the root hash value of the Merkel tree stored in the block header of the data block and the hash value of the previous data block. The hash value is compared with the hash value of the data block saved in advance.
  • S107 For any data record in the Nth data block, obtain multiple business attributes of the data record, respectively establish a corresponding relationship between each business attribute and the data record, and write an index with each business attribute as the main key .
  • the specified field in each data record in the data block contains the business attribute set of the data record.
  • the specific location of the set of business attributes in the data record and the method of obtaining it can be negotiated and defined in advance between the database server and the user.
  • the business attribute set can be obtained from the specified offset in the data record, or the start position and end position can be identified by specific characters; or
  • the business attribute set can be directly spliced at the beginning of each data record when uploading on the client.
  • the database server can directly obtain the data record of each data record from the head of the data record. Business attribute collection.
  • the corresponding relationship between each business attribute and the data record is established. Specifically, the relationship between the business attribute and the hash value of the data record can be established, or the corresponding relationship between the business attribute and the location information of the data record can be established.
  • the business attribute set is ⁇ rock, blues, Reggae ⁇ , assuming that the value in the index table is the hash value of the data record, and the hash value of the data record is "hash1", then Create three corresponding key-value pairs in the index table, (rock, hash1), (blues, hash1), (Reggae, hash1) and write them into the index.
  • the index may also record the relationship between the business attribute and the location information of the data record.
  • 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 located when a data record is saved, and where it is 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 unambiguously 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 sequence number can also be 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, and the block height of the data block is adopted Format, etc.), in different formats, the content of the location information will also be different, which does not constitute a limitation to this solution.
  • 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.
  • a key can correspond to multiple location information. Assume that the location information of the data record containing the business attribute set ⁇ rock, blues, Reggae ⁇ is: block height 2, sequence number 8. Then three corresponding relationships will be written into the index at the same time.
  • the index is an inverted index.
  • the primary key is the business attributes contained in the data record.
  • the specific writing method is: when the primary key in the index does not contain the business attribute of the data record, an index record with the business attribute as the primary key is created in the index table.
  • the hash value or location information of the data record is written into the index record where the business attribute is located. It should be noted that the writing here is not an overwriting write, but the hash value/location information is added to the value of the index record, and it exists in parallel with other hash values/location information in the index record. .
  • the business attributes of the data records are respectively determined, and the corresponding relationship between the business attributes and the data records is established for any business attribute.
  • an obtaining method can be created synchronously, that is, when the data record to be stored sent by the user is received, the specified field in the obtained data record is directly parsed
  • the multiple business attributes included are synchronized to create indexes when the data block is written into the ledger. Another way is that after the data block is written into the ledger, there is no need to create an index immediately, but when the database has free resources, it will target the newly written data block (that is, the Nth in the aforementioned ledger).
  • Each data record in each data block obtains multiple business attributes contained in its designated field, and creates an index asynchronously. In the asynchronous creation mode, it is beneficial for the database server to stagger the peak hours and save resources.
  • the hash value/location information can be written into the index
  • the hash value/location information can also be arranged in sequence according to the sequence of the data record, which is beneficial to the user's query and verification.
  • the sequence of data records in the ledger can be reflected by the timestamp when the data record is written into the ledger (that is, the block timestamp of the data block), and for data records in the same data block, it can be displayed in the data block The sort of order to reflect one after another.
  • the embodiment of this specification also provides a data storage device based on multiple business attributes, which is applied to a centralized database service provider that stores data through a block chain ledger, as shown in FIG. 4, which is the original
  • the embodiment of the specification provides a schematic structural diagram of a data storage device based on multiple business attributes, including:
  • the receiving module 401 receives a data record to be stored sent by a client, where the data record contains multiple pieces of business attributes and business data;
  • the determining module 403 determines the hash value of the data record, and sends the hash value to the client;
  • Index writing module 407 for any data record in the Nth data block, obtains multiple business attributes of the data record, respectively establishes the corresponding relationship between each business attribute and the data record, and writes each business attribute The index of the primary key.
  • Each data record in the data block and the hash value of the N-1th data block determine the hash value of the Nth data block, and generate the hash value of the Nth data block and the Nth data of each data record Block, where the block height of the data block increases monotonically based on the sequence of the block time.
  • the preset blocking condition includes: the number of data records to be stored reaches a quantity threshold; or, the time interval from the last blocking time reaches a time threshold.
  • the index writing module 407 when receiving the data record to be stored sent by the user, obtains multiple business attributes contained in the specified field in the data record; or, determines the ledger For the data record contained in the Nth data block in the data block, for any data record contained in the data block, multiple business attributes contained in its designated field are obtained.
  • the index writing module 407 determines the location information of the data record in the ledger, and the location information includes the block height of the data block where the data record is located, and where the data record is located.
  • the index writing module 407 determines the time stamp of the data record; in the index record with the business attribute as the main key, according to the order of the time stamp, the location information of the data record is Write the value of the index record in sequence.
  • 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. 1 when the program is executed. Storage method.
  • FIG. 5 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 in the device through the bus 1050.
  • the processor 1010 may be implemented by a general CPU (Central Processing Unit, central processing unit), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc., for execution related Program to realize the technical solutions provided in the embodiments of this specification.
  • CPU Central Processing Unit
  • ASIC Application Specific Integrated Circuit
  • the memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (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 this specification are implemented by 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 it can be connected to the device to provide corresponding functions.
  • the input devices may include keyboards, mice, touch screens, microphones, various sensors, etc.
  • the output devices may include displays, speakers, vibrators, indicator lights, and so on.
  • 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 above device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include the equipment necessary for normal operation. Other components.
  • the above-mentioned devices may also include only the components necessary to implement the solutions of the embodiments of the present specification, and not necessarily include all the components shown in the figures.
  • the embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the data storage method shown in FIG. 1 is implemented.
  • 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)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种基于多条业务属性的数据存储方法、装置及设备，所述方法包括：接收客户端所发送的待存储的数据记录，其中，所述数据记录中包含有多条业务属性和业务数据（101）；确定数据记录的哈希值，发送所述哈希值至所述客户端（103）；当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块（105）；针对所述第N个数据块中的任一数据记录，获取该数据记录的多条业务属性，分别建立各业务属性与该数据记录的对应关系，写入以各业务属性为主键的索引（107）。

Description

一种基于多条业务属性的数据存储方法、装置及设备 技术领域
本说明书实施例涉及信息技术领域，尤其涉及一种基于多条业务属性的数据存储方法、装置及设备。
背景技术
在中心化的数据库服务端以块链式的账本对外提供服务时，用户的数据记录经常会存在多种业务属性。例如，某用户创作了一份音乐作品，该作品的风格兼有摇滚、布鲁斯以及雷鬼风格。该用户在将该作品上传至数据库服务端进行存储时，同时标注了这几种风格。
基于此，在中心化的块链式账本中，需要一种基于多条业务属性的数据存储方案。
发明内容
本申请实施例的目的是提供一种中心化的块链式账本中实现基于多条业务属性的数据存储方案。
为解决上述技术问题，本申请实施例是这样实现的：
一种基于多条业务属性的数据存储方法，应用于通过块链式账本存储数据的中心化的数据库服务提供端中，所述方法包括：
接收客户端所发送的待存储的数据记录，其中，所述数据记录中包含有多条业务属性和业务数据；
确定数据记录的哈希值，发送所述哈希值至所述客户端；
当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块；
针对所述第N个数据块中的任一数据记录，获取该数据记录的多条业务属性，分别建立各业务属性与该数据记录的对应关系，写入以各业务属性为主键的索引。
对应的，本说明书实施例还提供一种基于多条业务属性的数据存储装置，应用于通过块链式账本存储数据的中心化的数据库服务提供端中，所述装置包括：
接收模块，接收客户端所发送的待存储的数据记录，其中，所述数据记录中包含有多条业务属性和业务数据；
确定模块，确定数据记录的哈希值，发送所述哈希值至所述客户端；
数据块生成模块，当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块；
索引写入模块，针对所述第N个数据块中的任一数据记录，获取该数据记录的多条业务属性，分别建立各业务属性与该数据记录的对应关系，写入以各业务属性为主键的索引。
通过本说明书实施例所提供的方案，对于用户所发送的包含有多条业务属性的数据记录，分别确定出数据记录的业务属性，针对任一业务属性，建立起业务属性和数据记录的对应关系，写入以该业务属性为主键的倒排索引，从而不必了解用户的业务详情，从索引中即可以实现基于业务属性对于用户的数据记录进行相应的查询和验证，实现对于多业务属性的有效管理。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是本说明书实施例提供的基于多条业务属性的数据存储方法的流程示意图；
图2为本说明书实施例所提供的一种数据块的块头的示意图；
图3为本说明书实施例所提供的一种数据记录的构成示意图；
图4是本说明书实施例提供的一种基于多条业务属性的数据存储装置的结构示意图；
图5是用于配置本说明书实施例方法的一种设备的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
以下结合附图，详细说明本说明书各实施例提供的技术方案。如图1所示，图1是本说明书实施例提供的基于多条业务属性的数据存储方法的流程示意图，应用于通过块链式账本存储数据的中心化的数据库服务提供端中，该流程具体包括如下步骤：
S101，接收客户端所发送的待存储的数据记录，其中，所述数据记录中包含有多条业务属性和业务数据。
此处的待存储的数据记录，可以是客户端个人用户的各种消费记录、原创作品，也可以是应用服务器基于用户的指令，在执行业务逻辑时产生的业务结果、中间状态以及操作记录等等。具体的业务场景可以包括消费记录、审计日志、作品存证、供应链条、政府监管记录、医疗记录等等。
在实际应用中，业务属性基于不同的业务场景，可以有多种形式。在某些存证场景下，业务属性可以包括用户名、用户身份证号、驾照编号、手机号、项目唯一编号等等。例如，对于第三方支付机构而言，业务数据是用户的消费记录，此时的业务属性即为用户标识(包括手机号、身份证号、用户名等等)，或者对该用户标识进行哈希算法所得到的哈希值。
在本说明书实施例中，一条数据记录中可以包含有多条业务属性。例如，某用户创作了一份音乐作品，该作品的风格兼有摇滚、布鲁斯以及雷鬼风格。用户即可以通过相应的操作指令对业务属性进行标注。例如，用户输入APPEND(CLUE_INFO，SET，{rock，blues，Reggae}，txbody)，其中，“CLUE_INFO，SET，{rock，blues，Reggae}”表明本次数据记录中的业务属性是包含有“rock，blues，Reggae”的集合，“txbody”即为用户原创音乐(即该用户的业务数据)。
客户端可以根据该指令生成包含有多条业务属性和业务数据的数据记录。例如，可以直接拼接业务属性集合和业务数据，生成数据记录。其中，数据记录的指定字段(例如，头部或者尾部)用于存储业务属性集合。
在一种实施方式下，也可以是客户端将业务属性集合和业务数据同时发送至数据库 服务端，数据库服务端再生成包含有多条业务属性和业务数据的数据记录。如图3所示，图3为本说明书实施例所提供的一种数据记录的构成示意图。
S103，确定数据记录的哈希值，发送所述哈希值至所述客户端。
哈希值的计算方式即为常规的计算方式，此处不再赘述。用户可以根据返回的哈希值进行验证或者查询，以证明数据库服务端并没有对业务数据进行篡改。
S105，当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块。
所述预设的成块条件包括：待存储的数据记录数量达到数量阈值，例如，每接收到一千条数据记录时，生成一个新数据块，将一千条数据记录写入块中；或者，距离上一次成块时刻的时间间隔达到时间阈值，例如，每隔5分钟，生成一个新数据块，将在这5分钟内接收到的数据记录写入块中。
此处的N指的是数据块的序号，换言之，在本说明书实施例中，数据块是以块链的形式，基于成块时间的顺序先后排列，具有很强的时序特征。其中，数据块的块高基于成块时间的先后顺序单调递增。块高可以是序号，此时第N个数据块的块高即为N；块高也可以其它方式生成。
当N＝1时，即此时的数据块为为初始数据块。初始数据块的哈希值和块高基于预设方式给定。例如，初始数据块中不包含数据记录，哈希值则为任一给定的哈希值，块高blknum＝0；又例如，初始数据块的生成触发条件与其它数据块的触发条件一致，但是初始数据块的哈希值由对初始数据块中的所有内容取哈希确定。
当N>1时，由于前一数据块的内容和哈希值已经确定，则此时，可以基于前一数据块(即第N－1个数据块)的哈希值生成当前数据块(第N个数据块)的哈希值，例如，一种可行的方式为，确定每一条将要写入第N个块中的数据记录的哈希值，按照在块中的排列顺序，生成一个默克尔树，将默克尔树的根哈希值和前一数据块的哈希值拼接在一起，再次采用哈希算法，生成当前块的哈希值。又例如，还可以按照块中数据记录的顺序进行拼接并取哈希得到整体数据记录的哈希值，拼接前一数据块的哈希值和整体数据记录的哈希值，并对拼接得到的字串进行哈希运算，生成数据块的哈希值。
用户在上传数据成功后，即可以得到对应的数据记录的哈希值以及所处的数据块的哈希值，并保存，并且可以基于该哈希值发起完整性验证。具体的验证方式包括重新计算数据记录自身的哈希值以及所处的数据块的哈希值，与本地所保存的进行对比。
上述方式生成的数据块，可以包括块头和块体两个部分。块体中可以用于存储数据记录的明文，或者数据记录的哈希值等等；块头中可以用于存储有关本数据块的元数据，例如，账本的版本号，前一数据块的哈希值，自身数据块中的数据记录所组成的默克尔树的根哈希值，自身数据块的哈希值，用于记录数据记录的被操作状态的状态数组等等。如图2所示，图2为本说明书实施例所提供的一种数据块的块头的示意图。
通过前述的数据块的生成方式，每一个数据块通过哈希值确定，数据块的哈希值由数据块中的数据记录的内容、顺序以及前一数据块的哈希值决定。用户可以随时基于数据块的哈希值发起完整性验证，对于数据块中任何内容(包括对于数据块中数据记录内容或者顺序的修改)的修改都会造成在验证时计算得到的数据块的哈希值和数据块生成时的哈希值不一致，而导致验证失败，从而实现了中心化下的不可篡改。
完整性验证包括对于一个数据块的完整性验证，即，根据数据块中数据记录的哈希值重新组成默克尔树，计算默克尔树的根哈希值，并且根据默克尔树的根哈希值与前一数据块的哈希值重新计算该数据块的哈希值，与事先保存的数据块的哈希值进行一致性对比。
完整性验证还可以包括对于若干连续数据块的完整性验证，即根据数据块的块头中所保存的默克尔树的根哈希值与前一数据块的哈希值重新计算该数据块的哈希值，并与事先保存的数据块的哈希值进行对比。
如前所述，这些数据记录已经可以已不可篡改的形式写入了账本。但是对于用户而言，数据记录通常是分散式的存储在多个数据块中的。同时，一条业务数据存在多种业务属性，如果用户需要从账本中将该用户的数据记录有针对挑选出来，则很不方便。
S107，针对所述第N个数据块中的任一数据记录，获取该数据记录的多条业务属性，分别建立各业务属性与该数据记录的对应关系，写入以各业务属性为主键的索引。
如前所述，对于新生成的数据块而言，数据块中的每条数据记录中的指定字段中均包含有该数据记录的业务属性集合。换言之，业务属性集合在数据记录的具体位置以及获取方式可以是数据库服务端和用户事先协商定义的。
例如，客户端所提供的数据记录为标准结构化的数据记录时，业务属性集合可以从数据记录中指定偏移量获取，或者由特定字符标识起始位置和结束位置；又或者，客户端所提供的数据记录为非结构化的业务数据时，在客户端上传时可以直接在每条数据记录的开头拼接上业务属性集合，数据库服务端可以直接从数据记录的头部获取每条数据 记录的业务属性集合。
针对于业务属性集合中的每一个业务属性，分别建立各业务属性与该数据记录的对应关系。具体而言，可以建立业务属性与数据记录的哈希值的关系，或者，建立业务属性与数据记录的位置信息的对应关系。
例如，以前序的音乐作品为例，业务属性集合为{rock，blues，Reggae}，假设在索引表中的值是数据记录的哈希值，该数据记录的哈希值是“hash1”，则在该索引表中分别创建3份对应的键值对，(rock，hash1)，(blues，hash1)，(Reggae，hash1)并写入索引。
在一种实施方式中，索引中还可以记录业务属性与数据记录的位置信息的关系。如前所述，一个块链式的账本由多个数据块组成，同时，一个数据块中通常包含多个数据记录。因此，在本说明书实施例中，所述的位置信息具体指的是一条数据记录被保存时，处于账本中的哪个数据块上，以及，在该数据块中的什么位置。
在本说明书实施例所提供的数据块中，可以有多种方式用来标识不同的数据块，包括数据块的哈希值或者块高。
数据块的哈希值为根据前一区块哈希值和自身数据记录进行哈希计算而得到的哈希值，可以用于唯一、明确地标识一个数据块。在块链式的账本中，通常第一个数据块其块高为0，以后每增加一个数据块，块高加1；或者，还可以将数据块的成块时间转换为一个大的单调递增整型数据(一般为12至15位)序列，作为数据块的块高。因此，一个数据块通常有一个明确的块高。
又例如，在一个已经确定的要写入数据库的数据块，其中数据记录的排序也已经固定，因此一个数据记录在该数据块中的序号也是明确的，在数据记录的长度为固定单位时，序号同样可以用于明确该数据记录在其所处的数据块中的位置信息。即，序号同样也可以用于指示偏移量。
同时，在一个数据块中，由于通常包含了多个数据记录，因此，还可以用各数据记录在该数据块中的地址偏移量来分别标识数据块中的数据记录。显而易见，在同一个数据块中，各数据记录的地址偏移量并不相同。
当然，由于在本说明书实施例所提供的方式中，数据块的具体格式是可以自定义的(例如，数据块的块头中所包含的元数据信息和备注信息，数据块的块高所采取的形式等等)，在不同的格式下，位置信息的内容也会有所不同，这并不构成对本方案的限定。
如表1所示，表1为本说明书实施例所提供的一种示例性索引表。其中Key即为业务属性的具体值，Value部分的每个数组即为一条位置信息，每个数组中的前部分块高，后部分为数据记录在该数据块中的序号，通过块高和序号即可以唯一的确定一条数据记录。容易理解，在索引表中，一个key可以对应于多个位置信息。假设包含有业务属性集合{rock，blues，Reggae}的数据记录的位置信息为：块高2，序号8。则在该索引中将会被同时写入三份对应的关系。
表1
Key Value
rock (2,08)，(300,999)
blues (2,08)，(100,99)
Reggae (2,08)
…… ……
换言之，该索引是一个倒排索引。在该索引中，主键是数据记录中所包含的各业务属性。具体的写入方式为，当索引中的主键不包含该数据记录的业务属性时，在索引表中创建以所述业务属性为主键的索引记录。
当所述索引中的主键包含所述业务属性时，将数据记录的哈希值或者位置信息写入所述业务属性所处的索引记录。需要说明的是，此处的写入不是覆盖性的写入，而是将哈希值/位置信息添加到该索引记录的值中，与其它哈希值/位置信息并列存在与该索引记录中。
在表1被创建之后，用户输入查询指令，Retrieve(rock，&v，FULL)即可以获取作品中有“rock”属性的作品的位置信息(2,08)，(300,999)，进而根据位置信息查询得到相应的数据记录，并返回至用户。
而在针对数据记录进行某些统计时，则只需直接依据索引表进行就可以了。例如，用户想要统计包含有“blues”属性的数据记录的数量，此时，直接统计在索引表中的以“blues”为主键的值之后的Value数量就可以了。
通过本说明书实施例所提供的方案，对于用户所发送的包含有多条业务属性的数据记录，分别确定出数据记录的业务属性，针对任一业务属性，建立起业务属性和数据记录的对应关系，写入以该业务属性为主键的倒排索引，从而不必了解用户的业务详情，从索引中即可以实现基于业务属性对于用户的数据记录进行相应的查询和验证，实现对于多业务属性的有效管理。
在实际应用中，数据库服务方获取业务属性集合并写入索引时，一种获取方式可以同步创建，即接收到用户所发送的待存储的数据记录时，直接解析获取数据记录中的指定字段中所包含的多条业务属性，在数据块写入账本时，同步创建索引。另一种方式则为，在数据块写入账本以后，并不需要立即创建索引，而是在数据库有空余资源的时候，再针对新写入账本的数据块(即前述的账本中的第N个数据块)中的每条数据记录，分别获取其指定字段中所包含的多条业务属性，异步创建索引，在异步创建的方式下，有利于数据库服务方错开高峰时段，节省资源。
在一种实施方式中，由于索引表中的一条业务属性可以对应于多个哈希值/位置信息(即对应于多个数据记录)，因此，可以在将哈希值/位置信息写入索引中时，还可以将哈希值/位置信息按照数据记录的先后顺序依次进行排列，有利于用户的查询以及验证。数据记录在账本中的先后顺序即可以数据记录被写入账本的时间戳(即数据块的成块时间戳)来体现，以及，对于同一数据块中的数据记录，则可以通过在数据块中的排序先后来体现。
对应的，本说明书实施例还提供一种基于多条业务属性的数据存储装置，应用于通过块链式账本存储数据的中心化的数据库服务提供端中，如图4所示，图4是本说明书实施例提供的一种基于多条业务属性的数据存储装置的结构示意图，包括：
接收模块401，接收客户端所发送的待存储的数据记录，其中，所述数据记录中包含有多条业务属性和业务数据；
确定模块403，确定数据记录的哈希值，发送所述哈希值至所述客户端；
数据块生成模块405，当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块；
索引写入模块407，针对所述第N个数据块中的任一数据记录，获取该数据记录的多条业务属性，分别建立各业务属性与该数据记录的对应关系，写入以各业务属性为主键的索引。
进一步地，在所述装置中，所述数据块生成模块405，当N＝1时，初始数据块的哈希值和块高基于预设方式给定；当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块，其中，数据块的块高基于成块时间的先后顺序单调递增。
进一步地，在所述装置中，所述预设的成块条件包括：待存储的数据记录数量达到 数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
进一步地，在所述装置中，所述索引写入模块407，接收到用户所发送的待存储的数据记录时，获取数据记录中的指定字段中所包含的多条业务属性；或者，确定账本中的第N个数据块所包含的数据记录，针对所述数据块中所包含的任一数据记录，获取其指定字段中所包含的多条业务属性。
进一步地，在所述装置中，所述索引写入模块407，确定所述数据记录在账本中的位置信息，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量；针对任一业务属性，建立该业务属性与所述位置信息的对应关系，写入以该业务属性为主键的索引。
进一步地，在所述装置中，所述索引写入模块407，确定数据记录的时间戳；在以该业务属性为主键的索引记录中，按照时间戳的先后顺序，将数据记录的位置信息依序写入索引记录的值。
本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现图1所示的数据存储方法。
图5示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器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，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现图1所示的数据存储方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式 可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (13)

  1. 一种基于多条业务属性的数据存储方法，应用于通过块链式账本存储数据的中心化的数据库服务提供端中，所述方法包括：
    接收客户端所发送的待存储的数据记录，其中，所述数据记录中包含有多条业务属性和业务数据；
    确定数据记录的哈希值，发送所述哈希值至所述客户端；
    当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块；
    针对所述第N个数据块中的任一数据记录，获取该数据记录的多条业务属性，分别建立各业务属性与该数据记录的对应关系，写入以各业务属性为主键的索引。
  2. 如权利要求1所述的方法，生成包含数据块的哈希值和数据记录的第N个数据块，具体包括：
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块，其中，数据块的块高基于成块时间的先后顺序单调递增。
  3. 如权利要求2所述的方法，所述预设的成块条件包括：
    待存储的数据记录数量达到数量阈值；或者，
    距离上一次成块时刻的时间间隔达到时间阈值。
  4. 如权利要求1所述的方法，获取该数据记录的多条业务属性，包括：
    接收到用户所发送的待存储的数据记录时，获取数据记录中的指定字段中所包含的多条业务属性；或者，
    确定账本中的第N个数据块所包含的数据记录，针对所述数据块中所包含的任一数据记录，获取其指定字段中所包含的多条业务属性。
  5. 如权利要求1所述的方法，分别建立各业务属性与该数据记录的对应关系，写入以各业务属性为主键的索引，包括：
    确定所述数据记录在账本中的位置信息，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量；
    针对任一业务属性，建立该业务属性与所述位置信息的对应关系，写入以该业务属性为主键的索引。
  6. 如权利要求5所述的方法，写入以该业务属性为主键的索引，包括：
    确定数据记录的时间戳；
    在以该业务属性为主键的索引记录中，按照时间戳的先后顺序，将数据记录的位置信息依序写入索引记录的值。
  7. 一种基于多条业务属性的数据存储装置，应用于通过块链式账本存储数据的中心化的数据库服务提供端中，所述装置包括：
    接收模块，接收客户端所发送的待存储的数据记录，其中，所述数据记录中包含有多条业务属性和业务数据；
    确定模块，确定数据记录的哈希值，发送所述哈希值至所述客户端；
    数据块生成模块，当达到预设的成块条件时，确定待写入数据块中的各数据记录，生成包含数据块的哈希值和数据记录的第N个数据块；
    索引写入模块，针对所述第N个数据块中的任一数据记录，获取该数据记录的多条业务属性，分别建立各业务属性与该数据记录的对应关系，写入以各业务属性为主键的索引。
  8. 如权利要求7所述的装置，所述数据块生成模块，
    当N＝1时，初始数据块的哈希值和块高基于预设方式给定；
    当N>1时，根据待写入数据块中的各数据记录和第N－1个数据块的哈希值确定第N个数据块的哈希值，生成包含第N个数据块的哈希值和各数据记录的第N个数据块，其中，数据块的块高基于成块时间的先后顺序单调递增。
  9. 如权利要求8所述的装置，所述预设的成块条件包括：待存储的数据记录数量达到数量阈值；或者，距离上一次成块时刻的时间间隔达到时间阈值。
  10. 如权利要求7所述的装置，所述索引写入模块，接收到用户所发送的待存储的数据记录时，获取数据记录中的指定字段中所包含的多条业务属性；或者，确定账本中的第N个数据块所包含的数据记录，针对所述数据块中所包含的任一数据记录，获取其指定字段中所包含的多条业务属性。
  11. 如权利要求7所述的装置，所述索引写入模块，确定所述数据记录在账本中的位置信息，所述位置信息包括数据记录所处的数据块的块高，以及，在所处的数据块中的偏移量；针对任一业务属性，建立该业务属性与所述位置信息的对应关系，写入以该业务属性为主键的索引。
  12. 如权利要求11所述的装置，所述索引写入模块，确定数据记录的时间戳；在以该业务属性为主键的索引记录中，按照时间戳的先后顺序，将数据记录的位置信息依序写入索引记录的值。
  13. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求1至6任一项所述的方法。
PCT/CN2020/097532 2019-09-25 2020-06-22 一种基于多条业务属性的数据存储方法、装置及设备 WO2021057127A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910913898.4A CN110750533A (zh) 2019-09-25 2019-09-25 一种基于多条业务属性的数据存储方法、装置及设备
CN201910913898.4 2019-09-25

Publications (1)

Publication Number Publication Date
WO2021057127A1 true WO2021057127A1 (zh) 2021-04-01

Family

ID=69277120

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/097532 WO2021057127A1 (zh) 2019-09-25 2020-06-22 一种基于多条业务属性的数据存储方法、装置及设备

Country Status (2)

Country Link
CN (1) CN110750533A (zh)
WO (1) WO2021057127A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110750533A (zh) * 2019-09-25 2020-02-04 支付宝(杭州)信息技术有限公司 一种基于多条业务属性的数据存储方法、装置及设备
CN111506580B (zh) * 2020-06-15 2020-12-22 支付宝(杭州)信息技术有限公司 一种基于中心化块链式账本的交易存储方法
CN112364383B (zh) * 2021-01-12 2021-04-27 支付宝(杭州)信息技术有限公司 一种业务记录真实性验证方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101464894A (zh) * 2008-12-30 2009-06-24 北京中创信测科技股份有限公司 数据查询方法和系统
CN109902071A (zh) * 2019-01-31 2019-06-18 阿里巴巴集团控股有限公司 业务日志存储方法、系统、装置及设备
CN109902086A (zh) * 2019-01-31 2019-06-18 阿里巴巴集团控股有限公司 一种索引创建方法、装置及设备
CN110162526A (zh) * 2019-04-18 2019-08-23 阿里巴巴集团控股有限公司 一种块链式账本中数据记录的查询方法、装置及设备
CN110162662A (zh) * 2019-04-18 2019-08-23 阿里巴巴集团控股有限公司 一种块链式账本中数据记录的验证方法、装置及设备
CN110188096A (zh) * 2019-04-18 2019-08-30 阿里巴巴集团控股有限公司 一种数据记录的索引创建方法、装置及设备
CN110750533A (zh) * 2019-09-25 2020-02-04 支付宝(杭州)信息技术有限公司 一种基于多条业务属性的数据存储方法、装置及设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105488068B (zh) * 2014-09-19 2018-11-16 阿里巴巴集团控股有限公司 搜索音乐和建立索引的方法及装置、搜索结果判断方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101464894A (zh) * 2008-12-30 2009-06-24 北京中创信测科技股份有限公司 数据查询方法和系统
CN109902071A (zh) * 2019-01-31 2019-06-18 阿里巴巴集团控股有限公司 业务日志存储方法、系统、装置及设备
CN109902086A (zh) * 2019-01-31 2019-06-18 阿里巴巴集团控股有限公司 一种索引创建方法、装置及设备
CN110162526A (zh) * 2019-04-18 2019-08-23 阿里巴巴集团控股有限公司 一种块链式账本中数据记录的查询方法、装置及设备
CN110162662A (zh) * 2019-04-18 2019-08-23 阿里巴巴集团控股有限公司 一种块链式账本中数据记录的验证方法、装置及设备
CN110188096A (zh) * 2019-04-18 2019-08-30 阿里巴巴集团控股有限公司 一种数据记录的索引创建方法、装置及设备
CN110750533A (zh) * 2019-09-25 2020-02-04 支付宝(杭州)信息技术有限公司 一种基于多条业务属性的数据存储方法、装置及设备

Also Published As

Publication number Publication date
CN110750533A (zh) 2020-02-04

Similar Documents

Publication Publication Date Title
WO2021073242A1 (zh) 索引创建和数据查询方法、装置及设备
WO2020211569A1 (zh) 一种数据记录的索引创建方法
CN110188096B (zh) 一种数据记录的索引创建方法、装置及设备
WO2021017422A1 (zh) 一种块链式账本中的索引创建方法、装置及设备
CN110162526B (zh) 一种块链式账本中数据记录的查询方法、装置及设备
WO2021057127A1 (zh) 一种基于多条业务属性的数据存储方法、装置及设备
WO2020244239A1 (zh) 一种基于业务标识的索引创建方法、装置及设备
CN110162662B (zh) 一种块链式账本中数据记录的验证方法、装置及设备
WO2020253231A1 (zh) 一种基于收据的数据存储方法、装置及设备
WO2021057164A1 (zh) 一种块链式账本中的查询方法、装置及设备
WO2020233146A1 (zh) 数据操作记录的存储方法、系统、装置及设备
WO2021073240A1 (zh) 一种块链式账本中的数据存储方法、装置及设备
WO2021073241A1 (zh) 一种基于磁盘存储的数据读取方法、装置及设备
CN110334094B (zh) 一种基于倒排索引的数据查询方法、系统、装置及设备
WO2020244237A1 (zh) 一种块链式账本中的验证方法、装置及设备
US10795874B2 (en) Creating index in blockchain-type ledger
WO2021093461A1 (zh) 一种块链式账本中的聚合计算方法、装置及设备
US10999062B2 (en) Blockchain-type data storage
US11816099B2 (en) Service identifier-based data indexing
WO2020199713A1 (zh) 数据验证方法、系统、装置及设备
US11126751B2 (en) Index creation for data records
WO2020211493A1 (zh) 一种块链式账本中的数据验证方法、系统、装置及设备
CN110362570B (zh) 一种数据存储方法、装置及设备
CN110636042B (zh) 一种服务端已验证块高的更新方法、装置及设备
CN111444194B (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: 20869669

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: 20869669

Country of ref document: EP

Kind code of ref document: A1