Places:Full Text Indexing

From MozillaWiki
Jump to: navigation, search


Full Text Indexing feature will allow user to search for a word/phrase from the pages that he has visited. The search query will be tightly integrated with Places's nsNavHistoryService. The tighter integration will allow queries like "search for pages visited between 01/05/07(dd/mm/yy) to 20/05/07(dd/mm/yy) containing the word 'places'"


Work-in-progress patch in bug 377244.

Design Decisions

A number of options were looked into before proposing this design. The options included implementing using CLucene(like flock), SQLite's FTS1 and FTS2 module, implementation using B+ Trees, using relational database etc.. The following text will briefly describe the advantage and disadvantage of all the implementation methods.

CLucene is a full-text indexing engine that stores the index as B+ Trees in files. It uses a very efficient method for storage and retrieval. It has an excellent support for CJK languages. The Places system is a new incorporation into firefox. Hence, it is important that during its initial stages all the code that is written or used is flexible, small and tightly integrated with it. Tighter integration would allow future enhancements specific to firefox. Hence this approach was dropped.

A custom implementation using B+ Tree is a very good option but however, it would require additional B+ Tree engine. In light of availability of an efficient algorithm for implementing full-text indexing using relational database, this method is used.

A naive implementation of full-text indexing is very costly in terms of storage. I'll briefly explain how it is so. Let us define term. A term is any word that appear in a page. So a relational database contains a table with two columns, term and id. Another table contains two columsn term id and doc id(id of the document the term appeard in). The GNU manuals were analyzed [1]. It is 5.15 Mb of text containing 958,774 occurrences of word out of which 27,554 are unique. But table 2 will require that every occurrence has a corresponding doc id. If term id were stored as int, the amount of space required to store the first column alone, would be 958,774 * 4 bytes, which is about 3 Mb. A B+ Tree implementation is atleast 3Mb more efficient. However a nice encoding scheme and storage model proposed by [2] is almost as efficient as a B+ Tree implementation. This algorithm also leverages the capabilites of relational database system while not losing too much in terms of storage and performance.

SQLite's FTS1 and FTS2 module are open source implementation of full-text indexing integrated with SQLite. According Scott Hess, FTS developer, "It sounds like a lot of what you're discussing here matches what we did for fts1 in SQLite. fts2 was a great improvement in terms of performance, and has no breaking changes expected" Hence Fts2 is a great option. I have built mozilla with sqlite and fts2 and it was easy. Moreover, FTS2 is integrated nicely with SQLite requiring no change in sqlite3file.h and sqlite.def files which are essentially exports. One can give queries like

 Create virtual table history_index using fts2(title, meta, content) 

The index gets created. Further to insert,

 insert into history_index(title, meta, content) values('some value', 'some value', 'some value') 

And to search,

 select * from history_index where content matches 'value'

Use Case

Actor: User
- Visit Page
- Search
- Clear History

Actor: Browser
- Expire Page

The use cases above will be used to validate the design.

Detailed Design


There are essentially four classes for the back-end:

  1. nsNavHistoryQuery
  2. nsNavFullTextIndexHelper
  3. nsNavFullTextIndex
  4. nsNavFullTextAnalyzer


This class is already implemented with all features except searching text. The mechanism of searching is no different from what described in

var historyService = Components.classes[";1"].getService(Components.interfaces.nsINavHistoryService);

var options = historyService.getNewQueryOptions();
var query = historyService.getNewQuery();
query.searchTerms = "Mozilla Firefox";

// execute the query
var result = historyService.executeQuery(query, options);

The result will contain a list of URI. A number of options can be specified in query and options making it very powerful. Conjunctive queries can be also be executed with historyService.executeQueries and a list of query as parameter.

Internally the function calls nsNavFullTextIndex::searchDocument(searchTerms) which returns a list of URI ranked according to algorithm described in SearchDocument(terms) function that will be described later in this document. The list of URI is further filtered by the other parameters set in query and options variable. In case of executeQueries method, the list is aggregated with results from multiple queries.


This class interacts with FTS2. It is responsible for executing queries that will insert content into the index and generate URI of matching documents on a search request. This class will be private and will not be exposed outside. A search request will also generate text snippets to be displayed for UI to display


This class implements nsParserDataListener and is registered to listen to data. The class is called every time there is data available upon page request. After aggregating the data, nsFullTextIndex::indexDocument(documentData) is called. This function will execute FTS2 queries.


These are bunch of classes that will be registered to FTS2 module allowing custom tokenizers and different languages. Before the standarad tokenizer, the stream has to pass through a html tag stripper.



The function of this is to break the query given in human language into a graph of TermQuery and BooleanQuery. BooleanQuery is a struct with two operand(each a TermQuery or BooleanQuery) and an operator(AND, OR, NOT, XOR). Although the idea here is to implement all kind of queries as in: eventually. nsNavHistoryQuery is used to query using the query struct. The results of which is url_list which is displayed using view.


  1. An Efficient Indexing Technique for full-text database systems Justin Jobel, Alistair Moffet, Ron Sacks Davis
  2. Using a relational database for an Inverted Text index Steve Putz, Xerox PARC