#3288 - Major overhaul of fulltext search support, the "Composr fast custom index"
-
By Chris Graham
- Added
- 1 view
| Identifier | #3288 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Major overhaul of fulltext search support, the "Composr fast custom index" |
| Status | Completed |
| Tags |
ocProducts client-work (likely) (custom) Type: Performance (custom) |
| Handling member | Chris Graham |
| Addon | core_database_drivers |
| Description | We can implement support for fulltext search on all database drivers, regardless of whether the database backends support it.
This is doable via an 'inverted index'. Essentially we just do our own word tokenisation and store it in our own table. An advantage to this is we can then do much more sophisticated metrics to stop slow searches. We could have fields in our inverted index table for all search qualifiers (post time, author, etc), so that we know we can easily only ever be looking at a subset of the index. Currently the problem with MySQL fulltext search is that the index can not be done against search qualifiers, so you get this huge trawl through non-qualified results as it gets to the occasional qualified ones. If we do this, I see no reason we can't just drop the regular fulltext search support we have. We can do better, so there's no need to do anything native to each database backend. EDIT: It is actually useful for non-search-engine querying, e.g. in the find_filedump_links function as an optimisation, or in Filtercode. It should stay. We don't need to support it on all DB backends though as it's an optimisation only. This depends on #3958 - we don't want to be populating the index when the server is under high load. EDIT: Not really. It is an iterative process. |
| Steps to reproduce | |
| Additional information | Alternatively we can also implement more fulltext search support for individual databases.
DB2, Oracle, and Sqlite (with non-default extension), also support fulltext search but we don't implement it. If we do this we will need to totally overhaul our fulltext search code too because our code currently assumes it works via indexes, which is not a universally valid assumption. Particularly when indexes are deleted, it doesn't even go into the database driver API for that. I prefer to implement our own fulltext rather than make a complex multi-vendor API, with lots of testing. It'd be a better result for less investment. |
| Related to | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
1) multi-dimensional indexing. Full text gets very slow because it hits the full text index for a set of matching post IDs but then it has to intersect these against other search parameters, such as forum ID. For a popular term such as 'comcode' this may mean MySQL skipping through 100s of posts that match the term for every 1 it finds in the right forum. With our own custom multi-dimensional index we have those intersections precomputed.
2) background indexing. We can populate the indexing in the background, rather than real-time. Meaning we can have our expansive indexing with no performance hit.
3) custom stop word lists and min-max word lengths. MySQL's list of stop words ('the', 'an', etc) is compiled in, as is the word lengths. With our own implementation we would have much more control. I'm sure there's words not included in searches that we want, and words so common that their presence in queries really bogs down index traversal.
4) searches no longer creating read locks. As searching right now has to do the aforementioned intersecting against post data held in the main f_posts table, it will create read locks (which block writes). We could massively reduce read locking if the main work is happening in isolated indexes rather than the main table.
EDIT: Actually the locks are probably still needed as we do need to query against it, so things like validation checks can happen, so a join can fix a case of a missing record, and generally to avoid having to do complex double querying. However, as searches will be a lot faster the issue of a long read lock will be gone.