The different nature of data and queries demands for multiple data store solutions in order to approach the best possible fit to functional and performance needs. Columnar stores for simulated invoices, together with relational data and in-memory data sets for the interactive load and process of raw usage data, are the main data store components considered, to enable quicker data loading and high-performance analytics. Several times, the customer selection (which is an integral part of functional parameters) is defined as a sub-graph where links correspond to relations among customers based on relevant usage analysis; henceforth, graph database is enabling efficient customer selections when such criteria are focused.
For instance, a query example is formulated when the marketing manager wants to assess the applicability of different charging scenarios onto a customer segment. The customer segment is defined as a group of contracts which can be affected by or follow a specific set of subscribers. These contracts are related to each other based upon usage criteria, mainly the amount and frequency of calls between each other; hence, a subgraph within the call usage graph must be located to extract the segment of interest. The team wants to calculate the change into revenue -within a certain period defined as a specific selection of billing cycles – that could have happened (and will possible happen in the future) if the customers within the segment change their subscription package, what ever that is, to a newly proposed package which the team considers to introduce, as a response to a competitor’s move with a similar competitive plan. The case must be replicated for many new, hypothetical charging plans and the time to respond to the administration cannot be long enough.
The query will attempt to calculate the new revenue; for this, it will sum the actual invoices of contracts which are not selected, with the sum of the simulated invoices with the new scenario, only for those contracts which match the selection criteria. Selection of contracts is facilitated by graph queries; actual invoices data are stored in-memory for quick, interactive access and processing, while simulated invoices are in the columnar store so that analysis and comparison can efficiently scale. Similar scenarios with higher interactivity are required when a telecom sales agent wants to find a specific customer’s simulated invoices in order to respond to a specific question, while the customer is in front of him or at the other side of the line. Then, the in-memory storage for CDRs is quickly delivering the asked data so that they can be re-rated and new simulated invoices can be compared to actual invoices or other simulated invoices stored in the analytical columnar store.
The CoherentPaaS model will enable the use of different technologies under the same programming and transaction layer. Otherwise, the employment of so many data stores could be extremely complex. The most important benefits derived from this model are:
- Ability to utilize multiple datastores efficiently and transparently; until now, tariff simulation development avoided to involve multiple datastores, though it was clear that for certain cases, different datastores were more appropriate in order to achieve best enhanced performance. Involving different technologies should increase complexity and will require a unified framework and appropriate abstraction mechanisms to address all stores transparently; the need for a common query layer such as the CloudMdsQL becomes apparent.
- Ability to support interactive functions queries; a feature which using conventional approaches would introduce restrictive latencies, capitalizing on different data store capabilities and advantages shows greater promise overcoming those restrictions by introducing polyglot persistence and involving the appropriate data stores. For instance efficient load of selected usage can be addressed through the use of the in-memory data store solution.
- Ability to scale in cloud environments; support for increasing number of scenarios, number of billing cycles and number of customers will be sustainable, performance barriers will be lessen, and limiting factors will be mitigated, contributing to enhancing the upper bounds of the system.