{"id":3969,"date":"2015-07-31T07:49:23","date_gmt":"2015-07-31T07:49:23","guid":{"rendered":"http:\/\/www.odbms.org\/blog\/?p=3969"},"modified":"2015-07-31T07:49:23","modified_gmt":"2015-07-31T07:49:23","slug":"in-memory-database-technology-for-telecom-interview-with-manjul-maharishi","status":"publish","type":"post","link":"https:\/\/www.odbms.org\/blog\/2015\/07\/in-memory-database-technology-for-telecom-interview-with-manjul-maharishi\/","title":{"rendered":"In-Memory Database Technology for Telecom. Interview with Manjul Maharishi"},"content":{"rendered":"

“Our evaluation of IMDSs determined that eXtremeDB-64 IMDS outperformed other IMDSs in terms of performance and scalability.”–Manjul Maharishi.<\/strong><\/p><\/blockquote>\n

I have interviewed Manjul Maharishi<\/strong>, Vice President (telecom software development)<\/em> at Transaction Network Services<\/a>.
\nThey use In-Memory Database technology<\/em> for\u00a0managing\u00a0real-time community networks in the world.<\/p>\n

RVZ<\/p>\n

Q1. What is the mission of Transaction Network Services (TNS)? <\/strong><\/p>\n

Manjul Maharishi<\/strong>: Transaction Network Services manages many of the largest real-time community networks in the world, enabling industry participants to simply and securely interact and transact with other businesses, to access the data and applications they need, over managed and secure communications platforms. TNS\u2019 existing footprint supports millions of connections and access to critical databases, enabling its customers through a single connection, a \u201cone-to-many and many-to-many\u201d global platform, securely blending private and public networking.<\/p>\n

Q2. What is TNS\u2019s Carrier ENUM Registry? And for what is it useful for? <\/strong><\/p>\n

Manjul Maharishi<\/strong>: Carrier ENUM Registry<\/a> is a product offering for telecom carriers that provides information critical to the accurate routing and billing of inter-carrier communications, such as voice and mobile data services.
\nCarrier ENUM Registry addresses a challenge that is posed every time you place a phone call or send a text message: how, in the split second of latency that is deemed acceptable, will the call or message find the way to its recipient?<\/p>\n

As a solution, Carrier ENUM Registry makes available an up-to-date, portability-corrected image of the entire public dial plan as well as authoritative information sourced directly from the service provider that \u201cowns\u201d (in telecom parlance, has the \u201cright-to-use\u201d) a particular telephone number. This is provided in the form of two registries, or databases:<\/p>\n

\u2022 Number Identity Registry<\/em> is a massive repository of global telephone numbers and carrier-of-record information that identifies which service provider a telephone number was allocated to for end-user assignment. In response to lookups the registry returns a Carrier Identifier (which can be in the form of a Service Provider Identifier (SPID), and\/or a Mobile Country Code+Mobile Network Code(MCC+MNC)) and when available, the Location Routing Number (LRN) of ported and pooled numbers.<\/p>\n

\u2022 Network Routing Directory<\/em> is a multi-party shared registration system that furnishes service providers with sophisticated data-sharing capabilities featuring safeguard controls designed to uphold data-sharing policies. Using our secure portal service, providers self-administer data and selectively grant access, in whole or part, to trading partners (and vice versa).<\/p>\n

Q3. Who are the customers using Carrier ENUM Registry? <\/strong><\/p>\n

Manjul Maharishi<\/strong>: The customers are telecom carriers \u2013 large, small and in-between \u2013 worldwide.
\nThey are mobile, landline and IP-based, including some ISPs (Internet Service Providers<\/a>) and cable MSOs (multiple system operators<\/a>) that offer phone service, as well as \u201cpure\u201d VoIP providers. Most query the Carrier ENUM Registry deployment hosted at TNS\u2019 facility in the US, but some host the application and database on their own premises.<\/p>\n

Q4. What services do you support? <\/strong><\/p>\n

Manjul Maharishi<\/strong>: Carrier ENUM emerged as a service to connect the public switched telephone network (PSTN) and new IP-based networks, by resolving phone numbers to IP addresses and services. It also provided a bridge between IP-based carriers. For example, with a multi-vendor database of routes, users and phone numbers available, a caller on IP-based Network A could communicate with a user of IP-based Network B without routing calls across the PSTN (which would incur costs and may require avoidable transcoding).<\/p>\n

Over time, though, Carrier ENUM Registry has gained complexity along with new features, and does much more than bridging between carriers. Supported services now include number portability, IP-peering between telephone service providers, SMS\/MMS (aka \u201ctext messages\u201d) routing, unbundling of services (allowing messaging to be offered separately from voice, for example), customized views of data, routing based on time\/destination\/origination, and more. These services have added complexity to TNS\u2019 Carrier ENUM Registry business logic and have caused its databases to grow larger and the routing logic to become more complex.<\/p>\n

Carriers can pick and choose from the various Carrier ENUM Registry features, to solve their particular challenges.
\nOne of the biggest use cases in demand now is identifying the right carrier to terminate an SMS or MMS when number portability is involved in the host country.<\/p>\n

Q5. What kind of real-time performance demands does Carrier ENUM Registry need to satisfy?<\/strong><\/p>\n

Manjul Maharishi<\/strong>: To customers, we commit to providing a response from our system within 10 milliseconds for 95% of the queries. Please note that a single customer query can result in dozens to a couple of hundred individual table queries based on the routing logic and services subscribed. However, largely through the use of in-memory database system<\/a> (IMDS) technology for data management, we have been able to have a much lower variance in the query responses and a higher degree of predictability. Our typical average response to a customer query is less than 2 msec. These numbers only reflect the latency introduced by our platform, i.e. the time difference between when we receive the query and when we respond back.
\nThe network latency \u2013 the time when the query leaves the customer network and when they receive the response \u2013 is larger (typical US cross-country network latency is 60-100 msec). An industry norm for the maximum acceptable time from when a subscriber dials digits to when they hear a ringing tone back is ~150-200 msecs, beyond which the \u201cdead air\/silence\u201d becomes noticeable for the subscriber. However, for international calls, people do tend to be more tolerant of such post-dial delays.<\/p>\n

Q6. Can you give an overview of the system architecture and toolset used to handle the increasingly complex business logic and growing data volume?<\/strong><\/p>\n

Manjul Maharishi<\/strong>: In order to handle the growing amount of stored data, we use general-purpose off-the-shelf Linux servers. This allows us to take advantage of industry-wide gains in processing power, memory and performance, as well as eliminate any dependence upon specific vendors for a software\/hardware upgrade cycle. Currently, the systems are running on dual CPU, 6- and 8-core processors.<\/p>\n

For data management we use eXtremeDB-64<\/a>, the 64-bit edition of McObject\u2019s eXtremeDB In-Memory Database System <\/a>(IMDS). The system is architected such that each server stores the entire database, and customer queries are load balanced across a set of such servers. Accordingly, the platform is easily scaled by adding new servers as needed. Apart from offering this service as a cloud-based offering (\u201cCentral Replica\u201d), we also offer the service as customer-premise deployment model (\u201cLocal Replica\u201d) whereby the customers can gain from a much lower round-trip time (RTT) by avoiding network-latency. The TNS network operations center (NOC) monitors key performance indicators of our Central and Local Replica servers on a 24×7 basis, and we have agreements in place with our customers to scale up the platform by adding more servers if needed.<\/p>\n

With the performance provided by eXtremeDB-64, we haven\u2019t had a need to partition the data set in order to meet our commitments. We do use the database system\u2019s Patricia trie indices to reduce the number of lookups required on certain tables, and work through the business logic to narrow down the search results to a manageable number early in the business rules processing.<\/p>\n

In terms of development tools, we are developing in C++ using eXtremeDB\u2019s C\/C++ API instead of accessing via an SQL API, and this contributes to lower application latency. We develop software using Agile methodology with Continuous Integration that has nightly builds with a suite of automated tests executing during these builds. We also incorporate code coverage, leak detection and profiling as part of this Continuous Integration.<\/p>\n

Q7. Can you tell more about how Carrier ENUM Registry meets its real-time data access requirements? Did it move to in-memory database technology recently or has this always been a feature?<\/strong><\/p>\n

Manjul Maharishi<\/strong>: The system architecture keeps data needed for real-time queries in memory, where it can be accessed quickly. Early versions of Carrier ENUM Registry accomplished searches using in-memory database code developed in-house for the application. However, TNS recognized several years ago that with the increasingly complex queries and higher data volumes, Carrier ENUM Registry would be better-served by an off-the-shelf in-memory database system (IMDS) that provides flexibility while scaling to hundreds of millions and even billions of records. After researching IMDSs, we chose the 64-bit eXtremeDB-64 and the new Carrier ENUM Registry version incorporating eXtremeDB-64 launched in 2013.<\/p>\n

Currently, the system holds a master or archival data set in Oracle Enterprise DBMSs, with the data used for real-time lookups hosted \u201cdownstream\u201d in eXtremeDB-64. Each downstream server hosts the entire data set used by the application; this data set consists of three separate (i.e. with unique schemas and data) databases with a combined size of 120 GB.
\nTwo of the databases managed by eXtremeDB-64 on each server are \u201cpure\u201d in-memory databases while the third utilizes McObject\u2019s eXtremeDB Fusion<\/a> technology to include some persistent (on-disk) data storage.<\/p>\n

Q8. Why did you choose eXtremeDB-64 from the field of available IMDSs and what has been your experience been using it? <\/strong><\/p>\n

Manjul Maharishi<\/strong>: Our evaluation of IMDSs determined that eXtremeDB-64 IMDS outperformed other IMDSs in terms of performance and scalability. Among other test findings, TNS determined that eXtremeDB\u2019s performance exceeded 2 million queries per second with a 10 million-row database. When TNS upped the challenge by increasing the test database size 3000% (to 300 million records), eXtremeDB\u2019s responsiveness fell only minimally, validating the near-linear scalability results documented in McObject\u2019s published benchmarks<\/a>. TNS\u2019 platform for these tests consisted of Intel Xeon X5570 2.93 GHz hardware, with 8 cores and hyper-threading enabled, running Red Had Enterprise Linux 4, with 72 GB RAM.
\nUsing eXtremeDB-64 in production with Carrier ENUM Registry has borne out our expectations: the database system meets current needs while providing room for future growth in both database size and complexity of application features.<\/p>\n

Q9. You mentioned the use of the Patricia trie index in your database. Can you elaborate on the advantage it provides? <\/strong><\/p>\n

Manjul Maharishi<\/strong>: Support for the Patricia trie database index<\/a> is another key eXtremeDB-64 feature (along with in-memory data storage) that enables Carrier ENUM Registry to meet its performance goals. The name of this specialized index derives from \u201cPractical Algorithm To Retrieve Information Coded In Alphanumeric<\/a>\u201d and \u201creTRIEval\u201d. Unlike the widely used B-tree index \u2013 which can also be used for finding keys with a specified prefix but can require multiple iterations to find the longest prefix match if there are multiple prefix matches in the index \u2013 the Patricia trie excels in searching for the longest prefixes of a specified value.<\/p>\n

This approach meshes well with the unique nature of Carrier ENUM Registry\u2019s data, and its queries. Phone numbers serve as keys for the searches that are performed when a call is placed. The key is stored on individual numbers, blocks or ranges.
\nA block consists of phone numbers in a quantity ranging from 1,000 to 10,000. For example, it could be the number 703667 and four additional digits ranging from 0000 to 9999. A range is a subset of a block. The key would be applied to an individual number, for example, when that number was ported from another carrier and does not fall into a large block of numbers serviced by the company using TNS\u2019 application.<\/p>\n

In most of the cases, it is not known beforehand if the number being queried has been \u201cported out\u201d of a block or not, so the application (in the absence of the Patricia trie) would have to make multiple queries \u2013 starting with the most specific match and then dropping the least-significant digit one-by-one till a match was found. With the Patricia trie, there is only one iteration within the original query, which is much less taxing in performance terms and greatly simplifies the application logic.<\/p>\n

Q10. Are there other aspects of your approach to data management that you\u2019d like to mention?<\/strong><\/p>\n

Manjul Maharishi<\/strong>: The hybrid storage capability of eXtremeDB Fusion, mentioned above, gives us useful flexibility. eXtremeDB Fusion enables the developer to specify in-memory or persistent storage for record types within a database. Storing data on a hard disk drive (HDD) or solid state drive (SSD) has two benefits: it reduces memory demands, thereby helping us stay within servers\u2019 maximum memory capacities (this was our primary reason for using eXtremeDB Fusion), and byte for byte, persistent storage is less expensive than memory.<\/p>\n

We first used eXtremeDB’s hybrid storage to manage a large set of meta-data for mobile handsets such as device types, model names, dates of activation, etc. This information is used by a non-call-processing application and is looked up less frequently than Carrier ENUM Registry’s real-time routing data, so we were okay with the higher latency and variance in response that is introduced by disk-based access.<\/p>\n

We are now expanding our use of hybrid storage to add some additional information (such as mobile device information and capabilities) to stored phone numbers, in order to enhance the communication between two subscribers – for example, by enabling features such as HD-voice, Rich Communications Services (RCS), etc. These features can result in substantially increasing the database size and memory footprint required, and eXtremeDB Fusion allows us to easily configure which portions of the data set are kept in memory and which ones are kept on persistent storage with a configurable subset cached in memory \u2013 thus allowing us to store some of the less heavily used dataset in SSDs or regular HDDs, while still maintaining the high performance required for the bulk of the transactions.<\/p>\n

——————-
\nIn his role as Vice President of Telecom Software Development at TNS, Manjul Maharishi<\/strong> is responsible for overseeing architecture, design, development and testing for all of the Products and Services offered by TNS\u2019 Telecom Services Division. These include several massively sized Telecom Databases (serving Number Portability, Toll Free, Call Routing and Calling Name services), 3G\/4G Roaming Hubs, associated Clearing and Settlement services and Data Analytics.<\/p>\n

Prior to joining TNS, Manjul has held senior technical management positions at VeriSign and Lucent Technologies working in similar areas, including building the industry\u2019s first widely deployed Softswitch while at Lucent Technologies.
\n<\/em>
\n——————-<\/p>\n

Resources<\/strong><\/p>\n

–\u00a0eXtremeDB Case Study: Industry Trend Toward Algorithmic Trading<\/a><\/p>\n

–\u00a0eXtremeDB Embedded Database Version 6.0<\/a><\/p>\n

Related Posts<\/strong><\/p>\n

–\u00a0Gartner Market Guide for In-Memory DBMS<\/a><\/p>\n

–\u00a0Looking beyond the DBMS: Towards Holistic Performance Optimization for Enterprise Architectures<\/a><\/p>\n

–\u00a0Gaining An Extreme Performance Advantage<\/a><\/p>\n

–\u00a0Database Persistence, Without The Performance Penalty<\/a><\/p>\n

Follow ODBMS.org on Twitter: @odbmsorg<\/a><\/strong><\/p>\n

##<\/p>\n","protected":false},"excerpt":{"rendered":"

“Our evaluation of IMDSs determined that eXtremeDB-64 IMDS outperformed other IMDSs in terms of performance and scalability.”–Manjul Maharishi. I have interviewed Manjul Maharishi, Vice President (telecom software development) at Transaction Network Services. They use In-Memory Database technology for\u00a0managing\u00a0real-time community networks in the world. RVZ Q1. What is the mission of Transaction Network Services (TNS)? Manjul […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[839,843,275,836,837,370,840,842,841,838],"_links":{"self":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/3969"}],"collection":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/comments?post=3969"}],"version-history":[{"count":10,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/3969\/revisions"}],"predecessor-version":[{"id":3989,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/3969\/revisions\/3989"}],"wp:attachment":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/media?parent=3969"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/categories?post=3969"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/tags?post=3969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}