## Storage Requirements and Performance Costs 

text indexes have the following storage requirements and performance costs: 

• text indexes can be large. They contain one index entry for each unique post-stemmed word in each indexed field for each document inserted. 

• Building a text index is very similar to building a large multi-key index and will take longer than building a simple ordered (scalar) index on the same data. 

• When building a large text index on an existing collection, ensure that you have a sufficiently high limit on open file descriptors. See the recommended settings (page 287). 

• text indexes will impact insertion throughput because MongoDB must add an index entry for each unique post-stemmed word in each indexed field of each new source document. 

• Additionally, text indexes do not store phrases or information about the proximity of words in the documents. As a result, phrase queries will run much more effectively when the entire collection fits in RAM. 

## Text Search 

Text search supports the search of string content in documents of a collection. MongoDB provides the $text operator to perform text search in queries and in aggregation pipelines (page 545). 

The text search process: 

• tokenizes and stems the search term(s) during both the index creation and the text command execution. 

• assigns a score to each document that contains the search term in the indexed fields. The score determines the relevance of a document to a given search query. 

The $text operator can search for words and phrases. The query matches on the complete stemmed words. For example, if a document field contains the word blueberry , a search on the term blue will not match the document. However, a search on either blueberry or blueberries will match. 

For information and examples on various text search patterns, see the $text query operator. For examples of text search in aggregation pipeline, see Text Search in the Aggregation Pipeline (page 545). 

## Hashed Index 

New in version 2.4. 

Hashed indexes maintain entries with hashes of the values of the indexed field. The hashing function collapses em- bedded documents and computes the hash for the entire value but does not support multi-key (i.e. arrays) indexes. 

Hashed indexes support sharding (page 661) a collection using a hashed shard key (page 674). Using a hashed shard key to shard a collection ensures a more even distribution of data. See Shard a Collection Using a Hashed Shard Key (page 696) for more details. 

MongoDB can use the hashed index to support equality queries, but hashed indexes do not support range queries. 

You may not create compound indexes that have hashed index fields or specify a unique constraint on a hashed index; however, you can create both a hashed index and an ascending/descending (i.e. non-hashed) index on the same field: MongoDB will use the scalar index for range queries. 

