VoIP call ticket persistent storage method and device, equipment and storage medium

Abstract

The invention provides a VoIP call ticket persistent storage method and device, equipment and a storage medium, and the method comprises the steps: obtaining a call ticket file, writing the call ticket file with a business rule being an accumulated account into an accumulated account table in a first relational database, and generating a storage file according to the call ticket file; traversing each call ticket file in the storage files, and storing the call ticket files of which the business types are first preset types into a second relational database; the ticket file of which the service type is not the first preset type is stored in a column database, and the second relational database and the column database are preset with respective corresponding data maximum time to live (TTL); and configuring an engine of the relational database in the column database. According to the method and the device, the call ticket storage module and the account accumulation service module are decoupled, and the combination of the relational database and the column database is adopted, so that the call ticket storage appeal is met, the dependence and the pressure on the first relational database are reduced, and meanwhile, the service statistics is responded more quickly.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a method, apparatus, device, and storage medium for persistent storage of VoIP call detail records (CDRs). Background Art

[0002] The Voice over Internet Protocol (VoIP) charging system based on international protocols is an integrated charging management platform designed for telecommunications operators, virtual operators, and call traffic agents to carry out VoIP network telephone services. It provides functions such as account management, business operation, and statistical settlement. Currently, the solution for the daily increase of 500 million CDR volumes in the VoIP charging system aims to persistently store CDR data in a timely manner and has the ability to perform quasi-real-time multi-dimensional CDR statistics and generate year-on-year and month-on-month analysis reports for 5 types of CDRs, namely voice / data / sms / value-added / rental income, etc.

[0003] The existing VoIP charging system mainly uses Oracle as the persistent storage. With the growth of the CDR volume, the operation and maintenance side has been continuously optimizing the CDR table, from ordinary partition tables to sub-partition tables, and then to database sharding + partitioning. As important but non-critical data in the persistent layer, CDRs occupy too large a proportion of database resources. Therefore, the storage pressure on the database is very high, and CDR statistics are inconvenient. The execution of a Structured Query Language (SQL) statement takes a long time. Moreover, the coupling degree between CDR warehousing and account accumulation services is high, and the overall performance is low. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for persistent storage of VoIP CDRs to solve the problems in the prior art, such as high storage pressure on the database, inconvenient CDR statistics, and long SQL execution time.

[0005] In a first aspect, this application provides a method for persistent storage of VoIP CDRs, including:

[0006] Obtain a CDR file, where the CDR file includes business rules, business types, and user information. Write the CDR file with the business rule of account accumulation into an account accumulation table in a first relational database, and generate an warehousing file according to the CDR file;

[0007] Traverse each CDR file in the warehousing file. Take the CDR file with the business type being a first preset type as the first CDR and store the first CDR in a second relational database; take the CDR file with the business type being a non-first preset type as the second CDR, and store the second CDR in a columnar database based on the user information corresponding to the second CDR, where the second relational database and the columnar database are both preset with their respective data maximum time-to-live (TTL);

[0008] Configure the engine of the relational database in the columnar database, where the engine is used to access the relational database and perform join queries and statistics.

[0009] Optionally, in the method as described above, storing the second call record in the columnar database based on the user information corresponding to the second call record includes:

[0010] Calculate the hash value of the second call record according to the user information corresponding to the second call record;

[0011] Based on the hash value, confirm the target data node in the columnar database corresponding to the second call record;

[0012] Store the second call record in the target data node.

[0013] Optionally, in the method as described above, before writing the call record file with the business rule of accumulating accounts into the accumulation table in the first relational database, it further includes:

[0014] Write the call record file into the first queue, traverse the call record files in the first queue, and determine whether the first queue meets the preset writing conditions;

[0015] If so, write the call record files with the business rule of accumulating accounts in the first queue into the accumulation table.

[0016] Optionally, in the method as described above, determining whether the first queue meets the preset writing conditions includes:

[0017] Determine whether the total number of call record files in the first queue exceeds a first preset threshold or the number of call record files with the business rule of accumulating accounts exceeds a second preset threshold;

[0018] If so, confirm that the queue meets the preset writing conditions.

[0019] Optionally, in the method as described above, generating an incoming warehouse file according to the call record file includes:

[0020] Pack the call record files in the first queue to generate an incoming warehouse file.

[0021] Optionally, in the method as described above, before storing the second call record in the columnar database based on the user information corresponding to the second call record, it further includes:

[0022] Write the second call record into the second queue, traverse the second call records in the second queue, and determine whether the total number of second call records in the second queue exceeds a third preset threshold or the number of second call records with the business rule of accumulating accounts exceeds a fourth preset threshold;

[0023] If so, write the second call record in the second queue to the columnar database.

[0024] Optionally, the method as described above further includes:

[0025] Perform full - volume and incremental synchronization on the first call records in the second relational database through a streaming processing tool.

[0026] In a second aspect, the present application provides a VoIP call record persistent storage device, including:

[0027] An incoming - warehouse file generation module, configured to obtain an accumulation file, where the accumulation file includes a service type and user information, write the accumulation file into an accumulation table of a first relational database, and generate an incoming - warehouse file;

[0028] A sub - database incoming - warehouse module, configured to traverse each accumulation file in the incoming - warehouse file, use the accumulation file with the service type being a first preset type as the first call record, and store the first call record in a second relational database; use the accumulation file with the service type being a non - first preset type as the second call record, and store the second call record in a columnar database based on the user information corresponding to the second call record, where the second relational database and the columnar database are both preset with their respective corresponding data maximum survival time TTLs;

[0029] An association module, configured to configure an engine of the relational database in the columnar database, where the engine is used to access the relational database and perform association queries and statistics.

[0030] In a third aspect, the present application provides an electronic device, including a memory, a processor, and computer - executable instructions stored in the memory and executable on the processor, where when the processor executes the computer - executable instructions, the VoIP call record persistent storage method described in any one of the first aspects above is implemented.

[0031] In a fourth aspect, the present application provides a computer - readable storage medium, where the computer - readable storage medium stores a computer program, and when the computer program is executed by a processor, the VoIP call record persistent storage method described in any one of the first aspects above is implemented.

[0032] The VoIP call record persistent storage method, device, equipment and storage medium provided by this application obtain call record files, where the call record files include service rules, service types and user information. Write the call record files with the service rule of accumulating accounts into the accumulation table in the first relational database, and generate an inbound file according to the call record files; traverse each call record file in the inbound file, regard the call record file with the service type of the first preset type as the first call record, and store the first call record in the second relational database; regard the call record file with the service type not being the first preset type as the second call record, and store the second call record in the columnar database based on the user information corresponding to the second call record. Among them, the second relational database and the columnar database are both preset with their respective data maximum survival time TTLs; configure the engine of the relational database in the columnar database, and the engine is used to access the relational database and perform association queries and statistics. By decoupling the call record inbound and accumulation service modules, this application reduces the dependence on and pressure on the first relational database, and improves the overall efficiency; moreover, the accumulation call record storage adopts a combination of a relational database and a columnar database, which meets the call record storage requirements, and also responds to business statistics faster. The columnar database accesses the call record table of the relational database through the engine to achieve multi-dimensional quasi-real-time statistics. By TTL, the daily operation and maintenance work is reduced. When the call record volume is increasing, it can also support twice the call record volume, and the effect is obvious. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with this application, and are used together with the specification to explain the principles of this application.

[0034] Figure 1 It is a schematic diagram of the application scenario of the VoIP call record persistent storage method provided by the embodiment of this application.

[0035] Figure 2 It is a flowchart of the VoIP call record persistent storage method provided by the embodiment of this application.

[0036] Figure 3 It is a schematic diagram of the VoIP call record persistent storage device provided by the embodiment of this application.

[0037] Figure 4 It is a schematic diagram of the structure of the electronic device of the VoIP call record persistent storage device provided by the embodiment of this application.

[0038] Through the above-mentioned accompanying drawings, the clear embodiments of this application have been shown, and there will be more detailed descriptions later. These drawings and text descriptions are not intended to limit the scope of the concept of this application in any way, but to explain the concept of this application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0039] Exemplary embodiments will be described in detail herein, and examples thereof are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0040] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or fully authorized by all parties. And the collection, use, and processing of relevant data need to comply with relevant laws, regulations, and standards, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0041] In the related art, there are 5 types of existing call detail records (CDRs) in the VoIP billing system, namely data / voice / sms / value-added / rental. Among them, data CDRs account for more than 80% of the total. The CDR persistence and accumulation modules are tightly coupled, and the CDRs are stored in the database while accumulating. The CDR table is first partitioned by user ID, then sub-partitioned by enterprise transformation and month, and finally partitioned by date and number. Overall, the CDRs require more than 20,000 partitions and 1TB+ of storage space, which brings great pressure to the original relational database (such as Oracle). The operation and maintenance need to constantly monitor the usage of disks and central processing units to avoid database downtime caused by excessive pressure. At the same time, the direct consequence of the large amount of data is inconvenient query and statistics, and the SQL execution time is too long, which affects the progress of the business.

[0042] To address the above technical problems, the embodiments of the present application aim to propose a VoIP CDR persistent storage method, device, equipment, and storage medium. The core idea of this method is: by decoupling the CDR storage and accumulation business modules, the dependence and pressure on the first relational database are reduced, and the overall efficiency is improved; moreover, the accumulated CDRs are stored using a combination of a relational database and a columnar database, which meets the CDR storage requirements and also responds to business statistics faster. The columnar database accesses the relational database CDR table through the engine to achieve multi-dimensional quasi-real-time statistics. By presetting the maximum data survival time (Time to Live, TTL), the daily operation and maintenance work are reduced. In the current situation where the amount of CDRs is increasing continuously, it can also support twice the amount of CDRs, and the effect is obvious.

[0043] To better understand the solution of the embodiments of the present application, an application scenario involved in the embodiments of the present application will be introduced first.

[0044] Please refer toFigure 1 , Figure 1 is a schematic diagram of the application scenario of the VoIP call record persistent storage method provided by the embodiments of the present application. As Figure 1 shown, it includes a data source 100 and a server 200. Among them, the data source 100 can be used to generate various call record data. The server 200 obtains various call record data generated by the data source 100, writes the call record file with the business rule of accumulating accounts into the accumulation table in the first relational database (such as Oracle), and generates an incoming warehouse file according to the call record file. Then, it traverses each call record file in the incoming warehouse file, stores the call record file with the business type of rent collection into the second relational database (such as mysql); regards the call record file with the business type not being the first preset type as the second call record, and stores the second call record into the columnar database (such as clickhouse) based on the user information corresponding to the second call record. And, an engine of the relational database is configured in the columnar database, and the engine is used to access the relational database and perform association query and statistics.

[0045] The following uses specific embodiments to elaborate in detail on the technical solution of the present application and how the technical solution of the present application solves the above technical problems. These specific embodiments below can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0046] Figure 2 is a flowchart of the VoIP call record persistent storage method provided by the embodiments of the present application. As Figure 2 shown, the method of this embodiment includes:

[0047] S201: Obtain a call record file, where the call record file includes a business rule, a business type, and user information, write the call record file with the business rule of accumulating accounts into the accumulation table in the first relational database, and generate an incoming warehouse file according to the call record file.

[0048] The execution subject of the embodiments of the present application can be a server or a VoIP call record persistent storage system in the server, where the VoIP call record persistent storage system can be implemented by software.

[0049] It can be understood that for the call record file, its business rules can include settlement rules, pricing rules, account combination rules, etc. Its business types generally include five categories: data / voice / sms / value-added / rent collection. The user information described in the present application can be a user ID, which is used to verify the user's identity information.

[0050] The present application decouples the business of the call record incoming warehouse and accumulation modules in the traditional VoIP system, and the process of accumulating accounts is no longer bound to the call record incoming warehouse.

[0051] S202: Traverse each call record file in the incoming storage file, use the call record file with the service type being the first preset type as the first call record, and store the first call record in the second relational database; use the call record file with the service type not being the first preset type as the second call record, and store the second call record in the columnar database based on the user information corresponding to the second call record. Among them, the second relational database and the columnar database are both preset with their respective corresponding data maximum survival time TTLs.

[0052] In this step, different incoming storage processes are performed on call record files of different service types. It can be understood that for call record files with the service type of rent collection, due to special circumstances, there may be data changes, so they are stored separately in the mysql database; while call record types with service types of data / voice / sms / value-added do not involve data changes. Therefore, they can be stored in the clickhouse cluster database.

[0053] It can be understood that TTL refers to the time limit for a data packet to survive in a computer network. It is a numerical value in seconds used to control the maximum survival time of a data packet when it is forwarded by a router. For clickhouse and the mysql database, physical and logical call record tables can be created in advance, ordinary / materialized views can be created, and TTL can be set.

[0054] S203: Configure the engine of the relational database in the columnar database. The engine is used to access the relational database and perform associated queries and statistics.

[0055] In this step, by configuring the mysql engine in the clickhouse cluster database, the mysql database can be directly accessed to achieve associated queries and statistics. For special rent collection type call records, the mysql engine is used to read and write the mysql database, which meets the scenario of data changes in the business and also realizes the requirement of real-time statistics.

[0056] The VoIP call record persistent storage method provided in this embodiment obtains a call record file, where the call record file includes business rules, business types, and user information. The call record file with the business rule of accumulating accounts is written into the accumulating accounts table in the first relational database, and an inbound file is generated according to the call record file. Each call record file in the inbound file is traversed. The call record file with the business type of the first preset type is used as the first call record, and the first call record is stored in the second relational database. The call record file with the business type not being the first preset type is used as the second call record, and the second call record is stored in the columnar database based on the user information corresponding to the second call record. Among them, the second relational database and the columnar database both have their respective preset data maximum survival time TTLs. An engine of the relational database is configured in the columnar database. The engine is used to access the relational database and perform associated queries and statistics. This application decouples the call record inbound and accumulating accounts business modules, reduces the dependence on and pressure on the first relational database, and improves the overall efficiency. Moreover, the accumulating accounts call records are stored using a combination of a relational database and a columnar database, which meets the call record storage requirements and also responds to business statistics faster. The columnar database accesses the call record table in the relational database through the engine to achieve multi-dimensional quasi-real-time statistics. The TTL reduces the daily operation and maintenance work. In the current situation where the call record volume is increasing continuously, it can also support twice the call record volume, and the effect is obvious.

[0057] The technical solution of the above VoIP call record persistent storage method will be introduced in detail below.

[0058] In a possible implementation manner, the VoIP call record persistent storage method provided in this embodiment calculates the hash value of the second call record according to the user information corresponding to the second call record, and stores the second call record in the data node corresponding to its hash value.

[0059] Specifically, storing the second call record in the columnar database based on the user information corresponding to the second call record includes: calculating the hash value of the second call record according to the user information corresponding to the second call record; confirming the target data node in the columnar database corresponding to the second call record based on the hash value; and storing the second call record in the target data node.

[0060] In this embodiment, since the Replicated Merge Tree engine adds distributed collaboration capabilities on the basis of the Merge Tree, only by using the Replicated Merge Tree replication table series engine can the capabilities of replicas be applied. In this application, the call detail record table of the columnar database (such as ClickHouse) can adopt the Replicated Merge Tree engine. Each data node creates a corresponding local physical table for the call detail record table respectively, and then creates a corresponding all logical table in the cluster. When the second call detail record is warehoused, the hash value can be obtained according to the user ID in the call detail record to determine the specific target data node and directly write it into the corresponding local physical table in batches. Further, a materialized view can also be established to generate statistical data in real time.

[0061] In this embodiment, by calculating the hash value of the second call detail record according to the user information corresponding to the second call detail record and storing the second call detail record in the data node corresponding to its hash value, fast and accurate storage of call detail records is realized, meeting the storage requirements of call detail records and reducing the dependence on relational databases.

[0062] In a possible implementation manner, the VoIP call detail record persistent storage method provided in this embodiment decouples the call detail record warehousing and the accumulative accounting function module, writes the call detail record file into the first queue, and when the first queue meets the preset writing condition, writes the call detail record file with the business rule of accumulative accounting in the first queue into the accumulative accounting table and generates an warehousing file according to the call detail record file.

[0063] Specifically, before writing the call detail record file with the business rule of accumulative accounting into the accumulative accounting table in the first relational database, it further includes: writing the call detail record file into the first queue, traversing the call detail record files in the first queue, and judging whether the first queue meets the preset writing condition; if so, writing the call detail record file with the business rule of accumulative accounting in the first queue into the accumulative accounting table.

[0064] Further, judging whether the first queue meets the preset writing condition includes: judging whether the total number of call detail record files in the first queue exceeds the first preset threshold or the number of call detail record files with the business rule of accumulative accounting exceeds the second preset threshold; if so, it is confirmed that the queue meets the preset writing condition.

[0065] It can be understood that generating an warehousing file according to the call detail record file can be: packing the call detail record files in the first queue to generate an warehousing file.

[0066] It can be understood that, due to the uneven sizes of call record files, the preset write condition can be either a condition for the total amount of call record files or a condition for the number of call record files for the accumulation rule. When any one of the thresholds is reached, the call record files in the first queue can be submitted to the repository, and the call record files with the business rule of accumulation are written to the physical table.

[0067] It should be noted that when submitting the call record files in the first queue to the repository, the accumulation files can first enter the accumulation file table of the distributed memory database, and then the distributed memory database accumulation file table asynchronously persists the accumulation files to the physical table, avoiding the dependence of call record warehousing on the physical database. When the physical database cannot be accessed, the business can still run normally, ensuring the continuity of the business and being beneficial to improving the stability and security of call record processing.

[0068] In this embodiment, by decoupling the call record warehousing and accumulation function modules, writing the call record files to the first queue, when the first queue meets the preset write condition, writing the call record files with the business rule of accumulation in the first queue to the accumulation table, and generating the warehousing files according to the call record files, it reduces the excessive dependence on the oracle database, reduces the pressure on the database, and improves the performance and stability of the system.

[0069] In a possible implementation manner, the VoIP call record persistent storage method provided in this embodiment writes the second call records to the second queue, and when the second queue meets the preset write condition, writes the second call records to the columnar database.

[0070] Specifically, before storing the second call records in the columnar database based on the user information corresponding to the second call records, it further includes: writing the second call records to the second queue, traversing the second call records in the second queue, and determining whether the total number of second call records in the second queue exceeds the third preset threshold or the number of second call records with the business rule of accumulation exceeds the fourth preset threshold; if so, writing the second call records in the second queue to the columnar database.

[0071] It can be understood that, due to the uneven sizes of call record files, the preset write condition can be either a condition for the total amount of the second call records or a condition for the number of call record files for the accumulation rule. When any one of the thresholds is reached, the second call records in the first queue can be submitted to the repository, so as to respond to business statistics more quickly.

[0072] In this embodiment, by writing the second call records to the second queue and writing the second call records to the columnar database when the second queue meets the preset write condition, it can overcome the problem of uneven file sizes and improve the stability and efficiency of call record warehousing.

[0073] In a possible implementation, considering the issue of data backup, in the VoIP call record persistent storage method provided in this embodiment, a streaming processing tool can be used to perform full and incremental synchronization of the first call records in the second relational database.

[0074] The streaming processing tool described in this embodiment, namely the Extract-Transform-Load tool, is mainly used for data synchronization. Exemplarily, the streaming processing tool can be DataX, so as to achieve efficient data synchronization between various heterogeneous data sources such as mysql and Oracle to ensure data security. Further, the full and incremental synchronization methods mentioned in this embodiment can be adopted as needed.

[0075] In this embodiment, by using a streaming processing tool to perform full and incremental synchronization of the first call records in the second relational database, the security and comprehensiveness of the call record file data are guaranteed.

[0076] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0077] Further, it should be noted that although the steps in the flowchart are sequentially shown according to the indication of the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limitation, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least a part of other steps or sub-steps or stages of other steps.

[0078] Figure 3 It is a schematic diagram of the VoIP call record persistent storage device provided in the embodiment of the present application. As Figure 3 shown, the VoIP call record persistent storage device includes:

[0079] An incoming file generation module 31, configured to obtain an accumulation file, where the accumulation file includes a service type and user information, write the accumulation file into an accumulation table of the first relational database, and generate an incoming file;

[0080] The sub-library warehousing module 32 is used to traverse each accumulated bill file in the warehousing file, regard the accumulated bill file with the business type being the first preset type as the first call record, and store the first call record in the second relational database; regard the accumulated bill file with the business type not being the first preset type as the second call record, and store the second call record in the columnar database based on the user information corresponding to the second call record. Among them, the second relational database and the columnar database are both preset with their respective corresponding data maximum survival time TTLs;

[0081] The association module 33 is used to configure the engine of the relational database in the columnar database. The engine is used to access the relational database and perform association queries and statistics.

[0082] In a possible design, the sub-library warehousing module 32 is specifically used for:

[0083] Calculate the hash value of the second call record according to the user information corresponding to the second call record;

[0084] Based on the hash value, confirm the target data node corresponding to the second call record in the columnar database;

[0085] Store the second call record in the target data node.

[0086] In a possible design, the warehousing file generation module 31 is specifically used for:

[0087] Write the call record file into the first queue, traverse the call record files in the first queue, and determine whether the first queue meets the preset writing conditions;

[0088] If so, write the call record file with the business rule being accumulated bill in the first queue into the accumulated bill table.

[0089] In a possible design, the warehousing file generation module 31 is specifically used for:

[0090] Determine whether the total number of call record files in the first queue exceeds the first preset threshold or the number of call record files with the business rule being accumulated bill exceeds the second preset threshold;

[0091] If so, confirm that the queue meets the preset writing conditions.

[0092] In a possible design, the warehousing file generation module 31 is specifically used for:

[0093] Pack the call record files in the first queue to generate a warehousing file.

[0094] In a possible design, the sub-library warehousing module 32 is also specifically used for:

[0095] Write the second call record into the second queue, traverse the second call records in the second queue, and determine whether the total number of second call records in the second queue exceeds a third preset threshold or the number of second call records with the business rule of cumulative billing exceeds a fourth preset threshold;

[0096] If so, write the second call records in the second queue into the columnar database.

[0097] In a possible design, the association module 33 is further specifically configured to:

[0098] Perform full - volume and incremental synchronization on the first call records in the second relational database through a streaming processing tool.

[0099] It should be understood that the above device embodiments are illustrative, and the devices of the present application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.

[0100] In addition, without special instructions, in each embodiment of the present application, each functional unit / module can be integrated in one unit / module, or each unit / module can exist physically alone, or two or more units / modules can be integrated together. The above - integrated unit / module can be implemented in the form of hardware or in the form of a software program module.

[0101] Figure 4 It is a schematic structural diagram of an electronic device of the VoIP call record persistent storage device provided by the embodiment of the present application. As Figure 4 shown, the electronic device of this embodiment includes: at least one processor 40 ( Figure 4 only one is shown in the figure), a processor, a memory 41, and a computer program stored in the memory 41 and operable on at least one processor 40. When the processor 40 executes the computer program, it implements the steps in any of the above - mentioned method embodiments.

[0102] The electronic device may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art can understand that Figure 4 This is only an example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0103] The so-called processor 40 may be a Central Processing Unit (CPU), and the processor 40 may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0104] For the specific implementation process of the processor 401, reference may be made to the above method embodiments. Their implementation principles and technical effects are similar, and will not be elaborated here in this embodiment.

[0105] In some embodiments, the memory 41 may be an internal storage unit of the electronic device, such as the memory of the electronic device. In other embodiments, the memory 41 may also be an external storage device of the electronic device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the electronic device. Further, the memory 41 may also include both the internal storage unit and the external storage device of the electronic device. The memory 41 is used to store the operating system, application programs, BootLoader, data, and other programs, such as the program code of a computer program. The memory 41 may also be used to temporarily store the data that has been output or will be output.

[0106] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above various method embodiments can be implemented.

[0107] The above computer-readable storage medium may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic memory, flash memory, a magnetic disk or an optical disc. The readable storage medium may be any available medium accessible by a general-purpose or special-purpose computer.

[0108] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an Application Specific Integrated Circuits (ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in the above-mentioned electronic device.

[0109] Those of ordinary skill in the art can understand that all or part of the steps for implementing the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including the above method embodiments; and the foregoing storage medium includes: various media such as ROM, RAM, magnetic disks, or optical discs that can store program codes.

[0110] In the above embodiments, the descriptions of the various embodiments have their own focuses. For parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0111] Those skilled in the art will readily conceive of other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any variations, uses, or adaptations of the present application, which follow the general principles of the present application and include common general knowledge or conventional technical means in the technical field not disclosed in the present application. The specification and embodiments are only regarded as exemplary, and the true scope and spirit of the present application are pointed out by the following claims.

[0112] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present application is only limited by the appended claims.

Claims

1. A method for persistent storage of VoIP call detail records, characterized in that, Including: Obtain a call record file, where the call record file includes business rules, business types, and user information. Write the call record file with the business rule of cumulative billing into the cumulative billing table in the first relational database, and generate an inbound file according to the call record file; Traverse each call record file in the inbound file, regard the call record file with the business type being the first preset type as the first call record, and store the first call record in the second relational database; Regard the call record file with the business type not being the first preset type as the second call record, and store the second call record in the columnar database based on the user information corresponding to the second call record. Among them, the second relational database and the columnar database both have their respective corresponding data maximum survival time TTLs; Configure the engine of the relational database in the columnar database, and the engine is used to access the relational database and perform associated queries and statistics.

2. The method according to claim 1, characterized in that, The storing the second call record in the columnar database based on the user information corresponding to the second call record includes: Calculate the hash value of the second call record according to the user information corresponding to the second call record; Confirm the target data node in the columnar database corresponding to the second call record based on the hash value; Store the second call record in the target data node.

3. The method according to claim 1, characterized in that, Before writing the call record file with the business rule of cumulative billing into the cumulative billing table in the first relational database, it further includes: Write the call record file into the first queue, traverse the call record files in the first queue, and determine whether the first queue meets the preset writing conditions; If so, write the call record files with the business rule of cumulative billing in the first queue into the cumulative billing table.

4. The method according to claim 3, characterized in that, The determining whether the first queue meets the preset writing conditions includes: Determine whether the total number of call record files in the first queue exceeds the first preset threshold or the number of call record files with the business rule of cumulative billing exceeds the second preset threshold; If so, confirm that the queue meets the preset writing conditions.

5. The method according to claim 3, characterized in that, The generating the inbound file according to the call record file includes: Pack the call record files in the first queue to generate an inbound file.

6. The method according to claim 1, characterized in that, Before storing the second call record in the columnar database based on the user information corresponding to the second call record, it further includes: Write the second call record into the second queue, traverse the second call records in the second queue, and determine whether the total number of second call records in the second queue exceeds the third preset threshold or the number of second call records with the business rule of cumulative billing exceeds the fourth preset threshold; If so, write the second call records in the second queue into the columnar database.

7. The method according to claim 1, characterized in that, This method further includes: Perform full - volume and incremental synchronization on the first call records in the second relational database through a streaming processing tool.

8. A device for persistent storage of VoIP call detail records, characterized in that, Including: An inbound file generation module, used to obtain a cumulative billing file, where the cumulative billing file includes a business type and user information, write the cumulative billing file into the cumulative billing table of the first relational database, and generate an inbound file; A sub - database inbound module, used to traverse each cumulative billing file in the inbound file, regard the cumulative billing file with the business type being the first preset type as the first call record, and store the first call record in the second relational database; Take the accumulated bill file with the service type not being the first preset type as the second call record, and store the second call record in the columnar database based on the user information corresponding to the second call record, wherein each of the second relational database and the columnar database is preset with its own corresponding data maximum survival time TTL; An association module, configured to configure an engine of the relational database in the columnar database, where the engine is used to access the relational database and perform association queries and statistics.

9. An electronic device, characterized in that, Including: A processor and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Computer-executable instructions are stored in the computer-readable storage medium, and when the computer-executable instructions are executed by the processor, they are used to implement the method according to any one of claims 1 to 7.

Images