Confidence-based database management systems and methods for use therewith

Abstract

A method for execution by one or more database storage nodes of a database management system includes obtaining a row of data that includes a plurality of columns. The method further includes generating a data confidence value for data within one or more columns of the plurality of columns. The method further includes storing the data confidence value in a memory of the database management system.

Description

FIELD OF THE DISCLOSURE

The present invention generally relates to a system and method for organizing and managing large volume of data, and more particularly relates to a massively parallel database management system optimized for managing time based data. More particularly still, the present disclosure relates to a manifest and a silo system in a massively parallel database management system, and a database system storing both data and data confidence.

DESCRIPTION OF BACKGROUND

With rapid development and widespread utilization of computer technologies in the last few decades, large volumes of digital data are generated on a daily basis. Organizing and managing such a huge amount of data has promoted the development of database technologies. Relational database management systems (“RDBMS”), such as Oracle Database Management System, Microsoft SQL Database Management System and MySQL Database Management System, have thus been proposed and gained broad acceptance for data management. Such database management systems store data by rows of tables. Querying and retrieving data from the conventional databases oftentimes include retrieving a list of records while such records contain information that is not requested. For example, the illustrative SQL query causes a conventional database management system to read all fifty rows from a disk drive storing the rows:

• • select column1 from table1 where key>100 and key<151

In the illustrative SQL query, column1 is a column of a table 1, and key is another column (such as a primary key) of the table 1. While only data in column1 is requested, data in other columns of table1 is already read from a storage disk drive. Furthermore, the conventional database management systems do not store data in an ordered manner on physical disk drives. However, many types of data (such as network logs, network access data, financial transaction data, weather data, etc.) are of extremely high volume and ordered by time. Accordingly, there is a need for a highly parallel and efficient database system that is optimized for managing large volumes of time based data. There is a further need for a highly parallel and efficient database system for storing data by columns for faster and more efficient data retrieval.

Conventional database management systems typically generate a large number of indexes for data. Such indexes logically identify rows (also referred to herein as records). Rows of data within a table are stored on disk drives. Related rows, such as rows of a particular order by time, are usually not consecutive stored on disk drives. Rows could also be related by other factors. Retrieving a set of related records thus involves multiple disk reads of data dispersed at different locations on a disk drive. Accordingly, there is a need for a highly parallel and efficient database system for storing related data consecutively or nearby on a disk drive to reduce the number of disk reads in serving a data request, and providing an efficient structure for locating such data on a disk drive. There is a further need for the new database management system to load the structure in memory for higher performance in locating data on disk drives.

To improve data retrieval performance, conventional database management systems take advantage of high end hardware platforms, such as a computer with multiple sockets and a large amount of memory. Each of the sockets includes one or more processing units (also interchangeably referred to herein as cores). A processing unit housed in one socket can access resources (such as disk drives and memory) local to another socket. Such cross socket access incurs a performance penalty due to latency and bandwidth limitations of the cross-socket interconnect. Accordingly, there is a need for a highly parallel and efficient database management system that improves performance by avoiding the cross socket boundary access. The present disclosure incorporates novel solutions to overcome the above mentioned shortcomings of conventional database management systems.

Objects of the Disclosed System, Method, and Apparatus

Accordingly, it is an object of this disclosure to provide a parallel database management system optimized for managing large volumes of time based data.

Another object of this disclosure is to provide a parallel database management system with silo systems that utilize only local resources for faster performance.

Another object of this disclosure is to provide a parallel database management system with silo systems that utilize only local resources to avoid latency and bandwidth limitations inherent in interconnect access.

Another object of this disclosure is to provide a parallel database management system with silo systems that utilize only local memory and local disk drives for faster performance.

Another object of this disclosure is to provide a parallel database management system with a signal rich manifest describing physical location of data stored on a disk drive for locating the maximum amount of data while taking the least amount of memory and disk space.

Another object of this disclosure is to provide a parallel database management system with a hierarchical manifest describing physical location of data stored on a disk drive for faster data retrieval from a storage disk by direct reads.

Another object of this disclosure is to provide a parallel database management system with a manifest for each segment.

Another object of this disclosure is to provide a parallel database management system with a manifest stored in each segment.

Another object of this disclosure is to provide a parallel database management system with a manifest stored at end of each segment.

Another object of this disclosure is to provide a parallel database management system with a hierarchical manifest in a physically backed memory region for faster access minimizing page faults.

Another object of this disclosure is to provide a parallel database management system with a hierarchical manifest organizing data by cluster keys.

Another object of this disclosure is to provide a parallel database management system with a hierarchical manifest organizing data by time based data buckets for each cluster key.

Another object of this disclosure is to provide a parallel database management system with a hierarchical manifest organizing data by time based data buckets of equal time frames.

Another object of this disclosure is to provide a parallel database management system with time based data stored on disk drives based on the order of time stamps of the data.

Another object of this disclosure is to provide a parallel database management system with time based data of different time periods stored in different segment groups.

Another object of this disclosure is to provide a parallel database management system with data records stored by columns for faster performance in retrieving data from physical disk drives.

Another object of this disclosure is to provide a parallel database management system with data records stored by columns for reducing reads of physical disk drives in data retrieval.

Another object of this disclosure is to provide a parallel database management system with data records stored by columns in coding blocks of different coding lines on a segment to allow fewer reads in data retrieval.

Another object of this disclosure is to provide a parallel database management system to store data records by columns in a segment with a manifest indicating the location of the data on the physical disk drive of the segment for faster data retrieval.

Another object of this disclosure is to provide a parallel database management system to store a data record along with a confidence about the accuracy of the data record.

Another object of this disclosure is to provide a parallel database management system that prioritizes analytical calculations on large datasets.

Another object of this disclosure is to provide a parallel database management system that prioritizes analytical calculations on large datasets based on characteristics of the analytical calculations and characteristics of the dataset.

Another object of this disclosure is to provide a parallel database management system that prioritizes an analytical calculation based the rank of a similar analytical calculation based on characteristics of the two analytical calculations.

Other advantages of this disclosure will be clear to a person of ordinary skill in the art. It should be understood, however, that a system or method could practice the disclosure while not achieving all of the enumerated advantages, and that the protected disclosure is defined by the claims.

SUMMARY OF THE DISCLOSURE

Generally speaking, pursuant to the various embodiments, the present disclosure provides a massively parallel database management system for managing massive volumes of data. In particular, massively parallel database management system is optimized for managing time based data. A database management software application running in user space directly accesses a disk drive to store and retrieve data for faster performance. The time based data is stored in coding blocks of segments of a segment group of a cluster. Coding blocks of different segments within the same segment group are grouped in coding lines. The cluster includes a set of nodes, each of which includes one or more storage disk drives. Each disk drive includes one or more segments.

Each node includes one or more sockets while each socket houses a set (meaning one or more) of processing units. A socket and its processing units are operatively coupled to a set of local resources, such as a local memory, a local disk drive and a local network interface card. A processing unit accesses the local devices at a higher speed than accesses to remote devices that are local to a different socket. The two sockets are interconnected by an interconnect interface. The cross socket access is slower due to latency and bandwidth limitation in the interconnect interface. A socket, the process units housed in the socket, physical devices local to the socket and an operating system running on the processing units are termed herein as a silo. The massively parallel database management system implementing the silo oriented computing achieves faster performance due to the fact that the data management processing within different silos uses only local devices. Data management threads are pinned to specific processing units with a silo such that the threads only access local memory and other local resources.

For improved performance in data retrieval reads and data storing writes, the novel data management system accesses disk drives directly without going through middle layers, such as a file system of an operating system. The data management system software application maintains a manifest to track the exact physical location where a particular piece of data is stored in a segment of a physical disk drive. The manifest embodies a compact structure such that it minimizes storage overhead for relational information in a segment while occupying a small footprint. The manifest is thus optimized to occupy less memory and disk drive space while providing the maximum amount of signal. The manifest is stored, for example, at the end of each segment while data is stored in coding blocks from the beginning of the segment.

Since data requests usually demand data in certain columns, but not all columns of data records, the database management system software application further improves on conventional technologies by storing data by columns in coding blocks on segments within a cluster. By retrieving only data of one or multiple columns, the number of reads is reduced because the amount of data read is less that the total amount of data within all of the relevant records. To further speed up data queries, different segment groups store time based data of different time periods. In such a case, a requested data record is first quickly narrowed to a segment group based on the time stamp of the data record.

The manifest indicates the location of data stored in the corresponding segment. The manifest organizes data records by cluster keys. For each cluster key, data is organized as data buckets of sequential, but not necessarily contiguous, time periods. The different time periods are of the same time duration (also referred to herein as time frame) in one implementation. For each data bucket, data is stored by columns, wherein each stored column is indicated by coding lines and storage byte offsets.

Further in accordance with various embodiments, the present teachings provide a database management system that stores data records along with confidence data. The confidence data indicates a confidence in the accuracy of a data record or data point. In addition, analytical calculations for analyzing large datasets are prioritized for effective data analysis. The prioritization can be based on characteristics of the analytical calculations and/or characteristics of a particular dataset. Furthermore, a rank of one analytical calculation is assigned to a similar analytical calculation. The ranks are determined based on, for example, execution results of the analytical calculations on the dataset.

Further in accordance with the present teachings is a method for managing data. The method is operated within a database management system and includes constructing a set of data records in a memory of the database management system. Each data record within the set of data records includes a set of data columns, and a confidence column. The confidence column includes a data confidence about the set of data columns. The method also includes storing the data records into a data storage device, and retrieving the set of data records from the data storage device. The data storage device includes a set of segments. The set of data records is stored in a segment within the set of segments. Moreover, the method includes analyzing data records within the set of data records by incorporating the data confidence within each data record within the set of data records.

BRIEF DESCRIPTION OF THE DRAWINGS

Although the characteristic features of this disclosure will be particularly pointed out in the claims, the invention itself, and the manner in which it may be made and used, may be better understood by referring to the following description taken in connection with the accompanying drawings forming a part hereof, wherein like reference numerals refer to like parts throughout the several views and in which:

FIG. 1 is a simplified block diagram of a node within a cluster of a highly parallel database management system in accordance with this disclosure.

FIG. 2A is a flow chart illustrating a process by which a node within a cluster of a highly parallel database management system implements silo oriented resource accesses in accordance with this disclosure.

FIG. 2B is a flow chart illustrating a process by which a node within a cluster of a highly parallel database management system implements silo oriented resource accesses in accordance with this disclosure.

FIG. 2C is a flow chart illustrating a process by which a node within a cluster of a highly parallel database management system implements silo oriented resource accesses in accordance with this disclosure.

FIG. 3 is a simplified block diagram depicting a segment with a manifest in accordance with this disclosure.

FIG. 4 is a table illustrating time stamp based data in accordance with this disclosure.

FIG. 5 is a simplified block diagram illustrating the layout of records stored in a segment in accordance with this disclosure.

FIG. 6 is a simplified block diagram illustrating a storage cluster of time based data in accordance with this disclosure.

FIG. 7 is a simplified block diagram illustrating a logical representation of a manifest in accordance with this disclosure.

FIG. 8 is a simplified block diagram illustrating the memory structure of a manifest 700 in accordance with the teachings of this disclosure.

FIG. 9 is a data record without 100% confidence of accuracy in accordance with the teachings of this disclosure.

FIG. 10A is a flowchart depicting a process by which a computer prioritizes analytical calculations in accordance with the teachings of this disclosure.

FIG. 10B is a flowchart depicting a process by which a computer prioritizes analytical calculations in accordance with the teachings of this disclosure.

A person of ordinary skills in the art will appreciate that elements of the figures above are illustrated for simplicity and clarity, and are not necessarily drawn to scale. The dimensions of some elements in the figures may have been exaggerated relative to other elements to help understanding of the present teachings. Furthermore, a particular order in which certain elements, parts, components, modules, steps, actions, events and/or processes are described or illustrated may not be actually required. A person of ordinary skill in the art will appreciate that, for the purpose of simplicity and clarity of illustration, some commonly known and well-understood elements that are useful and/or necessary in a commercially feasible embodiment may not be depicted in order to provide a clear view of various embodiments in accordance with the present teachings.

DETAILED DESCRIPTION

Turning to the Figures and to FIG. 1 in particular, a simplified block diagram of a node within a cluster of a highly parallel database management system is shown and generally indicated at 100. The database storage node 100 includes two sockets 106 and 108, each of which includes one or more processing units (also interchangeably referred to herein as cores and central processing units). The node 100 also includes a memory (such as 32 GB of DRAM) 110, a storage disk drive 114, and a networking interface (“NIC”) 118 that are operatively coupled to the socket 106. An operating system (such as Linux operating system) 122 runs on the processing units of the socket 106. The memory 110, the socket 106, the NIC 118 and the disk drive 114 are collectively referred to herein as a silo 102. The silo system 102 includes all processing units within the socket 106 and all the disk drives (such as the disk drive 114) operatively coupled to the socket 106. The node 100 further includes a memory 112, two storage disk drives 115 and 116, and a NIC 120 that are operatively coupled to the socket 108. The memory 112, the storage disk drives 115-116, and the NIC 120 are collectively referred to herein as a silo 104.

A specialized computer software 126 for managing data runs on the operating system 122. In one implementation, the operating system 122 is a single instance running on the sockets 106-108 of the node 100. In one implementation, the specialized computer software 126 programs each silo to perform a part of a task. The specialized computer software 126 can also program one silo (such as the silo 102) to perform one task, and another silo (such as the silo 104) to perform a different task.

The disk drives 114-116 are storage devices for storing data, and can be, for example, Non-volatile Random-Access Memory (“NVRAM”), Serial Advanced Technology Attachment (“SATA”) Solid State Drives (“SSDs”), or Non-volatile Memory Express (“NVMe”). As used herein, drives, storage drives, disk drives and storage disk drives are interchangeably used to refer to any types of data storage devices, such as NVRAM, SATA, SATA SSDs and NVMe. Each of the disk drives (such as the drives 114-116) has one or more segments. For ease of illustration, each of the disk drives 114-116 is said to include only one segment and interchangeably referred to as a segment herein. Segments within a cluster form a segment group.

The processing units within the socket 106 directly access the memory 110, the NIC 118 and the disk drive 114 over electrical interfaces, such as Peripheral Component Interconnect Express (“PCIe”). For example, the socket 106 directly accesses these physical devices via a PCIe bus, a memory control, etc. Similarly, the socket 108 directly access the memory 112, the NIC 120 and the disk drives 115-116.

In contrast, the processing unit(s) within the socket 108 accesses the memory 110, the disk drive 114 and the NIC 118 via an interconnection interface 152. Similarly, the processing unit(s) within the socket 106 accesses the NIC 120, the disk drives 115-116 and the memory 112 via the same interconnection interface 152. The access over the interconnection interface 152 between the sockets 106 and 108 is referred to herein as an indirect connection. In other words, a socket within each silo directly accesses physical devices within the same silo, and indirectly accesses physical devices within a different silo. Physical devices within one silo are said to be local to the silo and remote to a different silo.

In one implementation, the interface 152 is a QuickPath Interconnect (“QPI”) interface or an UltraPath Interconnect (“UPI”) interface. The indirect access between the silos 102-104 incurs a performance penalty due to latency inherent in indirect access. Furthermore, the interconnect interface 152 becomes a bottleneck in indirect access. In addition, the interconnect interface 152 has a bandwidth limitation. Accordingly, accessing remote devices over the interconnect interface 152 is less desirable. To overcome the performance issues imposed by the indirect access, the present teachings provide the specialized database management system software 126 to implement a silo oriented database system.

In the silo based data management system, the instance of the specialized database management system software 126, running on the processing unit(s) within the socket 106, accesses only the local resources, such as the memory 110, the NIC 118 and the disk drive 114 that are local to the socket 106 and all the processing units within the socket 106. Similarly, the instance of the software 126 running on the processing unit(s) within the socket 108 accesses only the NIC 120, the memory 112 and the disk drives 115-116 local to the socket 108 and all the processing units within the socket 108. In other words, the instance of the software 126 running on the socket 108 do not access the remotely connected physical devices 110, 114, 118 when, for example, data queries are performed. However, cross-silo access is possible in certain cases, such as system startup, shutdown and administrative actions. For instance, performance polling is an administrative action. It should be noted that the silo boundary based computing is programmed for a set of predetermined functionality. For example, for storing data into and retrieving data from a database and disk drives, the specialized program 126 limits its access to local devices and avoids remote access to a different silo. The silo boundary control is further illustrated by reference to FIGS. 2A, 2B and 2C.

Referring to FIGS. 2A, 2B and 2C, three flow charts illustrating processes by which the node 100 implements the silo oriented highly efficient database management are shown and generally indicated at 200A, 200B and 200C respectively. The processes 200A-200C are performed by the specialized database management program 126. The process 200A is initiated when the program 126 is loaded and run by the processing units within a socket of a silo, such as the socket 106 of the silo system 102. In one implementation, the software program 126 runs as a process in the silo 102. The process includes one or more threads. The threads within the process share the same virtual address space and can all access the same physical resources (such as memory and other physical devices). At 202, the specialized database management software 126 determines the identification of a list of local devices, such as the processing units within the socket 106, the memory 110, the disk drive 114 and the NIC 118. For instance, the software 126 queries the operating system 122 for identification and other information of the list of local devices. Each physical device within the list can be identified by, for example, a name or a handle.

At 204, the special software program 126 performs a specialized memory allocation to allocate a huge page of the memory 110. The huge page is a big swatch of memory (such as 1 GB) that is a virtual memory region. The huge page is physically backed by the memory 110. In other words, the virtual memory region corresponds to a region of the same size on the memory device 110. Multiple accesses to the virtual memory region result in the same physical region being accessed. A processor maintains a cache of virtual-to-physical page mappings (i.e., the Translation Lookaside Buffer (“TLB”)); and by utilizing a huge page the special software is able to address larger regions of memory with fewer TLB cache entries. The physically backed huge page is also referred to herein as a physical huge page of memory. The physically backed huge page is within the silo boundary, and corresponds to a segment manifest.

At 206, the specialized software program 126 loads a segment manifest into the physically backed huge page. The manifest describes a hierarchical structure indicating the location of data in the segment (such as the disk drive 114). In one implementation, each segment stores a manifest. A segment with a manifest is further illustrated by reference to FIG. 3.

Turning to FIG. 3, a simplified block diagram depicting a segment 114 with a manifest 302 is shown. In the segment 114, data is stored in coding blocks, such as the coding blocks 312-318. Coding blocks are written into the segment 114 in a sequential order starting from the beginning of the segment 114. In one implementation, the manifest 302 of the segment 114 is stored at the end of the segment 114. In one embodiment, the manifest 302 occupies a fixed size of the disk space on the segment 114. As further described below, the manifest 302 contains the maximum amount of signal for a certain size of storage. The signal is data indicating information about other data, such as the physical location of a block of data within a storage drive.

Returning to FIG. 2A, the manifest resides in memory for the best performance in locating data stored in the local disk drive 114. At 208, the specialized database software 126 pins a thread within the process of the software 126 to one or more processing units (such as CPUs and cores) within the socket 106 via operating systems calls. For example, the calls include “pthread_setaffinity_np” and/or “sched_setaffinity” on a Linux operating system. Operations (such as searches) on the loaded manifest that are performed by the pinned thread are then only performed on the memory 110 within the silo 102, not the memory 112 that is remote to the silo 102.

Referring to FIG. 200B, at 222, the specialized database management software 126 receives a chunk of data for storing into the disk drive 114 via the NIC 118. The chunk of data is some amount of data, such as a set of time based data records of the same or different cluster keys. At 224, the pinned thread processes the chunk of data for storing it onto the disk drive 114. For example, the pinned thread places the chunk of data into an open coding block, and updates the manifest to reflect the exact location where the chunk of data is stored in the segment 114. When the open coding block is full, at 226, the pinned thread directly flushes the coding block into the segment 114. It should be noted that the updated manifest is also flushed to the segment 114 periodically or when certain events occur.

Referring to FIG. 200C, at 242, the specialized database management software 126 receives a request for a chunk of data, such as a set of columns of certain records. At 244, the pinned thread searches the manifest in the physically backed huge page to determine the location of the coding blocks containing the requested data in the segment 114. At 246, the pinned thread reads the coding blocks from the segment 114. At 248, the pinned thread returns the request chunk of data over the NIC 118. It should be noted that the processes 200B-200C directly accesses the disk drive 114 using its identification determined by the process 200A. Furthermore, the process 200C directly accesses the NIC 118 using its identification determined by the process 200A. Accordingly, the operations to store a chunk of data are performed within a single silo; and the operations for retrieving and returning a chunk of data are also performed within a single silo. The silo oriented database management thus provides superior performance and efficiency.

Many types of data are generated in great volumes and of similar or same formats. For example, a computer network logger produces large volumes of records of the same format. Each record includes a time stamp (meaning the time when the record is generated), a cluster key, and a number columns of other types of data. The cluster key can identify, for instance in network log data, a source IP address and a destination IP address. The source IP address is the IP address of the computer or device sending the data contained in the record, while the destination IP address is the IP address of the computer or device receiving the data contained in the record. Another example of the time based data is weather data. Such time stamp based data is uploaded to a database management system to be stored in disk drives, such as the disk drives 114-116. A logical representation of the time based data is further illustrated by reference to FIG. 4.

Referring to FIG. 4, a table illustrating time stamp based data is shown and generally indicated at 400. The data is represented as a list of records 0-M (M stands for a positive integer). Each record has a time stamp in column 0, such as Oct. 12, 2016, 19:03:01, CST. The time stamp may further include additional information, such as milliseconds. A time stamp can also be represented by an integer, instead of a text string. Column 1 of the table 400 contains the cluster key of each record. Columns 2 through N (N stands for a positive integer) contain other data of each record.

The records with the same cluster key are said to be related. Taking a network logger as an example, the cluster key is the pair of source IP address and the destination IP address. All records with the same cluster key are data sent from a particular computer or device to another particular computer or device, and are said to be related herein. The related records have different time stamps and are also ordered by the time stamps. For instance, records 0-500 have a same cluster key while records 501-1000 share a different cluster key.

To maximize the performance in serving requests for such data after it is stored on the disk drives 114-116, the present database management system stores the records 0-M based on columns, instead of rows. Data queries usually request one or more columns of certain records, such as records during a particular time period. Storing the records 0-M by columns allows the minimum amount of reads to retrieve the desired data from a disk drive. The column based data storage in the highly parallel database management system is further illustrated by reference to FIG. 5.

Referring to FIG. 5, a simplified block diagram illustrating the layout of records stored in the segment 114 is shown. A set of representative coding blocks of data are indicated at 502 through 538 with the coding blocks 506, 512, 518, 524, 530, 536 being the parity blocks storing parity information for the corresponding coding lines. Each coding block of the coding blocks 502-538 is associated with a coding line that encompasses all segments within a segment group.

For example, data of Column 0 of the records with cluster key 0 (meaning a first cluster key) during a particular time period is stored in coding block 502; data of column 1 of the records with cluster key 0 during the particular time period is stored in coding blocks 502-504; data of column 2 of the records with cluster key 0 during the particular time period is stored in coding blocks 504, 508-510; data of column 3 of the records with cluster key 0 during the particular time period is stored in coding blocks 510 and 514; data of column 4 of the records with cluster key 0 during the particular time period is stored in coding blocks 514-516, 520-522, 526; data of column 0 of the records with cluster key 1 during the particular time period is stored in coding block 526; data of column 1 of the records with cluster key 1 during the particular time period is stored in coding blocks 526-528; etc. Records of the cluster key 0 (as well as the cluster key 1) during the particular time period are ordered by their corresponding time stamps from, for example, the oldest to the newest.

The time based data is sequentially stored in segments groups, each of which comprises a set of segments. A particular time period is mapped to a small fixed set of segment groups. For example, in one implementation, a particular time period is mapped to a unique segment group. As an additional example, a particular time period is mapped to two segment groups in a different implementation due to the fact that segment groups can overlap slightly in time at their boundaries. The mapping is further illustrated by reference to FIG. 6. Turning to FIG. 6, a simplified block diagram illustrating a storage cluster of time based data is shown and generally indicated at 600. The cluster 600 includes a set of nodes, of which two are indicated at 602 and 604. The node 602 includes data storage disk drives 606 (such as the drive 114), 608 and 610 while the node 604 includes disk drives 612, 614 and 616. The drive 606 includes a segment 622; the drive 608 includes three segments 624, 626 and 628; the drive 610 includes two segments 630 and 632; the drive 612 includes a segment 642; the drive 614 includes three segments 644, 646 and 648; and the drive 616 includes two segments 650 and 652. The illustrative cluster 600 includes segment groups 672, 674, 676, 678, 680 and 682. The segment group 672 includes the segments 622, 642 and other segments (not shown). As another example, the segment group 680 includes the segments 630 and 650.

The time based data between time TA and time TB is stored in the segment group 672; the time based data between time TB and time TC is stored in the segment group 674; the time based data between time TC and time TD is stored in the segment group 676; and so on. The time stamps TA, TB, TC, TD, TE, TF and TG are ordered from the oldest to the latest. Accordingly, when a data record is requested, the segment group storing the record is first determined based on the time stamp of the record. The time based storage of data in the cluster 600 thus provides an efficient and faster response to a data query. The lengths of different time periods, such as from TA to TB and from TB to TC, may differ.

When time based data records are received, a segment group and a segment within the segment group is first determined for storing the record. For example, a function is performed on the cluster key of the records to determine the segment group and the segment. The function is shown below:

• • function (cluster key)=segment group identifier and segment identifier

The data records are then forwarded to the node (such as the node 100) having the segment. The data records are then received by the target node. For example, the data record is received at 222 of the process 200B. The function (cluster key) enables even distribution data records between segments within a segment group.

For efficiently placing and searching the time based data records, a hierarchical manifest for each segment is created and managed by the specialized database management software 126. The manifest is further illustrated by reference to FIGS. 7 and 8. Turning first to FIG. 7, a logical representation of a manifest is shown and generally indicated at 700. Time based data is grouped by cluster keys (such as the cluster key 0 and the cluster key 1); and time based data of each cluster key is grouped into buckets based on time. For example, a first data bucket of the cluster key 0 includes data from time stamp TA1 to time stamp TA2; a second data bucket includes data from time stamp TA2 to time stamp TA3; and a third data bucket includes data from time stamp TA3 to time stamp TA4. In one implementation, the time period for each data bucket is the same. In other words, TA2−TA1=TA3−TA2=TA4−TA3.

Within each data bucket, data records are organized by columns starting from column 0 to column 1 to column 2, and so on. Taking the cluster key 0 as an example, the data in the column within the bucket of the period from TA1 to TA2 is stored in one or more coding blocks. The coding blocks are identified by a starting coding block number SL0, and an ending coding block number EL0. The coding block numbers SL0 and EL0 are also referred to herein as a starting coding block line and an ending coding block line. Accordingly, SL0 and EL0 identify one or more consecutive blocks on the segment storing the corresponding data. SB0 indicates the starting byte location from the beginning of the first coding block of the one or more consecutive coding blocks, while EB0 indicates the ending byte location from the beginning of the first coding block of the one or more consecutive blocks. In other words, the storage space starting from the byte at SB0 to the byte at EB0 in the one or more consecutive coding blocks store the data of the column of the time based records in the data bucket between TA1 and TA2 of the cluster key 0. A data bucket cannot be empty. If no data is present for a particular time period, no bucket is stored, and during retrieval the lack of a bucket is interpreted as there being no data for that time period. In one embodiment, the manifest is immutable; and, if changes are required, the entire manifest is regenerated.

Referring to FIG. 8, a simplified block diagram illustrating the memory structure of the manifest 700 is shown. Cluster keys are stored in memory slots 802, 804 and 806 (indicating multiple memory slots). Each of these slot further stores a location, such as offset from the beginning of the manifest 700, of the corresponding buckets for the associated cluster key. Taking cluster key 0 in the memory slot 802 as an example, the data bucket location information is pointed to by the location and stored in the memory slots 808, 810 and 812. Taking the first data bucket as an example, it is indicated in the memory slot 808, which contains the time stamps of the bucket and a location pointing to the column information of the bucket. The location points to the memory slot 822, which stores information (such as data type) of the column 0 and a location pointing to the memory slot 842. The memory slot 842 stores the starting coding line number (SL0), the ending coding line number (EL0), the starting byte offset (SB0) and the ending byte offset EB0. There could be more than one memory slot (such as the memory slot 842) corresponding to a particular column when the span of data for a key/column pair intersects with one or more parity blocks. In such a case, more than one memory slot is required to store the multiple non-contiguous sub-spans. The compact structure of the manifest 700 contains the maximum amount of signal about stored data while using the least amount of memory.

In one embodiment, the time based data is compressed before it is stored into a segment of the node 100. For instance, the data of column 3 of a particular data bucket of a particular cluster key is encoded. The compression can be optionally performed on some columns. For example, the compression is not performed on the time stamp and cluster key columns. The compression form can be, for example, Run-Length Encoding (“RLE”). In one implementation, the compression is performed at 224 of the process 200B.

Certain types of data, such as genomic base pairs in a genome sequence, are created in such a manner that the data value is not known to be 100% accurate. In other words, there is not a 100% confidence in the accuracy of such data. For instance, a gene sequencer may estimate that a genomic base pair at a given location is 90% likely to be C-G and 10% likely to be A-T. As an additional example, when network traffic data is collected, the accuracy of each data record may be affected by the bit error rate of the network hardware or some other reasons. When mathematical and statistical analysis is later performed on such data without 100% confidence in its accuracy, the confidence of the calculated output data would be affected by the less than 100% confidence in the network traffic data. Accordingly, in one embodiment, the confidence information about the data is stored in the database. When the data records are retrieved from the database system storing such records, the corresponding data confidence is also retrieved. The data confidence is further incorporated and considered in the analysis of the data records.

The data without 100% confidence in accuracy and the confidence information are further illustrated by reference to FIG. 9. Referring to FIG. 9, a data record without 100% confidence in its accuracy is shown and generally indicated at 900. The data record 900 includes columns 902 through 908. The confidence information is stored in one or more additional columns, such as the column 910. The data record 900 is first constructed in memory of a database management system computer and then stored in, for example, the segment 114.

Various datasets, such as network traffic data, financial transactions, and digital sensor data, are growing rapidly each day and becoming so large that humans can no longer examine such data and get a sense of what is unusual with such datasets. Accordingly, computers are needed to analyze these large datasets to determine whether any data abnormality are present. Computers generally analyze a dataset by performing analyses, such as calculating a standard deviation or a distance between data points. As used herein an analysis is also referred to as a calculation. On a large dataset, only a limited number of calculations could be effectively performed. Accordingly, prioritizing calculations to perform on large datasets is more desirable.

For example, it is beneficial to prioritize those next calculations of data abnormality in a dataset by prioritizing the calculations likely to complete faster. In a different implementation, future analytical calculations are prioritized based on how the results of previous calculations are scored. An analytical calculation similar to a previously executed calculation with high scoring results is also prioritized higher. In other words, the analytical calculation is assigned with the same priority score. The analytical calculation prioritization is further illustrated by reference to FIGS. 10A and 10B.

Referring to FIGS. 10A and 10B, two flowcharts depicting two processes by which a computer (such as the node 100) prioritizes analytical calculations are shown and generally indicated at 1000A and 1000B respectively. At 1002, a specialized software application running on the computer determines characteristics of a dataset. The characteristics include, for example, the number of records in the dataset and data types of columns of the records. At 1004, the software application determines a list of analytical calculations that may be executed on the dataset for determining any abnormality (such as errors, distorted data, data noise, etc.) in the dataset. At 1006, the software application prioritizes the list of analytical calculations based on the characteristics of a dataset and the characteristics of each analytical calculation in the list. For example, whether a calculation processes a dataset by performing only linear operations (such as comparisons) is a characteristic of the analytical calculation. As an additional example, whether a calculation processes a dataset by performing square root operations is a characteristic of the analytical calculation. Some characteristics deem the execution of a calculation on a dataset to be slower while others are faster. The prioritization associates a rank with each analytical calculation. At 1008, the software application selects the highest ranked analytical calculation from the prioritized list of analytical calculations. At 1010, the software application executes the selected analytical calculation on the dataset.

Referring now to FIG. 10B, at 1062, the software application executes each analytical calculation within a list of analytical calculations on a particular dataset. The list of analytical calculations includes one or more calculations. At 1064, the software application determines a result score of the execution of each analytical calculation on the dataset. At 1066, the software application ranks the list based on the scores. At 1068, the software application determines than an unlisted analytical calculation (meaning an analytical calculation that is not in the list) is similar to a listed analytical calculation (meaning a particular analytical calculation within the list). For example, the similarity is based on similar characteristics of the two analytical calculations. At 1070, the software application associates the rank of the listed analytical calculation with the unlisted analytical calculation.

Obviously, many additional modifications and variations of the present disclosure are possible in light of the above teachings. Thus, it is to be understood that, within the scope of the appended claims, the disclosure may be practiced otherwise than is specifically described above.

The foregoing description of the disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. The description was selected to best explain the principles of the present teachings and practical application of these principles to enable others skilled in the art to best utilize the disclosure in various embodiments and various modifications as are suited to the particular use contemplated. It should be recognized that the words “a” or “an” are intended to include both the singular and the plural. Conversely, any reference to plural elements shall, where appropriate, include the singular.

It is intended that the scope of the disclosure not be limited by the specification, but be defined by the claims set forth below. In addition, although narrow claims may be presented below, it should be recognized that the scope of this invention is much broader than presented by the claim(s). It is intended that broader claims will be submitted in one or more applications that claim the benefit of priority from this application. Insofar as the description above and the accompanying drawings disclose additional subject matter that is not within the scope of the claim or claims below, the additional inventions are not dedicated to the public and the right to file one or more applications to claim such additional inventions is reserved.

Claims

1. A method for execution by a database management system that includes at least one processor, the method comprising: obtaining, by the database management system, a row of data corresponding to a plurality of columns;generating, by the database management system, a data confidence value for data within one or more columns of the plurality of columns, wherein the generating the data confidence value includes determining a data type associated with the row of data, and determining, based on the determined data type, to generate the data confidence value, and wherein the data type includes one or more of digital sensor data, network traffic data, and genomic base pairs of a genome sequence;generating, by the database management system, a confidence data record that includes a new column added to the one or more columns, wherein the new column includes the data confidence value; andstoring, by the database management system, the confidence data record in memory of the database management system.

2. The method of claim 1, wherein the obtaining the row of the data comprises: retrieving a set of data records from the memory of the database management system; andextracting a data record from the set of data records to produce the row of data.

3. The method of claim 1 further comprises: determining whether the data confidence value associated with the one or more columns is less than a data confidence threshold; andwhen the data confidence value is less than the data confidence threshold, generating the new column.

4. The method of claim 1 further comprises: retrieving the confidence data record; andanalyzing the confidence data record to produce a result, wherein the result includes a confidence level that is based on the data confidence value.

5. The method of claim 1, wherein the data confidence value comprises: an estimate of an accuracy of the row of data.

6. The method of claim 1, wherein the data confidence value comprises: an estimate of an accuracy of data within a column of the one or more columns.

7. The method of claim 1, wherein the data confidence value comprises: an estimate of a reliability level of the row of data.

8. The method of claim 1, wherein the generating the data confidence value comprises: interpreting one or more data points of the data within the row of data to produce the data confidence value.

9. A database storage node of a database management system, the database storage node comprising: memory;an interface; andat least one processing unit operably coupled to the memory and the interface, wherein the at least one processing unit is operable to:obtain a row of data corresponding to a plurality of columns;generate a data confidence value for data within one or more columns of the plurality of columns, wherein the generating the data confidence value includes determining a data type associated with the row of data, and determining, based on the determined data type, to generate the data confidence value, and wherein the data type includes one or more of digital sensor data, network traffic data, and genomic base pairs of a genome sequence;generate a confidence data record that includes a new column added to the one or more columns, wherein the new column includes the data confidence value; andstore the confidence data record in memory of the database management system.

10. The database storage node of claim 9, wherein the processing unit is further operable to obtain the row of the data by: retrieving, via the interface, a set of data records from the memory of the database management system; andextracting a data record from the set of data records to produce the row of data.

11. The database storage node of claim 9, wherein the processing unit is further operable to: determine whether the data confidence value associated with the one or more columns is less than a data confidence threshold; andwhen the data confidence value is less than the data confidence threshold, generate the new column.

12. The database storage node of claim 9, wherein the processing unit is further operable to: retrieve, via the interface, the confidence data record; andanalyze the confidence data record to produce a result, wherein the result includes a confidence level that is based on the data confidence value.

13. The database storage node of claim 9, wherein the data confidence value comprises: an estimate of an accuracy of the row of data.

14. The database storage node of claim 9, wherein the data confidence value comprises: an estimate of an accuracy of a data within a column of the one or more columns.

15. The database storage node of claim 9, wherein the data confidence value comprises: an estimate of a reliability level of the row of data.

16. The database storage node of claim 9, wherein the processing unit is operable to generate the data confidence value by: interpreting one or more data points of the data within the row of data to produce the data confidence value.