Call bill query method and device, equipment, storage medium and program product

Abstract

The invention provides a ticket query method and device, equipment, a storage medium and a program product, and relates to the technical field of ticket query. The method comprises the following steps: based on a ticket query request, determining query parameters corresponding to a query task; based on the memory database and the query parameters, determining a query quantity corresponding to the query task; wherein the memory database stores telephone traffic key value pairs which are counted based on identification information, service categories and account periods of users; based on the query quantity, determining the number N of query threads, and distributing the query task to the N query threads; querying from a distributed database based on the N query threads, and obtaining a detailed list query result of each query thread; and based on the ticket query request, summarizing the detailed ticket query results of the N query threads through a summarizing thread to obtain a ticket query result corresponding to the ticket query request. According to the invention, the response speed of ticket query can be effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of call record query, and in particular to a call record query method, device, equipment, storage medium and program product. BACKGROUND

[0002] With the expansion of operator business and the substantial increase of 5G network speed, the network traffic charging largely adopts the OCS (Online Charging System) mode, and the number of call records of a single user often breaks through 3000 per month. Different users use different types of services, and the number of commonly used service types is more than 10. At the same time, various information query interfaces require to return the query results of user call records in seconds.

[0003] In the prior art, distributed architecture is used for call record storage, and parallelism of the distributed system is relied on to solve the delay problem of batch concurrent query. However, when a single user's large detailed record query is encountered, the returned data will be delayed, and even the system will be deadlocked. SUMMARY

[0004] The embodiments of the present application provide a call record query method, device, equipment, storage medium and program product, which effectively improve the system response speed under large detailed record query and avoid the problem of data delay.

[0005] In a first aspect, the embodiments of the present application provide a call record query method, comprising: determining a query parameter corresponding to a query task based on a call record query request; wherein the query parameter comprises target billing period, identification information of a target user and a target service type; determining a query amount corresponding to the query task based on an in-memory database and the query parameter; wherein the in-memory database stores a traffic volume key-value pair based on the identification information of the user, the service type and the billing period; determining the number N of query threads based on the query amount, and distributing the query task to N query threads; wherein N is a positive integer; querying from a distributed database based on the N query threads to obtain detailed record query results of each query thread; wherein the distributed database is used to store traffic detailed record data; and based on the call record query request, the detailed record query results of the N query threads are aggregated by an aggregation thread to obtain a call record query result corresponding to the call record query request.

[0006] In some embodiments, the determination of the query amount corresponding to the query task based on the in-memory database and the query parameter comprises: determining the traffic volume of the target service type of the target user in the target billing period from the in-memory database; and taking the traffic volume of the target service type of the target user in the target billing period as the query amount.

[0007] As a possible implementation manner, the number of the target service categories is 1; the determining the number N of query threads based on the query amount comprises: if the query amount is less than or equal to a first threshold, determining N as a first thread number; if the query amount is greater than the first threshold and less than a second threshold, determining N as a second thread number; wherein the second threshold is greater than the first threshold; the second thread number is greater than the first thread number; if the query amount is greater than or equal to the second threshold, determining N as a third thread number; the third thread number is greater than the second thread number.

[0008] As a possible implementation manner, the number of the target service categories is greater than 1; the determining the number N of query threads based on the query amount comprises: respectively determining the number of query threads corresponding to each target service category based on the query amount corresponding to each target service category; and determining N based on the number of query threads corresponding to each target service category.

[0009] In some embodiments, the respectively determining the number of query threads corresponding to each target service category based on the query amount corresponding to each target service category comprises: determining a total query amount corresponding to all target service categories based on the query amount; if the total query amount is less than or equal to a third threshold, determining N based on the number of tables in the distributed database queried by the query task; if the total query amount is greater than the third threshold, respectively determining the number of query threads corresponding to each target service category based on the query amount corresponding to each target service category.

[0010] In some embodiments, the method further comprises: if the query amount is not obtained based on the in-memory database and the query parameter, determining N based on the target service categories.

[0011] In a second aspect, an embodiment of the present application provides a call record query device, comprising: a first determining module configured to determine query parameters corresponding to a query task based on a call record query request, wherein the query parameters comprise target account period, identification information of a target user, and a target service category; a second determining module configured to determine a query amount corresponding to the query task based on an in-memory database and the query parameters, wherein the in-memory database stores traffic volume key-value pairs based on identification information of a user, a service category, and an account period; a third determining module configured to determine a number N of query threads based on the query amount, and distribute the query task to the N query threads, wherein N is a positive integer; a querying module configured to query a distributed database based on the N query threads, and obtain a detailed record query result of each of the query threads, wherein the distributed database is configured to store traffic detailed record data; and a summarizing module configured to obtain a call record query result corresponding to the call record query request by summarizing the detailed record query results of the N query threads based on the call record query request.

[0012] In a third aspect, an embodiment of the present application provides an electronic device, comprising a processor and a memory storing a computer program, wherein the processor implements the call record query method of the first aspect when executing the program.

[0013] In a fourth aspect, an embodiment of the present application provides a non-transitory computer readable storage medium, which stores a computer program, wherein the computer program is executed by a processor to implement the call record query method of the first aspect.

[0014] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the call record query method of the first aspect.

[0015] The application provides a call log query method, device, equipment, storage medium and program product, based on a call log query request, determining a query parameter corresponding to a query task; wherein the query parameter comprises target account period, identification information of a target user and a target service category; based on a memory database and the query parameter, determining a query amount corresponding to the query task; wherein the memory database stores a traffic volume key-value pair based on the identification information of the user, the service category and the account period; based on the query amount, determining a number N of query threads, and distributing the query task to the N query threads; based on the N query threads, querying from a distributed database to obtain a detailed list query result of each query thread; wherein the distributed database is used to store traffic detailed list data; based on the call log query request, aggregating the detailed list query results of the N query threads through an aggregation thread to obtain a call log query result corresponding to the call log query request. The application can determine the query amount corresponding to the query task by storing the traffic volume key-value pair based on the identification information of the user, the service category and the account period in the memory database, and dynamically determine the number N of query threads according to the query amount, so as to execute the query task in parallel based on the N query threads, thereby solving the problem of data return delay in large detailed list query, and effectively improving the response speed of the call log query. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0017] Figure 1 One of the flowcharts of the call log query method provided by the embodiments of the application; Figure 2 The second flowchart of the call log query method provided by the embodiments of the application; Figure 3 The third flowchart of the call log query method provided by the embodiments of the application; Figure 4 The fourth flowchart of the call log query method provided by the embodiments of the application; Figure 5 The fifth flowchart of the call log query method provided by the embodiments of the application; Figure 6 The structural schematic diagram of the call log query device provided by the embodiments of the application; Figure 7 The structural schematic diagram of the electronic equipment provided by the embodiments of the application. DETAILED DESCRIPTION

[0018] In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions in the present application will be described clearly and completely below in conjunction with the drawings in the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0019] With the expansion of operator business and the substantial increase of 5G network speed, network traffic billing largely adopts OCS mode technology, and the number of single user bills often breaks 3000 per month, and the types of services used by different users are not the same, and the number of commonly used service types is more than 10; at the same time, various information query interfaces require to return the query results of user bills in seconds.

[0020] The current operator business support system often uses distributed architecture for bill storage, and relies on the parallelism of distributed systems to solve the problem of batch concurrent query delay. For example, using hbase database, the detail table is divided according to the billing period, and there is one detail table per billing month; considering the increase of some business bill volume and the increase of query and statistical demand of the business, the business is also divided according to the billing period, that is, there is one table per billing month for a certain business, and one table per billing month for other businesses. The key and value in the detail table are also designed based on the user's query behavior. Because the front page query is generally based on user number or user ID, the query is divided according to time period and business, so the key in the detail table is designed as user number or user ID reverse sequence + business type + call start time or processing time + bill unique identifier. The user number or user ID reverse sequence is to use the distributed principle of Hadoop to disperse the read and write operations of the detail record to different regions to reduce the hot spot.

[0021] However, this architecture does not fully consider the user consumption record behavior, and when a single user large detail volume query (such as 10,000 per month) is encountered, it causes the return data delay (more than 5 seconds, or even system crash). In the case of multiple concurrent situations, there is no concurrent control and dynamic scaling, and the system resources applied for all user detail queries are basically the same, which causes problems such as system service expansion during high concurrency.

[0022] In order to solve the above problems, the present application provides a bill query method, device, equipment, storage medium and program product.

[0023] Figure 1 One of the flowcharts of the bill query method provided by the embodiments of the present application is shown in Figure Figure 1 The method can include the following steps.

[0024] In step 101, based on the call detail record query request, the query parameters corresponding to the query task are determined; wherein the query parameters include target account period, identification information of the target user, and target service category.

[0025] The call detail record query request refers to a query request for call detail records of a user within a time period, which can be initiated by a user terminal. The call detail record query request can include the start time and end time of the query, the identification information of the user, the identification information of the service category of the query, and can also include the call duration, tariff information, and other field information. The query task refers to the task of querying the detailed record based on the call detail record query request, that is, the detailed record data of the target account period corresponding to the detailed record table in which the user identification information is the identification information of the target user, the service category is the target service category, and the time range is from the start time to the end time of the query. The query parameter refers to the index condition for obtaining the query amount from the memory database, which can also be the index condition when querying the detailed record data. The service categories involved in the call detail record query field of the operator can include voice service category, short message service category, and Internet service category.

[0026] Generally, when storing detailed record data, it can be stored based on the account period. The account period can be divided by month, such as January 2025 account period, February 2025 account period, March 2025 account period, etc. Therefore, each account period can correspond to a table for storing detailed record data of all users in that account period. However, since the opening date of each user is different, the start time and end time of the account period corresponding to each user are different. For example, user A opened an account on January 5, so the start time of the January 2025 account period corresponding to user A is January 5, 2025, and the end time is February 4, 2025; user B opened an account on January 1, so the start time of the January 2025 account period corresponding to user B is January 1, 2025, and the end time is January 31, 2025; the data table corresponding to the January 2025 account period can include detailed record data of user A from January 5, 2025 to February 4, 2025, and detailed record data of user B from January 1, 2025 to January 31, 2025.

[0027] In some embodiments, the target account period refers to the account period in which the query period in the call detail record query request is located. If the query period is within an account period, the number of target account periods is one, and if the query period crosses account periods, the number of target account periods is multiple. The target user refers to the user queried in the call detail record query request, and the identification information of the target user is the user identification information contained in the call detail record query request. The target service category refers to the service category required to be queried in the call detail record query request, which can be determined based on the service category identification in the call detail record query request.

[0028] It should be noted that steps 101 to 105 are the execution process for a single account period query. When the number of target account periods is multiple, steps 102 to 105 are executed for each target account period respectively, and finally the query result of the bill for each target account period is obtained. That is, when the number of target account periods is multiple, for each target account period, the query amount of the query task corresponding to the target account period is determined based on the in-memory database, the identification information of the target user, the target service category and the target account period; based on the query amount of the query task corresponding to the target account period, the number N of query threads of the target account period is determined, and the query task of the target account period is distributed to N query threads; wherein N is a positive integer; based on the N query threads, the query is performed from the distributed database to obtain the detailed bill query result of each query thread; based on the bill query request, the detailed bill query results of all query threads are summarized by the summarizing thread to obtain the bill query result.

[0029] In some embodiments, the implementation process of determining the target account period based on the bill query request can include: based on the bill query request, obtaining the query start time and the end time; determining the account period day (the opening date) of the target user, and based on the account period day and the query start time and the end time, determining whether the query period crosses the account period; if the query period does not cross the account period, determining the target account period corresponding to the query period; if the query period crosses the account period, based on the query start time and the end time and the account period day, segmenting the query period to determine the target account period corresponding to each period after segmentation.

[0030] Step 102, based on the in-memory database and the query parameters, the query amount corresponding to the query task is determined; wherein the in-memory database stores the traffic volume key-value pairs based on the identification information of the user, the service category and the account period.

[0031] Among them, the in-memory database can be a Redis database, which is used to store the statistical information of user traffic volume.

[0032] In some embodiments, the in-memory database stores the traffic volume statistical key-value pairs of each user in each account period, which can include the total traffic volume key-value pairs of each user in each account period, or the service traffic volume key-value pairs of each user in each account period. Among them, the identification information of the user can be the user ID, the user's mobile phone number and other information that can uniquely identify the user's identity.

[0033] As an example, the total traffic volume key-value pairs stored in the in-memory database are as follows: Key = user ID + account period, Value = total traffic volume statistical value; the service traffic volume key-value pairs are as follows: Key = user ID + account period + service category, Value = traffic volume statistical value.

[0034] In some embodiments, the in-memory database can be updated each time a bill is imported. Among them, the distributed database storing bill data can be a Hbase database, and the process of importing the bill can include: obtaining a configuration parsing file; bill storage format initialization; obtaining a bill record to be imported; splicing rowkey, table name, bill export record; based on the user ID, billing period and business category in the bill record, updating the total traffic volume and the statistical traffic volume of the business category in Redis according to the user ID, billing period and business category; write the record to the Hbase bill table.

[0035] In some embodiments, based on the in-memory database and the query parameters, the process of determining the query volume corresponding to the query task can include: determining the traffic volume of the target business category of the target user in the target billing period from the in-memory database; and taking the traffic volume of the target business category of the target user in the target billing period as the query volume. Among them, the traffic volume of the target business category of the target user in the target billing period is the Value value of Key = "identification information of the target user + target billing period + target business category" in the in-memory database.

[0036] As a possible implementation, if the target business category includes all business categories, based on the in-memory database and the query parameters, the process of determining the query volume corresponding to the query task can include: determining the total traffic volume of the target user in the target billing period and the traffic volume of each business category of the target user in the target billing period from the in-memory database; and determining the total traffic volume of the target user in the target billing period and the traffic volume of each business category of the target user in the target billing period as the query volume corresponding to the query task.

[0037] Step 103, based on the query volume, determine the number of query threads N, and distribute the query task to N query threads; wherein N is a positive integer.

[0038] That is, the present application takes into account the query volume corresponding to different query tasks, for the query task with large query volume, the query response efficiency can be improved by multi-thread parallel query, and the problem of data return delay due to large bill query can be avoided.

[0039] In some embodiments, a correspondence table of query volume interval value and query thread number can be preset, the target interval value where the query volume is located is determined, and the query thread number corresponding to the target interval value can be determined based on the above correspondence table.

[0040] In some embodiments, the implementation of the allocation of the query task to the N query threads can be: based on the average division of the query period corresponding to the query task into N segments, determining the sub-query task corresponding to each divided segment of the query period as the task of each query thread. As an example, for the case where the number of target account periods is one, such as the query start time in the call detail record query request being January 1, 2025 and the query end time being January 10, 2025, and N = 2, the query task is divided into query task 1 corresponding to the query period from January 1, 2025 to January 5, 2025, and query task 2 corresponding to the query period from January 6, 2025 to January 10, 2025, and the other parameters involved in the query task 1 and the query task 2 (such as the identification information of the target user, the target service category, and the target account period) are saved unchanged according to the parameters in the original query task, and the query task 1 is allocated to the query thread 1 and the query task 2 is allocated to the query thread 2.

[0041] It should be noted that for the case where the query period in the call detail record query request crosses the account period, i.e., there are multiple target account periods, the query period corresponding to each target account period needs to be determined, and when the task is allocated, the query period corresponding to the current target account period is allocated. For example, the query period is from January 1, 2025 to January 28, 2025, the target user's January account period starts on January 5, 2025 and ends on February 4, 2025, and the target user's December 2024 account period starts on December 5, 2024 and ends on January 4, 2025. As can be seen, the query period crosses the account period, from January 1, 2025 to January 4, 2025 belongs to the December 2024 account period, and from January 5, 2025 to January 28, 2025 belongs to the January 2025 account period. The target account period 1 is determined to be the December 2024 account period, the target account period 2 is determined to be the January 2025 account period, the query period corresponding to the target account period 1 is from January 1, 2025 to January 4, 2025, and the query period corresponding to the target account period 2 is from January 5, 2025 to January 28, 2025.

[0042] Among them, the N query threads can be applied from a thread pool, such as based on the number N of query threads, first applying a query thread from a thread pool, and then dividing and allocating the query task to each query thread.

[0043] Step 104, querying from a distributed database based on the N query threads to obtain the detailed bill query result of each query thread; wherein the distributed database is used to store the call detail record data.

[0044] In some embodiments, all traffic detail data of all users is stored in a distributed database, and is stored by the above-mentioned detail storage method. The distributed database can be an Hbase database.

[0045] Each subquery task queries the database according to the target billing period, the specific query period in the target billing period, the rowkey range, and the target service category, respectively, to obtain the detail data. Therefore, the implementation process of obtaining the detail query result of each query thread based on N query threads from the distributed database includes: querying the distributed database according to the target billing period, the specific query period in the target billing period, the rowkey range, and the target service category based on each query thread, respectively, to obtain the detail query result corresponding to each query thread.

[0046] The detail query result refers to all detail data with the query period in the target billing period, the user identifier as the identifier information of the target user, and the service category as the target service category.

[0047] Step 105: Based on the traffic query request, the N query threads are summarized by the summary thread to obtain the traffic query result corresponding to the traffic query request.

[0048] In some embodiments, the summary thread is used to extract the data of the target field in each detail record based on the target field in the traffic query request from the detail query result corresponding to each of the N query threads, and to summarize the data of the target field in each detail record to obtain the traffic query result corresponding to the traffic query request. Since there are many fields involved in the detail data, only the relevant data in the traffic query request needs to be presented, so the summary thread is needed to extract the relevant data in each detail record, and to summarize the relevant data in all detail query results obtained by the N query threads.

[0049] For example, the traffic query request is used to query the call duration and the cost information in the detail, and the traffic query result includes all traffic records meeting the conditions in the traffic query request, and each traffic record includes the time, the service category, the call duration, and the cost information in the detail.

[0050] It should be noted that the number of threads of the summary thread can be one or multiple, which can be pre-set based on the actual scene.

[0051] According to the call record query method of the embodiment of the application, the query parameter corresponding to the query task is determined based on the call record query request, wherein the query parameter comprises target account period, identification information of a target user and a target service category; the query amount corresponding to the query task is determined based on the in-memory database and the query parameter, wherein the in-memory database stores the traffic volume key-value pairs counted based on the identification information of the user, the service category and the account period; the number N of query threads is determined based on the query amount, and the query task is distributed to the N query threads; the query is performed from the distributed database based on the N query threads to obtain the detailed record query result of each query thread, wherein the distributed database is used to store the traffic detailed record data; and the detailed record query result of each of the N query threads is summarized by the summary thread based on the call record query request to obtain the call record query result corresponding to the call record query request. By storing the traffic volume key-value pairs counted based on the identification information of the user, the service category and the account period in the in-memory database, the query amount corresponding to the query task can be determined, and the number N of query threads is dynamically determined according to the query amount, so that the query task is executed in parallel based on the N query threads, thereby solving the problem of data return delay in large detailed record query and effectively improving the response speed of the call record query.

[0052] Figure 2 The second flowchart of the call record query method of the embodiment of the application is provided. As shown in the figure, Figure 2 based on the above embodiment, if the number of target service categories is 1, the implementation process of determining the number N of query threads based on the query amount can include the following steps.

[0053] Step 201: If the query amount is less than or equal to the first threshold value, N is determined as the first thread number.

[0054] Step 202: If the query amount is greater than the first threshold value and less than the second threshold value, N is determined as the second thread number; wherein the second threshold value is greater than the first threshold value; and the second thread number is greater than the first thread number.

[0055] Step 203: If the query amount is greater than or equal to the second threshold value, N is determined as the third thread number; and the third thread number is greater than the second thread number.

[0056] As an example, the first thread number is 1, the second thread number is 2, and the third thread number is 3. The first threshold value can be less than the data amount that will appear delay when using a single thread, and the second threshold value can be less than the data amount that will appear delay when using two threads. For the case of thread number 2, the query period of the target account period can be divided into two to divide the query task into two sub-query tasks and distribute them to two query threads. For the case of thread number 3, the query period of the target account period can be divided into three to divide the query task into three sub-query tasks and distribute them to three query threads.

[0057] According to the call detail record query method provided by the embodiment of the present application, the number of query threads can be dynamically determined based on the size of the query amount, the query task can be executed in parallel based on N query threads, the problem of data return delay in large call detail record query can be solved, the response speed of the call detail record query can be effectively improved, and in the case of small query amount, the query task can be executed by using less resources, and the resource utilization rate can be improved.

[0058] Figure 3 Fig. 3 is a flowchart of a call detail record query method provided by the embodiment of the present application. As shown in Fig. 3, based on the above embodiment, if the number of target service categories is greater than 1, the implementation process of determining the number N of query threads based on the query amount can include the following steps. Figure 3

[0059] Step 301, respectively determine the number of query threads corresponding to each target service category based on the query amount corresponding to each target service category.

[0060] For the scenario that the number of target service categories is greater than 1, that is, the scenario that the call detail record query request needs to query call detail record data of multiple service categories, the query amount obtained in step 102 includes the traffic amount corresponding to each target service category, that is, the query amount corresponding to each target service category. Therefore, different query threads can be used for call detail record query of each target service category, and the number of query threads corresponding to each target service category can be determined based on the query amount corresponding to each target service category. For each target service category, the implementation process of determining the number of query threads corresponding to the target service category based on the query amount corresponding to the target service category can be consistent with the implementation process of steps 201 to 203.

[0061] In some embodiments, respectively determining the number of query threads corresponding to each target service category based on the query amount corresponding to each target service category includes: for each target service category, if the query amount corresponding to the target service category is less than or equal to a first threshold, determining the number of query threads corresponding to the target service category as a first thread number; if the query amount corresponding to the target service category is greater than the first threshold and less than a second threshold, determining the number of query threads corresponding to the target service category as a second thread number; wherein the second threshold is greater than the first threshold, and the second thread number is greater than the first thread number; if the query amount corresponding to the target service category is greater than or equal to the second threshold, determining the number of query threads corresponding to the target service category as a third thread number; and the third thread number is greater than the second thread number.

[0062] Step 302, determine N based on the number of query threads corresponding to each target service category.

[0063] ​That is, the number of query threads corresponding to each target service category is accumulated to obtain the total number of query threads required for executing the query task.

[0064] It should be noted that when the query task is allocated to the N query threads, the query task is first divided according to the target service category, and the query task corresponding to each target service category is allocated to the query thread of the corresponding category. For a target service category corresponding to a number of query threads greater than 1, the query task corresponding to the target service category can be allocated to multiple query threads by splitting the query period.

[0065] As an example, if the number of target service categories is 2, which are target service category 1 and target service category 2, the number of query threads corresponding to target service category 1 is 1, and the number of query threads corresponding to target service category 2 is 2, then the query task corresponding to target service category 1 (query service category = target service category 1, user identification information = identification information of the target user, account period = target account period, and detailed data within the query period) is allocated to query thread 1. The query period is divided into query period 1 and query period 2 to obtain query task 1 (query service category = target service category 2, user identification information = identification information of the target user, account period = target account period, and detailed data within query period 1) and query task 2 (query service category = target service category 2, user identification information = identification information of the target user, account period = target account period, and detailed data within query period 2), and query task 1 is allocated to query thread 2 and query task 2 is allocated to query thread 3.

[0066] According to the call log query method of the embodiment of the application, not only the call log query of one service category is supported, but also the call log query of multiple service categories is supported, and the response speed of the call log query can be effectively improved.

[0067] In order to improve resource utilization, the application also provides the following embodiments.

[0068] Figure 4 A flowchart of a fourth call log query method according to an embodiment of the application is shown in FIG. 4. Figure 4 As shown in FIG. 4, based on the above embodiment, if the number of target service categories is greater than 1, the implementation process of determining the number N of query threads based on the query amount can include the following steps.

[0069] In step 401, the total query amount corresponding to all target service categories is determined based on the query amount.

[0070] As a possible implementation, for a scenario in which the target service categories include all service categories, the total traffic amount of the target user within the target account period can be included in the query amount, and the total traffic amount is the total query amount corresponding to all target service categories.

[0071] As another possible implementation, the traffic volume corresponding to each target business category can be accumulated to obtain the traffic volume corresponding to all target business categories, i.e., the total query volume corresponding to all target business categories.

[0072] In step 402, if the total query volume is less than or equal to the third threshold, N is determined based on the number of tables in the distributed database queried by the query task.

[0073] The third threshold can be the same as the first threshold in the foregoing embodiments, or can be less than the first threshold, or can be greater than the first threshold.

[0074] That is, for a scenario with a small total query volume, different query threads can not be used to execute the query task for each target business category. In order to avoid resource waste, N can be directly determined according to the number of tables in the distributed database queried by the query task.

[0075] In some embodiments, the distributed database can have one table per billing period. For a business category with a large amount of data, the distributed database can have one table per billing period for a certain business category. The number of tables in the distributed database queried by the query task refers to the number of tables involved in the query of the detailed data of the target user in the target billing period for multiple target business categories in the distributed database. If the number of tables in the distributed database queried by the query task is 1, N can be determined as 1.

[0076] In step 403, if the total query volume is greater than the third threshold, the number of query threads corresponding to each target business category is determined based on the query volume corresponding to each target business category.

[0077] For a scenario with a large total query volume, the number of query threads is determined again according to the business category.

[0078] In step 404, N is determined based on the number of query threads corresponding to each target business category.

[0079] In some embodiments, if the in-memory database fails, the query volume corresponding to the query task cannot be obtained. In order to ensure the smooth progress of the query task and also to ensure the response speed, the method can further include: if the query volume is not obtained based on the in-memory database and the query parameters, N is determined based on the target business category.

[0080] As a possible implementation manner, a correspondence between the query task of each service category and the number of query threads can be preset, for example, the number of query threads corresponding to the voice service and the short message service is 1, and the number of query threads corresponding to the online service is 2; if the target service category is the voice service, the N is determined as 1; if the target service category includes the voice service and the short message service, the number of query threads N can be determined as 2, one query thread is used for the query task corresponding to the voice service, and the other query thread is used for the query task corresponding to the short message service; if the target service category includes the voice service and the online service, the number of query threads N can be determined as 3, one query thread is used for the query task corresponding to the voice service, and the other two query threads are used for the query task corresponding to the online service, and the query task corresponding to the online service is distributed to the two query threads according to the query time period.

[0081] According to the call log query method of the embodiment of the application, by determining the total query amount, in the case of small total query amount, the N is determined based on the number of tables in the distributed database queried by the query task, and in the case of large total query amount, the number of query threads of each target service category is determined based on the query amount corresponding to each target service category, the use of the query thread can be reduced in the case of small total query amount, and the utilization of resources is improved.

[0082] Next, in order to facilitate understanding, the flow of the call log query method of the embodiment of the application will be introduced in detail taking Figure 5 as an example. As shown in Figure 5 , the flow of the call log query method includes the following steps.

[0083] Step S1, based on the call log query request, the query parameter corresponding to the query task is determined.

[0084] Among them, based on the call log query request, the query start time and the end time are determined, and whether to cross the account period is determined based on the query start time and the end time; if not cross the account period, the target account period corresponding to the query start time to the end time is determined; if cross the account period, the query start time to the end time is divided by the account period, and a plurality of target account periods are determined. For the case that there are a plurality of target account periods, the following steps S2 to S15 are executed for each target account period, and then the execution process corresponding to a single target account period will be introduced.

[0085] Step S2, based on the memory database and the query parameter, whether the query amount corresponding to the query task can be determined. If the query amount corresponding to the query task can be determined, step S3 is continued, and if the query amount cannot be determined, step S4 is continued.

[0086] Step S3, determine whether the number of target service categories is greater than 1, if the number of target service categories is greater than 1, execute step S5, if the number of target service categories = 1, execute step S10.

[0087] Step S4, determine the number of query threads based on the target service category.

[0088] Step S5, determine the total query amount corresponding to all target service categories based on the query amount.

[0089] Step S6, determine whether the total query amount is less than or equal to the third threshold value, if the total query amount is less than or equal to the third threshold value, execute step S7, if the total query amount is greater than the third threshold value, execute step S8.

[0090] Step S7, determine N based on the number of tables queried in the distributed database by the query task, and then continue to execute step S15.

[0091] Step S8, for any target service category, determine the number of query threads corresponding to each target service category based on the query amount corresponding to each target service category. The process of determining the number of query threads corresponding to each target service category is consistent with the process of steps S10 to S14.

[0092] Step S9, determine N based on the number of query threads corresponding to each target service category, and then continue to execute step S15.

[0093] Step S10, determine whether the query amount is less than or equal to the first threshold value, if the query amount is less than or equal to the first threshold value, execute step S11, if the query amount is greater than the first threshold value, execute step S12.

[0094] Step S11, determine whether the query amount is greater than the first threshold value and less than the second threshold value, if yes, continue to execute step S13, otherwise continue to execute step S14.

[0095] Step S12, determine N = 1, and continue to execute step S15.

[0096] Step S13, determine N = 2, and continue to execute step S15.

[0097] Step S14, determine N = 3, and continue to execute step S15.

[0098] Step S15, distribute the query task to N query threads, and perform detailed bill query.

[0099] Step S16, aggregate the detailed bill query results by aggregation threads to obtain the bill query result.

[0100] In order to realize the above-mentioned embodiment, the application further provides a bill query device.

[0101] Figure 6 A structure diagram of a call query device provided by an embodiment of the present application is shown in FIG. 6. As shown in FIG. 6, the device can include a first determining module 610, a second determining module 620, a third determining module 630, a querying module 640, and a summarizing module 650. Figure 6

[0102] In some embodiments, the first determining module 610 is configured to determine, based on a call query request, a query parameter corresponding to a query task, wherein the query parameter includes target account period, identification information of a target user, and a target service category; the second determining module 620 is configured to determine, based on a memory database and the query parameter, a query amount corresponding to the query task, wherein the memory database stores a traffic volume key-value pair that is counted based on the identification information of the user, the service category, and the account period; the third determining module 630 is configured to determine, based on the query amount, a number N of query threads, and distribute the query task to the N query threads, wherein N is a positive integer; the querying module 640 is configured to perform querying from a distributed database based on the N query threads to obtain a detailed list query result of each query thread, wherein the distributed database is configured to store traffic detailed list data; and the summarizing module 650 is configured to obtain, based on the call query request, a call query result corresponding to the call query request by summarizing the detailed list query results of the N query threads through a summarizing thread.

[0103] In some embodiments, the second determining module 620 is specifically configured to determine, from the memory database, a traffic volume of the target service category of the target user in the target account period, and take the traffic volume of the target service category of the target user in the target account period as the query amount.

[0104] In some embodiments, the number of target service categories is 1, and the third determining module 630 is specifically configured to determine N as a first thread number if the query amount is less than or equal to a first threshold value, determine N as a second thread number if the query amount is greater than the first threshold value and less than a second threshold value, and determine N as a third thread number if the query amount is greater than or equal to the second threshold value, wherein the second threshold value is greater than the first threshold value, the second thread number is greater than the first thread number, and the third thread number is greater than the second thread number.

[0105] In some embodiments, the number of target service categories is greater than 1, and the third determining module 630 is further configured to determine, based on the query amount corresponding to each target service category, a number of query threads corresponding to each target service category, and determine N based on the number of query threads corresponding to each target service category.

[0106] ​As one possible implementation, the third determining module 630 is also used to: determine the total query volume corresponding to all target business categories based on the query volume; if the total query volume is less than or equal to the third threshold, determine N based on the number of tables queried by the query task in the distributed database; if the total query volume is greater than the third threshold, determine the number of query threads corresponding to each target business category based on the query volume corresponding to each target business category.

[0107] In some embodiments, the apparatus further includes a fourth determining module. The third determining module 630 is further configured to: determine N based on the target business category if no query volume is obtained based on the memory database and query parameters.

[0108] According to an embodiment of the present invention, a call detail record (CDR) query device determines query parameters corresponding to a query task based on a CDR query request. These query parameters include the target billing period, the target user's identification information, and the target service category. Based on an in-memory database and the query parameters, the query volume corresponding to the query task is determined. The in-memory database stores call volume key-value pairs statistically analyzed based on the user's identification information, service category, and billing period. Based on the query volume, the number of query threads, N, is determined, and the query task is allocated to N query threads. Based on the N query threads, queries are performed from a distributed database to obtain the detailed call detail record query results for each thread. The distributed database stores call detail record data. Based on the CDR query request, a summary thread aggregates the detailed call detail record query results from the N query threads to obtain the CDR query result corresponding to the CDR query request. This invention, by storing call volume key-value pairs statistically analyzed based on the user's identification information, service category, and billing period in an in-memory database, can determine the query volume corresponding to a query task and dynamically determine the number of query threads, N, to execute the query task in parallel based on N query threads. This solves the problem of data latency during large detailed call detail record queries and effectively improves the response speed of CDR queries.

[0109] It should be noted that the explanations and descriptions in the above embodiments of the call detail record (CDR) query method can also be applied to the CDR query device in the embodiments of the present invention, and will not be repeated here.

[0110] Figure 7 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 7 As shown, the electronic device may include a processor 710, a communication interface 720, a memory 730, and a communication bus 740, wherein the processor 710, the communication interface 720, and the memory 730 communicate with each other through the communication bus 740. The processor 710 can call the computer program in the memory 730 to execute the steps of the call detail record (CDR) query method.

[0111] For example, the method comprises: determining a query parameter corresponding to a query task based on a call query request, wherein the query parameter comprises target account period, identification information of a target user, and a target service category; determining a query volume corresponding to the query task based on an in-memory database and the query parameter, wherein the in-memory database stores a call volume key-value pair based on identification information of a user, a service category, and an account period; determining a number N of query threads based on the query volume, and distributing the query task to the N query threads, wherein N is a positive integer; querying a distributed database based on the N query threads to obtain a detailed call query result of each of the query threads, wherein the distributed database is configured to store call detail data; and aggregating the detailed call query results of the N query threads based on the call query request through an aggregation thread to obtain a call query result corresponding to the call query request.

[0112] In addition, the logic instructions in the memory 730 described above can be implemented in the form of a software functional unit and sold or used as an independent product, and can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0113] On the other hand, the embodiments of the present application also provide a computer program product, which comprises a computer program, the computer program can be stored on a non-transitory computer readable storage medium, and the computer program is executed by a processor, so that the computer can execute the steps of the call query method provided by the above-mentioned embodiments.

[0114] On the other hand, the embodiments of the present application also provide a non-transitory computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the call query method provided by the above-mentioned embodiments.

[0115] The non-transitory computer-readable storage medium can be any available medium or data storage device that a processor can access, including but not limited to a magnetic storage (e.g., floppy disks, hard disks, tape, MO, etc.), optical storage (e.g., CD, DVD, BD, HVD, etc.), and semiconductor storage (e.g., ROM, EPROM, EEPROM, NAND FLASH, SSD, etc.), etc.

[0116] The device embodiments described above are merely illustrative, wherein the units described as separate components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., can be located in one place or distributed to multiple network units. Part or all of the modules can be selected to achieve the purpose of the embodiment scheme according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0117] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be realized by means of software and the necessary general hardware platform, and of course can also be realized by hardware. Based on such understanding, the above technical solutions can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.

[0118] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement to some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for querying call detail records, characterized in that, include: Based on the call detail record (CDR) query request, the query parameters corresponding to the query task are determined; wherein, the query parameters include the target billing period, the target user's identification information, and the target service category; Based on the in-memory database and the query parameters, the query volume corresponding to the query task is determined; wherein, the in-memory database stores call volume key-value pairs that are statistically analyzed based on user identification information, service category, and billing period; Based on the query volume, the number of query threads N is determined, and the query task is assigned to N query threads; where N is a positive integer. Based on the N query threads, queries are performed from the distributed database to obtain the detailed call record query results for each query thread; wherein, the distributed database is used to store call detail record data; Based on the call detail record (CDR) query request, the CDR query results of the N query threads are aggregated by the aggregation thread to obtain the CDR query result corresponding to the CDR query request.

2. The method according to claim 1, characterized in that, The step of determining the query volume corresponding to the query task based on the in-memory database and the query parameters includes: From the memory database, determine the call volume of the target user for the target service category during the target billing period; The call volume of the target user in the target service category during the target billing period is used as the query volume.

3. The method according to claim 1, characterized in that, The number of target business categories is 1; determining the number of query threads N based on the query volume includes: If the query volume is less than or equal to the first threshold, N is determined to be the first thread number; If the query volume is greater than the first threshold and less than the second threshold, N is determined to be the second thread number; wherein the second threshold is greater than the first threshold; and the second thread number is greater than the first thread number. If the query volume is greater than or equal to the second threshold, N is determined to be the number of third threads; the number of third threads is greater than the number of second threads.

4. The method according to claim 1, characterized in that, The number of target business categories is greater than 1; determining the number of query threads N based on the query volume includes: Based on the query volume corresponding to each target business category, determine the number of query threads corresponding to each target business category; N is determined based on the number of query threads corresponding to each of the target business categories.

5. The method according to claim 4, characterized in that, The step of determining the number of query threads for each target business category based on the query volume for each target business category includes: Based on the query volume, determine the total query volume corresponding to all target business categories; If the total number of queries is less than or equal to the third threshold, N is determined based on the number of tables queried by the query task in the distributed database. If the total number of queries is greater than the third threshold, the number of query threads corresponding to each target business category is determined based on the number of queries corresponding to each target business category.

6. The method according to claim 1, characterized in that, Also includes: If the query volume is not obtained based on the in-memory database and the query parameters, N is determined based on the target business category.

7. A call detail record (CDR) query device, characterized in that, include: The first determining module is used to determine the query parameters corresponding to the query task based on the call detail record query request; wherein, the query parameters include the target billing period, the identification information of the target user, and the target service category; The second determining module is used to determine the query volume corresponding to the query task based on the in-memory database and the query parameters; wherein, the in-memory database stores call volume key-value pairs statistically based on user identification information, service category and billing period; The third determining module is used to determine the number of query threads N based on the query volume, and to allocate the query task to N query threads; where N is a positive integer; The query module is used to query the distributed database based on the N query threads and obtain the detailed call record query results for each query thread; wherein, the distributed database is used to store call detail record data; The aggregation module is used to aggregate the detailed call detail record (CDR) query results of the N query threads based on the CDR query request, and obtain the CDR query result corresponding to the CDR query request.

8. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the call detail record (CDR) query method according to any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the call detail record (CDR) query method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the call detail record (CDR) query method as described in any one of claims 1 to 6.

Images