Frequently Asked Questions

Yes, DBXten uses technology invented at BCS and described in US Patent 8,077,059 B2 ("Database Adapter for relational datasets") and Canadian Patent 2,645,354 ("Database Adapter for compressing tabular data partitioned in blocks"). In short, this invention provides improved methods for storing and retrieving relational data that reduce the space and time used to store data and the time taken to retrieve stored data.
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.
In principle, yes. Currently however we’ve only developed a few adapters while we test the market.
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.
That’s easy! Take any sensor network that requires complex data sequences from diverse sensors to be stored safely and then queried. A specific example would be an ocean bed laboratory consisting of a long fiber optic cable with attached sensors reading and transmitting physical, chemical, and biological data and images; there are several of these laboratories planned and in operation throughout the world.
We were aware that ingesting fast streams of complex data into databases was causing considerable “customer pain”, and so we set about solving that problem. The result was DBXten, which provides fast ingestion, compact storage, and improved query performance in a variety of application areas.

Yes, each of these products, when "plugged-in" to a database, adds functionality (data types and procedures) that wouldn't otherwise be available, thereby greatly reducing the effort required when dealing with large amounts of data.

DataBlades as Plug-ins

Each of our products, or "plug-ins", can be added to a database server, and registered into the databases on the server, simply by issuing some very simple commands.

A database extension "extends" the SQL language, adding new data types, functions, casts, aggregates, etc. to those normally available in a traditional relational database management system. For example, the BCS Grid DataBlade adds a grid data type and procedures for, among other operations, reprojecting, subsetting, interpolating, and combining grids.

Elements of a DataBlade

A database extension takes the form of a shared library; the database server engine automatically calls methods in the shared library whenever the user issues SQL that refers to the added data types and/or procedures.

We have developed a UFI Adapter Development SDK for exactly this reason. Send us an email stating your requirements and we will explain the options.
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.
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.

Click here to request a download link for the DaL program.
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.
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.
No. DBXten, UFI and the Grid DataBlade perform well on inexpensive workstations. They will, of course, perform even better on faster machines.
The only limit on the number of scenes you can store is the amount of data that your DBMS can store.
Joomla Templates: from JoomlaShack