No. The Grid DataBlade uses a tiling scheme to subset multidimensional data efficiently. Compression would cause the tiles to change, making it more challenging to locate them.
Yes, although the amount of space needed will be larger than would be required using a dedicated video format, because DBXten doesn't currently have video specific compression routines. DBXten's strength is compression algorithms that preserve user-specified data precision.
Yes. Although in some rare cases when there is more than one LAV line to a dataset, there will be LAV lines that do not pass through any of the points. For example, plot the four points {(0,0), (1,1), (2,1), (3,0)} on a sheet of paper and you’ll soon notice that there are infinitely many LAV lines for this dataset, including four LAV lines that pass through some pair of points. In contrast, an LS line is always unique.
LAV fits are not affected by the size of the mismatch (or residual) at any point, but only by the sign of the mismatch. So, if you move a mismatched point vertically through the LAV line it will have an effect.
The Grid DataBlade stores 4D data using a special type called a GRDValue. Internally, the GRDValue stores the 4D data in a blob or optionally (in the case PostgreSQL and Oracle) as an external file. The 4D data itself is stored as a serialized 4D array. The GRDValue also stores georeferencing information and a bit field to keep track of missing values. The Grid DataBlade doesn't require the grid spacing to be constant, but it works best when the spacing is fairly regular. DBXten is a separate and unrelated product that can be used to store N dimension data. It doesn't have the geospatial awareness that the Grid DataBlade does, but it automatically compresses data (using a variety of different techniques) to reduce loading, storage and querying costs. DBXten makes no assumptions about the spacing of the data in each dimension.
The Grid DataBlade's strength is its ability to resample data on the fly:
You can store your data as a satellite swath and later extract pieces of it in a planar projection.
It can sample grids from different coordinate systems to produce a single unified grid.
It can interpolate between samples vertically, horizontally, and temporally.
You typically need to write a client program to perform further processing on the produced GRDValue. BCS can write additional functions for clients, or assist them in doing so themselves.
DBXten's strength is compressing your data and reducing the size of your indexes so that data can be loaded and queried faster (for some problem types). DBXten is row oriented so you can use whatever statistical functions come with your server.
The functions that comprise the code body of DBXten and the Grid DataBlade are reentrant, so you can certainly run multiple jobs concurrently. However, there is no explicit use of parallelism in the functions; each is limited to a single thread of control. We're not aware of any database servers that typically support parallelism inside UDRs (User Defined Routines).
That said, in the Informix cases, data that is distributed across multiple dataspaces can be handled by concurrent processes. This can speed up DBXten, but is not expected to enhance the performance of the Grid DataBlade.
In addition to resampling data, the Grid DataBlade provides a means to search for grids that overlap or are contained in a particular region, regardless of their coordinate system.
FAQ
