Fault tolerant information recall

Fault tolerant information recall

Post by Dan Hepn » Sat, 24 Mar 1990 06:42:53




Quote:>My professor and I are doing research in fault-tolerant
>information recall.  This means that a data base query
>will always recall information in the presence of
>faults. If data is corrupted in the query and/or data
>is corrupted in the database, searches will always
>return the "best" match.

Some questions:

1) Does this plan assume underlying fault tolerant hardware?
   If not, what about them pesky processor faults?

2) How do you know that the data has been corrupted?

3) What have you defined to be "best match"?  If I ask for
   a record with primary key 1000, and that was not found,
   would 999 qualify, being quite close?  Would something
   with only one bit different qualify?  

4) What model of database corruption have you assumed?  "Bit-
   rot"?  From what source, memory and disk that lied, buses and
   cables that didn't pass clean data, or processors which output bad
   data?

5) Do you have any evidence that the faults which you can
   handle are high frequency faults which occur to real people in
   the markets you described?

Dan Hepner

 
 
 

Fault tolerant information recall

Post by Michael Endrizz » Sun, 25 Mar 1990 01:49:16


Thank you for replying Dan.  I appreciate any input and
feel free to try to put holes in the theory.  If I don't
know the answers, I will forward to my professor. Let's
see here...

Quote:>Some questions:
>1) Does this plan assume underlying fault tolerant hardware?
>   If not, what about them pesky processor faults?

No it does not (aside from CRC and parity checks).  We are
"fault-tolerant" in the software sense, not hardware. A spelling
checker would be a good analogy.  If there are errors in the
query OR errors in the dictionary, the spelling checker would
still continue to function and return answers that are "closest"
to the query.  In this sense the spelling checker if "fault-tolerant".

Quote:>2) How do you know that the data has been corrupted?

Again refering back to the spelling checker example, when you
use the spelling checker on a document, you do not know which
words are good or bad.  

Quote:>3) What have you defined to be "best match"?  If I ask for
>   a record with primary key 1000, and that was not found,
>   would 999 qualify, being quite close?  Would something
>   with only one bit different qualify?  

(spelling checker again). Spelling checkers to not guarantee the they
will return the correct word. They only return a list of "best matches"
To define "correct", the
search algorithm would also need to understand the semantics of a
word.  Semantic fault-tolerance is a
research area where ruled-based searches and integrity constraints
are being applied. Our method is strictly syntatic fault-tolerence.

Quote:>4) What model of database corruption have you assumed?  "Bit-
>   rot"?  From what source, memory and disk that lied, buses and
>   cables that didn't pass clean data, or processors which output bad
>   data?
>5) Do you have any evidence that the faults which you can
>   handle are high frequency faults which occur to real people in
>   the markets you described?

I have been mailing questionaires around the country(world) trying
to figure this out. If you have any input, I would appreciatte
hearing it.

                                        Thanks Again,

                                                Dreez

=================================================================
=================================================================
               Michael J. Endrizzi
        Secure Computing Technology Corp.
           1210 W. County Road E #100
              Arden Hills, Mn. 55112

                  (612) 482-7425

*Disclaimer: The opinions expressed above are not of my employer
             but of the American people.
=================================================================
=================================================================

 
 
 

Fault tolerant information recall

Post by Dan Hepn » Wed, 28 Mar 1990 10:06:03



Quote:

>Thank you for replying Dan.  I appreciate any input and
>feel free to try to put holes in the theory.

Maybe a more definite description of just what the theory is
would stimulate a wider discussion.  

All we have on the table so far is either only an analogue
(a spell checker), or a suggestion that it works just like a spell
checker.

Spell checkers work because humans spell incorrectly in somewhat
predictable ways.  On the surface anyway, computer faults wouldn't
seem to share the human misspelling predictive pattern.

Maybe Michael you could clarify what predictability of computer faults
your techniques exploit?

Dan Hepner

 
 
 

1. >Fault-tolerant Information Recall

I have been having ongoing discussions with several people
on the concept of fault-tolerant information retrieval as
applied to relational databases.  There seems to be a
misconception as to the definition of "fault-tolerant". I
would like to give you my definition of "fault-tolerant"
as it relates to information retrieval.

A common misconception is that software fault-tolerant retrieval
operates in conjunction with hardware fault-tolerance.

The following is a quote from my professor Vladimir Cherkassky:

If I may summarize the issue further. Traditional
CSci searching techniques found in database systems depend on
EXACT matches between the key and the target. If an EXACT match
is not present, the search fails.

Fault-tolerant searches always succeed. FT searches return a
list of APPROXIMATE matches, of which the EXACT (or correct)
match may or may not be present in this list.  A common example
of fault-tolerant searching is a spelling checker.  Most spelling
checkers will always return a list of APPROXIMATE matches, of which
the EXACT (or correct) spelling may or may not be present in the list.

Now comparing a traditional CSci RDBMS with our model. In traditional
CSci RDBMS, if errors exist in the query or database (either hardware
induced or human induced) a search/join/subtract will either fail or return
faulty information.  In our model, the search will succeed and return
results that APPROXIMATELY correct.

I hope this helps. I could go into more detail if people
desire.  Please let me know if this of interest.  Some
people who are implementing RDBMS's on associative memories
have asked how we store information in the tag fields. I
could go into this in future articles.

                                Dreez

2. some problems with VFP 3.0

3. Fault-tolerant DTS processes

4. SQL date

5. Fault-tolerant SQL Server 2000 Transactional Replication

6. Fault tolerant SQL Servers

7. Fault tolerant solution

8. Help: Fault tolerant SQL servers

9. Fault tolerant SQL Servers

10. Fault tolerant Solution