Main-Memory Databases for Real-Time Telecom Applications *

Transcription

1 Main-Memory Databases for Real-Time Telecom Applications * Fabiana F. Prabhakar Lehigh University CSE 492 Independent Studies Abstract Disk-based database systems are widely used, offering a great set of functionalities perfectly suited for most kinds of applications. However, when high performance is the priority, such databases are unable to produce satisfactory results. Telecom applications demand high performance especially for their real-time applications. Location management is one of many telecom applications that fall into this category. Currently, location information is managed by custom-developed applications requiring the use of proprietary API s and custom data models to achieve the performance expectations. This paper summarizes some possible approaches to handle the location problem in the telecom industry using main-memory database systems. Such systems have been proven able to deliver high response-time, throughput and reliability. 1) Introduction Disk-based database systems offer a very reliable storage option but are not able to attain the high performance required by a real-time application. Every access to these databases incurs network latency, disk latency and buffer manager overhead. Telecommunication applications are well-know for the need of high-performance real-time responses for their transactions. Main-memory database systems [[6], [11], [12], [13] have been designed to achieve this goal. These systems offer most of the features of a disk-based database while having an architecture designed to manipulate main-memory resident data. DataBlitz TM [5][6] is a Lucent Technologies product based on the Dali [4] research prototype developed at Bell Labs. During this independent study, other systems such as TimesTen[11] and Berkeley DB[12] were also taken in consideration, but the majority of this work refers to DataBlitz TM implementation. * Prepared as a part of the independent study conducted during the Fall of

2 This paper attempts to show how main-memory systems are design to achieve the reliability of a traditional database without sacrificing its performance. The flexibility is also an important feature that is successfully achieved by the current implementations. The remainder of this paper is structured as follows. Section 2 describes the wireless infrastructure and discusses the use of main-memory databases for location management in such networks. Section 3 describes the storage manager architecture and its functionalities compared to file systems and disk-based databases. Section 4 lists the existing requirements for a mobile cellular system. Section 5 shows some numbers from experiments comparing the performance of DataBlitz and a commercial disk-based database and Section 6 concludes. 2) Wireless Infrastructure Roaming management is one of the most important functions in a mobile network. The main operations in roaming management are registration, the process whereby a mobile subscriber informs the system of its current location, and location tracking, the process of locating the subscriber during a call delivery. The roaming management strategies are supported by two main databases, the Home Location Register (HLR) and the Visitor Location Register (VLR). When a user subscribes to the services of a Service Provider, such as Verizon, Cingular or any other currently in business, a record is created in the system s database, called the HLR. The HLR stores the mobile subscriber profile information such as services and identity number. Whenever a subscriber is visiting a network out of its home location range, the corresponding VLR of the visited location queries the HLR for the subscriber information. This process is called registration (Figure 1) and it happens whenever a user moves to a different coverage area. The VLR also stores the mobile subscriber profile, but this information is kept just while the user is roaming within its network range. In addition, The HLR sends a deregistration message to the previous VLR and keeps track of the user s current location. At this point it is clear that the simple action of a mobile user moving through different locations triggers a great number of database accesses. Figure 1 - Database Accesses for Mobile Subscriber Registration 2

3 Different approaches have been proposed to reduce the cost of deregistration. In implicit deregistration, obsolete VLR records are not deleted until the database is full. This prevents unnecessary repetition of the registration processes in case of subscribers moving in the border of two distinct VLR coverage areas. To reduce registration traffic, a pointer forwarding scheme was proposed. When an MS moves from one VLR to another, a pointer is created from the old VLR to the new VLR. The HLR is not updated. So, when the HLR needs to locate the MS, the pointer chain is traced. This method must be designed with care in order to control the length of the forwarding chain. A very long trace operation could degrade the call setup performance substantially. To originate a call, the mobile subscriber first contacts the Mobile Switching Center (MSC) in the visiting network. The call request is forwarded to the VLR for approval. If the call is accepted, the MSC sets up the call following the standard call setup procedure. It is also important to consider that each call delivery process may require an access to the HLR for the user location, and an extra query to the VLR which will provide routing information back to the HLR. The routing is actually provided by the MSC using the VLR information. Currently, both HLR and VLR are implemented as customized stand-alone applications that cater to the high performance requirement of a real-time system. On the other hand, maintenance costs are high and cannot be amortized across other applications within an organization. This paper focuses on a new architecture for both HLR and VLR based on main-memory databases. This architecture will be more flexible and easier to maintain while offering great performance and reliability. 3) Storage Manager For simplicity, a main-memory database, often named a storage manager, could be compared to a file system with the following characteristics: performance of main-memory applications, the flexibility of a file system and the reliability of a disk-resident database. File systems offer fairly rudimentary storage services. They allow applications to read or write any kind of data, but make no guarantee about how simultaneous updates to the same region of a single file are handled. Applications that need to make several independent changes to different files get no help from the file system, and must handle the concurrency themselves. In case of a system crash, most file system make no promises about the possible level of recovery of unsaved data. Relational database systems, on the contrary, offer a much more reliable set of data manipulation features, such as concurrency control and recovery through logging and checkpointing. If an application needs to make a change in a table, it simply starts a transaction, accesses the data, and ends the transaction, whenever it is done, by a commit or a rollback operation. The database makes sure that, once the transaction is committed, the data is not lost in any circumstance. It also manages multiple transactions accessing the same information and guarantees a well defined concurrency policy among the transactions. 3

4 2.1) Flexibility of a File System File systems are very effective data storages where files are organized according to the kind of data they store. Similar information is normally stored in the same file while different files store unrelated data. This principle is applied to main-memory databases which use a file structure to store their information in a very uniform and well-distributed fashion Database Files Storage Managers also manage a set of files, the database files, the basic storage units for a mainmemory database. A user/application can map as many files as needed. In addition, different applications running in the same address space can access the same file (the concurrency is also addressed and will be listed in section 2.2.1). On UNIX systems this can either be accomplished through memory mapped files or through shared memory. Database files can also be locked into memory for performance. Reference or static data tables could easily benefit from such feature because their information rarely changes over time. A great example is a help desk application that accesses a zip code translation table responsible to link zip codes to addresses. For such example it is easy to notice that this table will have a very low update rate, its contents almost never changing. The system data is also stored in database files keeping the storage uniformly organized. Another advantage is that users running applications in the same memory space as the Storage Manager can access the files directly avoiding expensive system calls which is a great performance factor. Inside a database file, smaller units called items are stored. An item can represent any data unit such as objects, for an object oriented implementation, and tuples, for a relational database point of view. This feature provides a high level of flexibility to the storage manager. It means that virtually any kind of data that could be organized in single smaller units could also be stored and managed by a main-memory database. Headers normally store valuable information about an item and could benefit from a greater level of protection. By storing the item header in a separated partition from the item data, the system is able to offer the header a higher degree of protection. The item header can be used to store additional information such as lock information, access control information, compression/decompression information and extra points for versioning implementation. 2.2) Reliability of a Disk-Resident Database A storage manager is responsible for storing and managing the data guaranteeing a high level of consistency. Disk-resident databases present ACID properties by using mechanisms such as In databases, ACID stands for Atomicity, Consistency, Isolation, and Durability. They are considered to be the key transaction processing properties of a DBMS. In practice, these properties are often relaxed somewhat to provide better performance. 4

5 concurrency control, logging and recovery. The main-memory databases must also implement these concepts while taking into account its high performance requirements Concurrency Control Concurrency control is an essential feature of any data manager system. It is important to guarantee that two concurrent operations will not mistakenly interfere with each others results. Databases are not an exception and independently of their architecture they must offer a reliable concurrency control scheme. There exist numerous concurrency control algorithms that could be taken in consideration when building a main-memory database system. The following is a list of some concurrency control mechanisms used in existing main-memory systems that have been shown very efficient. Pre-commit: whenever a transaction is ready to commit, also called the pre-commit phase, the lock is released giving other transactions the opportunity to start running. When designing a real-time application, it is important to keep in mind that a higher level of parallelism among transactions might have a great impact in the performance. This is the assumption of the pre-commit solution. Item level locking: the item header can store a bit of locking information. Whenever a transaction is accessing the item, the locking bit is set and no other transaction will access such information. When the transaction is done, it re-sets the locking bit. Keeping the looking mechanism directly in the memory greatly improves the overall performance. Since locking is kept at the item space, a more atomic level, the whole file doesn t need to be locked when just parts of it are being updated. This provides the system a fine locking while offering higher parallelism. Use of a mutex: mutexes are typically used to ensure mutual exclusion among operations accessing shared data structures. Operating System semaphores require system kernel calls, which allow the system to schedule the operations in the CPU. They usually involve several instructions, what makes OS semaphores usually quite expensive. Mutexes, in the contrary, are implemented in user space. When requesting a lock, a process performs the following operation as a single unit: check if the semaphore is free, and update its status to not free. The cost of this acquisition is very low compared to a system call Recovery A system failure may be hardware crash or operating system crash. In both cases, a total loss of RAM information is assumed and recovery is required. Logging and checkpointing performed during regular system execution allow the recovery process to restore the database to a consistent state after a system failure. In main-memory databases disk I/O is only needed for persistence of the log and must be designed with care to avoid impact in the performance of the system. 5

6 A number of recovery algorithms for main-memory environments have been proposed in the literature. The proposed schemes attempt to reduce logging and flushing to disk by exploiting the fact that in a main-memory database pages are not flushed to disk during normal processing, and logs for active transactions fit in the main-memory. For example, the recovery algorithm proposed in [9] works as follows. Logging information is kept in main-memory, with some exceptions: When a transaction is ready to commit, it sends the redo log to disk; All active transactions write both redo and undo logs to disk during a checkpointing. Note that physical undo information is moved to disk only during a checkpoint. Thus, physical undo log records are never written to disk for transactions which take place between checkpoints. Recovery starts from the last complete checkpoint entry in the log and all redo logs are processed. When the end of the log is reached, all incomplete transactions (those without commit or rollback records) are rolled back. It also uses ping-pong checkpointing in which two database images are maintained on disk and successive checkpoints write to alternate copies. This eliminates the need for write-ahead logging and reduces the number of flushes to disk. By keeping the persistent log as a collection of mostly redo entries, the recovery process becomes very effective. Instead of having to process the log multiple times in order to compare conflicting entries (redo and undo for the same data item), the recovery system is able to bring the system to a consistent state after just one log scan. Another great technique is the use of fuzzy checkpointing. It permits updates to start once the checkpoint record has been written to log, and before the modified buffer blocks are written to disk. A buffer block must not be updated while its being output to disk, although other buffer blocks may be updated concurrently. Fuzzy checkpointing and Hot Spares are used in order to minimize checkpointing interference with normal transaction processing. Hot Spares are described in section 4.2) Consistency Great performance improvement is achieved by having user processes sharing the same memory space with the system data. However it also adds risks of data corruption by stray pointer in the code, for example. A checksum (also known as codeword) can be added to each item s header. The item becomes a protection region. When data in an item is updated, its checksum is also updated. When a wild write or other addressing error updates data, with high probability the checksum value computed from the item will no longer match the value maintained for that item. This technique ensures that corrupted data is not propagated to subsequent transactions. The integrity of the data is always tested before it is written to disk, so the disk copy is never corrupted. Whenever an inconsistent state is verified, the system is able to perform a partial recovery. The partial recovery will recover the damaged file based on the persistent file copy and 6

7 the log information. This process is analogous to the recovery previously described but for a single file in the database. Schemes for computing codeword for data are well-know and in [16] several codeword-based techniques are investigated. The first scheme, Read Prechecking, verifies that the codeword matches the data each time it is read. The Data Codeword scheme, a less expensive variant of Read Prechecking, proposes asynchronously auditing the codewords. A variant of this scheme, Data Codewords with Deferred Maintenance, makes use of the database log to perform the updates to the codewords, reducing contention which may be caused by updating or auditing codewords. 4) Existing Requirements Whenever a new architecture is proposed, current issues that might affect its feasibility must be addressed. The following section lists some very important requirements for most telecom applications that are strongly related to call delivery, such as the location management discussed through the course of this paper. 4.1) Scalability Telecom is a highly competitive business. According to the Cellular Telecommunications Industry Association [10], there are currently approximately million mobile subscribers in the U.S in Imagine they are all roaming causing the HLR and VLR to be queried/updated massively. International roaming is also an issue, especially for continents like Europe were it is much more common and easy to travel to a different country. So, scalability is of great importance for such systems. The current implementations have efficiently addressed scalability by partitioning the HLR according to some key-attributes (such as the MS identity number). Data for each key is clustered at a single site that can point which site contains a given subscriber information. This is achieved by creating mapping tables that also can be used to balance information among the databases (no partition should be responding for a much greater number of subscribers). 4.2) High Availability Hot Spares High availability is essential for a Telecommunication system and it can be successfully achieve by the use of Hot Spare systems. Hot Spares receive log records from the primary system, and use these log records to keep their database synchronized. If the primary system fails, the Hot Spare is ready to take over with almost no transaction loss. The system continues to operate with minimal or no downtime. Another great feature is the ability to perform checkpointing at hot spares, eliminating interference of checkpoints with normal processing. 7

8 However, communications cost may be a consideration. Keep in mind that the Hot Spares are the backup mechanism for the primary system and most probably are placed in remote locations for security reasons (in this case if a natural disaster happens in the location were the primary resides, the hot spare could take over). 4.3) Use of Sophisticated Algorithms during call set-up Number translation: 800/888 numbers these are logical numbers that are mapped to real numbers during call set-up. In addition, the company may want to route their calls to different physical numbers according to day of the week or time of the day. Number Portability - it is a wireless consumer's ability to change service providers while still keeping the same phone number. Before the number portability was implemented, the network could route a given call just by looking at the telephone number. All the numbers in a range were known to belong to a certain service provider. After the number portability, the network must keep translation tables in order to find which provider currently owns a given number Fraud detection: A fraud detection system typically stores the customer s regular calling patterns (or signatures). Such signatures might show that a specific customer makes calls more frequently after 6PM. Or, that another customer makes a high number of international calls. Algorithms are designed depending on the kind of fraud that has been targeted. These algorithms use the customer signature during call-setup and look for fraud behaviors for that particular customer. Checking fraudulent activities can be expensive and must be also taken in consideration Rates discount (for pre-paid customers) Post-paid cellular customers are the majority in the US. But this is not the reality especially in the third world countries. Pre-paid customers are of great value in these countries forcing the companies to offer more elaborate plans, including discounts to attract such customers. A pre-paid phone call involves extra algorithms to retrieve the customer s balance and apply discounts in real-time. Such operations can impact the call-setup timeline and must be taken in consideration in the proposed architecture Route selection 8

9 Companies have different agreements for roaming charges. Imagine Verizon doesn t have its own network infrastructure in North Carolina. But it is important for Verizon to be able to offer coverage for its customers when roaming in that state. Verizon makes two different agreements with two distinct service providers: Cingular offers $0.02 per minute of its network usage; T-Mobile offers $0.03 per minute of its network usage. It might seem a small different but take in consideration that for every ten minutes call Verizon is losing $0.10. So, in such situations, the network must use routing algorithms that are able to select the best possible routes. 5) Performance: Number Lookup Benchmark The Figure 2 was extracted from [14] and represents a performance comparison between DataBlitz TM and a Disk-based System. Lookup Update Relational Level Collections Level Relational Level Collections Level Benchmark Characteristics: 250,000 records of 200 bytes each; 12 byte key consisting of three fields (phone number); Lookups retrieve entire tuple for a given phone number; Updates modify 62 non-key bytes of the tuple for a telephone number; Disk-based system has data fully buffered in main memory; Transaction features active: logging, locking, etc. Figure 2 - DataBlitz System Speedup over Disk-based System The benchmark compares Disk-Based Systems performance to two DataBlitz s layers of abstraction (Figure 3). The highest level, the Relational Manager offers an interface to access data stored as relational tables. The collection level (Heap File/Indexing) provides support for 9

10 collections and indexing abstraction. The heap file is abstraction for handling a large number of fixed-length data items, and is implemented as a thin layer on top of the Storage Manager allocator. Figure 3 - Layers of Abstraction in DataBlitz [5] 6) Conclusion Main-memory databases deliver real-time performance by changing the assumptions around where the data resides. By managing data in memory, and optimizing data structures and access algorithms accordingly, database operations execute with maximum efficiency, achieving dramatic gains in responsiveness and throughput, even compared to a fully cached RDBMS. Some principles involved in a main-memory database architecture are: Direct access to data: the database is mapped into the virtual address space of the process, allowing users to efficiently access the information through pointers to the memory location. No inter-process communication for basic system services: concurrency control and logging are provided via shared memory instead of calling external services. This eliminates expensive remote procedure calls significantly improving performance. Reduced volume of persistent logging: most of the logs are written to the memory. Just transactions that are ready to commit write a redo log to disk, reducing disk access considerably. Telecom applications such as location/roaming management could greatly benefit from a mainmemory database architecture. Both HLR/VLR store a limited amount of information for each mobile user which makes their architecture very simple to manage. With an appropriate set of database files and a robust storage manager, HLR/VLR databases could become more flexible and manageable. Such implementation would most probably not impact their performance and make them easily integrated to the remaining systems. 10

11 7) References [1] Y-B. Lin and I. Chlamtac, Wireless and Mobile Network Architectures, Wiley, [2] Y-B. Lin and I. Chlamtac, Mobility Management in [1]. [3] T. Imielinski and H. F. Korth, eds., Mobile Computing, Kluwer, [4] H. V. Jagadish, D. Lieuwen, R. Rastogi, A. Silberschatz and S. Sudarshan. Dali - a high performance main memory storage manager. In Proceedings of the Very Large Database Conference (VLDB), Chile, [5] G. D. Baulier, P. Bohannon, A. Khivesara, H. F. Korth, R. Rastogi, A. Silberschatz, and S. Sudarshan, The DatablitzTM Main-Memory Storage Manager: Architecture, Performance and Experience, The {VLDB} Journal, pp701, [6] The DatablitzTM (Dali) Home Page; [7] G. D. Baulier, S. M. Blott, H. F. Korth, and A. Silberschatz, Sunrise: A Real-Time Event- Processing System, Bell Labs Technical Journal, Jan-Mar 1998 [8] S. Blott and H. F. Korth, An Almost-Serial Protocol for Transaction Execution in Main- Memory Database Systems, Proc. 28th International Conference on Very Large Data Bases, 2002 [9] H.V. Jagadish, A. Silberschatz, and S. Sudarshan. Recovery from main-memory lapses, Proc. of the International Conf. of Very Large Databases, [10] Cellular Telecommunications Industry Association; ( [11] Oracle TimesTen Products and Technologies, An Oracle White Paper, 2005; [12] Oracle Berkeley DB Product Family; High Performance, Embeddable Database Engines; [13] Cloudscape Home Page; [14] DataBlitz Main Memory Database System - Approaching Zero Latency with High Reliability - Hank Korth [15] Silberschatz, Korth, Sudarshan, Database System Concepts, 5th edition, McGraw Hill [16] P. Bohannon, R. Rastogi, S. Seshadri, A. Silberschatz, S. Sudarshan, Using Codewords to Protect Database Data from a Class of Software Errors. Published in Proceedings of the International Conference on Data Engineering,