METHOD AND APPARATUS FOR
TRANSACTION PROCESSING IN A
DISTRIBUTED DATABASE SYSTEM
BACKGROUND OF THE INVENTION 5
1. Field of the Invention
The present invention relates generally to a method and system for processing transactions in a distributed database system. 10
2. Background of the Invention
With the increasing demand for the rapid processing of transactions, as well as the ever-increasing size of databases that these transactions must be processed against, many have turned to distributed database systems to accomplish their :5 goals. For purposes of this disclosure, the term "distributed database" shall refer to a database system in which data is located in more than one physical location and/or in more than one database. In some cases, data may be distributed such that certain data is located in only one database while 20 other data is located on more than one database. Usually, more than one client or user needs to access the data at the same time. Typically, many users require simultaneous or near simultaneous access. This presents a problem in that only a limited number of access requests can be processed 25 at a time.
Access requests to databases generally are one of two types. The first is termed a "query" and is associated with a request to read data from the database(s). The second is termed an "update" and is associated with a request to write 30 data to the database(s). For purposes of this discussion, both types of requests (and combinations thereof) shall be referred to generally as a "transaction." It is to be understood, however, that a transaction may involve one or more of either or both types of requests. 35
Various problems exist with distributed database systems. For example, in some cases multiple clients or users may request access to particular data at the same time. Typically, each data server may process one transaction (or a series of 4Q transactions) at a time. Thus, if multiple requests are made to one server at the same time, not all of the transactions can be processed at the same time. When this occurs the latter requests are generally queued or have to be resubmitted at a later time. This causes undesirable delays in the processing 4J of these transactions. Other factors also contribute to delays in processing such transactions. As a result, in some cases, one or more data servers may be idle while another is backlogged with multiple requests. This is obviously an inefficient use of resources. 5Q
In an attempt to address these types of problems, some systems have used different schemes to attempt to balance the distribution of requests among the multiple servers. According to one arrangement, particular clients or users are permanently associated with particular servers. The theory 55 behind this design is that by randomly limiting the number of clients accessing a particular data server, some minimization of the bottleneck effect may occur. According to another approach, multiple copies of particular data are stored in more than one database. 60
These schemes, however, generally suffer from at least three drawbacks. Firstly, many of the systems electing the first scheme are architected so that particular clients are "hard-wired" to particular servers. In such a case, clients in the system will not generally have access to the full comple- 65 ment of servers available in the system which are capable of processing the particular transaction. As a result, uneven
load distribution may still occur since a server which is free to service a request may not be called upon to do so since the requesting client may not have access to the free server.
A second major drawback to both of the prior art data distribution schemes described above is the significant time and cost of processing information which is necessary to determine the best way to allocate data requests. In some cases, particularly when the number of transactions to be processed is low and the complexity of the allocation scheme is high, the system performs more efficiently without a real-time decisional process.
Thirdly, in the case of distributed database systems containing redundant data (e.g. the second scheme), the availability of secondary storage (i.e. disk storage) is significantly decreased by virtue of the redundancy of the data. Often data redundancy is not a possibility because of severe limitations in storage capacity within an enterprise.
One particular industry having a great need for storage and manipulation of large amounts of data is the telecommunications industry and particularly the cable television industry. Cable system operators typically maintain large databases containing a variety of subscriber, product and billing information. Typical classes of information managed by cable companies include subscriber accounts, available products and their pricing structure, physical assets and their functionality and marketing data. It is often desirable to distribute this information across a network of databases whether or not they are located at the same physical location.
The processing requirements for cable based systems can be staggering. For example, it may be necessary to provide 24 hour a day, 7 day a week service for a subscriber base of millions or tens of millions of subscribers. In addition, such a system may be called upon to execute hundreds or thousands of transactions per second (UPS). In addition, such systems may be required to support thousands of interactive users operating client terminals (e.g. Customer Service Representatives (CSRs)) many of which may be concurrent users. It is farther anticipated that the average customer record may soon be on the order of 15 kilobytes requiring a total database capacity of about 225 Gigabytes (assuming 15 million subscribers).
Atypical prior art distributed database system that may be employed by a system operator includes a plurality of transaction generators or terminals which may be operated by CSRs to acquire access to data contained within the system. Each of the transaction generators communicates either directly or through a communications controller with a particular associated server or servers. Communication techniques and protocols which are known in the art are employed to allow the transaction generators to communicate with the servers. For example, EtherneTM may be used when both client and server are PC-based processors.
In prior systems, difficulty arises when access to data residing at differing locations is required. This places a burden on the CSR (or a transaction generator in general) because it may impose additional processing requirements to keep track of what data is accessible to a particular CSR and which is not. Additionally, if certain data is needed, but not accessible to a particular CSR, it may be necessary to determine where the data is located and which CSR may have access to that data.
An example of such a system exhibiting the drawbacks described above may include four data processing centers to support a national cable system operator. Each of four geographical regions in the United States (e.g. Northeast, Southeast, Midwest and West) may be supported by one of