5 ms·
Do you know why are case-insensitive searches not recommended? What's the realistic work-around?
by lucasjans 14y ago
Do you know why are case-insensitive searches not recommended? What's the realistic work-around?
- parfe 14y agohttp://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-RegularExpressions http://www.mongodb.org/display/DOCS/Advanced+Queries#Advance... Regex queries ending with /i (case-insensitive flag) cannot efficiently use indexes, but must do full index scans.
- ericcholis 14y agoI've found that a simple {"lastname":/cholis/i} works great. However, trying to do the same thing for a multi-key search isn't ideal. Specifically, searching for 3 words in a title using $and with multiple regex queries on a collection with 100,000+ documents took about 520 ms. The mongodb documentation suggests that you could have an array with your keywords, generated from the field you wish to search. Using indexes on multikeys would make this faster, but your index size would be much larger.[1] For my project, I'm likely going to institute solution like elasticsearch or SOLR. [1] http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mong...
- sureshv 14y agoBuilding over a full text search engine that indexes your db is going to scale much better in the long run. Plus you get stemming and other niceties to boot as long as consistency is not of the highest priority.
- r00fus 14y agoWith tools like SOLR or Elasticsearch, I keep wondering why people try to re-invent the full-text indexing wheel - these tools make it easy to focus your app/datastore on your functionality and leave search as an additional service, to be used whenever you need it.
- sureshv 14y agoThe documentation mentions that prefix searches will be much faster than other searches. Most likely reason is that the index is mapped with some sort of prefix tree, perhaps a case-sensitive prefix tree.