Updating SF-Tree Speaker: Ho Wai Shing

Contents Introduction, and summary of SF-Tree Possible SF-Tree update techniques and their limitations Future work

Introduction SF-Tree stands for Signature File Tree it is originally designed for storing XML SPE selectivity it can be generalized to store an "object-to-count" mapping

SF-Tree Basics Divide objects into groups of the same (or similar) count(s) Finding the count of an object is equivalent to finding the group containing the object Signature files are used to summarize groups SFs are organized in a tree form

Signature Files Are bit vectors Computed by hashing objects into bit positions and setting the bits Existence of an object can be checked by checking the hashed bit positions

Signature Files e.g., F has 10 bits, m = 3 "//name" is hashed to bits 2, 3, 8 "//buyer" is hashed to bits 2, 4, 9

SF-Tree

SF-Tree

Introduction Advantages: Time efficient: independent of database size Space efficient: independent of original object size Accurate: has statistical accuracy guarantee on the returned counts Flexible: can tune parameters to make trade-offs among space, accuracy, speed.

Introduction Disadvantages: Not 100% accurate, since original objects are discarded All information must be available before building a Shannon-Fano SF-Tree Updates may reduce its accuracy

Introduction Possible applications support count storage in stream data mining data cube storage Periodic reconstructions are not always feasible (esp. data streams), so we need good update strategy for SF-Tree

Updating SF-Tree basic idea: count of an object changed the object is changed from one group to another i.e., the object is deleted in a group, and inserted into another group

Updating SF-Tree Problems: No deletion algorithm for deleting objects in signature files No algorithm for creating a new group in a SF-Tree No way to compute new signatures for the existing objects

Updating SF-Tree Solutions to the problems For deletion: Counter-based signature files "No-deletion" scheme Look-ahead Retrieval For insertion: Dynamic expanding signature files Precomputed signature files Negative signature files

Counter-Based Signature Files Motivation: deletion of an object involves resetting some bits resetting bits may cause "false negatives" (can't retrieve some objects which are present in this group)

Counter-Based Signature Files e.g., "//name" is hashed to bits 2, 3, 8 "//buyer" is hashed to bits 2, 4, 9 when we remove "//buyer", "//name" can't be retrieved (since bit-2 = 0)

Counter-Based Signature Files Use counters instead of bits in the signature file e.g., "//name" is hashed to bits 2, 3, 8 "//buyer" is hashed to bits 2, 4, 9

Counter-Based Signature Files Advantages: deleting an objects which is in F won't cause "false negatives" Disadvantages: space requirement increases deletion due to false drop still causes troubles counters may overflow

"No-Deletion" Scheme Motivation: Deletion causes troubles (false negatives) No way to completely avoid it False negatives may cause big errors in counts

"No-Deletion" Scheme Won't reset the bits when deleting an object (i.e., no deletion) For retrieval, return the count of the group with largest count Advantages: completely remove all the troubles caused by deletion (no more false negatives)

"No-Deletion" Scheme Disadvantages: may reduce the accuracy of the signature (if the signature size is unchanged) may increase the space requirement significantly (if we maintain the accuracy) can be applied only to applications that counts are monotonic increasing (decreasing)

"No-Deletion" Scheme Still useful: for updates between periodic reconstructions since retrieval time is unchanged (for positive queries) more space efficient than counters if updates are not frequent (since we can use bit-based signature files)

Look-Ahead Retrieval Motivation: Reduces errors due to false negatives Retrieval stops only when two consecutive levels of signature files do not contain the query Re-insert the object if we think that it's a false negative

Look-Ahead Retrieval e.g.,

Look-Ahead Retrieval Advantages: Reduces the probability that SF-Tree is affected by false negatives The self-healing property removes some false negatives

Look-Ahead Retrieval Disadvantages: slower (more signatures to be examined) false drop rate increases more 1s created in the self-healing process one less level for false drop safe-guard

Insertion Involves 2 parts insertion within a signature file inserting new signature files in SF-Tree A signature file has a capacity under an error bound more objects  more 1s  higher false drop rate

Dynamically Expanding Signature Files To maintain the error (false drop prob.) bound, the size of SFs must be able to be increased However, objects are dropped  we can't recompute the signatures of previous objects Add new signatures to represent new objects

Dynamically Expanding Signature Files e.g., create a new signature if the first one is full doubling the size at each creation

Dynamically Expanding Signature Files Advantages: the signature files can now store arbitrary number of objects Disadvantages: less space efficient

Precomputed Signature Files The previous method solves insertion within a signature file The next two methods concentrates at inserting new count groups

Precomputed Signature Files Problem: adding a new count group (i.e., leaf node) may involve adding new internal nodes e.g.,

Precomputed Signature Files Solution: the signature file is precomputed, i.e.,

Negative Signature Files Alternative solution to the previous problem A "negative signature file" stores the deleted objects

Summary For deletion: For insertion: Counter-based signature files "No-deletion" scheme Look-ahead Retrieval For insertion: Dynamic expanding signature files Precomputed signature files Negative signature files

Future Work Implement and check the performance of different update strategies Identify the requirements of various applications (e.g., support counting, data cube storage) and choose a suitable SF-Tree strategy