WO2002091244A1

WO2002091244A1 - System and method for clustering database caches

Info

Publication number: WO2002091244A1
Application number: PCT/US2002/014375
Authority: WO
Inventors: Vijayakumar Perincherry; Erik Richard Smith
Original assignee: Appfluent Technology, Inc.
Priority date: 2001-05-09
Filing date: 2002-05-08
Publication date: 2002-11-14

Abstract

A system and method for selecting a subset of the objects stored in a database(104) to be copied to a cache(106) of a cache cluster(110). Database requests received by the database system(104) each identify a target, where the target includes at least one of the objects stored in the database(104). Requested objects are sorted into a plurality of groups based on similarities among the targets. Objects are selected from at least one of the groups for storage in the cache cluster(110) where objects selected from a particular group are stored in the same cache(106).

Description

System And Method For Clustering Database Caches

Background

Field of the Invention

The present invention relates generally to computer databases and more particularly to a system and method for selecting database objects to be cached in a cache cluster. Discussion of the Related Art

Many computer applications today utilize a database to store, retrieve, and manipulate information. Simply put, a database refers to a collection of information organized in such a way that a computer program can quickly select desired pieces of data. For example, an individual might use a database to store contact information from their rolodex, such as names, addresses, and phone numbers, whereas a business entity might store information tracking inventory or customer orders.

Databases systems include hardware that physically stores the data, and software that utilizes the hardware's file system to store the data and provide a standardized method for retrieving or changing the data. A database management system (DBMS) provides access to information in a database. This is a collection of programs that enables a user to enter, organize, and select data in a database. ith respect to hardware, database machines are often specially designed computers that store the actual databases and run the DBMS and related software.

The DBMS accepts requests for data (referred to herein as database requests) from an application program and instructs the operating system to transfer the appropriate data. Database requests can include, for example, read-only requests for database information (referred to herein as informational database requests) and requests to modify database information (referred to herein as transactional database requests). A database request can include a single command or a series of commands which instruct the DBMS to extract and possibly manipulate specific data elements from the database and to generate and present the results of this manipulation. For example, database requests can be expressed in structured query language (SQL). Computer applications commonly access information stored in a database, where the application logic communicates with the DBMS via a network in a client/server relationship. In this configuration, the application logic is a client to the DBMS server. The application logic submits database requests to the DBMS over the network according to the network protocol. The DBMS processes received database requests, and responds to the application logic when called for by the request.

The performance of a database system can be improved by adding a database cache. Traditional databases are characterized by high data storage capacity. By comparison, a database cache functions as a complement to the database, having lower storage capacity but faster operation. A database cache provides rapid access to a relatively small subset of the information stored in the database. The faster response time of the cache can provide an increase in performance for those database requests that are handled by the cache.

However, the limited storage capacity of database caches constrains both the number and size of data objects that may be stored therein. For example, some applications may require rapid access to a large number data objects. Though these data objects may individually be relatively small in size, in the aggregate they may overwhelm the capacity of a database cache. This can result in a high rate of objects being swapped between cache and database, which can significantly degrade performance. Other applications, by comparison, may require rapid access to a fewer number of much larger data objects. The limited capacity of a database cache might allow for the storage of only a small number of these large data objects.

Some of the limitations of database systems having a single cache can be overcome by using multiple caches that operate in a coordinated fashion to provide rapid access to database objects. Such an arrangement of two or more database caches will be referred to herein as a cache cluster. The combined resources of the cache cluster provide for the storage of larger or more numerous database objects. However, the effectiveness of the cache cluster will be determined, in part, by the manner in which database objects are selected for storage within the cluster. An improved system and method is needed for handling this selection in order to achieve efficient operation of the database system. Furthermore, database designers would benefit from a flexible arrangement wherein the number of caches in a cache cluster can be easily adjusted to increase or decrease rapid access storage capacity to satisfy the needs of a particular application. The arrangement would be particularly beneficial if such modifications to the cache cluster were transparent to the application logic. An improved system and method is therefore also needed wherein caches can be easily added to or removed from the cluster.

Summary of the Invention

The present invention addresses these needs by providing a system and method for selecting database objects to be cached in a cache cluster. The database system receives database requests each identifying a target that includes at least one of the objects stored in the database. According to the present invention, objects are sorted into a plurality of groups based on similarities among the targets. Objects are selected from at least one of the groups for storage in the cache cluster, where the selected objects associated with a particular group are stored in the same cache.

According to an aspect of the present invention, a controller selects database objects to be stored in particular caches in the cache cluster. The controller maintains an image of the cluster, including the contents of each cache within the cluster. The controller provides this image data to a cache driver that is called by the application logic when sending requests to the database system for processing. The cache driver uses the image data to determine which cache(s) within the cluster can service a particular request. The controller also updates the image data in the cache driver whenever caches are added to or removed from the cache cluster. However, the application logic need not be concerned with changes made to the cluster configuration, since the cache driver handles the selection of an appropriate cache to process the request. As a result, changes to the configuration of the cache cluster are transparent to the application logic.

Brief Description of the Drawings

The present invention is described with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.

FIG. 1 depicts a digital network environment wherein an application accesses data objects stored in a database via a network. FIG. 2 is a flowchart that describes the selection of objects for caching in a cache cluster according to an example embodiment of the present invention.

FIG. 3A depicts an example set of database requests and an example grouping of these requests according to an example embodiment of the present invention. FIG. 3B depicts an example initialization of groups 1 through 3 to zero.

FIG. 3C depicts the makeup of the example groups after examination of database request 1.

FIG. 3D depicts the makeup of the example groups after examination of database request 2. FIG. 3E depicts the makeup of the example groups after examination of database request 4.

FIG. 3F depicts the makeup of the example groups after examination of database request 5.

FIG. 3G depicts the makeup of the example groups after examination of database request 7.

FIG. 3H depicts the makeup of the example groups after examination of database request 9.

FIG. 4 describes the operation of sorting objects into groups in greater detail according to an example embodiment of the present invention FIG. 5 depicts a parallel cache configuration according to an example embodiment of the present invention.

Detailed Description

The present invention provides a system and method for selecting objects stored in a database to be cached in a cache cluster. Database requests received by the database system each identify a target, where the target includes at least one of the objects stored in the database. Requested objects are sorted into a plurality of groups based on similarities among the targets. Objects are selected from at least one of the groups for storage in the cache cluster, where objects selected from a particular group are stored in the same cache.

The present invention includes one or more computer programs which embody the functions described herein and illustrated in the appended flowcharts. However, it should be apparent that there could be many different ways of implementing the invention in computer programming, and the invention should not be construed as limited to any one set of computer program instructions. Further, a skilled programmer would be able to write such a computer program to implement the disclosed invention without difficulty based on the flowcharts and associated written description included herein. Therefore, disclosure of a particular set of program code instructions is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer program will be explained in more detail in the following description in conjunction with the remaining figures illustrating the program flow. Overview

FIG. 1 depicts a digital network environment 100 wherein an application 102 accesses data objects stored in a database 104 via a network 120. The performance of database 104 is enhanced with the addition of a cache cluster 110 that includes two or more caches 106. Application 102 generates database requests for database 104. Each database request identifies one or more objects stored in database 104 that are needed to successfully process the request. These objects are referred to individually as target objects and collectively as the target of a database request. A subset of the objects stored within database 104 are cached in cache cluster 110. Cache cluster 110 selectively handles those database requests identifying target objects that are cached in cache cluster 110.

Application 102 can represent any computer application that accesses database 104, such as a contact manager, order tracking software, or any application executing on an application server connected to the Internet. Database 104 represents computer software that utilizes the database hardware's file system to store database information and provide a standardized method for retrieving or changing the data. Database 104 includes a DBMS 112 that represents a collection of programs that enables a client to enter, organize, and select database information. DBMS 112, in response to a database request, instructs the operating system (not shown) to perform the desired oρeration(s) on the appropriate data. According to an example embodiment of the present invention, database 104 (and cache cluster 110) store database information as relational data, based on the well known principles of Relational

Database Theory wherein data is stored in the form of related tables. Many database products in use today work with relational data, such as products from INGRES, Oracle, Sybase, and Microsoft. Other alternative embodiments can employ different data models, such as object or object relational data models. Network 120 can represent any communications network such as a local area network (LAN), a wide area network (WAN), the Internet, a satellite communications network, a wireless network, or any combination of the above.

Cache cluster 110 provides rapid access to a subset of the database information stored in database 104. Each cache 106 in cache cluster 110 processes database requests from a connection established by a client. The faster response time of cache 106 provides an increase in performance for those database requests that can be handled by the cache. According to an example embodiment of the present invention, cache 106 represents a high performance computer application running on a dedicated machine. For example, the cache's architecture can be based on a main memory database (MMDB). An MMDB provides the ability to process database requests orders of magnitude faster than traditional disk based systems. As will be apparent, other cache architectures may be used. Further, cache 106 may also include a secondary disk based cache (not shown) to handle database requests that are too large to fit in main memory. The database information stored in database 104 and cache cluster 110 can be broken down into various components, wherein the components can be interconnected or independent. Depending upon their functionality and hierarchy, these components are referred to within the relevant art as, for example, tables, columns (or fields), records, cells, and constraints. These components are collectively referred to herein as objects (or database objects).

FIG. 2 is a flowchart 200 that describes the selection of objects for caching in cache cluster 110 according to the present invention. In operation 202, objects stored in database 104 are sorted into groups based on similarities among target objects. In general, objects that tend to be requested together (i.e., objects that tend to appear together in targets of database requests) are considered to be similar and are therefore grouped together. In operation 204, objects are selected from the groups formed in operation

202 for caching in cache cluster 110. One or more objects from each group can be selected, up to and including all the objects within a particular group. According to an example embodiment of the present invention, those objects selected from a particular group are stored in the same cache 106. By grouping objects that are similar in the same cache 106, the odds of finding all of the objects necessary for a particular database request in a single cache 106 are increased. This is a desirable outcome because otherwise multiple caches 106 must be accessed to service a single database request in the event that no single cache 106 can service the request (or, alternatively, the request can be sent to database 104 rather than cache cluster 110 for processing). FIG. 3 A depicts an example set of database requests and an example grouping of these requests. Ten database requests are shown, along with the target objects identified by each request. Note that the target associated with each object can include one or more objects. For example, the target associated with database request 1 includes four objects (A, B, C, and D) whereas the target associated with database request 6 includes 1 object (F). As described above with respect to operation 202, objects are sorted into groups based on similarities among target objects. For example, database requests 1 and 2 are not similar because they do not share any of the same target objects. Database requests 1 and 3 are similar, because the target objects associated with request 3 are a subset of the target objects associated with request 1. According to the principles of the present invention, this similarity between requests 1 and 3 make it more likely that the target objects associated with these requests will be grouped together.

FIG. 3A also depicts an example sorting of objects into three groups. Group 1 includes objects A, B, C, D, and I. This indicates that these objects tended to appear together in targets of database requests. For example, objects A and B appear together in requests 1, 3, 4, and 10. Similarly, objects E, F, G, H, and I are grouped together because these objects tended to appear together as targets of database requests. According to an example embodiment of the present invention, the same object can be included within multiple groups, such as where a particular object tends to appear together with other objects in different groups. For example, object I in included within all three groups because object I tends to appear with objects from all three groups. As described above with respect to operation 204, objects from each of these groups are selected for storage in cache cluster 110, with the objects associated with a particular group being stored in the same cache 106.

For example, assume that all the objects within each group are selected for caching in operation 204. Further assume that cache cluster 110 includes three caches 106 (106A, 106B, and 106C). Consistent with the principles described herein, each group of objects can be stored in one of the caches 106. Cache 106A stores objects A, B, C, D, and I. Cache 106B stores objects E, F, G, H, and I. Cache 106C stores objects I, J, K, and L. As a result of this grouping, most of the database requests can be satisfied by a single cache 106, i.e., all of the target objects required by a database request are available in a single cache 106. Database requests 1, 3, 4, and 8 can be sent to cache 106A for processing; database requests 2, 5, and 6 can be sent to cache 106B for processing; and database requests 7 and 9 can be sent to cache 106C for processing. As will be apparent, this grouping is desirable because each of these database requests can be processed by a single cache 106 without requiring that each cache 106 store all of the target objects. By contrast, database request 10 cannot be satisfied by a single cache because none of the caches contain all of the target objects (A, B, G, H). In these circumstances, the database request can be sent to multiple caches 106 (e.g., caches 106A and 106B) or forwarded on to database 104 for processing.

According to another example embodiment of the present invention, objects from two or more groups can be stored in a single cache 106. If cache cluster 110 in the previous example includes two rather than three caches, according to this example embodiment group 1 can be stored in cache 106 A and groups 2 and 3 in cache 106B. Sorting Objects Into Groups

FIG. 4 describes operation 202 in greater detail according to an example embodiment of the present invention. In operation 402, the groups are initialized prior to sorting the objects. According to this example embodiment of the present invention, a group is defined in terms of the collection of all target objects associated with all of its constituent database requests. Operation 402 can include, for example, determining an appropriate number of groups and setting initial group populations. The number of groups can be set equal to the number of available caches 106 in cache cluster 110. Alternatively, the number of groups can be set to reflect known groupings of the objects to be sorted. For example, if the database operator has knowledge that the objects stored in database 104 commonly access certain groups of objects, the number of groups can be initialized to reflect the number of known groups. Further, the populations of the groups can be initialized to zero (i.e., no objects initially populating the group). Alternatively, as before, the population (as well as the number) of the groups can be initialized to reflect known groupings of objects to be stored. FIG. 3B depicts an example initialization of groups 1 through 3 to zero.

In operation 404, the similarity between the target of the current database request and each of the groups initialized in operation 402 is determined. Similarity between a target and a group is measured as a function of the proportion of the target objects that are contained within the group. According to an example embodiment of the present invention, the following expression is used to compute a similarity 5:

5 =pe ^B where p is the proportion of target objects included in the group, e is the base of the natural logarithm, and B is the total amount of data (in bytes) represented by the objects not included in the group. Other alternative formulations are also contemplated within the scope of the present invention, such as simply using the proportion of target objects included in the group. Alternatively still, weights can be associated with the proportion and the data size to reflect the relative importance of each of them.

In operation 406, the target of the current database request is included within those groups determined to be similar to the target. Target objects not already present in the groups determined to be similar are added, effectively redefining these groups to include all target objects contained within the target. According to a first example embodiment of the present invention, operation 406 is limited to selecting only the most similar group for inclusion of the target. As a result, the target objects are only included within the group having the highest similarity to the target.

According to second example embodiment of the present invention, all groups having a similarity that meets a specified similarity threshold are selected in operation 406. The target may therefore be included in some, none, or all of the groups, depending upon the similarity determinations. In the event that none of the groups have a similarity satisfying the similarity threshold, the target may not be included in any of the groups. Alternatively, in the event that the highest similarity measure does not satisfy the similarity threshold, the target can be included in an empty group if one of the groups initialized in operation 402 has not yet been populated with objects. If no empty groups are available, the target can simply be included within the group having the highest similarity.

Operations 404 and 406 are repeated for each database request as they are generated by application 102. As will be apparent, the population of the various groups will vary over time as more database requests are examined. Groups may be added or deleted to reflect changed circumstances, such as where a cache is added or removed from cache cluster 110. The database requests associated with a deleted group can be distributed amongst the remaining groups on the basis of any of the similarity measures described above. Furthermore, objects can also be removed from groups over time. For example, the composition of the groups can be reevaluated over time, where objects having relatively low scores can be dropped. As another example, the length of time since the last request for a particular object can be monitored, so that objects that become stale can be pruned from the group. Consider again the example database requests and groups depicted in FIG.

3A. The three groups are initialized in operation 402 prior to examining any database requests, as shown in FIG. 3B. Examining database request 1 in operation 404, there is no similarity between the target (A, B, C, D) and the three empty groups. In operation 406, the target is included within group 1 (chosen arbitrarily from groups 1 through 3) since open groups are available. FIG. 3C depicts groups 1 through 3 after examination of database request 1, where group 1 has been redefined to include objects A, B, C, and D. Repeating operations 404 and 406 for database request 2, the target (E, F, G, H) has no similarity to group 1 because they do not share any common objects, and no similarity to empty groups 2 and 3. The target is therefore included within group 2 (chosen arbitrarily from groups 2 and 3) since open groups are available. FIG. 3D depicts groups 1 through 3 after examination of database request 2, where group 2 has been redefined to include objects E, F, G, and H. Repeating operations 404 and 406 for database request 3, the target (A, B, D) is determined to be completely similar to group 1 since all of the target objects are included within the group, and completely dissimilar to group 2 since they don't share any common objects. There is no need to redefine group 1 because all of the target objects are already included within the group. The group definitions therefore remain unchanged after examination of database request 3. Upon examining database request 4, the target (A, B, I) is determined to be similar to group 1 (2 out of 3 elements are common to both) and dissimilar to group 2 (no common elements). Assuming that the target is sufficiently similar to group 1 (e.g., the similarity satisfies a similarity thresholds), group 1 is redefined to include object I, as shown in FIG. 3E.

Alternatively, if the target is not sufficiently similar to group 1, the remaining empty group could be redefined to include the target objects. A similar outcome is reached upon examination of database request 5, where object I is added to group 2 based on the similarity between the target (E, H, I) and group 2 (shown in FIG. 3F). Database request 6 has a target that includes a single target object (object F).

In this circumstance the target is going to be completely similar to any group that includes this single object. As will be apparent, targets having a single target object do not provide any additional grouping information, and will not result in the redefinition of any groups (unless the target object is not included in any existing group and an empty group is available, in which case the empty group can be redefined to include the object).

Upon examining database request 7, the target (I, J, K) is determined to be equally similar to groups 1 and 2, since the target shares one object (object I) with both. Assuming that the target is not sufficiently similar to either group to be included therein, empty group 3 is redefined to include the target. FIG. 3G depicts groups 1 through 3 after examination of database request 7. The target (B, D, I) of database request 8 is completely similar to group 1 and somewhat similar to group 2 (shares common object I). This requires no redefinition either groups 1 or 2, since group 1 already includes all the target objects and group 2 is not sufficiently similar to warrant inclusion.

The target (I, J, L) of database request 9 is sufficiently similar to group 3 (they share common objects I and J) but not sufficiently similar to groups 1 and 2 to warrant inclusion (they share only common object I). Note that objects which are frequently the target of database requests can be included within many, if not all, groups (e.g., object I occurs in half of the targets and is included in all three groups). FIG. 3H depicts groups 1 through 3 following examination of database request 9. Upon examining database request 10, the target (A, B, G, L) is determined to be fairly similar to group 1 (half of the target objects are included in group 1) and less similar to groups 2 and 3 (one out of four common objects are included in groups 2 and 3). Assuming that the target is not sufficiently similar to group 1 (e.g., the similarity does not satisfy a similarity threshold) to warrant inclusion, as described above, the target can be included in an empty group (if available) or in the group having the highest similarity. In this case, the target is included in group 1 since there are no remaining empty groups

Selecting Objects from the Groups for Caching in the Cluster

Returning to FIG. 2, once objects from database 104 have been sorted into groups in operation 202, objects are selected from each group for caching in cache cluster 110. Those objects that are selected from a particular group are stored within the same cache 106 within cache cluster 110 so that database requests having targets similar to the group can be processed by a single cache. However, all of the objects within a group need not necessarily be cached. Various example embodiments according to the present invention are described herein for selecting none, some, or all of the objects in a group for caching. As will be apparent, the same method need not be applied to all groups; different techniques for selecting objects for caching can be applied to different groups.

According to a first example embodiment of the present invention, all of the objects in a group are selected for caching. This insures that those database requests having target objects in common with the group will always be satisfied by the cache in which the particular group is stored. However, storing all objects in a group can be expensive in terms of cache memory.

According to a second example embodiment of the present invention, objects are selected for caching according to the principles described in co-pending U.S. Patent Application No. 09/778,716, entitled "System and Method for Adaptive Data Caching," incorporated by reference above. The principles described therein for selecting objects for caching based on object cache-worthiness can be applied to selecting objects for caching within each group. According to this example embodiment, those objects within each group having the highest cache-worthiness are selected for caching subject to the constraint of available cache memory. Cache- worthiness values can also be used to determine the relative number of objects that are selected from each group for caching. For example, more objects are selected from a first group having high cache-worthiness objects as compared to other groups having lower cache-worthiness objects. Applying these principles, it is possible that no objects will be selected for caching from a group having low cache-worthiness objects. According to a third example embodiment of the present invention, conventional techniques for selecting objects for caching can be employed to select objects from each group, such as a least recently used (LRU) caching algorithm. As will be apparent, various other known techniques can alternatively be used for object selection. Consider again the example database requests and groups depicted in FIG.

3A. In operation 204, objects are selected from each of groups 1 through 3 for caching. Assuming that cache cluster 110 includes three caches (106 A, 106B, and 106C), objects from group 1 are stored in cache 106A, objects from group 2 are stored in cache 106B, and objects from group 3 are stored in cache 106C. For example, consider the second alternative embodiment described above using cache-worthiness to select objects for caching. Those objects from group 1 having the highest cache-worthiness values are selected for caching, subject to the constraint of available memory in cache 106A. Similarly, objects from groups 2 and 3 are selected based on their cache- worthiness values for caching in caches 106B and 106C, respectively. As a second example, assume that cache cluster 110 includes two caches

(106A and 106B), with objects from groups 1 and 2 being stored in cache 106A and group 3 in cache 106B. Cache-worthiness values can be used to select objects from groups 1 and 2 for caching in cache 106 A. For example, consider the objects from groups 1 and 2 having the following cache-worthiness values: A=0.6; B=0.2; C=0.9; D=0.1, 1=0.7; E=0.3; F=0.5; G=0.4; and H=1.0. Since objects from these two groups are stored in a single cache, those objects having the highest cache-worthiness from both groups are selected first for storage in the cache. Here, the objects would be selected in the following order: H, C, I, A, F, G, E, B, and D. Assuming that objects H, C, I, A, and F together exhaust the memory capacity of cache 106A, then those objects would be selected for caching and objects G, E, B, and D would not be cached. Heterogeneous and Homogeneous Caching According to an example embodiment of the present invention, objects can be distributed across cache cluster 110 in a heterogeneous or homogeneous fashion, or some combination of both. Heterogeneous caching refers to a distribution of objects within cache cluster 110 such that the objects stored in each cache 106 need not necessarily be the same. For example, storing each group in a particular cache 106 likely represents a heterogeneous distribution across cache cluster 110 because it is likely that the groups do not contain the same objects. This type of caching increases the available RAM for caching, and is particularly appropriate where requests are dispersed across broad data sections.

By comparison, homogenous caching refers to a distribution of objects such that the caches 106 within cache cluster 110 contain the same objects. This type of caching increases the database system's ability to process a large number of requests for a relatively small section of data that can be populated within the available RAM of a single cache unit. This type of caching is particularly appropriate, for example, where a single group of objects deemed to be the most desirable for caching (e.g., based on frequency of access, cache-worthiness) can be identified from database 104. This group can be copied into each cache 106, thereby providing greater access to these particular objects. According to an example embodiment of the present invention, load balancing techniques are employed to distribute the processing burdens associated with the database requests across cache cluster 110. Various load balancing techniques are known within the art for distributing processing burdens across multiple servers. The distribution of objects across cache cluster 110 can be both heterogeneous and homogeneous. For example, the same group can be stored in two or more caches 106, whereas other groups can be stored in the remaining caches 106. This can be useful where objects within a particular group are accessed more frequently than objects in other groups. Database requests accessing objects within the particular group can be satisfied by any of the caches 106 storing the group. Again, load balancing techniques can be used to distributed database requests amongst the homogenous caches.

Various configurations of a database system are described in the following sections that employ the techniques described above for selecting objects for caching in cache cluster 110.

Cache Cluster Within a Parallel Cache Configuration

The methods described herein may be applied to the parallel cache configuration described in co-pending U.S. Patent Application No. 09/711,881, incorporated by reference above. FIG. 5 depicts the digital network environment in greater detail according to an example embodiment of the present invention, wherein application 102, cache cluster 110, and database 104 are arranged in a parallel cache configuration 500. Application 102 includes application logic 502, a parallel cache driver 504, and a database driver 506. Cache cluster 110 includes a controller 520 and a replication component 522 in addition to two or more caches 106. Each of these components is described in greater detail below.

Application logic 502 represents the portion of application 102 devoted to implementing the application functionality. For example, application logic 502 can include a graphical user interface (GUI) to control user interactions with application 102, various processing routines for computing items of interest, and other routines for accessing and manipulating database information stored in database 104. Database driver 506 represents software that allows a calling routine to establish a connection (as a client) to DBMS 112. As described above, database driver 506 provides an API that can include a variety of other function calls for interacting with DBMS 112. According to an example embodiment of the present invention, database driver 506 represents the driver software that is distributed by the manufacturer of database 104.

As described in co-pending U.S. Patent Application No. 09/711,881, cache driver 504 causes database requests from application logic 502 to be routed to DBMS 112 and/or cache cluster 110. Cache driver 504 provides an API that can include a variety of function calls for use by application logic 502. According to an example embodiment of the present invention, the cache driver API can include one or more of the function calls defined in the database driver API. Application logic 502 establishes a connection 532 with cache cluster 110 by calling cache driver 504. Cache driver 504 calls database driver 506 to establish a connection 530 with DBMS 112. DBMS 112 establishes a connection 534 to cache cluster 110 to transfer objects between database 104 and cache cluster 110. As will be apparent, connections 530, 532, and 534 can represent data exchanged over network 120 according to an appropriate network protocol.

According to an example embodiment of the present invention, database driver 506 and cache driver 504 support the Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC) standards. Generally speaking, clients using these types of drivers can generate SQL query requests for the server to process. In another example embodiment, the caches 106 within cache cluster 110 also support the ability to respond to Extensible Markup Language Query Language (XQL) queries which do not specify a particular driver type (driverless) and use an open standard mechanism, such as Hypertext Transfer Protocol (HTTP), for its communication protocol. The principles described above can be applied to parallel cache configuration 500 to provide for the selection of objects from database 104 for caching in cache cluster 110. According to an example embodiment of the present invention, cache driver 504 monitors the database requests generated by application logic 502. Cache driver 504 provides data to controller 520 identifying the targets associated with those database requests deemed to be appropriate for caching in cache cluster 110. For example, as described in co-pending U.S . Patent Application No. 09/711,881, informational database requests are deemed to be appropriate for caching, whereas transactional database requests are not. In this example, cache driver 504 provides data to controller 520 identifying those targets associated with informational database requests. Controller 520 uses the data received from cache driver 504 to sort the objects into groups (operation 202) and to select objects from the groups for caching (operation 204). According to an example embodiment of the present invention, cache driver 504 also collects cache- worthiness data as described in co-pending U.S. Patent Application No. 09/778,716 and provides this to controller 520 for the purpose of selecting objects from the groups in operation 204 based on their cache-worthiness. Controller 520 works in conjunction with replication component 522 to insure that the objects selected from each group are copied into the appropriate cache 106 from database 104. Replication component 522 also interacts with DBMS 112 to update objects stored in cache cluster 110 as changes are made to corresponding objects in database 104.

Controller 520 maintains a current image of cache cluster 110, including the identity and contents of each cache 106. Controller 520 provides image data describing the image to cache driver 504. Cache driver 504 uses this data to determine whether a particular database request can be satisfied by one or more caches 106. If cache driver 504 determines that a particular database request is appropriate for cache processing, and if the request can be satisfied by at least one cache 106, then cache driver 504 forwards the database request to the cache for processing. If more than one cache 106 can satisfy the database request (i.e., more than one cache 106 includes the target of the request), then cache driver 504 can select one of the caches to handle the processing. As described above, load balancing techniques can be employed to distribute the processing burdens associated with the database requests across cache cluster 110. According to the present invention, alterations to the configuration of cache cluster 110 are transparent to application logic 502. This is because controller 520 updates the image data in cache driver 504 as cache units are added to or removed from cache cluster 110. This allows for the seamless introduction of new cache units, or removal of existing cache units, without any external intervention or disruption to the operation of cache driver 504 or application logic 502. Controller 520 sends all necessary information to cache driver 504 related to the updated cache cluster 110, such as the address, communication specifications, and contents of any new cache units. Cache driver 504 registers the new unit in its image of the cluster.

As will be apparent, data transfers between cache driver 504 and controller 520 can occur on an intermittent basis, where the time between updates can be adjusted to the requirements of a particular application. The data being transmitted can be formatted using various techniques for compression and/or encryption to reduce the size of the data or protect the data's confidentiality.

Although the present invention has been described with reference to a number of illustrative embodiments, it should be understood that numerous other modifications and embodiments can be devised by those skilled in the art that will fall within the spirit and scope of the principles of this invention. More particularly, reasonable variations and modifications are possible in the component parts and/or arrangements of the subject combination arrangement within the scope of the foregoing disclosure, the drawings and the appended claims without departing from the spirit of the invention. In addition to variations and modifications in the component parts and/or arrangements, alternative uses will also be apparent to those skilled in the art.

For example, it will be apparent to those skilled in the art that the operations described as being performed by cache driver 504 and controller 520 could be distributed differently according to alternative embodiments within the scope of the present invention. In an alternative example embodiment, cache driver 504 rather than controller 520 sorts objects into groups (operation 202) and selects objects from the groups for caching (operation 204). Cache driver 504 then sends the updated cache population to controller 520, which then coordinates with replication component 522 to insure that the selected objects are copied into cache cluster 110.

As another example, cache cluster 110 is depicted as having a single controller 520 and replication component 522. According to an alternative example embodiment, each cache 106 has its own controller and replication components which operate together to perform the functions ascribed to the single components described above.

As yet another example, the techniques according to the present invention for selecting objects to cache in a cache cluster are described above in the context of a parallel cache configuration. These techniques, however, have application outside this context. In fact, the techniques described herein can be applied to any database system wherein a cache cluster is used to cache data stored in a database 104, such as an in-line cache configuration. Conclusion

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. The previous description of exemplary embodiments is provided to enable any person skilled in the art to make or use the present invention. While the invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

Claims

What is claimed is:

1. A method for selecting database objects to be stored in a plurality of caches, comprising:

(a) sorting objects into a plurality of groups based on similarities among database requests having a target that includes one or more of said objects; and

(b) selecting at least one object from at least one of said groups for storage in the plurality of caches, wherein the objects selected from a particular group are stored in the same cache.

2. The method of claim 1 , wherein said sorting comprises: (al) determining a similarity measurement between said targets and said groups; and (a2) including said targets within those groups satisfying a similarity threshold.

3. The method of claim 2, wherein said similarity measurement between a particular target and a particular group is based on the number of objects common to said particular target and said particular group.

4. The method of claim 3, wherein said similarity measurement (S) is given by

S = p » e"^'1 where/; represents said number of common objects.

5. The method of claim 1, wherein said selecting comprises selecting objects based on object cache- worthiness.

6. A method, comprising:

(a) monitoring database requests that are sent to a database, wherein said database requests access at least one object stored within said database; (b) sorting said objects into a plurality of groups, wherein the objects associated with each database request are included within the same group; and

(c) storing the objects associated with a particular group in a cache, wherein said cache is part of a cache cluster.

7. In a database system including objects stored in a database and a plurality of caches, wherein database requests are received by the database system, and wherein the database requests each identify a target that includes a plurality of the objects, a method for selecting objects to be stored in the plurality of caches, comprising:

(a) selecting a first group from a plurality of groups based on a similarity between a target and the objects within each group; and

(b) adding to said first group those objects included in said target that are not already included within said first group; wherein at least one object from each of said groups is cached in the plurality of caches, and wherein the cached objects associated with a particular group are stored in the same cache.

8. A method comprising:

(a) monitoring requests sent to a database that stores objects, wherein said requests access targets that include one or more of said objects; and

(b) selectively storing said objects in a plurality of caches based on similarities amongst said targets.

9. The method of claim 8, wherein said selectively storing comprises: (bl) sorting said objects into a plurality of groups based on the occurrences of collections of objects within said targets; and (b2) storing a first group selected from said plurality of groups in a first cache selected from said plurality of caches.

10. The method of claim 9, wherein the objects associated with said first group are selected for storage in said first cache based on object cache-worthiness.

11. The method of claim 9, wherein all of the objects associated with said first group are stored in said first cache.

12. The method of claim 9, wherein said objects can be included in more than one of said plurality of groups.

13. The method of claim 8, wherein said objects are stored homogeneously in said plurality of caches.

14. The method of claim 8, wherein said objects are stored heterogeneously in said plurality of caches.

15. A system comprising: means for monitoring requests sent to a database that stores objects, wherein said requests access targets that include one or more of said objects; and means for selectively storing said objects in a plurality of caches based on similarities amongst said targets.

16. The system of claim 15, wherein said means for selectively storing comprises: means for sorting said objects into a plurality of groups based on the occurrences of collections of objects within said targets; and means for storing a first group selected from said plurality of groups in a first cache selected from said plurality of caches.

17. The system of claim 16, wherein the objects associated with said first group are selected for storage in said first cache based on object cache-worthiness.

18. The system of claim 16, wherein all of the objects associated with said first group are stored in said first cache.

19. The system of claim 16, wherein said objects can be included in more than one of said plurality of groups.

20. The system of claim 15, wherein said objects are stored homogeneously in said plurality of caches.

21. The system of claim 15, wherein said objects are stored heterogeneously in said plurality of caches.

22. A database system comprising: a database; a plurality of objects stored in said database; a plurality of caches; a cache driver configured to monitor requests sent by an application to said database, wherein said requests access targets that include one or more of said objects; and a controller configured to selectively cause said objects to be stored in said plurality of caches based on similarities amongst said targets.

23. The database system of claim 22, wherein said cache driver is further configured to provide data indicative of said targets to said controller.

24. The database system of claim 23, wherein said requests comprise informational requests and transactional requests, and wherein said cache driver provides said data for said informational requests.

25. The database system of claim 22, further comprising a replication component configured to selectively copy said objects from said database to said plurality of caches responsive to said controller.

26. In a database system having a database and a plurality of caches, wherein objects are stored in the database, computer executable software code comprising: code to monitor requests sent to the database, wherein said requests access targets that include one or more of the objects; and code to selectively store the objects in the plurality of caches based on similarities amongst said targets.

27. The software code of claim 26, wherein said selectively storing comprises: (bl) sorting said objects into a plurality of groups based on the occurrences of collections of objects within said targets; and (b2) storing a first group selected from said plurality of groups in a first cache selected from said plurality of caches.

28. The software code of claim 27, wherein the objects associated with said first group are selected for storage in said first cache based on object cache-worthiness.

29. The software code of claim 27, wherein all of the objects associated with said first group are stored in said first cache.

30. The software code of claim 27, wherein said objects can be included in more than one of said plurality of groups.

31. The software code of claim 26, wherein said objects are stored homogeneously in said plurality of caches.

32. The software code of claim 26, wherein said objects are stored heterogeneously in said plurality of caches.