Column-based storage method, device, computer program product, and storage medium

Abstract

Embodiments of the present disclosure provide a column-based storage method, a device, a computer program product, and a storage medium. Batch streams and incremental streams can be pulled in parallel while normal on-line service provision with row-based storage is maintained. A column-based storage file and a first primary key index can be generated by pulling batch streams; by synchronizing data operations occurring on a target data table detected during the pulling to pull incremental streams, an incremental file and a second primary key index can be generated, so that it can be ensured that column-based storage can keep consistency with row-based storage in terms of incremental processing; further, a primary key to be deleted is recorded for the first primary key index on the basis of the data operations detected during the pulling; and in response to the ending of the pulling, the first primary key index and the second primary key index are combined into a target primary key index, and the target primary key index and the column-based storage file are corrected on the basis of the primary key to be deleted, so that it can be ensured that column-based storage can also achieve consistency with row-based storage in terms of batch processing.

Description

[0001] A Column-Oriented Storage Method, Device, Computer Program Product, and Storage Medium. This disclosure claims priority to Chinese patent application number 202410232858.4, filed with the China Patent Office on February 29, 2024, the entire contents of which are incorporated herein by reference. Technical Field: This disclosure relates to the field of database technology, and more particularly to a column-oriented storage method, device, computer program product, and storage medium. Currently, row-oriented storage is the most common method of data storage in databases. However, column-oriented storage offers advantages in data analysis and query scenarios. This is because column-oriented storage organizes data by column dimension, effectively reducing the number of reads and writes to the storage medium during data analysis and query, thereby improving performance. To this end, an increasing number of database products support the transition from row-oriented to column-oriented storage. However, existing conversion solutions typically require blocking online services for row-based storage. The conversion must be completed in this blocked state before online services can be resumed. This results in database products being unable to provide online services based on row-based storage for a period of time. Furthermore, the more existing data in row-based storage, the greater the time cost, which creates numerous inconveniences for users. SUMMARY Various aspects of the present disclosure provide a column-based storage method, device, computer program product, and storage medium for implementing column-based storage without affecting the provision of online services based on row-based storage. Embodiments of the present disclosure provide a columnar storage method, comprising: in response to a columnar storage trigger event, sequentially pulling data rows from a target data table for columnar storage, thereby generating a columnar storage file and its corresponding first primary key index; synchronizing data operations detected on the target data table during the pull process, thereby generating an incremental file for storing incremental data rows and its corresponding second primary key index; recording a primary key to be deleted for the first primary key index based on the data operations detected during the pull process; and, in response to the completion of the pull process, merging the first primary key index and the second primary key index into a target primary key index, and modifying the target primary key index and the columnar storage file based on the primary key to be deleted. Embodiments of the present disclosure also provide an electronic device, comprising a memory, a processor, and a communication component; the memory being configured to store one or more computer instructions; and the processor being coupled to the memory and the communication component for executing the one or more computer instructions to perform the aforementioned columnar storage method. An embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program. When the computer program is executed by one or more processors, the one or more processors are caused to execute the aforementioned column storage method.Embodiments of the present disclosure also provide a computer program product, including a computer program. When executed by one or more processors, the computer program causes the one or more processors to perform the aforementioned columnar storage method. In this embodiment of the present disclosure, while maintaining the normal provision of online services using row-based storage, data rows can be sequentially pulled from a target data table in response to a trigger event for columnar storage, generating a columnar storage file and populating the columnar storage file with a first primary key index based on the actually pulled data rows. Data operations monitored on the target data table during the pull process can also be synchronized to generate an incremental file for incremental data rows and their corresponding second primary key index. This ensures that columnar storage maintains consistency with row-based storage in terms of increments. Furthermore, based on the data operations monitored during the pull, the primary key to be deleted can be recorded for the first primary key index. In response to the completion of the pull, the first and second primary key indexes are merged into a target primary key index, and the target primary key index and column storage file are modified based on the primary key to be deleted. In this way, the data operations on the inventory that occurred during the pull can be replicated on the target primary key index and column storage file using the recorded primary key to be deleted, ensuring that column-based storage can also achieve consistency with row-based storage on the inventory side. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part of this disclosure. The illustrative embodiments of this disclosure and their description are provided to explain the disclosure and are not intended to unduly limit the disclosure. In the accompanying drawings: Figure 1 is a flowchart of a column-based storage method provided by an exemplary embodiment of the present disclosure; Figure 2 is a logical diagram of a column-based storage method provided by an exemplary embodiment of the present disclosure; Figure 3 is an architectural diagram of an exemplary database system provided by an exemplary embodiment of the present disclosure; Figure 4 is a schematic diagram of the internal storage structure of a column-based file provided by an exemplary embodiment of the present disclosure; Figure 5 is a schematic diagram of an exemplary processing scheme for modifying a column-based file provided by the present disclosure; and Figure 6 is a schematic diagram of the structure of an electronic device provided by another exemplary embodiment of the present disclosure. DETAILED DESCRIPTION To further clarify the objectives, technical solutions, and advantages of the present disclosure, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure. Before describing in detail the technical solutions provided by the various embodiments of the present disclosure, several technical concepts involved in the present disclosure are briefly explained below. Row-based storage stores data in rows, with an entire row of data being considered as a storage unit.Column-based storage stores data in columns. During the conversion from row-based storage to column-based storage, a group of data rows can be stored as a column-based file, where data is stored in columns. In other words, a column of data can be used as a storage unit (called a column segment) in a column-based file. A primary key, also known as a primary key, is one or more fields in a data table whose value uniquely identifies a record in the table (or, more accurately, a row in the table). As described in the background section, the current conversion from row-based storage to column-based storage requires suspending the online services of the row-based storage to ensure data consistency between the two storage types. However, this conversion solution, which requires suspending online services, introduces numerous inconveniences for users. Therefore, embodiments of the present disclosure propose a column-based storage solution that ensures data consistency between the two storage types without impacting the online services provided by the row-based storage. Data consistency can be understood as ensuring that the data state of column-based storage is consistent with the data state of row-based storage. It should be understood that column-based storage typically lags behind row-based storage. Therefore, the goal of the embodiments of the present disclosure is to ensure that the data state obtained after the column-based storage solution is executed is consistent with the data state of the row-based storage at a certain historical moment. The following, combined with the accompanying drawings, details the technical solutions provided by various embodiments of the present disclosure. Figure 1 is a flow chart of a column-based storage method provided by an exemplary embodiment of the present disclosure, and Figure 2 is a logical diagram of a column-based storage method provided by an exemplary embodiment of the present disclosure. This method can be executed by a data processing device, which can be implemented as software, hardware, or a combination of software and hardware. The data processing device can be integrated into an electronic device. Referring to Figure 1 , the method may include: Step 100: In response to a columnar storage trigger event, sequentially pull data rows from a target data table for columnar storage, generating a columnar storage file and its corresponding first primary key index; Step 101: Synchronize data operations detected on the target data table during the pull process, generating an incremental file for storing incremental data rows and its corresponding second primary key index; Step 102: Based on the data operations detected during the pull process, record the primary key to be deleted for the first primary key index; Step 103: In response to the completion of the pull process, merge the first primary key index and the second primary key index into a target primary key index, and modify the target primary key index and the columnar storage file based on the primary key to be deleted. The columnar storage method provided in this embodiment is applicable to databases of various architectures. Figure 3 is a schematic diagram of the architecture of an exemplary database system provided in an exemplary embodiment of the present disclosure.Referring to FIG3 , the column-based storage method provided in this embodiment is applicable to a distributed database system. The distributed database system may include one or more compute nodes and one or more data nodes. The data nodes are used to store data tables, while the compute nodes are used to process various transactions targeting the data tables, such as various data operations in online transaction processing (OLTP) scenarios and various query and analysis operations in online analytical processing (OLAP) scenarios. In this exemplary database system, the column-based storage method provided in this embodiment can convert data tables stored in row format on the data nodes into data tables stored in column format. It is worth noting that this embodiment does not interfere with or delete the row-based data tables. Instead, it generates a column-based copy of the row-based data tables. In actual applications, various data operations still occur on data tables stored in row format, while the data tables stored in column format generated in this embodiment can be used to support the aforementioned OLAP scenarios, improving query and analysis performance. That is, this embodiment supports the coexistence of row-based and column-based storage, and can also ensure data consistency between column-based and row-based storage. This embodiment does not limit the execution entity of the column-based storage method. In some possible technical concepts, independent electronic devices can be added to the database system to serve as the execution entity of this embodiment. For example, in the distributed database system shown in Figure 3, independent nodes can be added to implement the column-based storage method. In other possible technical concepts, existing nodes in the database system can also serve as the execution entity of this embodiment. For example, in the distributed database system shown in Figure 3, the data processing device provided in this embodiment can be distributed and installed on each data node to implement the column-based storage method. In this way, the data nodes can perform column-based storage on their own row-based data tables. Furthermore, this embodiment does not limit the data table type used for row-based storage. This embodiment supports column-based storage of various types of data tables, including ordinary tables, partitioned tables, and bucketed tables. For ease of presentation, this embodiment uses a target data table stored in row format as an example to illustrate the technical solution. It should be understood that the target data table can be any common table, any partition in a partitioned table, or any bucket in a bucketed table. The specifications of the target data table are compatible with the data table type in row format.Referring to Figure 1 , in step 100, in response to a columnar storage trigger event, data rows can be sequentially pulled from the target data table for columnar storage, generating a columnar storage file and its corresponding first primary key index. As mentioned above, row-based storage in this embodiment can normally provide online services. That is, after a columnar storage trigger event occurs, data operations can normally occur on the target data table and these data operations will also be normally effective on the target data table. The columnar storage trigger event can be, for example, receiving a columnar storage startup instruction or a log node in the database system starting to push operation logs. The log node mentioned here can be used to record all data operations occurring on the row-based storage data table in the form of events. The operation log generated by the log node can be a binary file (binlog). During research, the inventors discovered that data operations occurring on the target data table typically include insert operations, delete operations, and update operations: an insert operation (insert) is used to insert one or more data rows into the target data table. A delete operation (delete) is used to delete one or more data rows from the target data table. An update operation (update) is used to update one or more rows in the target data table. It's worth noting that an update operation can be broken down into a delete operation followed by an insert operation. That is, an update operation can be understood as first deleting rows from the target data table and then inserting them. As can be seen, data operations will result in increments or deletions of rows in the target data table. In practical applications, the target data table typically contains a large number of rows. Therefore, the pull process in step 100 takes a considerable amount of time to complete, which may result in data operations occurring on the target data table during the pull process. In other words, the target data table is dynamically changing during the pull process. To address this, this embodiment proposes that, in step 100, after column storage is enabled, data is pulled sequentially from the target data table. This pull solution does not need to consider changes in the target data table; instead, it performs the pull process step by step based on the actual data state in the target data table. In practical applications, a paginated query can be performed on the target data table, pulling one page at a time. A single page can contain multiple data rows. In step 100, after the data rows are pulled, columnar storage can be performed to generate a column-based file. Thus, in step 100, as the pull operation proceeds, multiple column-based files will be gradually generated for the target data table. Optionally, the column-based files in this embodiment can use a format such as ORC, which is not limited here.For example, in step 100, after column storage is started, the first page can be pulled from the target data table, corresponding to the 1st to 10,000th data rows. After pulling the page, the data rows therein can be column-stored to obtain column storage file 1. After pulling the previous page, the second page can be pulled, corresponding to the 10,001st to 20,000th data rows. Similarly, after pulling the second page, column storage file 2 can be obtained. OThis sequential pulling process will gradually generate multiple column-based files for the target data table. Furthermore, in step 100, after the pulled data rows are stored in columnar format, corresponding primary key index entries can be constructed for the data rows to populate the first primary key index. In this embodiment, the primary key index records the mapping between primary keys and data locations, with each mapping recorded as a primary key index entry. Furthermore, this embodiment proposes two primary key indexes. The first primary key index is described here, and the second primary key index will be discussed later. In this embodiment, the first primary key index records the primary keys of the data rows pulled in step 100 and their data locations in the column-based files. Following the previous description of the multiple column-based files generated for the target data table, an exemplary data location representation structure can be [column-based file identifier, data location in file]. Figure 4 is a schematic diagram of the internal storage structure of a column-based file provided in an exemplary embodiment of the present disclosure. Referring to Figure 4 , the column-based file contains multiple column segments. A data location in the column-based file can point to all elements belonging to the same data row in each column segment (the multiple black squares in Figure 4 ). For example, for a data row with the primary key "name," if it is stored at data location pos1 in the column-based file (labeled "fiie1") in Figure 4 , the primary key index entry for this data row in the first primary key index can be recorded as: "name —> [fiie1, pos1]. During research, the inventors discovered that with the pull scheme proposed in this embodiment, at the end of the pull, the column-based data rows are redundant compared to the target data table. This is because, during the pull process, an insert operation on the target data table may occur before the corresponding data row is pulled. In this case, the inserted data row will be pulled in step 100. Furthermore, during the pull process, a delete operation on the target data table may occur after the corresponding data row is pulled. In this case, the data row will be pulled in step 100, but it will have already been deleted from the target data table. Accordingly, the first primary key index generated at the end of the pull process will be redundant with that of the target data table. To address this redundancy issue, this embodiment proposes not processing the index during the pull process, but instead performing a correction after the pull process is complete.As mentioned above, the column-based storage method provided in this embodiment aims to ensure data consistency between column-based and row-based storage. However, the column-based storage files and first primary key indexes generated during the pull process in step 100 do not yet meet data consistency requirements. Therefore, the column-based storage files and first primary key indexes generated during the pull process will not be delivered for use. Instead, they will be stored as background processing results and delivered for use at a later appropriate time. Deliverable here means allowing them to serve as the data foundation for query and analysis operations in the aforementioned OLAP scenario. With reference to Figure 2 , this embodiment proposes using an independent thread / process to perform the pull operation in step 100. For ease of explanation, this thread / process is described in Figure 2 and the following text as an inventory processing module. Referring to Figure 2 , the inventory processing module can be independently executed to gradually generate the column-based storage files and first primary key indexes corresponding to the target data table. Continuing with Figure 1 , in step 101, data operations monitored on the target data table during the pull process can be synchronized to generate incremental files and their corresponding second primary key indexes for storing incremental data rows. As mentioned above, this embodiment does not affect the online services provided by row-based storage. However, this embodiment proposes that, after the column-based storage is enabled, data operations occurring on the target data table during the pull process will be monitored. In practical applications, the operation logs provided by the aforementioned log node can be subscribed to. Based on this, after the column-based storage is enabled, the log node can proactively push operation logs generated on the target data table to the execution entity of this embodiment. In this way, this embodiment can timely and comprehensively monitor data operations occurring on the target data table during the pull process. It should be understood that these data operations are the cause of data consistency issues between the column-based storage and row-based storage. Referring to Figure 2, this embodiment proposes using an independent thread / process to monitor and process these data operations. For ease of explanation, this thread / process is described in Figure 2 and below as an incremental processing module. It is understood that, with reference to Figure 2, this embodiment proposes independent incremental processing modules and inventory processing modules. Furthermore, with reference to Figure 2, the period from the activation of the column-based storage to the end of the pull process is described as the first stage. In the first phase, the incremental processing module and the inventory processing module can execute in parallel without interfering with each other. The following describes the processing logic of the incremental processing module in the first phase. Referring to Figures 1 and 2, in step 101, the incremental processing module can synchronize data operations on the target data table monitored during the pull process. Synchronization here can be understood as replicating data operations occurring on the row-based storage side on the column-based storage side.During their research, the inventors discovered that data operations occurring on the target data table could target any data row in the target data table. However, in the first phase, the stock processing module had not yet completed pulling data rows. Therefore, the incremental processing module lacked a global perspective on the target data table. This resulted in some data operations on the target data table monitored during the pull process being unable to be directly replicated on the column-based storage side. To address this, this embodiment proposes dividing monitored data operations into two categories: incremental and non-incremental. Incremental data operations can include those that cause incremental data rows to appear in the target data table during the pull process, as well as data operations performed on incremental data rows. Incremental data rows here refer to data rows inserted into the target data table during the pull process. Non-incremental data operations can include those that target existing data rows in the target data table that existed when the column-based storage was enabled. Based on this, in step 101, when synchronizing detected incremental data operations, newly generated incremental data rows can be stored in incremental files. This allows the incremental processing module to generate incremental files containing all incremental data rows that appeared in the target data table during the pull process. This provides the incremental processing module with a global view of the incremental data rows, enabling seamless replication of data operations targeting incremental data rows in the incremental files. In step 101, a second primary key index is proposed to record the mapping between the primary key and data location of incremental data rows. This second primary key index enables accurate retrieval of data locations within the incremental files for incremental data operations, thereby enabling replication of such data operations in the incremental files. It will be appreciated that the data locations recorded for incremental data rows in the second primary key index are located within the incremental files proposed in this embodiment. Recall that the data locations recorded for data rows pulled from the target data table in the first primary key index are located within the column-stored files proposed in this embodiment. That is, in this embodiment, data rows on the column-based storage side are stored in both incremental files and column-based files. In step 101, when synchronizing detected non-incremental data operations, since the operation objects cannot be found in the incremental files or the second primary key index, these data operations cannot be directly replicated in the incremental files. In step 101, synchronization of these data operations can be considered a failure.However, during research, the inventors discovered that the impact of such data operations on the data state of the target data table primarily involves the deletion of data rows. This is because the insertion of data rows in the target data table (i.e., incremental data rows) has already been accurately replicated in step 101 using the incremental file and the second primary key index. Therefore, if other methods can be used to ensure accurate replication of the deletion of data rows in the target data table, the synchronization failure of such data operations in step 101 will not affect the data consistency between the column-based storage and row-based storage. To this end, referring to Figures 1 and 2, this embodiment proposes that, in step 102, the primary keys to be deleted can be recorded for the first primary key index based on the data operations monitored during the pull. Preferably, to ensure that subsequent data row deletions in the target data table during the pull can be fully replicated on the column-based storage side (specifically, the column-based file and the first primary key index obtained at the end of the pull), the primary keys targeted by the delete or update operations on the target data table monitored during the pull can be recorded as the primary keys to be deleted in the first primary key index. During research, the inventors discovered that this comprehensive deletion recording approach may result in some primary keys being generated for deletion that are not included in the first primary key index. (For example, if an incremental data row is not pulled, its primary key will not be included in the first primary key index. However, if the incremental data row is detected to have been deleted, it will still be recorded as the primary key for deletion.) While this may result in some invalid deletions, it effectively ensures accurate and comprehensive replication of data row deletions on the target data table during the pull process, avoiding missed deletions on the column-based storage side. Referring to Figure 2, in the first phase, through the coordination between steps 100 and 102, the data states between the column-based storage and the row-based storage are consistent at the end of the first phase. At this point, the data state of the column-based storage is represented by the processing results of the column-based storage file and its corresponding first primary key index, the incremental file and its corresponding primary key index, and the primary key for deletion recorded for the first primary key index. However, it should be understood that at the end of the first phase, the data state represented by these processing results is consistent with the data state of row-based storage. Based on this, with reference to Figures 1 and 2, this embodiment will proceed to the second phase. The second phase can be understood as the period from the completion of the pull to the delivery for use. During the second phase, the incremental processing module and the inventory processing module can continue to execute in parallel without interfering with each other.Referring to Figure 1 , step 103 corresponds to the second stage. In step 103, upon completion of the pull, the first and second primary key indexes can be merged into a target primary key index, and the target primary key index and column-based file can be modified based on the primary key to be deleted. Referring to Figure 2 , the incremental processing module can be responsible for performing both the operations of merging the first and second primary key indexes into the target primary key index and modifying the target primary key index based on the primary key to be deleted. The inventory processing module can be responsible for marking the column-based file for deletion based on the primary key to be deleted. To this end, in step 103, upon completion of the pull, the inventory processing module can provide the generated first primary key index to the incremental processing module. Upon completion of the pull, the incremental processing module can merge its generated second primary key index with the first primary key index provided by the inventory processing module into the target primary key index. In practical applications, this merge does not require memory copying or movement; instead, the two primary key indexes can be maintained uniformly through a list. The incremental processing module can also modify the target primary key index based on the primary key to be deleted, recorded for the first primary key index in step 101. This modification can at least include deleting the primary key index entry corresponding to the primary key to be deleted from the target primary key index. Referring to Figure 2 , the modified target primary key index can be delivered as one of the results after the second phase. Continuing with Figure 2 , in step 103, the incremental processing module can provide the primary key to be deleted, recorded for the first primary key index in step 101, to the inventory processing module, thereby triggering the inventory processing module to modify the column-based file based on the primary key to be deleted. In this embodiment, considering that data in the column-based file is stored by column, directly deleting data in the column-based file is relatively costly. Therefore, the modification can preferably be to mark the column-based file for deletion. An exemplary deletion marking solution can include constructing a deletion bitmap for the column-based file. The deletion bitmap can be used to mark the data location corresponding to the data row to be deleted in the column-based file as deleted. In this way, correctly maintaining a deletion bitmap for the column-stored file can indicate the deletion status of the data rows in the column-stored file without deleting the actual data in the column-stored file. Accordingly, in step 103, the inventory processing module can mark each column-stored file for deletion based on the primary key to be deleted. Referring to Figure 2, the corrected column-stored file can be included as one of the deliverables after the second phase.It's also worth noting that during the second phase, the incremental processing module continues to synchronize data operations on the monitored target data table. Specifically, during the second phase, both the incremental file and the second primary key index portion of the target primary key index dynamically change in sync with the data operations. This ensures that incremental data operations on the target data table can be continuously replicated on the column-based storage side. In this embodiment, a deletion bitmap can also be maintained for the incremental file. This allows deletion of incremental data rows during data synchronization by marking them for deletion, without deleting the actual data in the incremental file. Referring to Figure 2, the incremental file obtained at the end of the second phase can also serve as one of the delivery results. Therefore, referring to Figure 2, at the end of the second phase, the data state between the column-based storage and the row-based storage remains consistent. At this point, the data state of the column-based storage is collectively represented by the following delivery results: the revised target primary key index (which includes both the first and second primary key indexes), the revised column-based storage file (including the deletion bitmap maintained for it), and the incremental file obtained at the end of the second phase (including the deletion bitmap maintained for it). However, it should be understood that at the end of the second phase, the data state collectively represented by these delivery results is consistent with the data state of the row-based storage. After the second phase, the aforementioned delivery results of the column-based storage in this embodiment are available for delivery and use. The column-stored files and incremental files can serve as the data foundation for query and analysis operations in the aforementioned OLAP scenarios. In practical applications, to support the aforementioned OLAP scenarios, a column-stored index (CSI) can be generated based on the column-stored files and incremental files. The target primary key index provided in this embodiment can be used to synchronize data operations on the row-based storage side with the column-stored files and incremental files, thereby maintaining data consistency between the column-based and row-based storage systems after commissioning. Specifically, after the second phase, the incremental processing module can continue to monitor data operations occurring on the target data table. If a data operation requiring the insertion of a data row is detected, the inserted data row can be stored in the incremental file and a corresponding primary key index entry can be added to the second primary key index included in the target primary key index. If a data operation requiring the deletion of a data row is detected, the corresponding primary key index entry can be deleted from the target primary key index and the file containing the deleted data row (which may be an incremental file or a column-stored file) can be marked for deletion.In summary, in this embodiment, while maintaining the normal provision of online services using row-based storage, data rows can be sequentially pulled from the target data table for column-based storage in response to a trigger event, generating a column-based storage file and populating the column-based storage file with a first primary key index based on the actually pulled data rows. Data operations monitored on the target data table during the pull process can also be synchronized to generate an incremental file for the incremental data rows and its corresponding second primary key index. This ensures that the column-based storage maintains consistency with the row-based storage in terms of increments. Furthermore, based on the data operations monitored during the pull process, the primary key to be deleted can be recorded for the first primary key index. Upon completion of the pull process, the first and second primary key indexes are merged into a target primary key index, and the target primary key index and column-based storage file are modified based on the primary key to be deleted. In this way, the data operations on the inventory that occurred during the pull process can be replicated on the target primary key index and column-based storage file using the recorded primary key to be deleted, ensuring that the column-based storage maintains consistency with the row-based storage in terms of inventory. In the above or following embodiments, in the first phase, the following processing scheme can be employed to ensure the accuracy of the incremental file: If a data operation requiring the insertion of a data row is detected on the target data table during the pull process, the inserted data row is stored as an incremental data row in the incremental file; based on data operations requiring the deletion of incremental data rows detected during the pull process, the incremental file is marked for deletion. Data operations requiring the insertion of data rows may include the aforementioned insert and update operations. Furthermore, in practical applications, the incremental file may be formatted in a CSV format. When a new incremental data row appears, an append write operation can be performed at the end of the incremental file to store the incremental data row in the incremental file. Data operations requiring the deletion of incremental data rows may include the aforementioned delete and update operations. As mentioned above, in this embodiment, actual data in the incremental file is not deleted. Instead, data operations requiring the deletion of incremental data rows are replicated in the incremental file through a marking-for-deletion approach. For delete operations (delete) and update operations (update), the implementation scheme for marking deletion of incremental files during the pull period can be: if a delete operation for an incremental data row is detected on the target data table during the pull period, the data position corresponding to the desired deleted data row in the incremental file is marked as deleted; if an update operation for an incremental data row is detected on the target data table during the pull period, the data position corresponding to the data row deleted due to the update operation in the incremental file is marked as deleted.As mentioned earlier, an update operation can be understood as deleting a row before inserting it. When an update operation targeting an incremental row is detected, two actions can be taken: First, the data locations corresponding to the rows deleted by the update operation can be marked as deleted in the incremental file; second, the rows inserted by the update operation can be stored in the incremental file. This will mark the data locations corresponding to the incremental rows to be deleted as deleted in the delete bitmap maintained for the incremental file. As mentioned earlier, during the first phase, the secondary primary key index maintained for the incremental file must also be dynamically updated to synchronize data operations. For various data operations, the following processing scheme can be used to ensure the correctness of the second primary key index: If an insert operation is detected in the target data table during the pull process, a primary key index entry corresponding to the inserted incremental data row is added to the second primary key index. If a delete operation is detected in the target data table during the pull process for an incremental data row, the primary key index entry corresponding to the deleted data row is deleted from the second primary key index. If an update operation is detected in the target data table during the pull process for an incremental data row, the data location pointed to by the primary key index entry corresponding to the updated data row in the second primary key index is updated to the data location corresponding to the data row inserted by the update operation in the incremental file. It will be understood that in the aforementioned processing scheme for incremental files, after the incremental data row is stored in the incremental file, its data location in the incremental file and the primary key corresponding to the incremental data row can be determined, thereby constructing a primary key index entry for the incremental data row and populating it into the second primary key index. Furthermore, as mentioned above, an update operation can be understood as deleting a data row before inserting it. This causes the updated data row's data position in the incremental file to change, but the row's primary key remains unchanged. In this case, the data position mapped to the updated data row's primary key in the second primary key index is simply updated. In summary, this embodiment provides a processing solution for the incremental file and the second primary key index for various incremental data operations monitored in the first phase, thereby effectively ensuring the correctness of the incremental file and the second primary key index. It should be understood that the processing solution provided in this embodiment is also applicable to various incremental data operations monitored in the second phase, ensuring the correctness of the incremental file and the second primary key index in the second phase. This will not be repeated here.In the above or following embodiments, the following processing scheme can be employed in the second phase to ensure correct modification of the target primary key index: The primary key index entries corresponding to the primary keys to be deleted are deleted from the first primary key index portion of the target primary key index. This ensures that, during the second phase, the primary keys in the target primary key index are consistent with the primary keys actually present in the target data table. During research, the inventors discovered that the primary keys corresponding to some incremental data rows may appear repeatedly in both the first and second primary key index portions of the target primary key index. This is because, in the first phase, some incremental data rows in the target data table are pulled and stored in parallel in the columnar file. The primary keys corresponding to these incremental data rows appear in the first primary key index portion, and as mentioned in the first phase, these incremental data rows also appear in the second primary key index portion. If these incremental data rows are not deleted in the first phase, duplicate primary keys will appear in the first and second primary key index parts of the target primary key index. However, the data locations mapped to these duplicate primary keys in the first and second primary key index parts are different. This is because the incremental data rows corresponding to these duplicate primary keys are stored in both the incremental file and the column storage file. It is worth noting that these duplicate primary keys do not affect the correctness of column storage, but they do occupy excess memory space. To this end, this embodiment further proposes that in the second phase, the primary key index entries corresponding to the duplicate primary keys in the second primary key index part, which should be included in the first primary key index part of the target primary key, can be deleted. Thus, the modification of the target primary key index in the second phase involves two aspects:

[0002] 1. Delete the primary key index item corresponding to the primary key to be deleted from the first primary key index part.

[0003] 2. From the first primary key index portion, delete the primary key index entries corresponding to the duplicate primary keys in the second primary key index portion. These two modifications ensure that, at the end of the second phase, the target primary key index is consistent with the primary key in the target data table. Furthermore, during the second phase, at least two exemplary processing schemes can be employed to ensure the correct modification of the column-stored file. In the first exemplary processing scheme, if the primary key corresponding to any data row in the column-stored file is found to be the primary key to be deleted, the data location corresponding to the data row in the column-stored file is marked as deleted, thereby marking the column-stored file for deletion. In practical applications, each data location in the column-stored file can be traversed to determine which data locations need to be marked as deleted. It should be understood that each data location in the column-stored file stores a data row and records the primary key corresponding to the data row. Therefore, during the traversal process, it is possible to determine whether the primary key recorded at the traversed data location can be found in the primary key to be deleted. If so, the traversed data location is marked as deleted. It's also worth noting that after completing the repair of the target primary key index in the second phase, the incremental processing module obtains a global view consistent with the actual data state of the target data table. Subsequently, based on the target primary key index, the incremental processing module can seamlessly synchronize detected data operations on the target data table to the incremental file or column-level file. The deletion of column-level files due to synchronization of data operations and the deletion of column-level files due to the primary key to be deleted can proceed in parallel, without interfering with each other and causing no conflicts. In a second exemplary processing scheme, if a query finds that the primary key corresponding to any data row in the column-level file is not the primary key to be deleted, the data row is rewritten to a new file. If a data operation is detected on the target data table during the rewriting of the column-level file, in response to the completion of the column-level file rewriting, the generated new file is marked for deletion based on the detected data operation. Figure 5 is a schematic diagram of an exemplary processing scheme for modifying column-level files provided by the present disclosure. Referring to Figure 5, the second exemplary processing scheme is illustrated. During their research, the inventors discovered that some column-based files contain many rows of data that need to be deleted. These rows are actually useless data for column-based storage, but they occupy a large amount of storage space. Therefore, in a second exemplary processing solution, it is proposed to rewrite the rows of data that need to be retained in the column-based files to generate new files. In this way, multiple column-based files can be merged into a new file, freeing up a large amount of storage space.In this case, a traversal approach can still be used to determine which data rows at which data locations in the column-stored file need to be deleted and which data rows at which data locations need to be retained. During their research, the inventors also discovered that rewriting operations can be time-consuming, and therefore, data operations may occur on the target data table during the rewrite. In the second exemplary processing scheme, the original column-stored file remains valid until the rewrite is complete. Furthermore, the incremental processing module synchronizes non-incremental data operations detected during the rewrite to the column-stored file. This results in changes in the column-stored file during the rewrite (in addition to the primary keys that need to be deleted, more primary keys that need to be deleted may appear during the rewrite), but the new file is unaware of these changes. Therefore, referring to Figure 5 , the second exemplary processing scheme proposes dividing the second phase into two stages: the first stage and the second stage. The first stage runs from the completion of the pull to the completion of the column-stored file rewrite; the second stage runs from the completion of the column-stored file rewrite to the delivery of the new file. Referring to Figure 5, in the first phase, the column storage file remains valid. The incremental processing module can synchronize detected data operations on the inventory to the column storage file and update the first primary key index portion corresponding to the column storage file in the target primary key index. In the first phase, the inventory processing module can initiate in response to a rewrite operation and record the original data location for each data row in the column storage file based on the target primary key index. It should be understood that in the first phase, the incremental processing module may update the primary key index entries corresponding to some data rows in the column storage file in the target primary key index due to detected data operations. For example, in the first phase, if the data row at data position 1 in the column storage file is deleted, the primary key index entry corresponding to this data row in the target primary key index will be deleted. However, the original data location recorded for this data row by the inventory processing module will still be data position 1. For another example, in the first stage, the data row at the aforementioned data position 1 is updated. Then, the data position recorded in the primary key index item corresponding to the data row in the target primary key index has become data position 5 in the incremental file. However, the original data position recorded for the data row by the stock processing module is data position 1. It can be understood that in both cases, the stock processing module will rewrite the data row to the new file, but the data row has actually been deleted, and the data position corresponding to the data row should be marked as deleted in the new file.To this end, in the second phase, the inventory processing module can, in response to the rewrite completion, mark the data row as deleted in the new file if it finds that the data location corresponding to any rewritten data row in the column-stored file is different from its original data location in the target primary key index, or that the corresponding primary key index entry no longer exists in the target primary key index. This ensures the accuracy of the deletion bitmap corresponding to the new file delivered at the end of the second phase. Furthermore, considering that rewriting can cause changes in the data positions of data rows, referring to Figure 4 , in a second exemplary processing solution, the inventory processing module can also record the data location in the new file for each data row rewritten to the new file in the first phase. Based on this, in the second phase, in response to the rewrite completion, the inventory processing module can update the data locations of the remaining data rows in the new file that are not marked as deleted in the new file to the target primary key index. Thereafter, the new file can be delivered for use, and the column-stored file that has been rewritten will be invalidated. This ensures that the first primary key index portion of the target primary key index delivered at the end of the second phase correctly records the data locations corresponding to the relevant primary keys. During research, the inventors discovered that in the second exemplary processing scheme, the stock processing module also needs to perform write operations on the target primary key index. To avoid write conflicts between the stock processing module and the incremental processing module on the target primary key index, an exclusive write lock can be configured for the target primary key index. Referring to Figure 5 , before the start of the second phase, an incremental processing module may hold this exclusive write lock. Upon completion of the rewrite, the stock processing module may acquire this exclusive write lock to update the data locations of the remaining data rows in the new file that are not marked as deleted into the target primary key index. After the update operation is completed, the exclusive write lock is returned to the incremental processing module. As can be seen, in the second exemplary processing scheme, by dividing the second phase into two steps, the correctness of the deletion bitmap corresponding to the new file delivered at the end of the second phase is effectively guaranteed, as is the correctness of the data location corresponding to the relevant primary key recorded in the first primary key index portion of the target primary key index. Furthermore, by using an exclusive write lock, potential write conflicts on the target primary key index can be effectively avoided, further ensuring the correctness of the target primary key index. It should be noted that while some of the processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order, it should be understood that these operations may be executed in a different order or in parallel. Operation sequence numbers, such as 101 and 102, are merely used to distinguish between different operations and do not represent any execution order.Furthermore, these processes may include more or fewer operations, and these operations may be performed sequentially or in parallel. It should be noted that terms such as "first" and "second" herein are used to distinguish different stages, primary key indexes, or steps, and do not represent a sequential order, nor do they limit "first" and "second" to different types. Figure 6 is a schematic structural diagram of an electronic device provided in another exemplary embodiment of the present disclosure. As shown in Figure 6, the electronic device includes a memory 60 and a processor 61. The processor 61 is coupled to the memory 60 and is configured to execute a computer program in the memory 60, configured to: in response to a columnar storage trigger event, sequentially pull data rows from a target data table for columnar storage to generate a columnar storage file and a corresponding first primary key index thereof; synchronize data operations occurring on the target data table monitored during the pulling period to generate an incremental file for storing incremental data rows and a corresponding second primary key index thereof; based on the data operations monitored during the pulling period, record a primary key to be deleted for the first primary key index; in response to the end of the pulling, merge the first primary key index and the second primary key index into a target primary key index, and modify the target primary key index and the columnar storage file based on the primary key to be deleted. In an optional embodiment, when the processor 61 synchronizes data operations detected during a pull on the target data table to generate an incremental file, the processor 61 may be specifically configured to: if a data operation requiring the insertion of a data row is detected during the pull on the target data table, store the inserted data row as an incremental data row in the incremental file; and mark the incremental file for deletion based on a data operation detected during the pull on the target data table requiring the deletion of an incremental data row. In an optional embodiment, when the processor 61 marks the incremental file for deletion based on a data operation detected during the pull on the target data table requiring the deletion of an incremental data row, the processor may be specifically configured to: if a delete operation is detected during the pull on the target data table for an incremental data row, mark the data location in the incremental file corresponding to the deleted data row as deleted; and if an update operation is detected during the pull on the target data table for an incremental data row, mark the data location in the incremental file corresponding to the data row deleted by the update operation as deleted.In an optional embodiment, when the processor 61 synchronizes the data operations occurring on the target data table monitored during the pull period to generate a second primary key index, it can be specifically used to: if an insert operation is detected on the target data table during the pull period, then a primary key index item corresponding to the inserted incremental data row is added to the second primary key index; if a delete operation for the incremental data row is detected on the target data table during the pull period, then the primary key index item corresponding to the desired deleted data row is deleted in the second primary key index; if an update operation for the incremental data row is detected on the target data table during the pull period, then the data position pointed to by the primary key index item corresponding to the updated data row in the second primary key index is updated to the data position corresponding to the data row inserted due to the update operation in the incremental file. In an optional embodiment, when recording a primary key to be deleted for the first primary key index based on data operations monitored during the pull period, the processor 61 may be specifically configured to: record the primary key targeted by the delete operation or update operation detected on the target data table during the pull period as the primary key to be deleted. In an optional embodiment, when modifying the target primary key index based on the primary key to be deleted, the processor 61 may be specifically configured to: delete the primary key index entry corresponding to the primary key to be deleted from the first primary key index portion included in the target primary key index. In an optional embodiment, the processor 61 may also be configured to: delete the primary key index entry corresponding to the primary key to be deleted from the first primary key index portion included in the target primary key index that is duplicated in the second primary key index portion. In an optional embodiment, when the processor 61 modifies the column storage file based on the primary key to be deleted, it may be specifically configured to: if a query finds that the primary key corresponding to any data row in the column storage file is the primary key to be deleted, mark the data position corresponding to the data row in the column storage file as deleted, thereby marking the column storage file for deletion. In an optional embodiment, when the processor 61 modifies the column storage file based on the primary key to be deleted, it may be specifically configured to: if a query finds that the primary key corresponding to any data row in the column storage file is not the primary key to be deleted, rewrite the data row to a new file; and if a data operation is detected on the target data table during the rewriting of the column storage file, in response to the completion of the column storage file rewriting, mark the generated new file for deletion according to the detected data operation.In an optional embodiment, the processor 61 may further be configured to: in response to the initiation of a rewrite operation, record the original data location for each data row in the column-stored file according to the target primary key index; in response to the completion of the rewrite, if a query finds that the data location corresponding to any rewritten data row in the column-stored file in the target primary key index is different from its corresponding original data location or that the corresponding primary key index entry no longer exists in the target primary key index, mark the data row as deleted in the new file; and update the data locations of the remaining data rows in the new file that are not marked as deleted into the target primary key index. In an optional embodiment, an exclusive write lock may be configured for the target primary key index. Before the rewrite is completed, the process responsible for performing the rewrite operation acquires the exclusive write lock after the rewrite is completed to update the data locations of the remaining data rows in the new file that are not marked as deleted into the target primary key index. In an optional embodiment, after completing the modification of the target primary key index and the column storage file, the processor 61 may further be configured to: continue monitoring data operations occurring on the target data table; if a data operation requiring the insertion of a data row is detected, the inserted data row is stored in an incremental file and a corresponding primary key index entry is added to the second primary key index included in the target primary key index; if a data operation requiring the deletion of a data row is detected, the corresponding primary key index entry is deleted from the target primary key index and the file containing the deleted data row is marked for deletion. Furthermore, as shown in FIG6 , the electronic device also includes other components, such as a communication component 62 and a power supply component 63. FIG6 schematically illustrates only some components and does not imply that the electronic device includes only the components shown in FIG6 . It is worth noting that the technical details of the above-mentioned electronic device embodiments can be found in the relevant descriptions of the aforementioned method embodiments. To save space, these details will not be repeated here, but this should not compromise the scope of protection of the present disclosure. Accordingly, the present disclosure also provides a computer-readable storage medium storing a computer program, which, when executed, can implement the steps of the above-mentioned method embodiments. Accordingly, embodiments of the present disclosure also provide a computer program product, which, when executed, includes a computer program capable of implementing the steps of the aforementioned method embodiments. The memory in FIG. 6 is used to store the computer program and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phonebook data, messages, images, videos, and the like.The memory can be implemented using any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk. The communication component in Figure 6 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access a wireless network based on a communication standard, such as Wi-Fi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies. The power supply assembly in Figure 6 provides power to various components of the device in which the power supply assembly resides. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device in which the power supply assembly resides. Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, 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, such that the instructions executed by the processor of the computer or other programmable data processing device produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams.These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more flow charts and / or one or more blocks in a block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing the computer or other programmable device to execute a series of operational steps to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flow charts and / or one or more blocks in a block diagram. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or device comprising a series of elements may include not only those elements but also other elements not expressly listed, or elements inherent to such process, method, product, or device. In the absence of further restrictions, elements defined by the phrase "comprising a..." do not preclude the presence of other identical elements in the process, method, product, or device that includes the elements. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. The above description is merely an embodiment of the present disclosure and is not intended to limit the present disclosure. Persons skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present disclosure are intended to be included within the scope of protection of the present disclosure.

Claims

Claims 1. A column storage method, comprising: In response to a column storage trigger event, sequentially pull data rows from a target data table for column storage to generate a column storage file and its corresponding first primary key index; Synchronizing data operations on the target data table monitored during the pull period to generate an incremental file for storing incremental data rows and its corresponding second primary key index; recording a primary key to be deleted for the first primary key index based on the data operations monitored during the pull period; In response to the pulling being completed, the first primary key index and the second primary key index are merged into a target primary key index, and the target primary key index and the column storage file are modified based on the primary key to be deleted.

2. The method according to claim 1, wherein: The data operations occurring on the target data table monitored during the pull period are synchronized to generate an incremental file, including: if a data operation requiring the insertion of a data row is detected on the target data table during the pull period, the inserted data row is stored as an incremental data row in the incremental file; based on a data operation requiring the deletion of an incremental data row detected during the pull period, the incremental file is marked for deletion.

3. The method according to claim 2, wherein: Based on the data operation requiring deletion of incremental data rows detected during the pulling period, the incremental file is marked for deletion, including: if a deletion operation for the incremental data row is detected on the target data table during the pulling period, the data position corresponding to the required deleted data row in the incremental file is marked as deleted; if an update operation for the incremental data row is detected on the target data table during the pulling period, the data position corresponding to the data row deleted due to the update operation in the incremental file is marked as deleted.

4. The method according to any one of claims 1 to 3, wherein: Synchronizing data operations occurring on the target data table monitored during the pull period to generate a second primary key index, including: if an insert operation is detected on the target data table during the pull period, adding a primary key index item corresponding to the inserted incremental data row to the second primary key index; if a delete operation for the incremental data row is detected on the target data table during the pull period, deleting the primary key index item corresponding to the desired deleted data row in the second primary key index; if an update operation for the incremental data row is detected on the target data table during the pull period, updating the data position pointed to by the primary key index item corresponding to the updated data row in the second primary key index to the data position corresponding to the data row inserted due to the update operation in the incremental file.

5. The method according to any one of claims 1 to 4, wherein: Based on the data operations monitored during the pull period, recording the primary key to be deleted for the first primary key index includes: recording the primary key pointed to by the delete operation or update operation occurring on the target data table monitored during the pull period as the primary key to be deleted.

6. The method according to any one of claims 1 to 5, wherein: The target primary key index is modified based on the primary key to be deleted, including: deleting a primary key index item corresponding to the primary key to be deleted from a first primary key index part included in the target primary key index.

7. The method according to any one of claims 1 to 6, further comprising: From the first primary key index part included in the target primary key index, the primary key index item corresponding to the primary key repeated in the second primary key index part is deleted.

8. The method according to any one of claims 1 to 7, wherein: The columns based on the primary key that needs to be deleted The column storage file is modified, including: if it is queried that the primary key corresponding to any data row in the column storage file is the primary key to be deleted, marking the data position corresponding to the data row in the column storage file as deleted, so as to mark the column storage file for deletion.

9. The method according to any one of claims 1 to 8, wherein: The column storage file is modified based on the primary key to be deleted, including: if it is queried that the primary key corresponding to any data row in the column storage file is not the primary key to be deleted, the data row is rewritten to a new file; if a data operation is detected on the target data table during the rewriting of the column storage file, in response to the completion of the rewriting of the column storage file, the generated new file is marked for deletion according to the detected data operation.

10. The method according to claim 9, further comprising: In response to the rewrite operation being started, recording the original data position for each data row in the column storage file according to the target primary key index; In response to the rewriting completion, if it is found that the data position corresponding to any data row that has been rewritten in the column storage file in the target primary key index is different from its corresponding original data position or the corresponding primary key index item no longer exists in the target primary key index, the data row is marked as deleted in the new file; and the data positions of the remaining data rows in the new file that are not marked as deleted are updated in the new file to the target primary key index.

11. The method according to claim 10, wherein: An exclusive write lock is configured for the target primary key index. Before the rewriting is completed, the process responsible for performing the rewriting operation obtains the exclusive write lock after the rewriting is completed to update the data locations of the remaining data rows in the new file that are not marked as deleted to the target primary key index.

12. The method according to any one of claims 1 to 11, wherein: After completing the modification of the target primary key index and the column storage file, the method further includes: continuing to monitor data operations occurring on the target data table; if a data operation requiring the insertion of a data row is detected, storing the required inserted data row in an incremental file and adding a corresponding primary key index item to the second primary key index contained in the target primary key index; if a data operation requiring the deletion of a data row is detected, deleting the corresponding primary key index item from the target primary key index and marking the file containing the deleted data row for deletion.

13. An electronic device, comprising a memory, a processor, and a communication component; the memory is configured to store one or more computer instructions; and the processor is coupled to the memory and the communication component, configured to execute the one or more computer instructions to perform the column storage method according to any one of claims 1 to 12.

14. A computer-readable storage medium storing a computer program, which, when executed by one or more processors, causes the one or more processors to execute the column storage method according to any one of claims 1 to 12.

15. A computer program product, comprising a computer program, which, when executed by one or more processors, causes the one or more processors to execute the column storage method according to any one of claims 1 to 12.

Images