Next Page | Prev Page | Main Index | Home |
The problem is to be able to track a single sub in the ocean of
information coming from the undersea passive sonar network. This
network produces sample records at a rate of 10,000 every 2 seconds,
consisting of 64 16-bit numbers (FFT), a location, and a time/date
stamp. This large volume of data must somehow be stored in a database.
The database must then be able to find all of the records within
a time range that have soft matches to a target FFT. This output
set must then be displayed as a track on a map. This answers the
question. Where did this sub go?
This problem can be solved by using MPbase. Although this
is a complex data problem, it a simple information problem. MPbase's
combination of internal characteristics make easy work of this
task.
First, the multidimensional hypercube nature of MPbase
allows the relevant data to be logically located near each other
in all of the 66 dimensions (64 numbers, location and time). This
entire database would need to be stored in only one MPbase
table.
Second, the content-addressable memory (CAM)
nature of MPbase will cause all of the records with similar
FFTs to be stored near each other in the hypercube.
Third, MPbase's ability to do a soft match makes locating
the needed FFTs a simple task. This can be further enhanced with
the addition of custom match or analysis routines. These routines
can be used to augment and/or replace MPbase's own internal
routines.
Fourth, the massively parallel architecture allows for the sheer
volume of updates that such a database will need to accept. MPbase
has no special "data load" function. None is needed.
All data placed in MPbase goes through the update cycle
with no performance penalty. As a mater of fact, the more updates
MPbase has to process the more efficiently it does so.
The farther behind it gets, the more quickly it will catch up.
Fifth, data in MPbase is internally compressed to a very
high level. This, coupled with the parallel nature, allows all
of the needed performance to do this task in real-time.
Sixth, the relational nature and formatting functionality in the
output view allows MPbase to provide the result set in
any needed format. This could directly feed a GIS system or even
a CAD program to graphically display the sub's track.
Seventh, the fault-tolerant nature of MPbase provides the
kind of reliability such a system must have. If enough hardware
remains to run a query, MPbase will continue to function
In short, with MPbase this nasty real world problem is
no problem.
Next Page | Prev Page | Main Index | Home | © 1998-2004 NPSI |