Building Subscriber Databases Using Mysql Cluster

Guide to Developing Subscriber Databases with MySQL Cluster Delivering Personalized Services on Next Generation Networks

A MySQL Technical Whitepaper

Copyright © 2009, Sun Microsystems

Table of Contents

Page #

1. Executive Summary..........................................................................................................................3 2. Introducing The MySQL Cluster Database..................................................................................... 4 3. Why Use MySQL Cluster CGE for Subscriber Databases?........................................................... 5 3.1.Benefits of MySQL Cluster to Subscriber Databases....................................................6 4. Linear Scalability in a Shared-Nothing, Distributed Database.....................................................7 4.1.Distribution Awareness in MySQL Cluster ....................................................................8 5. Creating Tables Partitioned by Subscriber-ID.............................................................................. 11 6. Improved Scalability with Distribution-Awareness...................................................................... 12 7. Conclusion...................................................................................................................................... 13 8. Additional Resources .................................................................................................................... 14 9. Glossary.......................................................................................................................................... 15

Copyright © 2009, Sun Microsystems

Page 2

1.

Executive Summary

Call it integration. Call it convergence. Call it simply the next step in the evolution of the communications industry. But Communications Service Providers (CSPs) and Telecoms Equipment Manufacturers are feeling the effect of new trends and new technologies - both the new possibilities that they create and the challenges they present. At the center of it all is the issue of data management. How well you manage your data determines how efficient you can be, how flexible you can be, how nimbly you can create and offer new services, and how effectively you can mine customer information for added insight. In today's communications marketplace, the killer application to drive increased revenue and ARPU is the one most valued by each individual subscriber – the reality is that personalization and targeting of unique services to individual subscribers ultimately drives adoption and monetization. The only way to deliver highly personalized communication services is to create and maintain a unified, 360 degree view of the subscriber. Not just their identity and billing information, but also their service entitlements, preferences, presence, usage patterns, contacts, device information, etc. All of this subscriber information exists today, but is scattered across multiple data stores, including HLR/HSS, CRM systems, network elements, AAA (RADIUS, DIAMETER, etc) systems, LDAP Examples of Telecoms Applications using servers and portals. MySQL Cluster: Subscriber Databases (HLR/HSS) Consolidating this data into fewer centralized databases is critical to accelerate – service delivery, reduce operational expense and enhance personalization and – Telecoms Application Servers targeting. – AAA & LDAP Databases – IMS Services In this paper we describe how MySQL Cluster Carrier Grade Edition (CGE) can – Intelligent Network Nodes be used to build scalable, highly available, geographically replicated Subscriber – IPTV & VoD Databases. We show how user-defined partitioning and distribution keys help a – Location & Presence Services subscriber database to scale performance linearly with cluster size, while – Application Stores & Portals maintaining the benefits of a relational database, accessed via an industry – Soft-Switches standard SQL API1. – VoIP Communications Service Providers’ (CSPs) subscriber systems have extreme requirements on the underlying database, including: –

99.999% availability

–

Scalability to handle millions of subscribers

–

Strict low latency bounds on data access.

In addition to these challenges, subscriber databases need to be easy to integrate into existing systems and run on low-cost commodity off-the shelf (COTS) hardware. MySQL Cluster CGE is a distributed, highly available real-time database, which is deployed in some of the most demanding subscriber database systems found in the telecommunications industry. Every day, MySQL Cluster is handling many millions of subscribers, providing unrivaled performance and quality of service, while meeting the need for increasing scale as CSPs extend their reach globally. “The selected database would need to initially handle the information of 7 to 8 million subscribers and to subsequently scale to handle more than 50 million subscribers! MySQL Cluster won the performance test hands-down and it fitted our needs perfectly. The combination of accessing data in memory and backing it up on disk makes MySQL Cluster an ideal solution for our subscriber database platform. Moreover, competing alternatives offered inferior performance at a higher cost”.

By exploiting the distributed architecture and real time design of the MySQL Cluster database, and coupling these with advanced techniques to enable distribution awareness in applications, it is possible to build highly scalable and highly available real-time subscriberservices on low cost commodity hardware and open source software.

Alain Chastagner, Systems Manager, Alcatel-Lucent

1

In proprietary subscriber systems, data typically has to be offloaded to an external relational database in to perform complex SQL queries, e.g., for accounting or other BSS purposes.

Copyright © 2009, Sun Microsystems

Page 3

2. Introducing The MySQL Cluster Database MySQL Cluster is a real-time, distributed database combining the flexibility of a highly available relational database with the low TCO of open source. Featuring a “shared-nothing” distributed architecture with no single point of failure, MySQL Cluster is designed to deliver 99.999% availability demanded by telecommunications services. MySQL Cluster's real-time design delivers predictable, millisecond response times with the ability to service tens of thousands of transactions per second. Support for in-memory and disk based data, automatic data partitioning with load balancing and the ability to add nodes to a running cluster with zero downtime allows linear database scalability to handle the most unpredictable telecoms services and applications. MySQL Cluster is already proven in the toughest telecommunications environments delivering higher database throughput and faster response times at 10x lower cost than proprietary clustered shared-disk databases2, with the added benefit of running on commodity hardware and operating systems. Customers include Alcatel Lucent, Cisco, Deutsche Telekom, Ericsson, Nokia Siemens Networks, Nortel, Telenor and UTStarcom.

Figure 1: The MySQL Cluster architecture eliminates any single point of failure To learn more about the MySQL Cluster architecture, refer to the MySQL Cluster Architecture and New Features whitepaper posted at: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster7_architecture.php “Telenor has found MySQL Cluster to be the best performing database in the world for our applications”. Peter Eriksson, Manager of Network Provisioning, Telenor

2

http://www.mysql.com/why-mysql/case-studies/mysql-cs-alcatel.php

Copyright © 2009, Sun Microsystems

Page 4

3. Why Use MySQL Cluster CGE for Subscriber Databases? A subscriber database aims to consolidate relevant subscriber information, including among other things: address, account status, profile, preferences, contacts, device data and the provisioned services. An illustrative example of MySQL Cluster Carrier Grade Edition managing subscriber data for multiple communication services can be seen in the figure below.

Figure 2: MySQL Cluster CGE powers the subscriber database used by multiple telecommunications services Referring to the figure above, MySQL Cluster CGE implements specific capabilities to build highly scalable and reliable subscriber services: NDB API provides real-time access to data stored within the MySQL Cluster database. The NDB API is also easily integrated with Subscriber-style APIs, such as LDAP, via a series of drivers developed by the leading open source directory vendors and communities, including OpenDS and OpenLDAP3. NDB API provides specialized features, which provide significant performance optimizations not available in the SQL API or traditional ODBC / JDBC connectors. These include: –

Batching of operations inside transactions to optimize network usage, and significantly improve transactional throughput

–

An adaptive-send buffer at clients to optimize use of the network medium

–

Distribution-aware transactions, through partitioning by key, distribution keys and controlling parallelism in scans (discussed in detail in sections 4 and 5 of this Guide).

Real-Time SQL API using a MySQL Server is a simple and efficient means of enabling a range of applications to access subscriber data stored in MySQL Cluster. Provisioning requests, AAA (Authentication, Authorization and Accounting) protocols such as RADIUS and Diameter, in addition to a range of BSS applications can make use of the SQL API to provide standard access to data stored in MySQL Cluster.

http://www.mysql.com/products/database/cluster/features.html#data_ldap

3

Copyright © 2009, Sun Microsystems

Page 5

The MGM API is the management interface to MySQL Cluster, and can be used to monitor and maintain a cluster. Typically systems such as a Home Subscriber Server control, monitor, analyze and manage a subscriber database using the MGM API, and these systems, in turn, are integrated into an OSS. Geographic Replication is supported through MySQL’s replication of an active cluster to a remote cluster, which may be active or standby. As Geographic Replication in MySQL Cluster supports Conflict Resolution and Detection, most users run active/active configurations where each cluster handles a sub-set of the traffic. MySQL replication handles the catastrophic event of a site failure, where monitoring systems can fail-over subscriberrelated traffic from one site to another. Redundant MySQL servers can be installed to handle the failure of a replicating MySQL server. MySQL servers implement replication using row-based replication, new in MySQL Server 5.1. In addition to handling Disaster Recovery scenarios, MySQL Cluster's geographic replication capability can be used to distribute data physically closer to the subscribers that are being served, thereby reducing affects of network latency and improving response times.

3.1. Benefits of MySQL Cluster to Subscriber Databases Some of the benefits of MySQL Cluster Carrier Grade Edition for subscriber databases include: o

Consolidation of many subscriber data sources managed by different services to a unified database, where a single, consistent copy of the subscriber data can be accessed by all services and systems. This reduces new service introduction time and costs, as integrating new services require less interface development and testing.

“Based on our previous experience and its extensive user base within the telecommunications industry, selecting MySQL to power the Open IMS Core project’s HSS was the obvious choice”.

Peter Weik, Senior Researcher, Fraunhofer Institute FOKUS

o

High Performance with a Shared-Nothing, Parallel Database that provides real-time access to in-memory subscriber data (2 to 5 millisecond latency for both reads and writes) and can be scaled by adding additional resources on-line and by storing less frequently accessed data on disk.

o

99.999% availability which is achieved in three levels with MySQL Cluster CGE: o

Distributed, shared-nothing architecture with the database partitioned across multiple server hosts in the cluster;

o

Synchronous replication of data between multiple database nodes for purposes of redundancy;

o

Recovery (check-pointed) data persisted to disk;

Availability levels can be further extended by implementing Geographic Replication, which serves to replicate data off-site to a remote cluster. o

Self-Healing of data nodes with sub-second fail-over times, and an optimized node recovery protocol that automatically resynchronizes data for MySQL Cluster data nodes after they have been restarted.

o

Distribution-awareness enabled in MySQL Cluster Carrier Grade Edition with the partitioning of tables by subscriber identifiers, and by using the subscriber identifier as part of the primary key when accessing data to ensure that reads/writes are localized to the data node(s) containing the subscriber data. This topic is covered in detail in the section entitled “Distribution Awareness in MySQL Cluster”

o

Open Source licensing and distribution ensures that many users help improve the quality of MySQL software, along with valuable feedback from MySQL Community. Transparency of the code also enables developers of subscriber-based services to fully understand and optimize their applications for MySQL Cluster.

o

Standards-based allows vendors of telecommunications solutions to easily integrate their subscriber applications with MySQL Cluster CGE using their preferred database-independent Subscriber API, e.g. LDAP or SQL. Access to subscriber data can be performed either on a database independent subscriber API or directly using the native NDB API.

o

Database size can be increased significantly using disk-based storage. It is possible to decide, per-table or even per-column, which attributes reside in memory and which ones reside on disk. For example in IMS or portal applications, BLOBs can be stored on disk.

Copyright © 2009, Sun Microsystems

Page 6

o

Flexible relational database supports mature relational tools for analyzing and mining customer data via an SQL interface to the MySQL Cluster database, or alternatively, to a replicated copy of the real time data held in tables in a non-production database. Convergence means that you must have all of the data for your services available centrally, allowing the BSS to analyze the data either online or by automatically archiving real-time data to a data warehouse using Geographic Replication.

o

Faster time to market for CSPs with existing relational models for subscribers and service data. MySQL Cluster Carrier Grade Edition provides a smoother migration to a subscriber-centric model, compared to proprietary approaches.

4. Linear Scalability in a Shared-Nothing, Distributed Database Scalability of any system is measured by the ability to increase throughput in proportion to increases in resources powering the system (i.e. as more hosts are added, or as memory / CPU resource is increase in existing hosts). As telecommunications services become more feature-rich and gain adoption, the number of subscribers, and potentially the amount of data stored for each subscriber, can grow rapidly. To ensure a good quality customer experience, it is vital that the subscriber database is able to scale throughput (performance) while maintaining ultra-low response times and continuous availability.

Figure 3: Achieving Near-Linear Scalability In a shared-nothing, distributed database architecture, all data is partitioned, including indexes to data, using hash indexes on the primary key, or a sub-component of the primary key. In this architecture, primary key operations (singletuple operations on subscribers) are extremely efficient. Increasing the number of primary key operations in a transaction (i.e., increasing the batch size) typically brings linear improvements in performance, often up to network bandwidth saturation limits. In subscriber-centric databases, another data access pattern involves multiple-tuple subscriber-specific operations. To improve the performance of this access pattern, MySQL Cluster offers user-defined partitioning to allow the partitioning of tuples using subscriber identifiers. This enables index scans operations for subscriber-specific data to be sent directly to the data node containing the subscriber-specific data, and allowing them to scale linearly with the cluster’s size. Both full table scans and joins do not have linear scalability properties. To improve system performance, it is best to minimize their use. If they are scheduled in a controlled manner, full table scans and joins can still be included as operations in a scalable, subscriber system. Additionally, the data from a MySQL Cluster database can be automatically replicated to a near-real time copy stored in a different storage engine (on a different host) that is designed to handle scans and joins much more efficiently.

Copyright © 2009, Sun Microsystems

Page 7

For larger cluster configurations (of 16 data nodes and up), another factor to consider is the global maintenance and recovery protocols (e.g., Global Checkpoints and Heartbeats4) that consume a very small fraction of network bandwidth and which increase slightly with a cluster’s size (from a very low base). These protocols cause a small divergence from full linear scalability for 16-node cluster’s and up. To put a cluster size in context, a four-node system on COTS quadcore 64-bit hardware can easily process 125,000 replicated operations/second5 with a response time of less than 5 milliseconds.

4.1. Distribution Awareness in MySQL Cluster Applications accessing MySQL Cluster CGE either via the NDB API or SQL must have: –

Replication transparency, meaning applications are not aware of how many replicas of the data are stored in a cluster. The cluster automatically manages the synchronous replication of data based on the number of replicas specified and the number of data nodes in the cluster;

–

Partition transparency so applications do not know on which partition a particular tuple is stored;

–

Access transparency which hides network details of how applications read/write data to the cluster.

Partition and access transparency allows developers to write applications that are independent of the cluster size. So, if more data nodes are added to the cluster, applications continue to work as before.

Figure 4: Scalability impacted by absence of Distribution Awareness As illustrated in the figure above, in a 4-Node cluster with no distribution awareness, there is a 50% chance of transaction starting on a Data Node in the wrong Node Group (a node not containing the data), resulting in unnecessary inter-node group communications. In this example, the transaction is a batch6 of two operations (a read 4

See the MySQL Cluster Documentation: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html http://blogs.sun.com/hasham/entry/mysql_cluster_7_performance_benchmark 6 Increasing the number of operations in a transaction produces large performance gains, as it reduces the number of times NDB API clients send transactions to Data Nodes, better utilizing network bandwidth. 5

Copyright © 2009, Sun Microsystems

Page 8

and an update of subscriber data) which is submitted to a data node in the cluster using a ‘nearest data node heuristic’ or round-robin policy7. In this case, we assume that the transaction is sent to a data node which is not in the Node Group containing a copy of the subscriber’s tuples. This incurs unnecessary extra inter-Node Group network traffic, as the Transaction Coordinator (TC) needs to coordinate the 2-Phase Commit Protocol (2PC) for the update operation between the Local Query Handlers (LQHs) on the Data Nodes for Primary and Secondary Partitions.

Figure 5: Index Scans from MySQL Server have Parallel=0 (i.e., maximum parallelism) Similarly, in Figure 5, we can see how an index scan that is sent to a MySQL Server causes the scan to be executed on all of the data nodes in the cluster. The TC sends the index scan to the LQHs of all nodes, which execute the index scan locally, and then return the results back to the MySQL Server. However, we can reduce the number of index scans significantly by partitioning the database in such a way that all relevant tuples belonging to a specific subscriber are located within a single node. The index scan will then only execute on that data node. An example of this can be found in Figure 6.

7

See NDB-API Documentation: http://dev.mysql.com/doc/ndbapi/en/overview-selecting-tc.html

Copyright © 2009, Sun Microsystems

Page 9

Figure 6: Partitioning the Database for Distribution Awareness In the figure above, where tables that are partitioned by the same distribution key (here the ‘uid’ column), tuples from those tables with the same distribution key value are stored on the same Primary Partition. With this background, we can now discuss how developers can write NDB API applications that are distributionaware. Such applications eliminate inter-Node Group network traffic for primary key operations and optimize the number of index scans started in a cluster. Distribution-aware applications are, however, still partition and access transparent, i.e., they are still cluster-size independent. Distribution-awareness is achieved by: o

User-level partitioning with the PARTITION BY KEY syntax that allows for the specification of a distribution key (i.e., a subscriber-ID) for a schema8;

o

Controlling the partition where a transaction is started in the cluster by supplying a distribution key value (i.e., a subscriber-ID) when starting the transaction;

Controlling the level of parallelism for an index scan ensures that the index scan is only started on the data node that contains the primary copy of the subscriber-specific data9. An MD5 hash function (in the NDB API and SQL API) uses the distribution key to map tuples in a schema to partitions, as shown in the figure above. The distribution key maintains partition transparency, as applications do not know on which partition the tuples are stored. Distribution key values determine on which data node a transaction is started, and they do not break access transparency, as applications only know that the transaction has started on the partition containing tuples with the distribution key value. Similarly, when starting an index scan, if we know that the data for the index scan is on the same data node where the transaction started, then we can set the level of parallelism to ‘1’, as shown in Figure 7. The NDB API allows applications to set distribution key values when starting transactions and the level of parallelism for index scans.

8

9

Partition by key is available in MySQL Cluster CGE The parallel parameter for index scans is ignored and set to maximum if the scan results are sorted.

Copyright © 2009, Sun Microsystems

Page 10

Figure 7: Optimizing Index Scans with NDB API As illustrated above, when using the NDB API, a distribution key value is set for the Transaction, and an Index Scan’s level of parallelism is 1. The Index Scan executes on the Primary Partition for the subscriber data. For existing relational subscriber databases, MySQL Cluster's approach represents a painless transition to a subscriber-oriented database compared to hierarchical approaches, such as LDAP and DAP for X.500. MySQL Cluster CGE provides the performance benefits of distribution-aware operations, while still maintaining partition and access transparency, as well as offering the advantages of the relational database model. Similar benefits from distribution awareness can be realized when accessing data through the SQL interface where the MySQL Server can parse the query and internally make the appropriate calls to the NDB API.

5. Creating Tables Partitioned by Subscriber-ID We can now work through a simple example of a subscriber database with an associated IMS service. First, we define a simplistic schema for subscriber profiles, partitioned by subscriber-ID (‘uid’ column in the schema definition) as follows: CREATE TABLE subscriber_profile ( uid INT NOT NULL, name VARCHAR(255) NOT NULL, addr VARCHAR(255) NOT NULL, PRIMARY KEY(uid) ) ENGINE=NDB PARTITION BY KEY (uid); PARTITION BY KEY allows the specification of the distribution key for the table as a list of zero or more column names. Where no column name is specified as the distribution key, the table's primary key is used (as would have been the case in the above table). If no partition key or primary key is specified for the table, the table is reorganized using a “hidden” primary key as the table's new partitioning key. Columns specified as the distribution key do not have to be integer values, since the MD5 hashing function supplied by MySQL guarantees an integer result regardless of the column data type. The distribution key can also be a composite key, consisting of more than one column. Now, we define an IMS service that uses the subscriber database, called Push-to-Talk (PTT). PTT is a “walkie-talkie”style service, where users push a button on their mobile device to instantaneously set up a one-way voicecommunication channel to one or more users.

Copyright © 2009, Sun Microsystems

Page 11

CREATE TABLE service_pushtalk ( uid INT NOT NULL, ip_addr INT NOT NULL, credit INT NOT NULL, PRIMARY KEY (uid) ) ENGINE=NDB PARTITION BY KEY (uid); PTT also maintains a history of calls made by users, defined in the following pushtalk_history schema. Here, the primary key is a composite of the uid and group_id columns, although the distribution key is defined on the uid column, i.e., the schema is still partitioned by subscriber-ID. CREATE TABLE pushtalk_history ( uid INT NOT NULL, group_id INT NOT NULL, duration long NOT NULL, PRIMARY KEY (uid, group_id) ) ENGINE=NDB PARTITION BY KEY (uid); NDB-API is required to write distribution-aware applications that can start transactions with the primary key or index scan operations on the node containing the subscriber data. Some sample code is given in Figure 7 above.

6. Improved Scalability with Distribution-Awareness In this section, we evaluate the performance improvement gained with user-defined partitions, distribution key values, and optimal parallelism for index scans. In the following figure, we can see how supplying a distribution key value when starting a transaction (containing subscriber-specific operations), guarantees the transaction will start on the Data Node containing the subscriber data (probability = 1). However, when no distribution key value is supplied, the probability that the transaction will start on a Data Node in the same Node Group as the Primary decreases with the increasing size of the cluster. For a transaction containing Primary Key operations, in an 8-node cluster, this can lead to a performance drop of roughly 20%. This demonstrates that, for large cluster sizes, a reasonable performance improvement can be gained by using distribution key values for transactions containing individual subscriber operations.

Probability of Transaction Starting in Node Group containing Subscriber Data is '1' for Distribution Key 1 0.8 Probability

0.6 No Distribution Key

0.4

Distribution Key

0.2 0

2

4

8

16

Number of Data Nodes

Figure 8: For Linear Scalability, Start Transactions with a Distribution Key Value.

Copyright © 2009, Sun Microsystems

Page 12

Figure 9 shows the extra overhead in starting a transaction containing an index scan operation on the wrong Data Node increasing as the size of the cluster increases. This demonstrates that particularly for increasing cluster sizes, a significant performance improvement can be gained by using distribution key values to start transactions and control parallelism when performing index scans for subscribers.

Num of Nodes executing an Index Scan remains constant, using Distribution Key and Parallelism=1 16 14 12 10 Num Scans 8 6 4 2 0

No Distribution Key, Parallel=max With Distribution Key, Parallell=1

2

4

8

16

Number of Data Nodes

Figure 9: For Linear Scalability with Index Scans, use a Distribution Key Value and Parallel=1 to start the Transaction and Index Scan on the Data Node that contains the Subscriber Data.

7.

Conclusion

MySQL Cluster Carrier Grade Edition is a perfect fit for Subscriber Databases due to its high performance, high availability, and ease of integration with database-independent Subscriber APIs or existing relational or directory-based subscriber models. Many of its features are aimed specifically at meeting the requirements for Subscriber Databases deployed with CSPs, including: –

Distribution-Awareness through the partitioning of tables by subscriber identifiers, and by using those identifiers when accessing subscriber data to ensure that reads/writes are localized to the data node(s) containing the subscriber data;

–

Standards Based, open source database allows vendors and users of subscriber data management solutions to easily integrate their applications with MySQL Carrier Grade Edition using their preferred database-independent Subscriber API, e.g., LDAP, SQL, C++, Java, HTTP, etc;

–

LDAP drivers enabling MySQL Cluster CGE to be accessed via the LDAP protocol;

–

High Performance with a Shared-Nothing, Distributed Database that provides real-time access to in-memory subscriber data with just a few milliseconds latency for reads and writes, and can be scaled out by adding additional resources or by storing data on disk;

–

99.999% Availability achieved by synchronously replicating data across active nodes in the cluster, with recovery data being asynchronously written to disk;

–

Self-Healing of data nodes with sub-second fail-over times, and an optimized node recovery protocol that automatically re-synchronizes data across re-starting data nodes;

–

Geographic-Replication for site-level redundancy;

Copyright © 2009, Sun Microsystems

Page 13

–

Relational Database technology supports mature tools for analyzing and mining customer data via an SQL interface;

–

Low TCO through the ability to scale on low cost, commodity hardware and open source economics.

When deploying MySQL Cluster Carrier Grade Edition as a centralized Subscriber Database to handle Subscriber Profiles and Service-related Data, it is easier and more efficient to roll out new services, while being sure that the database system can meet extreme performance and availability guarantees. Major Telecom Equipment Manufacturers and CSPs are already realizing the benefits of building Subscriber Databases using commodity hardware and open source components.

8.

“Service availability is the number one requirement for our customers. MySQL Cluster delivers the high availability that enables us to guarantee continuous services to our subscribers. This has had an immediate impact in significantly improving customer satisfaction, and has reduced the cost of operating our network”.

Lars-Ake Norling, CTO (B2), Telenor

Additional Resources

Alcatel-Lucent uses MySQL Cluster Carrier Grade Edition to Handle over 60 million Subscribers: http://www.mysql.com/why-mysql/case-studies/mysql-alcatel-casestudy.php Open IMS Core Project uses MySQL as HSS: http://www.mysql.com/why-mysql/case-studies/mysql_cs_IMS_Core.php BT Plusnet Achieves Continuous Availability of Subscriber AAA Services with MySQL Cluster and FreeRADIUS: http://www.mysql.com/why-mysql/case-studies/mysql_cs_plusnet.php MySQL Cluster Architecture and New Features Whitepaper: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster7_architecture.php MySQL Cluster Evaluation Guide: http://www.mysql.com/why-mysql/white-papers/mysql_cluster_eval_guide.php Integrating LDAP with MySQL Cluster: http://www.mysql.com/why-mysql/white-papers/mysql_wp_openldap-scaling-guide.php Integrating AAA with MySQL Cluster: http://www.mysql.com/why-mysql/white-papers/mysql_wp_ha_auth_account.php MySQL Cluster on the web: www.mysql.com/cluster Getting Started with MySQL Cluster: http://www.mysql.com/products/database/cluster/get-started.html

Copyright © 2009, Sun Microsystems

Page 14

9. Glossary o o o o o o o o o o o o o o o o o o o o o o o o o o o o

2-Phase Commit (2PC) AAA (Authentication, Authorization, Accounting) Application Programming Interface (API) Average Revenue Per User (ARPU) Business Support Systems (BSS) Carrier Grade Edition (CGE) Communication Service Provider (CSP) Customer Relationship Management (CRM) Directory Access Protocol (DAP) Home Subscriber Server (HSS) Home Location Register (HLR) IMS Application Servers (AS) IP Multimedia System (IMS) Java Database Connectivity (JDBC) Lightweight Directory Access Protocol (LDAP) Local Query Handler (LQH) Network Database (NDB) Next Generation Network (NGN) Operations Support Systems (OSS) Open Database Connectivity (ODBC) Prepaid Account Manager (PAM) Push-to-Talk (PTT) Remote Access Dial-In User Service (RADIUS) Service Control Point (SCP) Session Initiation Protocol (SIP) Total Cost of Ownership (TCO) Transaction Coordinator (TC) Video on Demand (VoD)

Copyright © 2009, Sun Microsystems Inc. MySQL is a registered trademark of Sun Microsystems in the U.S. and in other countries. Other products mentioned may be trademarks of their companies.

Copyright © 2009, Sun Microsystems

Page 15