HK1245445B - Data storage and query method and device based on block chain - Google Patents

Description

A method and device for data storage and query based on blockchain

Technical Field

The present application relates to the field of computer technology, and in particular to a method and device for data storage and query based on blockchain.

Background Art

With the continuous development of computer technology, blockchain technology (also known as distributed ledger technology) as a new distributed data storage technology has the characteristics of being tamper-proof, which makes the data stored in the blockchain have the characteristics of notarization and credibility, making the application of blockchain technology more and more extensive.

Specifically, the principle of blockchain data storage can be understood as follows: a user initiates a service request through an Ethereum client (a client that supports blockchain technology, also referred to as a blockchain client). The Ethereum client then sends the service request to the consensus network, where the blockchain nodes in the consensus network reach consensus on the service request. Once the blockchain nodes in the consensus network reach consensus on the service request, they store a data summary of the service request in the blockchain corresponding to each blockchain node. Simultaneously, the Ethereum client can store the service data in the service request in its own corresponding memory according to the data storage format specified in the pre-set smart contract.

However, in order to facilitate subsequent querying of the data stored in the memory, an index is usually established in a set manner, so that the user can use the index to perform a query operation on the business data stored in the memory.

However, in actual applications, once the query conditions used to query business data are different from the established index (that is, the query conditions do not match the index specified by the smart contract), the data query efficiency will be low or the query will fail.

Summary of the Invention

The embodiments of the present application provide a data storage method to solve the problems of low query efficiency or query failure when querying data stored in a blockchain in the prior art.

An embodiment of the present application provides a data storage method, including:

The blockchain node receives the business request;

Parsing each data category and the business data corresponding to each data category from the business request;

The parsed business data is stored in the database corresponding to the blockchain node according to the correspondence between the data category and the business data.

The embodiments of the present application provide a data storage device to solve the problems of low query efficiency or query failure when querying data stored in a blockchain in the prior art.

An embodiment of the present application provides a data storage device, including:

Receiving module, receiving business requests;

A data parsing module, which parses the business request to obtain various data categories and the business data corresponding to each data category;

The storage module stores the parsed business data in the database corresponding to the blockchain node according to the correspondence between the data category and the business data.

The embodiments of the present application provide a data query method to solve the problems of low query efficiency or query failure in the prior art when querying data stored in a blockchain.

An embodiment of the present application provides a data storage method, including:

The blockchain node receives the business data query request;

Determining the data category corresponding to the business data to be queried according to the business data query request;

Business data matching the data category is queried from a database corresponding to the blockchain node, where the database contains a correspondence between the data category and the business data.

The embodiments of the present application provide a data storage device to solve the problems of low query efficiency or query failure when querying data stored in a blockchain in the prior art.

An embodiment of the present application provides a data storage device, including:

Request receiving module, receiving business data query requests;

A category determination module, which determines the data category corresponding to the business data to be queried according to the business data query request;

The data query module queries the business data matching the data category from a database corresponding to the device, wherein the database contains a correspondence between the data category and the business data.

At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

In an embodiment of the present application, after receiving a business request from a user, a blockchain node can parse the business request to identify each data category and the business data corresponding to each data category, and store the parsed business data in the database corresponding to the blockchain node according to the corresponding relationship between the data category and the business data. By parsing the business data, the business data can be stored in the database corresponding to the blockchain node according to the corresponding relationship between the data category and the business data. In this way, when a user queries business data, the query can be implemented based on this corresponding relationship in the database, avoiding the problems existing in index-based queries in existing blockchains, increasing the flexibility of data queries in the blockchain, and effectively improving data query efficiency.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

FIG1 is a schematic diagram of a data storage process provided in an embodiment of the present application;

FIG2 is a schematic diagram of a data table provided in an embodiment of the present application;

FIG3 is a detailed diagram of the data storage process provided by an embodiment of the present application;

FIG4 is a schematic diagram of a data storage device provided in an embodiment of the present application;

FIG5 is a schematic diagram of a data query device provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

FIG1 is a schematic diagram of a data storage process according to an embodiment of the present application, which specifically includes the following steps:

S101: The blockchain node receives a service request.

In actual applications, users can send service requests to blockchain nodes during business processing. The blockchain nodes mentioned here can be terminal devices or servers. For example, when the blockchain node is a server, the user can enter business information on their terminal device and perform a specified operation on the terminal device. The terminal device then sends the business information entered by the user to the server in the form of a business request, and the server can receive the business request in response.

When the blockchain node is a terminal device, the user can fill in business information on the terminal device. When the terminal device confirms that the user has performed a specified operation (such as a click operation, etc.), a corresponding business request can be generated based on the business information, which is equivalent to receiving the business request sent by the user.

Of course, the blockchain nodes mentioned above can also be blockchain clients (referring to clients that can handle related services based on blockchain technology, such as Ethereum clients). Accordingly, when users conduct business processing through the blockchain consensus network, they can start the blockchain client through the terminal device and fill in the business information in the interface displayed by the blockchain client. When the blockchain client detects that the user has performed a specified operation, it can generate a corresponding business request based on the business information filled in by the user, which is equivalent to receiving the business request sent by the user. In addition, the business requests received by the blockchain node can also be sent by other blockchain nodes through broadcasting.

S102: Convert the service request according to a preset data format to obtain a data sequence.

After receiving the above business request, the blockchain node can convert the business request according to the preset data format to obtain the corresponding data sequence.

In this embodiment of the present application, the preset data format includes but is not limited to the following fields:

Identification information field, which is used to distinguish various business data at the user level. For example, the user public key or user identity number (ID) carried in the above business request can uniquely identify the user, so as to facilitate subsequent business data queries based on the user dimension.

The business type field is used to distinguish the business data of various types of users' businesses, so that the user can further query the business data based on the business dimension during the subsequent business data query process.

In addition, the above-mentioned preset data format also stipulates a data field, which is used to indicate the correspondence between each data category and each business data in the business request. For example, suppose a business request contains the following data fields: Name - Xiao Ming, Age - 18, Weight - 130 Jin. In this information, the actual business data is Xiao Ming, 18, 130 Jin, and the name, age, and weight are the data categories of each business data. In other words, in this embodiment of the present application, the data category is equivalent to the key, and the business data is equivalent to the value, and the data field is a key-value data mapping set.

Based on the preset data format described above, after receiving a business request sent by a user, the blockchain node can parse the business request according to the preset data format to obtain the identification information, business category, each data category in the data field, and business data corresponding to each data category, and other data content contained in the business request. Then, the blockchain node can serialize the parsed data in a certain form to obtain a data sequence.

For example, suppose that after receiving a business request from a user, the blockchain node uses a preset data format to parse the business type field from the business request as commodity, the identification information field as PublicKey, and the data field as name: umbrella and cost: 46. The blockchain node serializes these parsed fields in a certain format to obtain the data sequence:

{"PublicKey.schema":"DEFAULT","data":"name:umbrella,cost:46"}.

The purpose of converting the above-mentioned business request into a data sequence according to a preset data format is that, in the embodiment of the present application, the blockchain node needs to write the business request into the blockchain for subsequent verification of the business data. In actual applications, the blockchain node usually needs to write the business request into the blockchain according to a certain data format. To this end, after receiving the business request sent by the user, the blockchain node needs to convert the business request into a data format that can support the business request to be written into the blockchain in the subsequent process, that is, a data sequence. Then, the business request is written into the blockchain in the form of a data sequence to ensure that the business data can be effectively verified based on the business request stored in the blockchain.

It should be noted that in an embodiment of the present application, the blockchain node may also parse the business data corresponding to each data category and each data category from the above-mentioned business request, and then convert the parsed data category and the business data corresponding to each data category according to a preset data format to obtain the above-mentioned data sequence. The blockchain node may also, after parsing each data category and the business data corresponding to each data category, first store the parsed business data in the database corresponding to the blockchain node according to the correspondence between the data category and the business data (i.e., execute step S103), and then convert each data category and the business data corresponding to each data category contained in the above-mentioned business request according to a preset data format to obtain a data sequence.

In other words, in the embodiment of the present application, converting the service request according to a preset data format to obtain a data sequence is not a necessary step.

As for step S102, the specific implementation process involved in converting the business request according to a preset data format to obtain a data sequence does not necessarily mean parsing the business request to obtain each data category and the business data corresponding to each data category, and then converting the parsed data categories and the business data corresponding to each data category according to the preset data format to obtain a data sequence. In addition to the data categories and the business data corresponding to each data category parsed from the business request, the data sequence can also be generated through other fields in the business request. The specific fields required for generation depend on the actual data format required to support the business request being written into the blockchain.

S103: parse the service request to obtain various data categories and service data corresponding to each data category.

In an embodiment of the present application, after receiving the above-mentioned business request, the blockchain node may first send the business request to other blockchain nodes in the consensus network by broadcasting, so that the business request can be reached through consensus by each blockchain node in the consensus network. Once it is determined that the business request has passed the consensus of each blockchain node in the consensus network, each blockchain node can store the business request in its corresponding blockchain.

Not only that, in an embodiment of the present application, after receiving the above-mentioned business request, the blockchain node can parse the business request, parse out the various data types and business data of each data type contained in the business request from the business request, and in the subsequent process, store the parsed business data in the database corresponding to the blockchain node according to the correspondence between each data type and the business data.

Among them, the database mentioned in the embodiment of the present application can be a relational database. This data storage method not only enables fast data search, but also is not affected by query conditions. In other words, even if the index field changes, the business data stored in the database can still adapt to the new index field, and will not affect the user's business data query due to changes in the index field used to query the business data.

In an embodiment of the present application, when a blockchain node stores business data, it can distinguish the stored business data according to business categories or identification information, so as to store business data of different business types or identification information in different databases. This makes it convenient for subsequent users to accurately query business data based on the dimensions of business categories or identification information during the process of business data query.

Based on this, in addition to parsing out the various data categories and the business data corresponding to each data category from the above-mentioned business request, the blockchain node can also parse out the business categories and identification information corresponding to the business data contained in the business request, and then convert the parsed data categories, the business data corresponding to each data category, the business categories and identification information according to the preset statement format to obtain a data storage statement, and in the subsequent process, by executing the data storage statement, the parsed business data is stored in the database corresponding to the blockchain node.

For example, by parsing the above business request, the blockchain node determines that the business data to be stored is shoes#12xew,158, the business type corresponding to the business data to be stored is commodity, the identification information corresponding to the business data to be stored is PublicKey1, and the data categories corresponding to the business data shoes#12xew,158 are name and cost respectively. The blockchain node can convert the parsed business category, identification information, each data category, and the business data corresponding to each data category according to the preset statement format to obtain the corresponding data storage statement, which is in the following form:

insert into "PublicKey1.schema:commodity" (name, cost) value ('shoes#12xew', '158').

The blockchain node can store the business data in the database corresponding to the blockchain node by executing the data storage statement in the subsequent process.

Among them, in the process of parsing the above-mentioned business requests, the blockchain node can do so through a preset parsing program, which specifies the data format and fields to be parsed. The blockchain node parses the above-mentioned business requests by running the parsing program, and the parsing program mentioned here can be compiled by the blockchain node operation and maintenance personnel as needed.

It should be noted that, in addition to storing the aforementioned business data in a database according to business categories and identification information, if the blockchain node corresponds to a single database, different data tables can be set up in the database, with each business type and identification information corresponding to a data table. In this way, the blockchain node can store the aforementioned business data in separate data tables within the database according to business categories and identification information. Of course, in addition to using data tables to distinguish business data according to business categories and identification information, other forms of distinction can also be used in the database, which will not be explained in detail here.

It should be noted that in the embodiment of the present application, the blockchain node may first execute step S103 and then execute step S102; it may also execute step S102 first and then execute step S103; it may also execute step S102 first and then parse each data category and the business data corresponding to each data category from the data sequence obtained in step S102 according to the method shown in the step S103; step S102 and step S103 may also be implemented simultaneously in the embodiment of the present application, and no specific limitation is made here.

S104: The parsed business data is stored in a database corresponding to the blockchain node according to the correspondence between the data category and the business data.

In an embodiment of the present application, after the blockchain node parses the various data categories and the business data corresponding to each data category from the above-mentioned business request, it can store the parsed business data in each data category in the database.

As for business data corresponding to different business types and identification information, the blockchain node can determine the database corresponding to the business category and identification information based on the parsed business category and identification information, and then the blockchain node can store the parsed business data in each data category of the database.

Specifically, after the blockchain node obtains the data storage statement through the above step S103, it can execute the data storage statement to determine the business category and identification information corresponding to the business data to be stored. Then, the blockchain node can further determine whether the blockchain node corresponds to the database corresponding to the business type and identification information. If so, the blockchain node can further store the parsed business data in each data category of the database respectively. If not, the blockchain node needs to construct a database corresponding to the business type and identification information based on the determined business type and identification information, so that the blockchain node can store the business data in the database.

Of course, in the embodiment of the present application, if the blockchain node corresponds to a single database, it can be determined from the database whether it contains a data table corresponding to the above-mentioned business category and identification information. If so, the parsed business data will be stored in each data category of the data table respectively. If not, a data table corresponding to the business category and identification information will be constructed through a preset table construction method, and then the parsed business data will be stored in the data table.

For example, assume that the blockchain node determines, by executing the above data storage statement, that the business type field corresponding to the business data to be stored is commodity, and the user public key PublicKey1 used to represent the identification information (because the actual user public key may be more complex, only PublicKey1 is used here for simple representation). The blockchain node can further determine from its corresponding database whether it contains a data table with identification information PublicKey1 and business type commodity. If it is determined that the data table does not exist, it constructs a data table corresponding to the business type commodity and identification information PublicKey1 in the database based on the determined business type commodity, identification information PublicKey1, and the preset table construction method. The specific execution statement is as follows:

create table "PublicKey1.schema:commodity" if "PublicKey1.schema:commodity" does not exist.

After the blockchain node determines (or constructs) the data table corresponding to the above-mentioned business data from its corresponding database by executing the above-mentioned data storage statement, it can determine whether each data category contained in the business data exists in the data table. If so, it can construct the row or column corresponding to the data category in the data table. If not, it can add the row/column corresponding to the data category in the data table according to the data category and the preset row/column construction method.

Continuing with the above, the data field determined by the blockchain node from the above data sequence is: "name: shoes#12xew, cost: 158", where name and cost are data categories, i.e., relative to the key, and the business data corresponding to name and cost is equivalent to the value. For each data category in the data field, the blockchain node can determine whether the data table determined based on the business type community and identification information PublicKey1 contains the data category. If so, the column corresponding to the data category is not constructed in the database. If not, the column corresponding to the data category can be added to the data table based on the data category and the preset column construction method (if the data table is constructed based on the behavioral dimension, the row construction method can also be used). The specific execution statement is as follows:

create column "name" if "PublicKey1.schema:commodity". "name" not exist;

create column "cost" if "PublicKey1.schema:commodity". "cost" not e xist.

When the blockchain node determines the data category corresponding to the business data to be stored in the database by executing the above-mentioned data storage statement (the data category may already exist in the database or be constructed by the blockchain node after executing the above-mentioned data storage statement), the business data may be stored in the data category of the database. Of course, if it is determined that the data category corresponding to the business data to be stored exists in a data table in the database (i.e., a data table that matches the above-mentioned business category and identification information), the blockchain node may store the parsed business data in the data category of the data table, as shown in Figure 2.

FIG2 is a schematic diagram of a data table provided in an embodiment of the present application.

In Figure 2, name and cost are data categories of business data, PublicKey1 is the identification information corresponding to the business data, and commodity is the business category corresponding to the business data. Business data belonging to the data category is recorded under each data category. In this way, when the user subsequently queries business data, the blockchain node can receive the business data query request sent by the user and further search for business data matching the business data query request from the database. The specific query process can be: after the blockchain node receives the business data query request, it can first determine the business type and identification information contained in the business data query request, and then the blockchain node can determine the data table that matches the business type and identification information from the database, and then search the data table for the business data to be queried in the business data query request based on the correspondence between the data category and the business data recorded in the data table.

For example, assuming that the business data query request received by the blockchain node contains the following fields: PublicKey: PublicKey1, schema: commodity, name: blouse#4212v, the blockchain node can determine that the business type corresponding to the business data query request is commodity, and the identification information is PublicKey1, and then find the data table that matches the business type commodity and identification information PublicKey1 from its corresponding database, and according to the index field blouse#4212v, find the business data corresponding to the index field blouse#4212v in the data table as 211.

Of course, if each business data is distinguished only by data category, then after receiving a business data query request from a user, the blockchain node can determine the data category corresponding to the business data to be queried based on the business data query request, and then search the database corresponding to the blockchain node for business data that matches the data category. Specifically, with respect to the method for determining the data category, after receiving a business data query request from a user, the blockchain node can determine the index field key contained in the business data query request and determine the index field key as the data category corresponding to the business data to be queried.

The above data table not only supports querying business data using the key as the index field, but also supports users to query business data by building their own indexes. For example, in the above example, if the user needs to query business data by price range, the price range can be entered into the blockchain node. The blockchain node can then query the business data that meets the price range from the data table of the above database based on the price range entered by the user, and then return the qualified business data to the user for viewing.

In the prior art, when a blockchain node stores business data, it needs to write the business data into the blockchain according to the data storage format specified by the smart contract. At the same time, the blockchain node usually stores the business data in its own corresponding memory according to this data storage format by default. Therefore, in the process of writing a smart contract, it is usually necessary to specify that the blockchain node stores the business data in its own corresponding memory according to this specified data storage format. Correspondingly, when the user uses the smart contract to query business data through the blockchain node, it is also necessary to query the corresponding business data from the memory corresponding to the blockchain node according to a fixed query method (such as through a fixed index field).

However, in actual applications, the index fields used by users when querying business data are not unique. This means that the index fields used by users when querying business data may not be the index fields specified by the smart contract. Once the user uses an index field that does not conform to the smart contract, the blockchain node cannot query previous business data in the blockchain node through the smart contract.

For example, when a blockchain node stores a service request in its corresponding memory according to the aforementioned preset data storage format via a smart contract, users can subsequently only query service data from the memory using the key as the index field. However, since blockchain nodes typically store each service data item by item in the set data format specified by the smart contract through a smart contract, i.e., they do not store each service data item in a format similar to a data table in a relational database, when a user needs to query service data using the content recorded in the value, the smart contract will not be able to effectively support the query field entered by the user in the blockchain node. This may result in the user being unable to query previous service data from the blockchain node's corresponding memory through the smart contract (because previous service data only supports queries using the key as the index field), or requiring the blockchain node to perform a lengthy traversal according to the query field entered by the user before finding the corresponding service data from the blockchain node's corresponding memory, thereby causing inconvenience to the user.

In the embodiment of the present application, after receiving a business request from a user, a blockchain node can parse the business request to determine the various data categories contained in the business request and the business data corresponding to each data category. The parsed business data is then stored in the database corresponding to the blockchain node according to the corresponding relationship between the data type and the business data. This allows users to query business data based on this corresponding relationship in the database, avoiding the problems of index-based queries in existing blockchains, increasing the flexibility of data queries in the blockchain, and effectively improving data query efficiency.

It should be noted that in the embodiments of the present application, the database may also use only identification information to distinguish the business data between users, without classifying each user by business type. Therefore, in the above process, whether the blockchain node constructs the database, constructs a data table in the database, or determines a data table from the database, it can all be achieved through identification information. Of course, the above database may also distinguish business data only by business type, and the specific method used to distinguish business data depends on business needs.

In order to further illustrate the data storage process provided by the above embodiment, in the embodiment of the present application, the data storage method provided by the present application will be further described according to the specific execution process, as shown in Figure 3.

FIG3 is a detailed data storage process provided by an embodiment of the present application, which specifically includes the following steps:

S301: The blockchain node receives a service request.

A blockchain node can receive business requests sent by users through terminal devices. A blockchain node can be a terminal device, a server, or a client that can handle related businesses based on blockchain technology.

S302: Parse the service request to determine the data categories contained in the service request and the service data corresponding to each data category.

After receiving the above-mentioned business request, the blockchain node can parse the business request to determine the data categories contained in the business request and the business data corresponding to each data category. The blockchain node can parse the business request through a preset parsing program, and the parsing program mentioned here can be set by the blockchain node operation and maintenance personnel according to actual needs.

S303: Convert the parsed data categories and the business data corresponding to each data category according to a preset data format to obtain a data sequence.

After parsing the business request to obtain the various data categories and the business data corresponding to each data category, the blockchain node may convert the parsed data categories and the business data corresponding to each data category according to a preset data format to obtain a data sequence. The specific process of obtaining the data sequence may be: the blockchain node may serialize the parsed data according to a certain format to obtain the corresponding data sequence.

S304: Send the business request to the consensus network for consensus, and when it is determined that the business request passes the consensus, store the data sequence in the blockchain of the blockchain node.

When a blockchain node receives a business request, it can send the business request to the consensus network so that other blockchain nodes in the consensus network can reach a consensus on the business request. After determining that the business request has passed the consensus of other blockchain nodes, the business request can be stored in the form of the above-mentioned data sequence in the blockchain it saves for subsequent use in data verification of the business data.

Among them, in an embodiment of the present application, each time a blockchain node receives a business request, it can send the business request to the consensus network for consensus, or it can first receive each business request sent by each user, and when it is determined that the consensus stage has been reached, the received business requests will be packaged into a pre-processing block, and the pre-processing block will be sent to the consensus network for consensus. Accordingly, after receiving each business request sent by each user, the blockchain node can parse each business request one by one to determine the data category contained in each business request and the business data corresponding to the data category, and then convert the data category contained in each business request and the business data corresponding to the data category according to the preset data format to obtain each data sequence.

Once it is determined that the pre-processed block sent to the consensus network has passed the consensus of other blockchain nodes in the consensus network, the business requests contained in the pre-processed block can be stored in the blockchain contained in itself in the form of data sequences corresponding to each business request.

S305: The parsed business data is stored in the database corresponding to the blockchain node according to the correspondence between the data category and the business data.

While converting the parsed data categories and business data, the blockchain node can also store the parsed business data in the database corresponding to the blockchain node according to the correspondence between the data categories and the business data, to ensure that users can subsequently find the corresponding business data in the database according to the correspondence between the data categories and the business data.

Among them, the blockchain node can execute the above steps S303 and S305 in parallel, that is, in the process of converting the parsed data categories and the business data corresponding to each data category into a data sequence, the blockchain node does not affect the execution of the step of storing the parsed business data in its own corresponding database according to the correspondence between the data category and the business data.

Of course, after determining that the above-mentioned business request has passed the consensus of other blockchain nodes in the consensus network, the blockchain node can also store the parsed business data in its own corresponding database according to the correspondence between data category and business data.

The above is the data storage and query method provided in the embodiment of the present application. Based on the same idea, the embodiment of the present application also provides data storage and query devices, as shown in Figures 4 and 5.

FIG4 is a schematic diagram of a data storage device provided in an embodiment of the present application, specifically comprising:

Receiving module 401, receiving a service request;

The data parsing module 402 parses the business request to obtain various data categories and the business data corresponding to each data category;

The storage module 403 stores the parsed business data in the database corresponding to the blockchain node according to the correspondence between the data category and the business data.

The device further comprises:

The consensus module 404 converts the data categories and the business data corresponding to each data category contained in the business request according to a preset data format to obtain a data sequence; uses a consensus network to reach a consensus on the business request; and after the business request passes the consensus, stores the data sequence in the blockchain of the device.

The data parsing module 402 determines the service type and/or identification information corresponding to the service request;

The storage module 403 converts the parsed data categories, the business data corresponding to each data category, the business type and/or identification information according to a preset statement format to obtain a data storage statement; and stores the parsed business data in the database by executing the data storage statement.

The storage module 403 executes the data storage statement. When it is determined that a database matching the business type and/or identification information has not been found, it constructs a database corresponding to the business type and/or identification information based on the business type and/or identification information; and stores the parsed business data in the constructed database.

The storage module 403 creates each data category parsed from the data sequence in the database when it is determined that the data category is not included in the database; and stores the business data corresponding to the data category in the database.

FIG5 is a schematic diagram of a data query device provided in an embodiment of the present application, specifically comprising:

Request receiving module 501, receiving a business data query request;

Category determination module 502, determining the data category corresponding to the business data to be queried according to the business data query request;

The data query module 503 queries the business data matching the data category from the database corresponding to the device, wherein the database contains the correspondence between the data category and the business data.

In an embodiment of the present application, after receiving a business request from a user, a blockchain node can parse the business request to identify each data category and the business data corresponding to each data category, and store the parsed business data in the database corresponding to the blockchain node according to the corresponding relationship between the data category and the business data. By parsing the business data, the business data can be stored in the database corresponding to the blockchain node according to the corresponding relationship between the data category and the business data. In this way, when a user queries business data, the query can be implemented based on this corresponding relationship in the database, avoiding the problems existing in index-based queries in existing blockchains, increasing the flexibility of data queries in the blockchain, and effectively improving data query efficiency.

In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and/or hardware.

It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present invention is described with reference to the flowcharts and/or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of processes and/or boxes in the flowchart and/or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. 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, compact disc read-only memory (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 that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims (12)

1. A method for data storage, characterized in that it includes: A blockchain node receives a business request, which includes the business type and/or identification information corresponding to the business data. Parse the data categories and the corresponding business data from the business requests. The parsed business data is stored in a database corresponding to the blockchain node and matching the business type and/or identification information, according to the correspondence between data categories and business data. 2. The method as described in claim 1, characterized in that, after parsing the service request, the method further includes: According to the preset data format, the data categories contained in the business request and the business data corresponding to each data category are transformed to obtain a data sequence; The service request is reached into consensus using a consensus network. After the business request passes the consensus, the data sequence is stored in the blockchain of the blockchain node. 3. The method as described in claim 1, characterized in that, upon receiving a service request, the method further includes: Determine the service type and/or identification information corresponding to the service request; The parsed business data is stored in the database corresponding to the blockchain node, specifically including: According to the preset statement format, the parsed data categories, the corresponding business data, business types and/or identification information are converted to obtain the data storage statement; By executing the data storage statement, the parsed business data is stored in the database. 4. The method as described in claim 3, characterized in that, by executing the data storage statement, the parsed business data is stored in the database, specifically including: By executing the data storage statement, when it is determined that no database matching the business type and/or identification information has been found, a database corresponding to the business type and/or identification information is constructed based on the business type and/or identification information. The parsed business data is stored in the constructed database. 5. The method as described in claim 1 or 4, characterized in that storing the parsed business data in a database specifically includes: For each data category parsed from the data sequence, if it is determined that the data category does not exist in the database, the data category is created in the database; The business data corresponding to this data category is stored in the database. 6. A method for data querying, characterized in that it includes: A blockchain node receives a business data query request, which includes the business type and/or identification information corresponding to the business data to be queried. Based on the business data query request, determine the data category corresponding to the business data to be queried; From the database corresponding to the blockchain node and matching the business type and/or identification information, query the business data that matches the data category. The database contains the correspondence between data categories and business data. 7. A data storage device, characterized in that it comprises: The receiving module receives a service request, wherein the service request contains the service type and/or identification information corresponding to the service data; The data parsing module parses out each data category and the corresponding business data from the business request; The storage module stores the parsed business data in a database corresponding to the blockchain node and matching the business type and/or identification information, according to the correspondence between data categories and business data. 8. The apparatus of claim 7, wherein the apparatus further comprises: The consensus module transforms the data categories and corresponding business data contained in the business request according to a preset data format to obtain a data sequence; it uses a consensus network to reach a consensus on the business request; and after the business request passes the consensus, it stores the data sequence in the blockchain of the device. 9. The apparatus as described in claim 7, wherein the data parsing module determines the service type and/or identification information corresponding to the service request; The storage module converts the parsed data categories, corresponding business data, business types, and/or identification information according to a preset statement format to obtain a data storage statement; by executing the data storage statement, the parsed business data is stored in the database. 10. The apparatus of claim 9, wherein the storage module, by executing the data storage statement, when it is determined that no database matching the service type and/or identification information has been found, constructs a database corresponding to the service type and/or identification information based on the service type and/or identification information; and stores the parsed service data in the constructed database. 11. The apparatus of claim 7 or 10, wherein the storage module, for each data category parsed from the data sequence, when it is determined that the database does not contain the data category, creates the data category in the database; and stores the business data corresponding to the data category in the database. 12. A data query apparatus, characterized in that it comprises: The request receiving module receives a business data query request, which includes the business type and/or identification information corresponding to the business data to be queried. The category determination module determines the data category corresponding to the business data to be queried based on the business data query request. The data query module queries business data that matches the data category from a database corresponding to the device and matching the business type and/or identification information. The database contains the correspondence between data categories and business data.