Browse Prior Art Database

Segmented Relational Database Tables

IP.com Disclosure Number: IPCOM000115936D
Original Publication Date: 1995-Jul-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 105K

Publishing Venue

IBM

Related People

Comeau, AC: AUTHOR [+2]

Abstract

In computer systems the data storage requirements are continually increasing. Not only is the total amount of data to be stored increasing, but so is the desired size of a data object. An database object of terabyte size is desirable, as is a file object of terabyte size to store data such as sound or full motion video. The problem is that most of the computer systems that are available today are incapable of storing objects of this size. For example, IBM* AIX* can only handle files that are no greater than 2 gigabytes in size. The invention supports the storage of objects far in excess of 2 gigabytes in in filesystems that themselves cannot store single files of this size.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 49% of the total text.

Segmented Relational Database Tables

      In computer systems the data storage requirements are
continually increasing.  Not only is the total amount of data to be
stored increasing, but so is the desired size of a data object.  An
database object of terabyte size is desirable, as is a file object of
terabyte size to store data such as sound or full motion video.  The
problem is that most of the computer systems that are available today
are incapable of storing objects of this size.  For example, IBM*
AIX* can only handle files that are no greater than 2 gigabytes in
size.  The invention supports the storage of objects far in excess of
2 gigabytes in in filesystems that themselves cannot store single
files of this size.  This use of this invention is not restricted by
the size of the filesystem which typically supports up to 2 to 4
gigabytes combined for all files stored in the filesystem.  This
objective is achieved by dividing the large object into segments,
each in a separate file and possibly stored in different filesystems.
Having divided the file up into segments, the locations of these
segments are computed algorithmically (no lookup table is required
and, therefore, location lookup table integrity is not an issue).

      These segments are then stored on the disk storage of the
system in a systematic manner so that the location of each portion of
the object is predetermined by the location of the first segment of
the object and the first segment of each different object is located
at a predetermined location within the storage.  In the preferred
example, for example, the first segment which may consist of a fixed
and predetermined number of pages (fixed sized "pieces" of the object
typically set to the page size of the underlying filesystem), may be
located in the first storage device, the second segment of the same
number of pages in a second storage device, and continuing with each
storage device and each segment until all segments are stored.  Here
is an example of a object's segments stored in a hierarchical file
system.  Here "root" is the root directory, and "segdir0", "segdir1",
etc. are subdirectories of "root".
                                    Root
                                     |
                                     |
  -------------------------------------------------------
  |                |                 |                  |
  |                |                 |                  |
  segdir0          segdir1           segdir2            segdir3
  object0.file     object0.file      object0.file       object0.file

      The logical Object0 is composed of the concatenation of each
file physical file of the same name under each segment dir...