CN110019181B

CN110019181B - Warehouse-in method and device computer readable storage medium

Info

Publication number: CN110019181B
Application number: CN201710681326.9A
Authority: CN
Inventors: 刘月清; 钱建阳
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2017-08-10
Filing date: 2017-08-10
Publication date: 2024-04-16
Anticipated expiration: 2037-08-10
Also published as: CN110019181A; WO2019029395A1

Abstract

A warehouse-in method an apparatus and a computer-readable storage medium, the warehousing method comprises the following steps: acquiring an object to be put in storage; when the table corresponding to the object to be put in storage does not create an index, writing the object to be put in storage into the table corresponding to the object to be put in storage in the database; and scanning the table in the database, and creating an index for the table after the index creating condition is met. The method and the device separate warehouse entry and index creation, and improve warehouse entry speed.

Description

Warehouse entry method and device and computer readable storage medium

Technical Field

The present invention relates to communications technologies, and in particular, to a method and apparatus for warehousing, and a computer readable storage medium.

Background

With the development of various new services, the amount of service ticket also has a tendency of rapid increase, and in a service system with a large amount of ticket, the service ticket reaches tens of millions and billions in scale, which is a common phenomenon. The requirements of warehouse-in performance, warehouse-in reliability and query performance of the operator dialogue sheets are higher and higher. The oracle database is a relational database management system with strong availability, strong expandability, strong data security and strong stability, and is widely used in various business systems. In a service system with huge telephone traffic, the common batch insert warehousing method cannot meet the requirements, and a few service systems adopt the batch insert method in the oci interface of oracle to improve the warehousing performance, but the method can reconstruct indexes in the batch warehousing process, so that the longer the data volume is, the slower the warehousing speed is, if the indexes in the table are abnormal (such as platform restarting, database transient faults and the like) in the process of reconstructing the indexes, the indexes are also invalid, and the problem that the execution time is excessively long when the secondary supplementary records are executed and the program is abnormal is caused because the secondary supplementary records depend on the indexes.

Disclosure of Invention

At least one embodiment of the invention provides a warehousing method and a warehousing device a computer-readable storage medium having stored thereon, and the warehouse-in speed is improved.

In order to achieve the object of the present invention, at least one embodiment of the present invention provides a warehousing method, including:

acquiring an object to be put in storage;

when the object to be put in storage corresponds to when the table of (a) is not being indexed, writing the object to be put in storage into a table corresponding to the object to be put in storage in a database;

and scanning the table in the database, and creating an index for the table after the index creating condition is met.

In an optional embodiment, the acquiring the object to be binned includes: and acquiring objects which are not subjected to warehousing operation, sequencing, and taking a batch of objects with the longest generation time as the objects to be warehoused.

In an alternative embodiment, said scanning the tables in said database comprises:

and the tables in the database have a sequence relation, and one or more tables before the table corresponding to the object with the shortest time are generated in the scanned and put data.

In an alternative embodiment, said creating an index for said table when an index creation condition is satisfied comprises:

and if no new warehousing data exists in the first time threshold value of any table which is not created with the index, and warehousing data after the second time threshold value exists in the first table behind the table, creating the index for the table.

In an alternative embodiment, the method further comprises: when the table corresponding to the object to be put in storage has created an index, deleting the index of the table corresponding to the object to be put in storage, and writing the object to be put in storage into the table corresponding to the object to be put in storage.

In an alternative embodiment, the method further comprises:

when the object to be put in storage is written into a table corresponding to the object to be put in storage in a database, if the storage fails or is overtime, the object to be put in storage is used as the object to be complemented and stored;

acquiring an object to be complemented, judging whether a corresponding table of the object to be complemented has created an index, and if the index has been created, complementing the object to be complemented into the corresponding table in a duplicate removal mode; if the index is not created, the index is created in the corresponding table, and then the index is restored in a repeated manner to the corresponding table.

An embodiment of the present invention provides a warehouse entry device, including: the device comprises an acquisition module, a batch warehousing module and an index scanning module, wherein:

the acquisition module is used for acquiring an object to be put in storage;

the batch warehousing module is set to interact with the index scanning module to judge whether the table corresponding to the object to be warehoused has created an index, if not, the object to be warehoused is written into the table corresponding to the object to be warehoused in the database;

the index scanning module is used for scanning the tables in the database, and creating indexes for the tables after the index creating conditions are met.

In an alternative embodiment, the acquiring module includes: an acquisition unit and a sorting unit, wherein:

the acquisition unit is used for acquiring an object which is not subjected to warehousing operation;

the sorting unit is configured to sort the objects that are not subjected to the warehousing operation, and take a batch of objects with the longest generation time as the objects to be warehoused.

In an alternative embodiment, the index scanning module scanning the table in the database includes:

In an optional embodiment, the batch warehousing module is further configured to notify the index scanning module to delete the index of the table corresponding to the object to be warehoused when the table corresponding to the object to be warehoused has been created, and write the object to be warehoused into the table corresponding to the object to be warehoused after the index scanning module deletes the index of the table corresponding to the object to be warehoused.

In an alternative embodiment, the warehousing device further includes a secondary complement module, wherein:

the batch warehousing module is further configured to store the object to be warehoused as an object to be complemented if the warehousing fails or is overtime when the object to be warehoused is written into a table corresponding to the object to be warehoused in a database;

the secondary complement module is configured to acquire an object to be complement, judge whether a corresponding table of the object to be complement has created an index, and complement the object to be complement to the corresponding table by adopting a duplicate removal mode if the index has been created; if the index is not created, the index is created in the corresponding table, and then the index is restored in a repeated manner to the corresponding table.

An embodiment of the present invention provides a warehousing apparatus, including a memory and a processor, the memory storing a program which, when read and executed by the processor, performs the following operations:

acquiring an object to be put in storage;

when the table corresponding to the object to be put in storage does not create an index, writing the object to be put in storage into the table corresponding to the object to be put in storage in the database;

In an alternative embodiment, the program, when read and executed by the processor, further performs the following: when the table corresponding to the object to be put in storage has created an index, deleting the index of the table corresponding to the object to be put in storage, and writing the object to be put in storage into the table corresponding to the object to be put in storage.

In an alternative embodiment, the program, when read and executed by the processor, further performs the following: when the object to be put in storage is written into a table corresponding to the object to be put in storage in a database, if the storage fails or is overtime, the object to be put in storage is used as the object to be complemented and stored;

An embodiment of the present invention provides a computer-readable storage medium storing one or more programs executable by one or more processors to implement the steps of:

acquiring an object to be put in storage;

Compared with the prior art, in the method, batch warehousing and index creation are separated, and warehousing speed is improved on the basis of ensuring warehousing accuracy.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate and do not limit the invention.

FIG. 1 is a flowchart of a warehousing method according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of a warehouse entry device according to an embodiment of the present invention;

FIG. 3 is a flow chart illustrating a ticket ordering process according to an embodiment of the present invention;

FIG. 4 is a flow chart of a batch warehousing process according to one embodiment of the invention;

FIG. 5 is a flowchart of an index scan according to an embodiment of the present invention;

FIG. 6 is a flow chart of a second supplemental recording provided by an embodiment of the present invention;

FIG. 7 is a flowchart of index information updating and maintaining according to an embodiment of the present invention;

FIG. 8 is a timing diagram for index detection and maintenance according to one embodiment of the present invention.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail hereinafter with reference to the accompanying drawings. It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be arbitrarily combined with each other.

The steps illustrated in the flowchart of the figures may be performed in a computer system, such as a set of computer-executable instructions. Also, while a logical order is depicted in the flowchart, in some cases, the steps depicted or described may be performed in a different order than presented herein.

If the index is not built during warehouse entry, the problem of slow batch warehouse entry can be solved. In addition, the problem of accuracy in secondary supplementary recording can be solved by establishing indexes after batch storage.

As shown in fig. 1, an embodiment of the present invention provides a warehousing method, including:

step 101, obtaining an object to be put in storage;

102, when an index is not created in a table corresponding to the object to be put in storage, writing the object to be put in storage into a table corresponding to the object to be put in storage in a database;

and step 103, scanning the table in the database, and creating an index for the table after the index creating condition is met.

The object may be various information to be written into the database. In this embodiment, a ticket is used as an object to be put in storage. But the present application is not limited thereto.

Each object to be put in storage corresponds to a table existing in the database, and the object is written into the corresponding table in the database, which is called put in storage.

In an optional embodiment, the acquiring the object to be binned includes: and acquiring objects which are not subjected to warehousing operation, sequencing, and taking a batch of objects with the longest generation time as the objects to be warehoused. Taking a bill as an example, warehousing sequentially according to the time of bill generation, wherein the bill generation time is early, and the bill generation time is late. Of course, the present application is not limited thereto, and may be put in storage in other orders as needed.

and the tables in the database have a sequence relation, and one or more tables before the table corresponding to the object with the shortest time are generated in the scanned and put data. Taking the ticket as an example, the table corresponding to the ticket of the current day is not scanned, and the ticket of several days before the current day is scanned. Of course, other means may be employed, such as scanning all existing binned data but not indexed tables, and so forth.

Note that the above-described index creation conditions are only examples, and may be set to other conditions as needed.

In an alternative embodiment, the method further comprises:

and acquiring an object to be complemented, judging whether an index is created in a corresponding table, if so, complementing the object to be complemented in a duplicate removal mode into the corresponding table, and if not, complementing in a duplicate removal mode into the corresponding table after the index is created in the corresponding table.

As shown in fig. 2, the warehousing system according to an embodiment of the present invention includes a service processor 10, a ticket server 20, and a database 30. The service processor 10 and the ticket server 20 can interact through ftp protocol, and the ticket server 20 and the database 30 can interact through the oci interface of oracle. It should be noted that, the service processor 10, the ticket server 20, and the database 30 may also interact through other protocols, which is not limited in this application.

The ticket server 20 comprises a warehousing device, which comprises an acquisition module 21, a batch warehousing module 22 and an index scanning module 23, wherein:

the acquiring module 21 is configured to acquire an object to be put in storage;

the batch warehousing module 22 is configured to interact with the index scanning module 23 to determine whether the table corresponding to the object to be warehoused has created an index, and if not, write the object to be warehoused into the table corresponding to the object to be warehoused in the database; the method is also used for distributing a warehousing sequence number for the warehousing object;

the index scanning module 23 is configured to scan the tables in the database and create an index for the tables when the index creating condition is satisfied.

In an alternative embodiment, the obtaining module 21 includes: an acquisition unit 2101 and an ordering unit 2102, wherein:

In an alternative embodiment, the batch warehousing module 22 is further configured to notify the index scanning module to delete the index of the table corresponding to the object to be warehoused when the table corresponding to the object to be warehoused has been created, and write the object to be warehoused into the table corresponding to the object to be warehoused after the index scanning module deletes the index of the table corresponding to the object to be warehoused.

In an alternative embodiment, the method further comprises a secondary complement module, wherein:

the batch warehousing module 22 is further configured to store the object to be warehoused as an object to be complemented if the warehousing fails or is overtime when the object to be warehoused is written into a table corresponding to the object to be warehoused in a database;

the secondary complement module 24 is configured to acquire an object to be complement, determine whether an index is created in a table corresponding to the object to be complement, and complement the object to be complement to the table corresponding to the object by adopting a duplicate removal mode if the index is created; if the index is not created, the index is created in the corresponding table, and then the index is restored in a repeated manner to the corresponding table.

In an alternative embodiment, the index scanning module 23 scans the tables in the database includes:

In an alternative embodiment, the index scanning module 23 creates an index for the table when the index creating condition is satisfied, including:

Taking the example that the object is a ticket, the service processor 10 processes the service system message to generate the ticket. The acquisition unit 2101 in the ticket server 20 acquires a ticket to a specified directory by ftp, the sorting unit 2102 places a batch of call tickets with the longest time in the directory under the directory to be put in storage. The batch warehousing module 22 detects that the index of the corresponding table does not exist through interaction with the index scanning module, performs ticket warehousing, generates a unique warehousing serial number for each warehousing record, and stores the largest warehousing serial number into a file. If errors occur in the warehousing process, a batch of records in the current warehouse and the warehouse-in serial number are saved in a secondary supplementary catalog. The secondary supplementary recording module 24 scans the ticket under the supplementary recording directory and determines whether the table corresponding to the ticket has been indexed through interaction with the index scanning module. If the index is not established, the ticket is moved to the supplementary recording standby directory, and if the index is established, the ticket is rearranged and put into storage according to the put-in serial number. The batch warehousing module 22 distributes warehousing serial numbers during the repeated warehousing, and applies serial number groups to the batch warehousing module during the processing of the supplementary recording ticket so as to ensure the increment of final serial numbers and the application efficiency. And switching the catalogues when all the telephone bills in the current catalogues are processed, so that the secondary supplementary recording module supplements the telephone bills. The index scanning module 23 scans the table of the previous N days at regular time, if the current table has no new warehouse-in data within a certain threshold time and the following table has data after a certain threshold time, the batch warehouse-in of the previous table is considered to be finished, if the table is not created with an index, the index is created for the table, the index is marked as an in-creation state, and after the index is created successfully, the index is marked as an established state.

When there is a ticket delay generated by the scp downtime in the scp cluster, the batch warehousing module 22 acquires the index information of the table corresponding to the ticket to be warehoused from the index scanning module 23, if the index is not built, the warehouse entry is stopped, if the index is built, the secondary supplementary recording module 24 is informed of deleting the table name of the index, and the index state of the table is acquired at regular time after receiving the notification response.

When receiving the index deletion message sent by the batch warehousing module 22, the secondary supplementary recording module 24 finishes warehousing the current ticket, sets the table index state to be acquired again, stops warehousing, notifies the index scanning module 23 to delete the index, and continues processing after receiving the notification response.

The index scanning module 23 deletes the index of the corresponding table after receiving the delete index message of the secondary supplementary recording module 24, sets the table to the index positive delete state, replies a response, and checks the index condition of the table at regular time, and sets the state of the table to the index deleted after the index of the table is deleted.

In the method, batch warehousing and secondary supplementary recording are completely separated, different threads are adopted to complete the batch warehousing, and the supplementary recording process does not affect the batch warehousing. And the index is delayed to be built, so that the speed during batch warehouse entry is improved. And (4) warehousing and sorting the dialog sheets, and indexing for subsequent complement and inquiry after the batch warehousing of a certain table is finished. And storing the current maximum warehousing serial number into a file after the unique warehousing serial number generated for each ticket is subjected to batch warehousing of a batch of tickets, and storing unsuccessful tickets together with the warehousing serial number for secondary repeated-deletion and re-entry, so as to ensure the warehousing reliability. And when the catalogue is subjected to secondary catalog repairing, a warehouse-in serial number group is applied to a batch warehouse-in module according to the current single line number, so that the warehouse-in serial number is always increased and the application efficiency is ensured. And the ticket without the index is moved to the secondary supplementary recording directory, and after the ticket under the secondary supplementary recording main directory is completely processed, the secondary supplementary recording main directory and the secondary supplementary recording directory are switched, so that the continuous processing of the supplementary recording directory is ensured. When a ticket delay is generated due to a certain scp fault, the automatic warehousing of the backlog ticket is realized through the detection, deletion and reconstruction of the index.

The present application is further illustrated by a specific example below.

FIG. 3 is a flowchart of a method for implementing ticket ordering according to an embodiment of the present application; as shown in fig. 3, includes:

step 301, scanning the ticket under the ftp target list, and sorting according to the time dialogue ticket in the ticket name;

the common ticket names contain time information generated by the ticket, so that the ticket names can be directly ordered according to the ticket name dialogue ticket;

step 302, after a round of scanning is finished, selecting M telephone bills with longest generation time;

namely, M telephone bills generated earliest are selected; if the number of the remaining call ticket is less than M, the remaining call ticket is directly selected.

Step 303, scanning the directory to be put in storage, and checking the number of calls under the directory to be put in storage;

step 304, judging whether the number of calls under the directory to be put in storage is less than N, if yes, executing step 305; otherwise, go to step 303;

step 305, moving the M phone lists to the to-be-put directory, and turning to step 301.

Wherein N is greater than or equal to 1, M is greater than or equal to 1.

In this embodiment, the dialog sheets are put in storage in batches according to the time sequence. However, the present application is not limited thereto, and the ticket storage may be performed in other order.

Fig. 4 is a flow chart of batch warehousing according to an embodiment of the present application, as shown in fig. 4, including:

step 401, scanning a catalog to be put in storage, and taking a ticket from the catalog to be put in storage;

step 402, the batch warehousing module interacts with the index scanning module to obtain whether the list corresponding to the ticket has an index established, and stores the corresponding relation between the list name and the index established, if not, the step 403 is changed, if so, the step 408 is changed;

step 403, reading K rows in the current ticket, and distributing a warehouse-in serial number for each row;

a ticket typically includes multiple lines, which may be entered into multiple passes. Wherein K is 1 or more.

Step 404, performing logic processing, namely warehousing (i.e. writing the K line of the current ticket into a corresponding table), judging whether the warehousing is successful, and if not, turning to step 405; if successful, go to 406;

step 405, storing the current K rows and the warehouse-in serial numbers of the K rows into a secondary supplementary recording main catalog;

step 406, saving the largest warehouse-in serial number to the file, and turning to step 407;

step 407, judging whether the ticket is processed, if not, turning to step 403, otherwise, turning to step 401;

step 408, suspending the warehouse entry, notifying the secondary complement module, waiting for the response of the secondary complement module, inquiring the state of the table after receiving the response of the secondary complement module, and turning to step 403 after the index of the table is deleted.

In this embodiment, batch warehousing is realized, and warehousing is performed according to whether the corresponding table is indexed. If the index is not built, the storage can be performed, otherwise, the storage is performed after waiting for the index to be deleted.

FIG. 5 is a flowchart of an index scanning implementation according to an embodiment of the present invention. As in fig. 5, comprising:

step 501, periodically scanning a table on the first L days;

initially, l=l0, L0 being 1 or more;

taking a ticket as an example, through a table corresponding to a ticket every day, a table corresponding to a ticket yesterday is called a table of the first 1 day, a table corresponding to a ticket of the previous day is called a table of the first 2 days, a table of one day is further pushed forward to be called a table of the first 3 days, and so on;

step 502, if the table index is established, go to step 507; if the table index is not established, go to step 503;

step 503, judging whether the table has no new warehouse-in data in the first time threshold, if yes, turning to step 504; otherwise, go to step 507;

step 504, scan the table for the first L-1 days;

step 505, judging whether the data after the second time threshold is stored in the table on the previous L-1 day, if yes, considering that the table on the previous L day is stored in batches, turning to step 506, otherwise, turning to step 507;

step 506, indexing the table on the previous L days, marking the state of the table as index creation, and marking the state of the table as index established after the index corresponding to the table is established;

step 507, judging whether L is greater than 1, if yes, turning to step 508, otherwise, turning to step 509, finishing scanning, and waiting for the next scanning period;

step 508, subtracting 1 from L, turning to step 501;

step 509, the scanning is completed and the next scanning cycle is waited.

In this embodiment, an index creation method is provided. It should be noted that the above creation method is merely an example, and other methods may be actually adopted as required. For example, an index is created directly for the table preceding the table of the current day, and so on.

Fig. 6 is a flowchart of a second complement implementation provided in an embodiment of the present invention, as shown in fig. 6, including:

step 601, scanning a secondary complement master catalog;

step 602, judging whether a ticket exists in the directory, if yes, turning to step 603, otherwise, turning to step 604;

step 603, a ticket is taken from the secondary complement master catalog, whether the corresponding table is indexed or not is queried according to the ticket name, and the corresponding relation between the table name and whether the index is built or not is saved, if the index is not built, the step 605 is turned, otherwise, the step 606 is turned;

step 604, switching the secondary complement master catalog and the secondary complement backup catalog, and switching to step 601;

the switching is to take the secondary complement catalog as the secondary complement main catalog, and take the secondary complement main catalog as the secondary complement catalog;

step 605, moving the ticket to the secondary supplementary recording directory, and turning to step 601;

step 606, applying for a warehousing sequence number group to the batch warehousing thread according to the current single line number;

step 607, judging whether the warehouse-in serial number group is successfully obtained, if yes, turning to step 608, otherwise, turning to step 606;

step 608, performing secondary supplementary recording on the ticket by adopting a weight removing method, and warehousing the new warehousing serial number;

step 609, it is determined whether the current ticket is processed, if so, the step 601 is executed, and if not, the step 608 is executed.

In the foregoing embodiment, as an implementation manner of the supplementary recording, it should be noted that, other manners may be adopted to carry out the supplementary recording, for example, a secondary supplementary recording main directory and a secondary supplementary recording standby directory are not established, only one secondary supplementary recording directory is established, before the supplementary recording, when it is determined that the corresponding table does not create an index, an index is created for the table where the index is not created, and then the supplementary recording is carried out.

Fig. 7 is a flowchart of updating and maintaining index information provided by an embodiment of the present invention, in which, in order to increase the speed of whether the lookup table has created an index, the table and the information of whether to create an index are stored in the memory. In this embodiment, T pieces of information are stored in the memory, where each piece of information includes a table name and information related to the table, for example, whether the table has been indexed, a processing time of the table (i.e., a time of last processing the table), and an index acquisition time of the table, as shown in fig. 7, including:

step 701, searching table names in a memory;

in order to improve efficiency, only T table names and related information of the tables are stored in the memory; wherein T is 1 or more.

Step 702, judging whether the table name exists, if so, turning to step 703, otherwise, turning to step 704;

step 703, checking whether the acquisition time corresponding to the table name is overtime, if yes, turning to step 704, otherwise turning to step 709;

step 704, obtaining index information through interaction with an index scanning module;

step 705, judging whether the index information is successfully acquired, if yes, turning to step 706, and if acquisition fails or is overtime, turning to step 704;

step 706, checking whether there is space in the memory to store new information, if there is space, turning to step 707; otherwise, go to step 708;

step 707, storing whether to build an index, an index acquisition time and a processing time, and ending;

step 708, selecting one of the existing T pieces of information with the longest processing time, replacing the selected T pieces of information with the newly searched table name and the related information of the table, and ending;

step 709, directly obtaining index information in the memory, updating the processing time of the table, and ending.

Of course, the information may not be stored in the memory, but may be stored in other locations, such as in a file, etc.

It should be noted that, the above-mentioned ticket sorting, batch warehousing, index scanning, secondary complement, index information updating and maintenance may all be performed in parallel, for example, each may be implemented by using an independent thread.

An embodiment of the invention provides a method for realizing warehousing (indexing of a batch warehousing corresponding table and exception handling). When the scp clusters, a certain scp is abnormally backlogged, the ftp function is automatically restored at the same time when the scp is restored, the ticket is downloaded to a ticket server, and a sorting module of the ticket server generates the ticket with the longest time according to the ticket name (generally, the tables corresponding to the tickets are indexed), and the follow-up processing is as follows:

step 801, the batch warehousing module interacts with the index scanning module to find that the list corresponding to the ticket has established an index;

step 802, the batch warehousing module stops warehousing, sends an index deletion notification to the secondary supplementary recording module, and carries the table name of the index to be deleted;

step 803, after receiving the index deletion notification, the secondary supplementary recording module stops warehousing after finishing the supplementary recording of the current ticket if the ticket is being supplementary recorded, and sets the index state of the corresponding table to be overtime (to be acquired again);

step 804, the secondary complement module sends an index deletion notification to the index scanning module, carrying the table name of the table to be deleted with the index;

step 805, after receiving the index deletion notification, the index scanning module deletes the table index and sets the table state to be a positive deletion state;

step 806, the index scanning module replies an index deletion response to the secondary supplementary recording module;

step 807, after receiving the index deletion response, the secondary complement module continues to process complement;

step 808, the secondary complement module returns an index deletion response to the batch warehousing module;

step 809, after receiving the index deletion response, the batch warehousing module periodically acquires the index state of the table, and performs batch warehousing after the index deletion of the table;

in step 810, the index scanning module checks the index condition of the table at regular time, and after the index of the table is deleted, the index of the table is set to be in a deleted state.

It should be noted that the above implementation is only an example, and the batch storage module may also interact with the index scanning module directly, notify the index scanning module to perform index deletion, notify the secondary supplementary recording module to suspend supplementary recording, continue to process supplementary recording after receiving the index deletion response of the index scanning module, and obtain the index state of the table at regular time after receiving the index deletion response of the index scanning module, and perform batch storage after the index deletion of the table.

In the application, the service processor can be replaced by the service processor cluster, and at the moment, if a certain service processor in the service processor cluster is down for a period of time due to a fault, the ticket server can realize automatic warehousing of backlog ticket through detection, deletion and reconstruction of indexes during recovery.

According to the method, batch warehousing is realized by sequentially warehousing, storing the warehousing serial numbers into the files and delaying indexing; continuously supplementing the directory by waiting for indexing and switching the directory; reliable warehousing when the system is abnormal is realized through the weight removal of the warehousing serial number; and realizing automatic warehousing of backlog ticket when a certain scp is abnormal through detection, deletion and reconstruction of the index.

Compared with the prior art, the method and the device solve the problems that the oracle is slower and slower after the index is built in batch warehouse entry, and the warehouse entry cannot be reliably performed after the index is invalid, achieve the effects of improving performance and warehouse entry accuracy, and can be used in a non-real-time service system to realize the alternate-day inquiry of a ticket.

The method can also be used for improving the warehousing performance when the system/sqlserver is used for realizing multi-index, and when the indexes are more, the method can be used for delaying indexing to improve the warehousing performance.

An embodiment of the present invention provides a warehousing device, including a memory and a processor, where the memory stores a program, and the program implements the warehousing method according to any one of the above embodiments when the program is read and executed by the processor.

For example, the program, when read and executed by the processor, performs the operations of:

acquiring an object to be put in storage;

An embodiment of the present invention provides a computer readable storage medium storing one or more programs executable by one or more processors to implement the warehousing method according to any one of the above embodiments.

For example, the one or more programs may be executed by one or more processors to perform the operations of:

acquiring an object to be put in storage;

The computer-readable storage medium includes: a U-disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a removable hard disk, a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Note that, in the present application, ticket storage is described as an example, but the present application is not limited thereto, and the present application may be applied if there is other types of data to be stored.

Although the embodiments of the present invention are described above, the embodiments are only used for facilitating understanding of the present invention, and are not intended to limit the present invention. Any person skilled in the art can make any modification and variation in form and detail without departing from the spirit and scope of the present disclosure, but the scope of the present disclosure is to be determined by the appended claims.

Claims

1. A method of warehousing, comprising:

acquiring an object to be put in storage;

scanning a table in the database, and creating an index for the table after the index creating condition is met;

wherein the method further comprises:

2. The warehousing method of claim 1, wherein the acquiring the object to be warehoused includes: and acquiring objects which are not subjected to warehousing operation, sequencing, and taking a batch of objects with the longest generation time as the objects to be warehoused.

3. The warehousing method of claim 1, wherein said scanning the tables in the database includes:

4. The warehousing method of claim 3, wherein said creating an index for said table when an index creation condition is satisfied comprises:

5. The warehousing method of claim 1, wherein the method further comprises: when the table corresponding to the object to be put in storage has created an index, deleting the index of the table corresponding to the object to be put in storage, and writing the object to be put in storage into the table corresponding to the object to be put in storage.

6. A warehouse entry device, comprising: the device comprises an acquisition module, a batch warehousing module and an index scanning module, wherein:

the acquisition module is used for acquiring an object to be put in storage;

the index scanning module is used for scanning the tables in the database, and creating indexes for the tables after the index creating conditions are met;

the warehousing device further comprises a secondary supplementary record module, wherein:

7. The warehousing apparatus of claim 6 wherein the acquisition module comprises: an acquisition unit and a sorting unit, wherein:

8. The warehousing apparatus of claim 6, wherein the index scanning module scanning the table in the database comprises:

9. The warehousing apparatus of claim 8, wherein said creating an index for said table when an index creation condition is satisfied comprises:

10. The warehousing apparatus of claim 6 wherein the batch warehousing module is further configured to notify the index scanning module to delete the index of the table corresponding to the object to be warehoused when the table corresponding to the object to be warehoused has been created and to write the object to be warehoused into its corresponding table after the index scanning module deletes the index of the table corresponding to the object to be warehoused.

11. A warehousing apparatus comprising a memory and a processor, the memory storing a program which, when read by the processor for execution, performs the operations of:

acquiring an object to be put in storage;

the program, when read and executed by the processor, further performs the operations of: when the object to be put in storage is written into a table corresponding to the object to be put in storage in a database, if the storage fails or is overtime, the object to be put in storage is used as the object to be complemented and stored;

12. The warehousing apparatus of claim 11 wherein said acquiring an object to be warehoused includes: and acquiring objects which are not subjected to warehousing operation, sequencing, and taking a batch of objects with the longest generation time as the objects to be warehoused.

13. The warehousing apparatus of claim 11, wherein said scanning the table in the database comprises:

14. The warehousing apparatus of claim 13, wherein said creating an index for said table when an index creation condition is satisfied comprises:

15. The warehousing apparatus of claim 11 wherein the program, when read by the processor, performs the further operations of: when the table corresponding to the object to be put in storage has created an index, deleting the index of the table corresponding to the object to be put in storage, and writing the object to be put in storage into the table corresponding to the object to be put in storage.

16. A computer-readable storage medium storing one or more programs executable by one or more processors to perform the steps of:

acquiring an object to be put in storage;