CN109299035B - CHR file management method, system and computer readable storage medium - Google Patents
CHR file management method, system and computer readable storage medium Download PDFInfo
- Publication number
- CN109299035B CN109299035B CN201810725180.8A CN201810725180A CN109299035B CN 109299035 B CN109299035 B CN 109299035B CN 201810725180 A CN201810725180 A CN 201810725180A CN 109299035 B CN109299035 B CN 109299035B
- Authority
- CN
- China
- Prior art keywords
- file
- chr
- ueid
- snapshot
- database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
The invention discloses a CHR file management method, which comprises the following steps: storage management: responding to a CHR file import request, and receiving a CHR file; the received CHR file is imported into a UEID memory database, whether the time point of the CHR file in the UEID memory database exceeds a preset time period or not is detected in real time in the importing process, and if yes, the CHR file located before the time point of the CHR file is deleted; importing the received CHR file into a UEID file database and writing the CHR file into an MDFS; updating a UEID disk snapshot file corresponding to a UEID memory database; query management: responding to the CHR file query request, and judging whether the CHR file in the query request is in the UEID memory database; if yes, inquiring a corresponding CHR file in a UEID memory database and returning an inquiry result; if not, inquiring the corresponding CHR file in the MDFS and returning an inquiry result. The invention has low requirement on hardware environment, low requirement on IT technical capability and quick construction, and can manage the data volume of more than TB-level billion records.
Description
Technical Field
The invention relates to the field of big data analysis, in particular to a CHR file management method, a CHR file management system and a computer-readable storage medium.
Background
At present, after a wireless network is built, in order to know network quality, some basis is provided for network optimization, meanwhile, in order to locate some network operation problems, detailed information of each Call needs to be recorded, and by analyzing a CHR (Call History Record), the probability, the reason and the like of abnormal Call sending can be found, for example, the number of a cell with poor wireless signal coverage, the number of a certain single board causing most of Call failures and the like can be found.
The data size of the CHR data is large and complex, and the optimal management of the CHR data can provide great convenience for the CHR analysis. However, although a common large data processing platform such as Hadoop/telada can also process CHR data, such a system is generally large in investment, high in technical threshold, long in construction period, and not ideal in investment benefit effect, and especially for small and medium-sized enterprises, due to the limitation of ITs IT technical capability and economic capability, IT is difficult to apply the platforms to solve the own large data requirement.
Disclosure of Invention
In order to overcome the defects of the prior art, one of the objectives of the present invention is to provide a management method for CHR files, which has low requirements on hardware environment, low requirements on IT technical capability and fast construction, and can manage the data volume of more than TB-level billion records.
The second purpose of the present invention is to provide a CHR file management system which has low requirements for hardware environment, low requirements for IT technical capability, and fast construction, and can manage data volume of more than TB-level billion records.
IT is a further object of the present invention to provide a computer-readable storage medium in which a program stored in the storage medium can manage CHR files when running, and which has low requirements for hardware environment, low requirements for IT technology capability, and fast construction, and can manage data volumes of more than TB-level billion records.
One of the purposes of the invention is realized by adopting the following technical scheme:
a CHR file management method comprising the steps of:
storage management:
receiving a CHR (Call History) file in response to a CHR file import request;
importing the received CHR file into a UEID (terminal identification code) memory database, detecting whether the time point of the CHR file in the UEID memory database exceeds a preset time period in real time in the importing process, and if so, deleting the CHR file positioned before the time point of the CHR file;
importing the received CHR file into a UEID file database and writing the CHR file into an MDFS (distributed file system);
updating a UEID disk snapshot file corresponding to the UEID memory database;
query management:
responding to the CHR file query request, and judging whether the CHR file in the query request is in the UEID memory database;
if yes, inquiring a corresponding CHR file in the UEID memory database and returning an inquiry result;
if not, inquiring the corresponding CHR file in the MDFS and returning an inquiry result.
Further, the importing the received CHR file into the UEID memory database specifically includes:
grouping the received CHR files according to ENBs (evolved node Bs) and storing the grouped CHR files in ENB objects corresponding to the ENBs;
and grouping the CHR files in the ENB objects according to the UEIDs and storing the CHR files in the UEID objects corresponding to the UEIDs.
Further, the UEID disk snapshot files have two, and only one of the UEID disk snapshot files is updated at a time.
Further, the method for updating the ue id disk snapshot file corresponding to the ue id in-memory database includes:
creating a snapshot write thread in the system;
after a CHR file is processed, a data import thread sends a snapshot writing signal to a snapshot writing thread;
after receiving the snapshot writing signal, the snapshot writing thread waits for 5 seconds;
if the snapshot writing thread receives a new snapshot writing signal again within 5 seconds, the snapshot writing thread enters a waiting state again;
if the snapshot write-in thread does not receive a new snapshot write-in signal within 5 seconds, entering a snapshot write-in state;
if the snapshot write-in thread receives a new snapshot write-in signal in the snapshot write-in state process, judging whether the number of the currently processed ENBs is less than 80% of the total number;
if yes, giving up the current snapshot and reentering the waiting state;
if not, continuing to write the current snapshot.
Further, the detecting whether the time point of the CHR file in the UEID memory database exceeds a preset time period in real time in the importing process, and if so, deleting the CHR file located before the time point of the CHR file specifically includes:
and detecting whether the time point of the CHR file in the UEID memory database is located 24 hours before the current time in real time in the importing process, and if so, deleting the CHR file located before the time point of the CHR file.
Further, the UEID file database is a MONGODB database, and the CHR files in the MONGODB database are stored in the following manner: the CHR file for each day of each ENB is stored in one data file.
Furthermore, the snapshot files in the UEID disk snapshot files are grouped according to ENBs, the data of each ENB is stored in the corresponding ENB snapshot file, and each ENB snapshot file is stored in the corresponding subdirectory according to the ID of the ENB snapshot file.
Furthermore, the loading mode of the UEID disk snapshot file is an on-demand loading mode.
The second purpose of the invention is realized by adopting the following technical scheme:
a CHR file management system comprising: the system comprises a memory server, a file server, a UEID memory database, a UEID file database, a snapshot file storage unit, a memory server query interface and an MDFS;
the memory server is used for importing a CHR file into the UEID memory database, the file server is used for importing the CHR file into the UEID memory database, the snapshot file storage unit is used for storing a snapshot file of the UEID memory database, the snapshot file storage unit is connected with the UEID memory database, the memory server query interface is connected with the UEID memory database, the MDFS is connected with the UEID file database, and a client can acquire the CHR file in the UEID memory database through the memory server query interface and acquire the CHR file in the UEID file database through the MDFS.
The third purpose of the invention is realized by adopting the following technical scheme:
a computer-readable storage medium storing an executable computer program which when executed implements a CHR file management method as described above.
Compared with the prior art, the invention has the beneficial effects that:
the CHR file management method has low requirements on hardware environment and IT technical capability, can be quickly constructed, and can manage the data volume of more than TB-level billion records; the CHR file is respectively stored in a UEID memory database and a UEID file database, the UEID memory database only stores data within 24 hours from the current time, and the CHR file in the UEID memory database is automatically cleared once the CHR file is detected to exceed 24 hours from the current time; when the client wants to acquire the CHR file within 24 hours from the current time, the UE ID memory database is directly inquired, and when the client wants to acquire the CHR file before 24 hours, the CHR file is directly loaded from the UE ID file database.
Drawings
FIG. 1 is a flow chart of storage management in a CHR file management method according to the present invention;
FIG. 2 is a flowchart illustrating query management in a CHR file management method according to the present invention;
fig. 3 is a structural framework diagram of a CHR file management system provided by the present invention, and illustrates a client for facilitating understanding of the work flow of the system.
Detailed Description
The present invention will be further described with reference to the accompanying drawings and the detailed description, and it should be noted that any combination of the embodiments or technical features described below can be used to form a new embodiment without conflict.
Referring to fig. 1 to 3, a CHR file management method includes the following steps:
storage management:
s11, responding CHR (calling history record) file import request, receiving CHR file;
s12, importing the received CHR file into a UEID (terminal identification code) memory database, detecting whether the time point of the CHR file in the UEID memory database exceeds a preset time period in real time in the importing process, and if so, deleting the CHR file positioned before the time point of the CHR file; in this embodiment, the preset time period is within 24 hours from the current time;
s13, importing the received CHR file into a UEID file database and writing the CHR file into an MDFS (distributed file system);
s14, updating a UEID disk snapshot file corresponding to the UEID memory database;
query management:
s21, responding to the CHR file query request, and judging whether the CHR file in the query request is in the UEID memory database;
s22, if yes, inquiring a corresponding CHR file in the UEID memory database and returning an inquiry result;
and S23, if not, inquiring the corresponding CHR file in the MDFS and returning the inquiry result.
The CHR file management method has low requirements on hardware environment and IT technical capability, can be quickly constructed, and can manage the data volume of more than TB-level billion records; the CHR file is respectively stored in a UEID memory database and a UEID file database, the UEID memory database only stores data within 24 hours from the current time, and the CHR file in the UEID memory database is automatically cleared once the CHR file is detected to exceed 24 hours from the current time; when the client wants to acquire the CHR file within 24 hours from the current time, the UE ID memory database is directly inquired, and when the client wants to acquire the CHR file before 24 hours, the CHR file is directly loaded from the UE ID file database.
In this embodiment, the MME-ue id query service end is used as a resident service process, the CHRs within 24 hours from the current time are cached in the memory, that is, stored in the ue id memory database, and the query service for these CHR data is provided through the WCF query interface. The UEID disk snapshot file provides a complete mirror image of the UEID in-memory database at a certain moment, and when the service is restarted, the UEID in-memory database can be quickly restored to the newly-saved and updated state from the UEID disk snapshot file.
As a preferred embodiment, the step of importing the received CHR file into the UEID memory database specifically includes:
grouping the received CHR files according to ENBs (evolved node Bs) and storing the grouped CHR files in ENB objects corresponding to the ENBs;
the CHR files in the ENB objects are respectively grouped according to the UEID and stored in the UEID object corresponding to each UEID, and the following table shows that:
according to the distribution characteristic analysis of the CHR, the frequency of UEID repeated distribution in the CHR is high, namely: for each different UEID under each ENB, there are an average of 15 contributing reallocation records per day. In this case, grouping all records by UEID is an optimal organizational structure, with which the set of records that need to be reordered in the update operation will be smaller, while in the query, the UEID can be located directly, and then the corresponding record can be located directly by binary search.
In the embodiment, CHR data are partitioned according to ENBs at first, and after the data are partitioned according to the ENBs, the data set of each ENB partition only accounts for one part of ten-thousandth of the whole record on average, so that the updating and querying performance is greatly improved; in the updating and inquiring operation, the CHR or the MR/ticket needing to be matched is generally required to be updated, and the data are organized together according to the ENB, so that N updating or inquiring requests under the same ENB are packaged into a batch updating or inquiring request, thousands of updating and inquiring requests can be completed only by one-time positioning of the ENB partition, and the updating and inquiring performance is further improved; in addition, after the update or query requests are packaged according to the ENBs for batch processing, the locking operation between the update and query operations can be promoted to ENB-level locking, which is a lock granularity with moderate scale, the number of locking operations required is less than that of a lock with a record level, the occupation of the lock operations on the memory is less by several orders of magnitude, and a higher concurrency is provided compared with a lock with a library level, and the read-write operations can be concurrently performed on different ENBs.
Because the daily data volume of each ENB is uncertain, the size of each ENB record array cannot be determined in advance, and dynamic allocation and adjustment can be carried out only according to actual data. According to data statistics, the data volume of each ENB per day is 5000 pieces on average, therefore, in the embodiment, the record array of each ENB takes 512 as a base number, and when the size of the array is not enough to store 24 hours of data, the capacity of the array is expanded by 512 elements.
In a preferred embodiment, the UEID disk snapshot files have two, and only one of the UEID disk snapshot files is updated at a time. The process of writing a snapshot is a long time operation in which the service process may be corrupted or terminated, leaving an incomplete snapshot on the disk that obviously cannot be made to affect the service restart thereafter. Therefore, during the snapshot writing process, a complete snapshot should be kept on the disk, and if the snapshot writing process fails, the previous complete snapshot is used for the next startup. Therefore, two snapshots, at least one of which is a complete snapshot, are actually maintained in the system at all times.
We distinguish the two snapshots with two different directory names: snap shot-X, snap srt-Y where X, Y are two numbers representing versions of SNAPSHOTs, the two numbers being consecutive such as (1, 2). First, it is assumed that these two directories always exist (the first run can create a SNAPSHOT with the history data and then copy one to become two SNAPSHOTs), which is assumed to be snap-1, snap-2, when the SNAPSHOT is written, the one with the smaller label, i.e. snap-1, is always written, and after the writing is successful, the directory name is modified to be snap-3. Since the directory rename is an atomic operation, once the directory is renamed to SNAPSHOT-3, it indicates that the write operation is complete. When the service is started, data is always read from only the SNAPSHOT with the large label, therefore, if SNAPSHOT-1 write fails, SNAPSORT-2 in the SNAPSHOTs (SNAPSHOT-1 and SNAPSORT-2) is still a complete SNAPSHOT, otherwise, the two SNAPSHOTs should be (SNAPSHOT-2 and SNAPSORT-3), wherein SNAPSORT-3 is the latest complete SNAPSHOT.
The frequency of snapshot writing is a problem to be considered in balance, on one hand, even if the state can be restored from the snapshot to the state when the snapshot is created after the service is restarted, the subsequent data file needs to be imported and processed once again from the moment, so it is obvious that the more frequently the snapshot is updated, the fewer the files left after the snapshot are, the more reliable the data processing and the state after the service is restarted, on the other hand, 10GB of IO overhead is required for updating the snapshot every time, and the influence of the overhead on the server is not small.
The updating of the memory data is in units of CHR original record files, so that it is not necessary to update the snapshot in the process of processing a CHR file, and after the records of a CHR file are all updated to the memory, a snapshot should be theoretically created immediately, so that after the service is restarted, the CHR file and the files before the CHR file do not need to be processed. However, CHR files may arrive in batches, several CHR files may be reached at a time within a few minutes, and it is obviously not suitable if a snapshot is created after each file is processed — a snapshot is just created and may fail immediately.
In view of the above points, as a preferred embodiment, the system employs a balanced snapshot write strategy, which is as follows:
creating a snapshot write-in thread in the system, maintaining the snapshot write-in thread all the time, enabling the snapshot write-in thread to be in a waiting state, and waiting for a snapshot write-in signal;
after a CHR file is processed, a data import thread sends a snapshot writing signal to a snapshot writing thread;
after receiving the snapshot writing signal, the snapshot writing thread waits for 5 seconds;
if the snapshot writing thread receives a new snapshot writing signal again within 5 seconds, abandoning the previous signal and reentering the waiting state;
if the snapshot writing thread does not receive a new snapshot writing signal within 5 seconds, entering a snapshot writing state, starting to process ENBs one by one, and writing snapshots;
if the snapshot write-in thread receives a new snapshot write-in signal in the snapshot write-in state process, judging whether the number of the currently processed ENBs is less than 80% of the total number;
if yes, giving up the current snapshot, re-entering a waiting state, and waiting for the completion of the processing of the batch of files;
if not, continuing to write the current snapshot.
In addition, in the updating process, when a data import thread updates certain ENB data, firstly, the state of the data import thread is queried for a snapshot write thread, and if the snapshot write thread is already in the snapshot write state: and if the snapshot write-in thread declares that the ENB data is in the write-in state, updating the ENB data, otherwise, after the ENB snapshot is written, updating the ENB data. This situation typically occurs during a batch update and when a snapshot writer thread has processed a portion of the ENBs, the ENBs that have been processed for the snapshot writer thread may be updated directly.
As a preferred embodiment, detecting whether a time point of a CHR file in a ue id memory database exceeds a preset time period in real time during the importing process, if so, deleting the CHR file located before the time point of the CHR file specifically:
and detecting whether the time point of the CHR file in the UEID memory database is located before 24 hours from the current time in real time in the importing process, and if so, deleting the CHR file located before the time point of the CHR file.
In this embodiment, the UEID memory database should have at least 24-hour records. For example, now there are two such records for a certain UEID, T0: 23:50 and T1: 02: 30. If the record T0 is deleted, then the query before 02:30 will not match the result, which is obviously not appropriate. As can be seen from this example, "at least 24 hours recorded" shall actually mean "for a time T that falls within 24 hours, it is guaranteed that a certain result can be queried". As can also be seen from this example, if T1 is before 24 hours, then T0 can be culled, otherwise the query will not be guaranteed after culling T0. Therefore, when performing the update operation, it is first necessary to sort the records by the next time point (expiration time T1) of each record. When a record is added, the minimum T1 in the existing record is detected, if the T1 is before 24 hours, the record can be removed, and the capacity expansion of an array is not needed; if the array capacity is insufficient to accommodate the updated data within 24 hours of T1, the array is expanded.
Since the smallest T1 needs to be detected and culled continuously during the update operation, we use a small top heap structure to sort T1. The use of a small top-heap structure can effectively improve the performance of the update since each update operation involves only about 5% of the data volume.
In addition, because the records need to be sorted according to T1 in the updating operation, the sorting mode in the query process is completely different, and only one update is concurrent in the whole system, the original data is firstly copied to the update area for processing in the updating process, and then copied to the ENB after the updating process is finished. Therefore, in the whole updating process, the ENB is written only in the later copy-back ENB stage, the time of the writing operation is reduced to the minimum, and the collision probability of the read-write lock on the ENB is reduced.
As a preferred embodiment, the UEID file database is a MONGODB database, and the CHR files in the MONGODB database are stored in the following manner: the CHR file for each day of each ENB is stored in one data file. In order to be able to query data days ago, the data must be stored in a persistent file, and when a client needs to query the data, the client directly loads the data from the file to the memory space of the client for querying. Considering that the querying client may be distributed on any server and that these data files should be accessible from one server, it is appropriate to store these files in the MONGODB database. Since query operations are typically in the unit of an ENB, and in the case of complementary acquisitions, only a few ENBs may typically be involved. Therefore, it is appropriate that the external data file is organized in ENB days, that is, data of one ENB day is organized in one data file. Approximately 3 ten thousand by 30 to 100 ten thousand data files per month. On average, about 5000 records per file, each record holding (MME-UID, T, IMSI, MDN)4 fields 32 bytes, i.e. on average 160KB per file, even though the amount of data increases by 10 times, 2MB per day of file.
As a preferred implementation mode, snapshot files in UEID disk snapshot files are grouped according to ENBs, data of each ENB is stored in the corresponding ENB snapshot file, and each ENB snapshot file is stored in a corresponding subdirectory according to the ID of the ENB snapshot file. Because the number of ENBs contained in the system is tens of thousands, all ENB snapshot files cannot be placed under one directory, otherwise the IO performance is greatly influenced due to too many ENB snapshot files under the directory. Therefore, the ENB snapshot files are distributed under 00-99 one hundred subdirectories, and the subdirectory corresponding to the snapshot file of one ENB is determined according to the ID% 100 of the ENB.
As a preferred embodiment, the loading mode of the UEID disk snapshot file is an on-demand loading mode. In order to start providing service immediately after the service is restarted, obviously, the whole snapshot cannot be waited to be loaded to the memory, therefore, the snapshot must be loaded in an on-demand loading manner, that is, data is loaded when the data is needed to be used, and only a small part of the data is loaded each time, so that the loading of the whole snapshot is dispersed to a large amount of on-demand loading processes, although each loading needs to wait for a short time (<1s), the client does not need to wait for several minutes.
Referring to fig. 3, the present invention further provides a CHR file management system, including: the system comprises a memory server, a file server, a UEID memory database, a UEID file database, a snapshot file storage unit, a memory server query interface and an MDFS;
the memory server is used for importing the CHR file into the UEID memory database, the file server is used for importing the CHR file into the UEID file database, the snapshot file storage unit is used for storing a snapshot file of the UEID memory database, the snapshot file storage unit is connected with the UEID memory database, the memory server query interface is connected with the UEID memory database, the MDFS is connected with the UEID file database, and the client can acquire the CHR file in the UEID memory database through the memory server query interface and acquire the CHR file in the UEID file database through the MDFS.
As the occupied amount of the UEID disk snapshot file reaches 10-20GB, in order to improve the performance of writing and fast recovery from snapshot, the snapshot file storage unit adopts an SSD (solid state disk).
Furthermore, the present invention also provides a computer-readable storage medium storing an executable computer program, which when running implements the CHR file management method as described above.
The above embodiments are only preferred embodiments of the present invention, and the protection scope of the present invention is not limited thereby, and any insubstantial changes and substitutions made by those skilled in the art based on the present invention are within the protection scope of the present invention.
Claims (9)
1. A CHR file management method, comprising the steps of:
storage management:
responding to a CHR file import request, and receiving a CHR file;
the received CHR file is imported into a UEID memory database, whether the time point of the CHR file in the UEID memory database exceeds a preset time period or not is detected in real time in the importing process, and if yes, the CHR file located before the time point of the CHR file is deleted;
importing the received CHR file into a UEID file database and writing the CHR file into an MDFS;
updating the UEID disk snapshot file corresponding to the UEID memory database, specifically: creating a snapshot write thread in the system; after a CHR file is processed, a data import thread sends a snapshot writing signal to a snapshot writing thread; after receiving the snapshot writing signal, the snapshot writing thread waits for 5 seconds; if the snapshot writing thread receives a new snapshot writing signal again within 5 seconds, the snapshot writing thread enters a waiting state again; if the snapshot write-in thread does not receive a new snapshot write-in signal within 5 seconds, entering a snapshot write-in state; if the snapshot write-in thread receives a new snapshot write-in signal in the snapshot write-in state process, judging whether the number of the currently processed ENBs is less than 80% of the total number; if yes, giving up the current snapshot and reentering the waiting state; if not, continuing to write the current snapshot;
query management:
responding to a CHR file query request, and judging whether the CHR file in the query request is in the UEID memory database;
if yes, inquiring a corresponding CHR file in the UEID memory database and returning an inquiry result;
if not, inquiring the corresponding CHR file in the MDFS and returning an inquiry result.
2. The CHR file management method according to claim 1, wherein the importing the received CHR file into the UEID memory database specifically comprises:
grouping the received CHR files according to ENBs and storing the grouped CHR files in ENB objects corresponding to the ENBs;
and grouping the CHR files in the ENB objects according to the UEIDs and storing the CHR files in the UEID objects corresponding to the UEIDs.
3. The CHR file management method according to claim 1, wherein the UEID disk snapshot files have two, and only one of the UEID disk snapshot files is updated at a time.
4. The CHR file management method according to claim 1, wherein the detecting in real time during the importing process whether the time point of the CHR file in the UEID memory database exceeds a preset time period, and if so, deleting the CHR file located before the time point of the CHR file specifically includes:
and detecting whether the time point of the CHR file in the UEID memory database is located 24 hours before the current time in real time in the importing process, and if so, deleting the CHR file located before the time point of the CHR file.
5. The CHR file management method according to claim 1, wherein the UEID file database is a MONGODB database, and the CHR files in the MONGODB database are stored in a manner that: the CHR file for each day of each ENB is stored in one data file.
6. The CHR file management method according to claim 1, wherein the snapshot files in the UEID disk snapshot files are grouped according to ENB, the data of each ENB is stored in the corresponding ENB snapshot file, and each ENB snapshot file is stored in the corresponding subdirectory according to the ID of the ENB snapshot file.
7. The CHR file management method according to claim 6, wherein the UEID disk snapshot file is loaded in an on-demand manner.
8. A CHR file management system applied to the CHR file management method according to any one of claims 1 to 7, comprising: the system comprises a memory server, a file server, a UEID memory database, a UEID file database, a snapshot file storage unit, a memory server query interface and an MDFS;
the memory server is used for importing a CHR file into the UEID memory database, the file server is used for importing the CHR file into the UEID memory database, the snapshot file storage unit is used for storing a snapshot file of the UEID memory database, the snapshot file storage unit is connected with the UEID memory database, the memory server query interface is connected with the UEID memory database, the MDFS is connected with the UEID file database, and a client can acquire the CHR file in the UEID memory database through the memory server query interface and acquire the CHR file in the UEID file database through the MDFS.
9. A computer-readable storage medium, characterized in that the computer-readable storage medium stores an executable computer program which when executed implements the CHR file management method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810725180.8A CN109299035B (en) | 2018-07-04 | 2018-07-04 | CHR file management method, system and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810725180.8A CN109299035B (en) | 2018-07-04 | 2018-07-04 | CHR file management method, system and computer readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109299035A CN109299035A (en) | 2019-02-01 |
| CN109299035B true CN109299035B (en) | 2021-10-15 |
Family
ID=65167840
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810725180.8A Active CN109299035B (en) | 2018-07-04 | 2018-07-04 | CHR file management method, system and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109299035B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110297673B (en) * | 2019-06-20 | 2022-04-12 | 福建天泉教育科技有限公司 | Method and storage medium for optimizing loading of memory data |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101196852A (en) * | 2008-01-03 | 2008-06-11 | 杭州华三通信技术有限公司 | Distributed caching method and system, caching equipment and non-caching equipment |
| CN103020236A (en) * | 2012-12-15 | 2013-04-03 | 安科智慧城市技术（中国）有限公司 | Method, system and distributed database system for retrieving recorded video |
| CN106339860A (en) * | 2016-09-05 | 2017-01-18 | 南京简睿捷软件开发有限公司 | Enterprise internal call response management system and management method |
| CN107911565A (en) * | 2017-11-02 | 2018-04-13 | 平安科技（深圳）有限公司 | Calling-control method, terminal, equipment and computer-readable recording medium |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8718262B2 (en) * | 2007-03-30 | 2014-05-06 | Mattersight Corporation | Method and system for automatically routing a telephonic communication base on analytic attributes associated with prior telephonic communication |
| CN101231642A (en) * | 2007-08-27 | 2008-07-30 | 中国测绘科学研究院 | Space-time database administration method and system |
| JP4988875B2 (en) * | 2010-01-21 | 2012-08-01 | 株式会社三井住友銀行 | Inter-site telephone handover system and method |
| US8244743B2 (en) * | 2010-06-08 | 2012-08-14 | Google Inc. | Scalable rendering of large spatial databases |
| CN102073739A (en) * | 2011-01-25 | 2011-05-25 | 中国科学院计算技术研究所 | Method for reading and writing data in distributed file system with snapshot function |
| CN104317926B (en) * | 2014-10-31 | 2017-10-17 | 北京思特奇信息技术股份有限公司 | The data storage and query method and corresponding device and system of a kind of persistence |
| CN105718484A (en) * | 2014-12-04 | 2016-06-29 | 中兴通讯股份有限公司 | File writing method, file reading method, file deletion method, file query method and client |
| CN106934001A (en) * | 2017-03-03 | 2017-07-07 | 广州天源迪科信息技术有限公司 | Distributed quick inventory inquiry system and method |
| CN107071005A (en) * | 2017-03-24 | 2017-08-18 | 厦门中控生物识别信息技术有限公司 | A kind of method of data synchronization and system |
-
2018
- 2018-07-04 CN CN201810725180.8A patent/CN109299035B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101196852A (en) * | 2008-01-03 | 2008-06-11 | 杭州华三通信技术有限公司 | Distributed caching method and system, caching equipment and non-caching equipment |
| CN103020236A (en) * | 2012-12-15 | 2013-04-03 | 安科智慧城市技术（中国）有限公司 | Method, system and distributed database system for retrieving recorded video |
| CN106339860A (en) * | 2016-09-05 | 2017-01-18 | 南京简睿捷软件开发有限公司 | Enterprise internal call response management system and management method |
| CN107911565A (en) * | 2017-11-02 | 2018-04-13 | 平安科技（深圳）有限公司 | Calling-control method, terminal, equipment and computer-readable recording medium |
Non-Patent Citations (2)
| Title |
|---|
| VSFS: A Searchable Distributed File System;Lei Xu 等;《IEEE》;20150122;第25-30页 * |
| 基于HBase的海量小文件管理系统的设计与实现;陈栋波;《中国优秀硕士学位论文全文数据库 信息科技辑》;20180315;I138-858 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109299035A (en) | 2019-02-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11537659B2 (en) | Method for reading and writing data and distributed storage system | |
| CN109284073B (en) | Data storage method, device, system, server, control node and medium | |
| CN111414362A (en) | Data reading method, device, equipment and storage medium | |
| US11061889B2 (en) | Systems and methods of managing manifest refresh in a database | |
| CN109299035B (en) | CHR file management method, system and computer readable storage medium | |
| US20180276267A1 (en) | Methods and system for efficiently performing eventual and transactional edits on distributed metadata in an object storage system | |
| CN113253932B (en) | Read-write control method and system for distributed storage system | |
| CN112148745B (en) | Multi-HBase cluster access method, device and storage medium | |
| WO2021014436A1 (en) | Data restoration using dynamic data structure altering | |
| CN114020691B (en) | Read-write separated data updating method and device and KV storage system | |
| CN108021562B (en) | Disk storage method and device applied to distributed file system and distributed file system | |
| CN115544037A (en) | Transaction execution method and distributed database system | |
| CN106354830B (en) | Method and device for data synchronization between database cluster nodes | |
| CN114036226A (en) | Data synchronization method, device, equipment and storage medium | |
| CN110866068B (en) | Advertisement data storage method and device based on HDFS | |
| CN114691307A (en) | Transaction processing method and computer system | |
| CN113495807A (en) | Data backup method, data recovery method and device | |
| CN113849574A (en) | Data processing method, front end and computer readable storage medium | |
| CN117009364A (en) | Cache data updating method, device, equipment and storage medium | |
| CN114372052A (en) | Data change record storage method and device, computer equipment and storage medium | |
| CN114595224A (en) | Data storage method and device and data query method and device | |
| CN116821085A (en) | Data processing method, data processing device and distributed file system | |
| CN112631741A (en) | Transaction processing method, device and storage medium | |
| CN110806953A (en) | Backup method and device | |
| CN117076571A (en) | Transaction data synchronization method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |