WO2010060179A1

WO2010060179A1 - Methods for organizing a relational database by using clustering operations

Info

Publication number: WO2010060179A1
Application number: PCT/CA2008/002078
Authority: WO
Inventors: Dominik Slezak; Marcin Kowalski; Victoria Eastwood; Jakub Wroblewski
Original assignee: Infobright Inc.
Priority date: 2008-11-28
Filing date: 2008-11-28
Publication date: 2010-06-03

Abstract

A relational database having a plurality of records is organized by using a processing arrangement to perform a clustering operation on the records so as to create a number of clusters. At least one of the clusters is characterized by a selected metadata parameter. The clustering operation is performed to optimize a calculated value of a selected precision factor for the selected metadata parameter. The selected metadata parameter is selected to optimize execution of a database query and the value of the selected precision factor is related to efficiency of execution of the database query.

Description

METHODS FOR ORGANIZING A RELATIONAL DATABASE BY USING

CLUSTERING OPERATIONS

CROSS REFERENCE TO RELATED APPLICATION

This application incorporates by reference in their entirety each of U.S. Application No. 11/854,788, filed 13 September 2007, U.S. Provisional Application No. 60/845,167 filed 18 September 2006, U.S. Application No. 11/843,019 filed 22 August 2007, and PCT Application Serial No. PCT/CA2007/001627, filed 13 September 2007.

FIELD OF THE INVENTION

The present disclosure relates generally to relational database management systems (RDBMS) and more particularly to methods and systems for optimizing the organization of a relational database so as to improve the efficiency of executing queries on the database.

BACKGROUND

Databases and database management systems are being implemented in more and more businesses, organizations and institutions, and are being used to store and manage increasingly large amounts of data of increasingly different types and complexity. It is a continuing objective to increase or maintain the speed of responding to data search queries and data analysis tasks in the face of at least the following trends:

Increased diversity in user needs * Increased demands for ad hoc and complex decision support queries vs. standard canned reports

Need for more "real time" information Rapidly growing volumes of data

As a result, there is a need for improved database management solutions to facilitate rapid execution of database queries.

Traditional approaches to database organization fail to effectively deliver a solution to such diverse requirements because of high computational cost, and slow query performance against large volumes of data. As evidenced, for example, in Fayyad, et al., U.S. 6,374,251 ("Fayyad"), there is an acute, largely unsolved, challenge to sift through large databases in search of useful information in a reasonable amount of time, especially where the database size may be much larger than the available computer memory. In US application No. 11/854,788, filed September 13, 2007, and assigned to the assignee of the present application, metadata parameters of various types (referred to therein as data information units, data pack nodes, knowledge nodes and/or statistical data elements) were disclosed as means for characterizing the content of data units where the data units were, for example, a group of data from a single category (or column) extracted from a group of data records. The disclosed method enabled faster processing of a data query by, inter alia, using the metadata parameters to avoid searching individual data records (or fractions thereof) when the metadata parameter indicated those records (or fractions thereof) would not contain data responsive to the data query. Thus, the metadata parameter improved planning and execution of data query operations, irrespective of how the data records were ordered.

Some known methods organize databases by partitioning data into smaller blocks to assist in subsequent data operations. Partitioning may provide for a physical data model design aimed at organization and enhancement of the data transparently to the logical data model layout. Such physical data model design approaches are generally based on certain assumptions about the way users will use the system and usually leave the tuning task to the database administrator (DBA). Some known approaches attempt to analyze automatically the data and query samples to assist the DBA as a kind of decision support tool while others attempt to alert the DBA during the system's operation whenever the users' requirements have changed significantly enough to reconsider the current design.

However, dynamic changes in the users' requirements are not handled sufficiently flexibly by such existing tools. In particular, there is a lack of flexibility in known RDBMS data partitioning techniques, which split the data into separate groups defined in terms of distinct values or ranges of some columns or functions. Such partitioning criteria are so closely related to specific query and data patterns that any change in the query workload or incoming data may cause a significant decrease in the query performance until the data is re-partitioned.

Furthermore, dynamic changes in the database itself, as a result of arrival of new data, are handled inefficiently by such existing methods. For example, in the case where a user of a RDBMS wants to run queries immediately after new portions of data are loaded into the previously existing data sets, it is not acceptable that recalculation of the data structures over the old data merged with the new data takes a larger amount of time. Instead, there is a growing expectation that both old and newly arriving data should be available for efficient querying as it arrives and without delay.

Techniques of data mining known in the art as "cluster analysis" look for relations between data elements in a set of data records. Cluster analysis has been defined as "the organization of a collection of patterns (usually represented as a vector of measurements, or a point in a multidimensional space) into clusters based on similarity." Jain, A.K., et al., Data Clustering: A Review, ACM Computing Surveys, Vo. 31, NO. 3, September 1999. Data "clustering" in the context of data mining has the objective of grouping similar data items into clusters that would be practically meaningful to the end users of a data mining system. Such methods seek to extract useful information from an essentially unordered (or randomly ordered) set of records by finding relationships between data items. As noted above, present methods of applying such techniques to large databases are costly in terms of execution time and computer resources.

Accordingly, what are needed are improved methods and systems for optimizing the organization of a relational database so as to improve the efficiency of executing search queries on the database.

SUMMARY OF THE INVENTION

The present inventors have mitigated the aforementioned problems with techniques that improve query execution efficiency, particularly of very large relational databases, by clustering records in the database so as to optimize associated metadata parameters with respect to query execution efficiency. The techniques are effective when practiced prior to or upon receipt of a query and may be practiced on a database during or after load.

In an embodiment, a relational database is organized by using a processing arrangement to perform a clustering operation on database records so as to create data clusters, at least one data cluster being characterized by a selected metadata parameter. The clustering operation optimizes a calculated value of a selected precision factor for the selected metadata parameter.

In a further embodiment, the selected metadata parameter is selected to optimize execution of a database query.

In another embodiment, the value of the selected precision factor is related to efficiency of execution of a database query. In yet a further embodiment, a data unit consisting of a plurality of data elements in the database is characterized by the selected metadata parameter. The selected metadata parameter identifies: a minimum value of all data elements in the data unit, a maximum value of all data elements in the data unit, a number of non-null values found within the data elements in the data unit; a histogram mapping an occurrence of at least one value in the data unit, information about occurrence of a character in an alphanumeric string, and/or a total value of the data elements in the data unit.

In an embodiment, the precision factor measures effectiveness of the metadata parameter in maximizing efficiency of a database query.

In a further embodiment, the clustering operation consists of a first clustering operation and a second clustering operation, and the second clustering operation is performed only when the second clustering operation is predicted to improve the value of the selected precision factor by at least a selected threshold amount. Moreover, the selected metadata parameter may be a first selected metadata parameter and the at least one of said plurality of clusters may be characterized by the first selected metadata parameter and a second selected metadata parameter such that the selected precision factor is a first selected precision factor for the first metadata parameter and a second selected precision factor for the second metadata parameter. The first selected metadata parameter may have a first weighting factor applied to the first selected precision factor and the second selected metadata parameter may have a second weighting factor applied to the second selected precision factor. A cluster quality parameter may consist of a sum of the weighted first selected precision factor and the weighted second selected precision factor. Each of the first and second clustering operations improves the cluster quality parameter.

In a further embodiment the method is repeated when a change occurs to at least one of the relational database and parameters related to the relational database. Moreover, the change may consist of a change to an existing record, addition of a record, and/or deletion of a record. Furthermore, the change may consist of a change in value of at least one of a metadata parameter, a precision factor, a weighting factor, and/or a cluster quality parameter.

In yet another embodiment, performing a clustering operation consists of assigning a first record to a first cluster container, the first cluster container being one of a selected number of cluster containers; assigning each subsequent record to a selected one of (a) the first cluster container and (b) a different cluster container, and the selection is made so as to maximize an average value of the selected precision factor. Moreover, the selected number of cluster containers may be adjusted in response to at least one of (i) a speed of executing the method and (ii) the selected precision factor average value. Furthermore, each cluster container may have a selectable maximum size that may be adjusted in response to at least one calculated value of a precision factor of the cluster container. In addition, the selection may be made so as to improve a cluster quality parameter, the cluster quality parameter consisting of a product of a weighting factor and the selected precision factor, and the weighting factor corresponding to an average historical in value of the selected precision factor.

In an embodiment, a relational database is organized by duplicating a plurality of records in the relational database so as to create at least a first and a second plurality of records, the first plurality of records being identical to the second plurality of records; performing a first clustering operation on each of the first plurality of records and second plurality of records so as to create a first plurality of clusters and a second plurality of clusters, each cluster in the plurality of clusters characterized by at least one respective metadata parameter, each respective metadata parameter having an associated precision factor, each associated precision factor having a respective weighting factor applied thereto, such that the first clustering operation maximizes a calculated value of a weighted selected precision factor; and, responsive to a database query, executing the database query on a selected one of the first plurality of records and the second plurality of records, the selection being made on the basis of a correlation between a property of the query and the calculated value of the selected precision factor for each of the first plurality of records and the second plurality of records.

In another embodiment, a query of a relational database is executed on a relational database, by using a processing arrangement to perform a clustering operation on database records so as to create a data cluster, at least one data cluster being characterized by a selected metadata parameter. The clustering operation optimizes a calculated value of a selected precision factor for the selected metadata parameter, the metadata parameter optimizes the query, and the processing arrangement returns a response to the query.

In a further embodiment, computer readable instructions stored on a computer-usable medium for execution by a processor perform a method of organizing a relational database by performing a clustering operation on database records so as to create data clusters, at least data cluster being characterized by a selected metadata parameter. The clustering operation optimizes a calculated value of a selected precision factor for the selected metadata parameter.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not limitation, in the figures of the accompanying drawings, in which:

Figure 1 is an example illustrating data homogeneity as the term may be applied in an embodiment;

Figure 2 illustrates a data structure suitable for processing by an embodiment; Figure 3 a and b are an exemplary flow diagram illustrating an embodiment for data clustering;

Figure 4 illustrates an example database;

Figures 5a-5k illustrate an exemplary process of clustering records from the database illustrated in Figure 4;

Figure 6 illustrates a processing arrangement of an exemplary embodiment.

DETAILED DESCRIPTION

Methods and systems for optimizing the organization of a relational database (RDB) so as to improve the efficiency of executing search queries on the database will now be described. Optimizing the organization of a database may mean grouping (or "clustering") data records belonging to the RDB in such a way that data synopses computed for selected data groups are, on average, most useful to the conduct of searches. Such data synopses are referred to as "metadata parameters" in the present specification and claims. A measure of the "usefulness" of a metadata parameter is referred to hereinafter, in the specification and claims, as a "precision factor". A precision factor may characterize, for example, the homogeneity of data within a data unit, and be calculated from information contained within the metadata parameters.

Query execution performance may be enhanced by clustering RDB records into more optimal groups. "Clustering", as the term is used hereinafter in the specification and the claims, refers to the grouping and/or regrouping of data records within the RDB. As such, the term is to be distinguished from "data clustering" as described in Jain, and other works on data mining. As described in Jain, for example, data clustering has the objective of finding and selecting records from within an essentially unordered (or arbitrarily ordered) database, the selected records characterized in that similar data items may be grouped into clusters that would be practically meaningful to the end users of a data mining system.

Such methods extract data from an essentially unordered (or arbitrarily ordered) set of records with an objective of finding relationships between data items, and are not concerned with structuring the database itself to facilitate execution of queries.

As described in more detail hereinbelow, the metadata parameters, and the RDB itself, may be updated dynamically taking into account changes to user query statistics and to the database itself. In an embodiment, optimizing may be performed on-line, that is, even while new data records are arriving and may be performed transparently to any ongoing user queries.

In an embodiment, a method of organizing an RDB includes using a processing arrangement to perform a clustering operation on records of the RDB so as to create two or more "clusters" of records, at least one of which is characterized by a selected metadata parameter such that a calculated value of a selected precision factor for the selected metadata parameter is optimized.

Metadata parameters

Metadata parameters may provide a descriptive synopsis of data making up a subset of a RDB. For example, metadata may include a set of statistics about the data subset. In an embodiment, the data subset may be associated with one or more columns a column- oriented RDB. Advantageously, the data subset may be compressed, using methods known in the art appropriate to the type of data stored in a particular column.

A RDB may include one or more data clusters. In some embodiments, referring now to Fig. 2, the RDB may be a column-oriented database 2001, and each cluster 221 may represent column data from a base table. The clusters 221 may include compressed data representing the records or entries in the respective column. In some embodiments, the clusters 221 may contain data concerning up to 2¹⁶ (approximately 65.5K) consecutive records of which some values may be null. Depending on its size, the column may be stored in more than one cluster (e.g., if there are more than 65.5K records). The clusters 221 may be compressed, and may contain more or less records than discussed here, depending on the application. In an embodiment, clusters may be compressed using techniques described in U.S. Application No. 11/843,019.

Metadata parameters 222 may store information about data elements in a cluster 221, such as basic statistical or analytical information associated with each cluster 221 in the RDB. In some embodiments, there may be one metadata parameter 222 for each cluster 221. Each metadata parameter 222 may contain basic information (e.g., statistics) about its respective cluster 221. The particular information maintained in the metadata parameter 222 for each cluster 221 may depend on the particular data type of the respective cluster 221. Typically, the size of each metadata parameter 222 may be small and so the metadata parameter 222 may be not compressed. As compared to conventional indices used in RDB, such metadata parameters require much less overhead, because they are operative on clusters rather than rows. The present inventors have found, for example, that the overhead of metadata parameters may be as little as 1% of the RDB size, even after compression of the RDB. Conventional indices, by way of comparison, may typically represent overhead on the order of 20-50%.

Generally, data types may be at least one of: a string, a numeric value, a floating point value, or a binary value. A compression algorithm may be selected for each of these four primary data types. In some aspects, within each of these four primary data types there may be sub-types (e.g., large string, short string, date, or other) for which different compression algorithms may be selected.

In an example of numerical data types, the metadata parameter 222 for cluster 221 may include: the number of non-null values in the respective cluster 221, the minimum and maximum values in the respective cluster 221, and the sum of values in the respective cluster 221. In the case of non-numerical data types, the metadata parameter may include, for example, lexicographic minimum and maximum or the largest common prefix (e.g., the longest sub-string that is common to all strings) for a cluster 221. If all non-null values in the cluster 221 are the same, the metadata parameter 222 may store only the statistical information and positions of nulls. In some embodiments, additional or different information may be included in the metadata parameter 222. Further, other information about the respective cluster 221 may be derived from the information in the metadata parameter 222. For example, the average value may be derived directly from the number of non-null values and the sum of values which are both stored in the metadata parameter 222 of the example.

A metadata parameter 222 may be associated with one or more clusters 221 , one or more columns, one or more tables, or a combination thereof. A metadata parameter 222 may include analytical information about the data elements stored in one or more clusters 221, one or more columns, one or more tables, or a combination thereof, information about relationships between data elements in multiple clusters 221, information about relationships between data elements in different columns in a base table, and/or relationships between data elements in columns in different base tables. For example, a metadata parameter may consist of information about correlation of data elements in a data unit with data element of at least one other data unit. Moreover, a metadata parameter may identify common occurrence of at least one value in a first data unit and a second data unit. A metadata parameter 222 may be dynamic and may change over time. Moreover, a metadata parameter may include more than simple statistics such as min and max values within a cluster. For example, a metadata parameter may include a histogram that maps the occurrence of particular values in a particular cluster. Such a histogram may enable quick and precise determination of whether a particular value occurs in a cluster without the need to decompress the cluster itself. Analogously, basic information about alphanumeric data may be extended by storing information about the occurrence of particular characters in particular positions in the cluster.

A metadata parameter 222 may be used in query planning and execution, and may allow minimization of the need to access the data stored in the respective data cluster 221 during query execution, as will be described in more detail below.

As discussed above, large databases may be organized as clusters, each cluster containing, for example, 2^Λ16 ~ 65.5K records. Thus, for example, for a table T with columns A and B, and 300,000 records, the following clusters may be provided:

Cluster 1 : values of column A and Column B for row nos. 1-65.5K Cluster 2: values of column A and Column B for row nos. 65.5K-131K Cluster 3: values of column A and Column B for row nos. 131.1K-196.6K Cluster 4: values of column A and Column B for row nos. 196.6K-262.1K Cluster 5: values of column A and Column B for row nos. 262.1K-300K

Analytical information about each cluster may be collected and stored as metadata parameters. For example, for the following table I, assume that both A and B store some numeric values. The following table should be read as follows: for the first 65.5K rows in T the minimum value of A is 0, maximum is 5, the sum of values on A for the first 65.5K rows is 10,000. Table I

Metadata parameters may be accessible without a need to decompress data in the corresponding clusters. In an embodiment, whenever a query may require access to (and decompression of) data stored in a given cluster the method first examines a corresponding metadata parameter to determine if decompression of the contents is really necessary. In many cases, information contained in a metadata parameter is enough to optimize and execute a query.

In other cases, because decompressing a cluster is substantially faster than decompressing an entire database, and metadata parameters provide a mechanism for identifying the clusters which need to be decompressed in response to a query, query execution efficiency is substantially improved.

For example, upon receiving a query, clusters may be categorized as "relevant", "irrelevant", or "suspect" according to the following criteria: Relevant cluster - in which each element in the cluster is identified, based on its metadata parameter(s), as applicable to the query.

Irrelevant cluster — based on its metadata parameter(s), the cluster holds no relevant values.

Suspect cluster - some elements may be relevant, but it is not possible to determine whether the cluster is either fully relevant or fully irrelevant, based on its metadata parameters).

In executing a query, it is not necessary to decompress either Relevant or Irrelevant clusters. Irrelevant clusters may be simply not taken into account at all. In case of Relevant clusters, we know that all elements are relevant, and the required answer is obtainable-at least for a large number of types of analytic queries-from a metadata parameter without a need to decompress the cluster.

For example, using the metadata parameters provided in Table I consider the following SQL query statement:

Query 1 : SELECT SUM(B) FROM T WHERE A > 6; • Clusters Al, A2, and A4 are Irrelevant - none of the data can satisfy A > 6 because all these clusters have maximum values below 6. Consequently, clusters Bl, B2, and B4 need not be analyzed while calculating SUM(B) - they are Irrelevant too. • Cluster A3 is Relevant - all the data elements satisfy A> 6. As a result cluster B3 is Relevant as well. The sum of values on B within cluster B3 is one of the components of the final answer. Based on one of B3's metadata parameter, it is known that that sum equals to 100. Since this is everything we need to know about this portion of data, it is not necessary to decompress cluster A3 or B3. • Cluster A5 is Suspect - some rows satisfy A > 6 but it is not known which ones.

As a consequence, cluster B5 is Suspect too. It is necessary to decompress both A5 and B5 to determine which rows out satisfy A > 6 and sum up together the values over B precisely for those rows. A result will be added to the value of 100 previously obtained for Pack B 3, to form the final answer to the query.

Precision Factors

As described above, metadata parameters may generally be effective in improving execution of a database query. A "precision factor" is a measure of a metadata parameter's effectiveness in maximizing efficiency of execution of a database query.

For example, the precision factor for a metadata parameter characterizing column 'A' within a cluster 'X' may be reversely proportional to the following difference:

[maximum A's value in X] - [minimum A's value in X]

"Reversely proportional" may be defined mathematically as, for example:

Exp(-difference); or

1 / (difference + 1); or 1 - (difference / global), where global = [maximum A's value in the whole data] -

[minimum A's value in the whole data] A "difference", as the term is used in the foregoing discussion may be related to homogeneity of some subset of data found in a cluster of records with respect to their values within column A. However, homogeneity, as the term is used herein, is not limited to the formal meaning found in classical statistical approaches to data analysis. For example homogeneity may not be related only to a low standard deviation of the value variations (e.g., the variation of data values in column A over a cluster X). Instead, homogeneity is adjusted to the actual way of using metadata parameters in executing a database query.

For example, a metadata parameter may store the number of NULL values on column A in cluster X. Generally, query execution efficiency is improved to the extent that NULL values are gathered into fewer number of clusters. The precision factor with respect to NULLs may be defined as:

MAX { parameter, 1 - parameter}, where parameter = [# of NULLs on A in X] / [# of all rows in X]

Generally, the above formula provides that a more optimum precision factor is found for a corresponding metadata parameter when clusters have very high or very low percentage of NULLs.

As a further example, where the metadata parameter is a histogram of the column A for cluster X, its precision factor may be even less related to the traditional notion of homogeneity. Referring now to Figure 1 , a range of values of column A in the whole data 101 as well as a shorter range of values of A in cluster X 102 are illustrated. A precision factor for some types of metadata parameters is improved if the internal interval (X) is minimal compared to the external one (whole data). However, where the metadata parameter stores histogram information, its precision factor is improved even if the internal interval is long, but with many "holes" 103 inside it. The "holes" 103 mean that the range between minimum and maximum is not uniformly covered by values in cluster X, more specifically, that the values of A in cluster X occur only within the shaded intervals 104. Because a histogram metadata parameter encodes those shaded intervals by means of a binary sequence, the shorter the overall length of the shaded intervals, the more nearly optimum is the metadata parameter's precision factor.

Clustering Operations

The foregoing description related to determining metadata parameters, and precision factors associated therewith, for a RDB consisting of clusters of records. Characterizing such existing clusters with one or more metadata parameters has been shown to improve efficiency of executing a query on the RDB. The present inventors have found that performing a clustering operation, that is, grouping and/or regrouping of data records within the RDB, may result in substantial additional improvements in query execution efficiency. The improvement arises because data clusters having more "homogenous" values will be better represented by metadata parameters (i.e., the metadata parameters will have a more optimal precision factor). For example, minimum and maximum values will be closer to each other for each cluster. As another example, there will be more O's inside histograms for clusters of numeric values. As a result, metadata parameters will filter out more clusters when a RDB query is executed. Advantageously, a clustering operation may be performed during load, insert, data compacting, or even while processing intermediate results during query execution.

Referring now to Figure 2, an example of data clustering within a simple two column table is provided. Simple sorting by either column destroys regularities in the other column. But inside clusters, values of both columns can be kept relatively homogeneous (for simplicity of illustration, each cluster has two rows).

In an embodiment, a clustering operation may be performed on load, for example upon receipt of a stream of data records (or rows) of an RDB by assigning each record as it arrives to a cluster "container". Each cluster container may have a selectable maximum size, i.e., a capacity for a selectable number of records. In an embodiment, the selected maximum size may be 2^A16 records. As illustrated in Figure 3a, each of a stream of rows 301 may be assigned to a selected cluster container, from a set 302 of cluster containers. As will be described in detail hereinbelow, selection of a "best" cluster container for each respective row may be made so as to optimize an average value of a selected precision factor. For each arriving row of data an embodiment may find the best cluster container to which the row may be added. A "full" container may be replaced with an empty container, and the data within the full container may constitute a finished data cluster 303; data clusters 303 may thereafter be processed within the RDB.

An example of a clustering operation will now be provided with reference to Figure 4 where a simplified RDB 401 having nine records is illustrated. For purposes of the example, each record will be assigned to one of a set of cluster containers, each cluster container having a capacity to hold four records. The objective of the clustering operation may be to optimize a calculated value of precision factors for selected metadata parameters. In the present example, it is assumed that two metadata types are of interest:

MinMax(A) and MinMax(B). For simplicity, the example assumes each metadata parameter to have equal weight. It should be noted, however, that an embodiment provides for non-equal weighting factors to be separately applied to respective precision factors of each metadata parameter. Moreover, each weighting factor may be a default value, a manually set value, and/or an automatically recalculated value during the regrouping step. Automatic recalculation may be performed by applying a weight derived from a previous iteration of the method. Advantageously, at least one of the weighting factors may be selected based on an estimated correlation between its associated metadata parameter and query execution efficiency.

As previously discussed, a precision factor may be calculated according to various mathematical formulations. For purposes of the present example precision factors P(A₅X) and P(B,X) are defined as

^'

Figure 5 a illustrates the initial state of each cluster container (before assignment of first record Rl . The precision factor over an empty cluster container is set by default as equaling 1. Average historical precision changes P(A) and P(B) may be recorded for each of metadata types and updated when each new record is assigned an existing cluster container. At the start of a clustering operation, P(A)=O and P(B)=O. In the present example, the maximum number of record capacity of each cluster container equals to 4. Whenever a cluster container has been assigned four records, the new data group is created as the algorithm's output and the data bucket is emptied before continuing the algorithm.

When a first record, Rl [2, 20], arrives, the result of assigning it to any empty cluster container is the same (the precision factor equals one for a cluster container containing zero data records or a single data record) so the assignment is arbitrary. For this example, it assumed that record Rl is assigned to cluster container Xl as shown in Fig. 5b. When a record arrives, it may be tested for possible assignment in each cluster container (resulting here in three "observations", one with respect to each of three cluster containers).

When second record R2 [1, 2] (and each subsequent record) arrives a decision with respect to cluster container assignment may be made taking into account (1) the metadata precision changes over container X if R is assigned to X and (2) the current number of records in X, denoted as |X|. The second parameter permits, for example, a weighting of how much to rely on the calculated precision change and how to rely on an average historical change instead. A record may be assigned to a cluster container on the basis of a calculated cluster quality parameter D(X₅R), where D(X₁R) = D(X₁R₁A) + D(X₁R₁B) D(X₁R₁A) = [P(A,X)-P(A,X+R)]^*IXI + P(A)^*(4-IXI); and D(X₁R₁B) = [P(B,X)-P(B,X+R)]^*IXI + P(B)*(4-IXI) and an objective of clustering is to assign records to cluster containers so as to minimize the calculated value of D.

Now, in the case of record R2[l,2]:

D(X1 ,R2) = [(1 - )*1+0^*(4-1)] + [(1 )^*1+0^*(4-1 )] l + (2 - l) l + (20 - 2) ^{V ;}

D(X2,R2) = 0 and D(X3,R2) = 0

The result of assigning R2 to either X2 or X3 is the same (resulting in a D(X₅R)=O) and is preferred to assigning R2 to Xl . For this example, it assumed that record R2 is assigned to cluster container X2 as shown in Fig. 5c. It may be noted that the number of observations is now six, of which one is non-zero.

The decision calculation upon arrival of third record R3 [30, 1]:

D(X1 ,R3) = [(1 )^*1+0.083^*(4-1)] + [(1 ^l- )*1+0.158*(4-1)] l + (30 - 2) l + (20 - l) ^{; V n} D(X2,R3) = [(1 )^*1+0.083^*(4-1)] + [(1 )^*1 +0.158^*(4-1)l l + (30 - l) l + (2 - l)

D(X3,R3) = 0.083^*4 + 1^*0.158^*4

The calculation above determines that D(X3, R3) is the smallest value, so, as a result R3 may be assigned to cluster container X3, with the results summarized in Fig. 5d.

When each of record R4 through R6 arrives, a similar decision calculation is made, with results presented in Figs. 5e through 5g.

When record R7 is assigned to cluster container X2, in accordance with a decision calculation presented in Fig. 5h, cluster container X2 reaches its full capacity of four records. The data cluster represented by those four records represents an intermediate output reported by the example method, whereafter cluster container 2 is emptied and enabled to accept new arriving records. The results just prior to arrival of record R8 are presented in Fig. 5i.

When each of record R8 and R9 arrives, for example, it is treated in a manner similar to the foregoing with results presented in Figs. 5j and 5k. Any number of records may be handled in accordance with the method described above.

The foregoing example presented an embodiment in which clustering of records is performed so as to improve a cluster quality parameter calculated as a sum of a weighted first and a weighted second precision factor, each precision factor being associated with a respective first and second metadata parameter. The method may be readily applied to more or fewer precision factors and metadata parameters. In an embodiment, for example, a single metadata parameter and associated selected precision factor is considered, and assignment of records to cluster containers during a clustering operation is made so as to maximize an average value of the selected precision factor. In a further embodiment, a cluster quality parameter may be calculated and optimized based on a sum of several respectively weighted precision factors.

In some embodiments, a cluster container may be designated as a "trash" container. Referring now to Fig. 3b, such a trash container 311 may be designated to gather outliers, i.e., records which do not fit well enough in any other cluster container within set 302. The criteria for classifying a record as an outlier that should be placed in trash container 311 may be based on a history of changes in one or more precision factors obtained as a result of prior assignments of new records to cluster containers. When the result of placing a record in a container other than trash container 311 would be a decrease in the precision factors to a degree sufficiently higher than historical changes to the precision factors, then the record may, instead, be advantageously placed in trash container 311.

In yet a further embodiment, trash container 311 may also gather records already located in another cluster container, when that other cluster container remains unchanged (or, "stuck") during a portion of a clustering operation of a sufficiently large number of records. In such event there may be a high probability that the "stuck" cluster container will remain unchanged and unfinished until the end of the clustering operation, resulting in no clusters produced. In such a case, it may be advantageous to empty the records from the stuck cluster container into trash container 311, with the expectation that such emptied cluster container will work better for the remaining portion of records to be clustered. A precision factor for clusters 313 resulting from the trash container 311 will usually be very low. However, precision factors of other clusters will likely significantly increase as a result of placing into the trash container 311 the major portion of data from various types of outliers. By judicious selection of criteria for moving records to the trash container 311 , a percentage of clusters being moved to the trash container may be kept relatively low, and an improvement of average value of precision factors across the database may be achieved.

Embodiments of the method further provide for adjustment of the size and quantity of cluster containers. For example, a selected quantity of cluster containers may be adjusted downward when speed of executing the method is below a threshold, and adjusted upward when a value of the selected precision factor is below a threshold. Moreover, the quantity of cluster containers may be adjusted based on a weighted function of the speed and the selected precision factor when both are below a threshold.

Other embodiments may include repetition of a clustering operation when a change occurs to the RDB and/or to parameters related to the RDB. For example, a clustering operation may be repeated after a change to an existing record, addition of a record, and/or deletion of a record. As a further example, a clustering operation may be repeated upon occurrence of a change resulting from execution of a database query (e.g., a database query inserting, updating or deleting some records. In addition, a clustering operation may be repeated upon occurrence of a change in value of a metadata parameter resulting from statistics of previously calculated metadata parameters.

Processing Arrangement;

Referring now to Figure 6, a processing arrangement 600 for carrying out an embodiment will be described. Processing arrangement 600 is described with reference to functional program modules for the purpose of illustration only. When implemented, one or more of these functional modules may be combined into a single program module or may include two or more sub-modules. Processing arrangement 600 may interface with a client application (also referred to as a client) 202 providing a query tool executed on a user terminal (not shown). Processing arrangement 600 may be coupled to a database storage 201, which may be implemented using SQL (Structured Query Language), and may provide an interface, such as an SQL interface, to query tools for use via the client application 202. The SQL interface may manage the creation and management of database objects like tables, views and user permissions to those tables. Although only one client application 202 is shown, multiple client applications 202 may be connected to the processing arrangement 600. The client application 202 may provide a user interface (not shown) through which SQL requests and responses may be sent and received between the client application 202 and the processing arrangement 600. Processing arrangement 600 may include, for example, a query parser 204, a query representation optimizer 206, a query optimizer 208 and a query execution module 210.

Processing arrangement 600 may also include functional program modules such as: connectors, connection pool, management services and utilities, caches and buffers, a file system, and the like. The functionality of these program modules will be understood by a person of ordinary skill in the art and so will only be briefly described. The connectors may provide various mechanisms/protocols for external tools to connect to the database. The connection pool may manage multiple clients connecting and making requests to the database. The connection pool may manage the concurrency of many requests competing for resources. The management services and utilities are supporting tools that may be used with the data to manage administration, settings, users, and the like. The caches and buffers are lower level services that may be provided to all the system components which manage data in memory (e.g., Random Access Memory (RAM)) for query responses and optimizations among other functions. The file system may manage the storage device.

During or prior to query execution, data records received from external data sources 203 may be clustered by data clustering module 205. During an initial clustering operation (or clustering of new data), for example, data clustering module 205 may receive a data stream from external data sources 203. Alternatively, during a second or other subsequent operation, data clustering module 205 may receive a data from decompression module 246. In performing a data clustering operation, data clustering module 205, interacts with metadata parameter statistics 242 and metadata parameters manager 220. For example metadata parameter statistics 242 may provide data clustering module 205 with information about metadata parameter weighting factors. Moreover data clustering module 205 may optimize a clustering operation based on metadata parameter information provided by metadata parameters manager 220.

Outputs of a completed clustering operation and/or contents from a filled cluster container may be outputted by data clustering module 205 to load/reload module 248. Load/reload module 248 may perform compression, file storage, and recomputation of metadata parameters, for example, and may output the results of these steps to database storage 201. Database storage 201 may include one or more data clusters 221. In some embodiments, database storage 201 may store a column-oriented database, and the data clusters 221 may each represent column data from a base table. The data clusters 221 may include compressed data representing the records or entries in the respective column. Database storage 201 may provide for partitioning on one or more data storage devices (not shown) such as a hard disk drive (HDD) or other suitable storage medium, which may be a permanent (i.e., non-volatile) storage medium. Depending on the size of a column, the column data may be stored in more than one cluster (e.g., if there are more than 65.5K records). The data clusters 221 may contain more or less records than discussed here, depending on the application.

Information about data elements in a data cluster 221, such as basic statistical or analytical information, may be stored as a metadata parameter 222 associated with each data cluster 221 in the metadata parameter storage 224. In some embodiments, there may be one metadata parameter 222 for each data cluster 221. Each metadata parameter 222 may contain basic information (e.g., statistics) about some aspects of its respective data cluster 221. The particular information maintained in metadata parameter 222 for each data cluster 221 may depend on the particular type of data within the respective data cluster

221 (e.g., on whether the data consists of alphanumeric strings, numeric, floating point, or binary values). Typically, the size of each metadata parameter 222 may be small and so the metadata parameter 222 may not be compressed. However, if the information contained in metadata parameter 222 becomes more complex or large, metadata parameter

222 may be compressed.

As an example, metadata parameters 222 for data clusters 221 may include: the number of non-null values for at least one column in the respective data cluster 221, the minimum and maximum values for at least one column in the respective data cluster 221 , and the sum of values for at least one column in the respective data cluster 221. In the case of non-numerical columns, the lexicographic minimum and maximum or the largest common prefix (e.g., the longest sub-string that is common to all strings) for a data cluster 221 may be stored. If all non-null values for a column in the data cluster 221 are the same, the metadata parameter 222 corresponding to that column may store only statistical information, in which case only the position of nulls may be stored in a file for that column within the cluster. In some embodiments, additional or different information may be included in the metadata parameter 222. Further, other information about the respective data cluster 221 may be derived from the information in the metadata parameter 222. For example, the average value may be derived directly from the number of non-null values and the sum of values which are both stored in the metadata parameter 222.

As previously discussed, metadata parameter 222 may be used in query planning and execution, and may allow minimization of the need to access the data stored in the respective data cluster 221 during query execution, as will be described in more detail below. Metadata parameters may also be used for optimized scheduling of data access by, for example, optimizing the usage of memory buffers, processing the data in a way so as to find query resolution faster, and the like.

Database storage 201 may also have indices based on the data clusters 221 analogous to database indices based on records. Most standard database indices may be adapted for the processing arrangement 600 to be based on the data clusters 221 rather than records.

The processing arrangement 600 may further include a metadata parameter manager 220 and a metadata parameter optimizer 240. The metadata parameter manager 220 may be a functional program module that may manage the metadata parameters 222. The metadata parameter manager 220 works with the query optimizer 208 and metadata parameter optimizer 240. The metadata parameter manager 220 may generate, modify and remove metadata parameters 222 based on instructions from the metadata parameter optimizer 240. The metadata parameter manager 220 may also be responsible for informing the query optimizer 208 about the available metadata parameters 222 and may load them into memory from storage (e.g., HDD) as necessary. When loaded into memory, the query optimizer 208 may use information from the metadata parameters 222 to determine the optimum query execution plan. Once loaded into memory the metadata parameters 222 may also be used in the execution of the query execution plan as will be explained in more detail below.

The metadata parameter optimizer 240 may be a functional program module that may be used to determine an optimum set of metadata parameters 222 based on metadata parameter usage and quality statistics 242 obtained from the metadata parameter manager 220.

Metadata parameter usage and quality statistics 242 may store information about the frequency and/or kind of usage (e.g., relevant, irrelevant, partially relevant) of metadata parameters 222 and data clusters 221. Data cluster usage statistics may influence compression/speed ratios for particular data clusters 221 and influence which data clusters 221 are loaded directly into memory. Metadata parameter usage and quality statistics 242 may also be used to vary the content of the metadata parameters 222 for particular data clusters 221. Moreover, metadata parameter usage and quality statistics 242 may be used to characterize the respective data clusters 221 of the data being queried.

Using the metadata parameter usage and quality statistics 242, the metadata parameter optimizer 240 may update the optimal set of metadata parameters 222. If metadata parameters 222 do not exist over a desired data range, the metadata parameter optimizer 240 may determine that creation of one or more metadata parameters 222 would improve query execution. In this case, the metadata parameter optimizer 240 may instruct the metadata parameter manager 220 to create one or more metadata parameters 222 of a given type (e.g., create a histogram for a given data cluster 221, for a plurality of data clusters 221, or for a column of data consisting of two or more data clusters). If metadata parameters 222 exist over a desired data range (e.g., for a given data cluster 221) but, for example, the metadata parameters 222 cannot be used to answer the most frequent queries over this range, the existing metadata parameters 222 may be modified (e.g., a histogram resolution may be changed) or new metadata parameters 222 may be created in order to provide sufficient statistics to satisfy such queries. In this case, the metadata parameter optimizer 240 may instruct the metadata parameter manager 220 to modify or create the relevant metadata parameters 222. If metadata parameters 222 exist, but the relevant data is infrequently or never queried, and hence the relevant metadata parameter 222 is infrequently or never queried, these metadata parameters 222 may be deleted. In this case, the metadata parameter optimizer 240 may instruct the metadata parameter manager 220 to delete the relevant metadata parameters 222. If such data becomes accessed or queried more frequently in the future, this may be detected by the metadata parameter optimizer 240, which may instruct the metadata parameter manager 220 to start (re)creating relevant metadata parameters 222 if doing so will improve query performance.

The metadata parameter optimizer 240 provides an improved collection of metadata parameters 222, that is, metadata parameters that cooperate with each other in an improved way in resolving queries. For example, two particular metadata parameters may be far more valuable than other metadata parameters. However, it may only be necessary to retain and store one of those two metadata parameters because they usually aid in resolving the same queries with the same data clusters. In such a case, it is possible to store only one of those two best metadata parameters since they are somewhat redundant. Instead of storing the second metadata parameter, it may be beneficial to generate another more complementary metadata parameter that may be helpful with other queries or data clusters.

Query parser 204 may receive SQL queries, sometimes referred to as requests or SQL statements, from client application 202. Query parser 204 parses or separates the SQL query received from the client application 202 and converts it into an internal representation usable by the processing arrangement 600. Query parser 204 may forward this internal representation to query representation optimizer 206.

Query representation optimizer 206 may perform a syntactical optimization of the query. Query representation optimizer 206 replaces any references to views with references to the underlying base tables and reformats the query to attempt to make it easier to execute based on the structure of the query request. Query representation optimizer 206 may forward this optimized representation to the query optimizer 208.

Query optimizer 208 may optimize the query for execution using analytical information from the metadata parameters 222 relating to the underlying data (e.g., column, table, or view described in the original SQL query) provided via the metadata parameter manager 220, and from intermediate query results obtained from the query execution module 210 as will be described in more detail below. The query optimizer 208 may prepare the query for execution by preparing a query execution plan. If intermediate query results are obtained from the query execution module 210, the query optimizer 208 may modify the initial query execution plan based on these intermediate results. The query optimizer 208 may forward the initial and any modified query execution plans to the query execution module 210 for execution.

Query execution module 210 may execute the initial and any modified query execution plans provided by query optimizer 208. Query execution module 210 may also be coupled to the metadata parameter manager 220 so as to provide access to the analytical information of the metadata parameters 222 for use in answering the query. Query execution module 210 may, if the query cannot be resolved solely from the basic and/or advanced analytical information in the metadata parameters 222, use retrieved data from storage (e.g., HDD) by decompressing the relevant data clusters 221 in the database storage 201 using a decompression module 246. A file system (not shown) may be responsible for storing and retrieving data from data clusters 221 in storage and compressing or decompressing the data clusters 221 as required. The processing arrangement 600 may further include load/reload module 248.

Load/reload module 248 may receive data clusters 221 from data clustering module 205. As part of the encoding/decoding operation, the data in the data clusters 221 may be compressed by the compression module 252 in the load/reload module 248. The load/reload module 248 may also produce metadata parameters by way of metadata creation module 256 in the load/reload module 248.

The database content and metadata may be stored in several types of files: (1) column description files; (2) data cluster description files; (3) data files; and (4) metadata parameter description files. Column description files contain a description of the column which may include: its data type, metadata parameter information, and data cluster localization.

In some embodiments, there are data cluster description files in addition to the column description files, in which case the column description files may contain information on the data type and basic statistics of the column (e.g., information as to whether each record has a unique value, a dictionary of values if a column has small number of distinct values, or others), and the data cluster description files may contain metadata parameter information.

The data files contain the compressed column data. The data files may be stored with the column description file, although they may be stored in a different location (e.g., different storage device, etc.). In some aspects, the data files may be limited to 2 GB in size, or some other suitable size depending on the application. When reading data from a data cluster 221, the file system may only need to decompress the parts of the data files associated with data elements related to the values of the relevant column in the relevant data cluster 221.

The metadata parameter description files store information about the metadata parameters 222. Each metadata parameter description file describes a separate metadata parameter 222, allowing individual metadata parameters 222 to be created, modified, or removed by the metadata parameter manager 220 without affecting other objects, such as other metadata parameters 222. This may improve the ability to manage (e.g., by creation or deletion of metadata parameters 222) the metadata parameters 222 of the database 201. The metadata parameter description files may be stored on the same or different storage device (e.g., HDD) as the column description files and data files. The metadata parameter description files are loaded into memory on the first use of the metadata parameters 222, however the metadata parameter manager 220 may load and remove metadata parameters

222 from memory in accordance with usage of such metadata parameters 222. The metadata parameter description files are not necessary for data decoding, and may therefore be lost or restored at any time.

All of the data files may be subject to memory management. Once the column metadata (e.g., column description files), data cluster 221 or metadata parameter 222 is loaded into memory, it may be kept in memory as long as it is being used, and may be kept by the memory manager for future use. When the available memory becomes low, the less used objects may be removed from memory, as managed by the metadata parameter manager 220.

Thus, a method of organizing a RDB to perform a clustering operation on records of the RDB has been disclosed, whereby a number of clusters are created, at least one of which being characterized by a selected metadata parameter, and the clustering operation optimizes a calculated value of a selected precision factor for the selected metadata parameter.

Embodiments of the present invention involve computer software and hardware, for example in the form of servers, point of sale terminals, personal computers, mobile computer-based devices, mobile phones, and the like. Such devices and software generally execute algorithms which implement methods that are embodiments of the present invention. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it will be appreciated that throughout the description of the present invention, use of terms such as "processing", "computing", "calculating", "determining",

"displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Various embodiments of the present invention may be implemented with the aid of computer-implemented processes or methods (a.k.a. programs or routines) that may be rendered in any computer language including, without limitation, C#, C/C++, Fortran, COBOL, PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), and the like, as well as object-oriented environments such as the Common Object Request Broker Architecture (CORBA), Java™ and the like. In general, however, all of the aforementioned terms as used herein are meant to encompass any series of logical steps performed in a sequence to accomplish a given purpose.

The present invention can be implemented with apparatus to perform the operations described herein. This apparatus may be specially constructed for the required purposes, or may comprise a general-purpose computer, selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

The algorithms and processes presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method. For example, any of the methods according to the present invention can be implemented in hard- wired circuitry, by programming a general-purpose processor or by any combination of hardware and software. One of ordinary skill in the art will immediately appreciate that the invention can be practiced with computer system configurations other than those described below, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, DSP devices, network PCs, minicomputers, mainframe computers, and the like. The invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. The required structure for a variety of these systems will appear from the description below. Thus, methods and systems for optimizing the organization of a relational database so as to improve the efficiency of executing search queries on the database have been described.

Claims

CLAIMSWhat is claimed is:

1. A method of organizing a relational database having a plurality of records, said method comprising: using a processing arrangement to perform a clustering operation on the records so as to create a plurality of clusters, at least one of said plurality of clusters characterized by a selected metadata parameter, wherein said clustering operation optimizes a calculated value of a selected precision factor for the selected metadata parameter.

2. The method of claim 1, wherein the selected metadata parameter is selected to optimize execution of a database query.

3. The method of claim 1, wherein the value of the selected precision factor is related to efficiency of execution of a database query.

4. The method of claim 1, wherein the selected metadata parameter characterizes a corresponding data unit, said data unit comprising a plurality of data elements in the database, by identifying at least one of: a minimum value of all data elements in the data unit; a maximum value of all data elements in the data unit; a number of non-null values found within the data elements in the data unit; a histogram mapping an occurrence of at least one value in the data unit; total value of the data elements in the data unit information about occurrence of a character in an alphanumeric string; information about correlation of the data elements in the data unit with at least one data element of at least one other data unit; and common occurrence of at least one value in the data unit and in the at least one other data unit.

5. The method of claim 1, wherein, the precision factor comprises a measure of effectiveness of the metadata parameter in maximizing efficiency of a database query.

6. The method of claim 1, wherein the clustering operation comprises a first clustering operation and a second clustering operation, wherein said second clustering operation is performed only when said second clustering operation is predicted to improve the value of the selected precision factor by at least a selected threshold amount.

7. The method of claim 6, wherein: the selected metadata parameter is a first selected metadata parameter and the at least one of said plurality of clusters is characterized by the first selected metadata parameter and a second selected metadata parameter, wherein the selected precision factor is a first selected precision factor for the first metadata parameter and a second selected precision factor for the second metadata parameter; the first selected metadata parameter has a first weighting factor applied to the first selected precision factor and the second selected metadata parameter has a second weighting factor applied to the second selected precision factor ; a cluster quality parameter comprises a sum of the weighted first selected precision factor and the weighted second selected precision factor; and each of the first and second clustering operations improves the cluster quality parameter.

8. The method of claim 7, wherein each of the first weighting factor and the second weighting factor is at least one of (i) a default value, (ii) a manually set value, (iii) automatically recalculated during the regrouping step.

9. The method of claim 7, wherein a value of at least one of the first weighting factor and the second weighting factor is selected based on an estimated correlation between said associated metadata parameter and query execution efficiency.

10. The method of claim 7, wherein at least one of the first weighting factor and the second weighting factor is automatically recalculated by applying a weight derived from a previous iteration of the method.

11. The method of claim 10, wherein: at least one calculated value of at least one of the first selected precision factor and the second selected precision factor is recorded; and at least one of the first weighting factor and the second weighting factor is automatically recalculated while performing the second clustering operation using a statistical value derived from the corresponding at least one recorded first selected precision value and second selected precision value.

12. The method of claim 7, wherein performing a clustering operation comprises: assigning a first record to a first cluster container, said first cluster container being one of a selected number of cluster containers; assigning each subsequent record to a selected one of (a) the first cluster container and (b) a different cluster container, said selection being made so as to improve the cluster quality parameter.

13. The method of claim 1, further comprising repeating the method when a change occurs to at least one of the relational database and parameters related to the relational database.

14. The method of claim 13, wherein the change comprises at least one of a change to an existing record, addition of a record, deletion of a record.

15. The method of claim 13, wherein the change comprises a change in value of at least one of a metadata parameter, a precision factor, a weighting factor, and a cluster quality parameter.

16. The method of claim 15, wherein the change in value results from executing a database query.

17. The method of claim 15 wherein the change in value is based on statistics of previously calculated metadata parameters.

18. The method of claim 1, wherein performing a clustering operation comprises: assigning a first record to a first cluster container, said first cluster container being one of a selected number of cluster containers; assigning each subsequent record to a selected one of (a) the first cluster container and (b) a different cluster container, said selection being made so as to maximize an average value of the selected precision factor.

19. The method of claim 18, further comprising: adjusting the selected number of cluster containers in response to at least one of (i) a speed of executing the method and (ii) the selected precision factor average value.

20. The method of claim 19, wherein the quantity of cluster containers is adjusted downward when the speed is below a threshold.

21. The method of claim 19, wherein the quantity of cluster containers is adjusted upward when the value of the selected precision factor is below a threshold.

22. The method of claim 19, wherein the quantity of cluster containers is adjusted based on a weighted function of the speed and the selected precision factor when both are below a threshold.

23. The method of claim 18, wherein each cluster container has a selectable maximum size and further comprising adjusting, responsive to at least one calculated value of a precision factor of said cluster container, the selected maximum size of said data container.

24. The method of claim 23, wherein, when a total number of records assigned to a cluster container corresponds to the selectable maximum size of the cluster container, a data cluster is formed from said records, and said cluster container is emptied and enabled to be assigned additional subsequent records.

25. The method of claim 18, wherein said selection is made so as to improve a cluster quality parameter, said cluster quality parameter comprising a product of a weighting factor and the selected precision factor, said weighting factor corresponding to an average historical value of the selected precision factor.

26. The method of claim 18, wherein said selected number of cluster containers comprises a designated trash container and said step of assigning each subsequent record comprises: assigning each subsequent record to a selected one of (a) the first cluster container, (b) the trash container, and (c) a different cluster container.

27. The method of claim 26, wherein a record is assigned to the trash container when a result of assigning said record to any other container is found to decrease the average value of the selected precision factor more than a threshold amount.

28. The method of claim 26, wherein, when a total number of records assigned to a cluster container remains unchanged during a portion of a clustering operation, said portion exceeding a specified number of records, said cluster container is emptied and said total number of records is moved to the trash container.

29. A method of organizing a relational database, said method comprising:

(i) duplicating a plurality of records in said relational database so as to create at least a first and a second plurality of records, said first plurality of records being identical to said second plurality of records; (ii) performing a first clustering operation on each of the first plurality of records and second plurality of records so as to create a first plurality of clusters and a second plurality of clusters, each said cluster in the plurality of clusters characterized by at least one respective metadata parameter, each respective metadata parameter having an associated precision factor, each said associated precision factor having a respective weighting factor applied thereto, wherein said first clustering operation maximizes a calculated value of a weighted selected precision factor; and, responsive to a database query,

(iii) executing said database query on a selected one of the first plurality of records and second plurality of records, said selection being made on the basis of a correlation between a property of the query and the calculated value of the selected precision factor for each of said first plurality of records and second plurality of records.

30. A method of executing a query of a relational database, said relational database having a plurality of records, said method comprising: using a processing arrangement to perform a clustering operation on the records so as to create a plurality of clusters, at least one of said plurality of clusters characterized by a selected metadata parameter, wherein said clustering operation optimizes a calculated value of a selected precision factor for the selected metadata parameter; using the at least one metadata parameter to optimize the query; and returning a response to the query.

31. A computer-usable medium having computer readable instructions stored thereon for execution by a processor to perform a method of organizing a relational database having a plurality of records, said method comprising: performing a clustering operation on the records so as to create a plurality of clusters, at least one of said plurality of clusters characterized by a selected metadata parameter, wherein said clustering operation optimizes a calculated value of a selected precision factor for the selected metadata parameter.