[[choosing-a-stemmer]]
=== Choosing a Stemmer
The documentation for the
http://bit.ly/1AUfpDN[`stemmer`] token filter
lists multiple stemmers for some languages.((("stemming words", "choosing a stemmer")))((("English", "stemmers for"))) For English we have the following:
`english`::
The http://bit.ly/17LseXy[`porter_stem`] token filter.
`light_english`::
The http://bit.ly/1IObUjZ[`kstem`] token filter.
`minimal_english`::
The `EnglishMinimalStemmer` in Lucene, which removes plurals
`lovins`::
The http://bit.ly/1Cr4tNI[Snowball] based
http://bit.ly/1ICyTjR[Lovins]
stemmer, the first stemmer ever produced.
`porter`::
The http://bit.ly/1Cr4tNI[Snowball] based
http://bit.ly/1sCWihj[Porter] stemmer
`porter2`::
The http://bit.ly/1Cr4tNI[Snowball] based
http://bit.ly/1zip3lK[Porter2] stemmer
`possessive_english`::
The `EnglishPossessiveFilter` in Lucene which removes `'s`
Add to that list the Hunspell stemmer with the various English dictionaries
that are available.
One thing is for sure: whenever more than one solution exists for a problem,
it means that none of the solutions solves the problem adequately. This
certainly applies to stemming -- each stemmer uses a different approach that
overstems and understems words to a different degree.
The `stemmer` documentation page ((("languages", "stemmers for")))highlights the recommended stemmer for
each language in bold, usually because it offers a reasonable compromise
between performance and quality. That said, the recommended stemmer may not be
appropriate for all use cases. There is no single right answer to the question
of which is the best stemmer -- it depends very much on your requirements.
There are three factors to take into account when making a choice:
performance, quality, and degree.
[[stemmer-performance]]
==== Stemmer Performance
Algorithmic stemmers are typically four or ((("stemming words", "choosing a stemmer", "stemmer performance")))((("Hunspell stemmer", "performance")))five times faster than Hunspell
stemmers. ``Handcrafted'' algorithmic stemmers are usually, but not always,
faster than their Snowball equivalents. For instance, the `porter_stem` token
filter is significantly faster than the Snowball implementation of the Porter
stemmer.
Hunspell stemmers have to load all words, prefixes, and suffixes into memory,
which can consume a few megabytes of RAM. Algorithmic stemmers, on the other
hand, consist of a small amount of code and consume very little memory.
[[stemmer-quality]]
==== Stemmer Quality
All languages, except Esperanto, are irregular.((("stemming words", "choosing a stemmer", "stemmer quality"))) While more-formal words tend
to follow a regular pattern, the most commonly used words often have irregular rules. Some stemming algorithms have been developed over years of
research and produce reasonably high-quality results. Others have been
assembled more quickly with less research and deal only with the most common
cases.
While Hunspell offers the promise of dealing precisely with irregular words,
it often falls short in practice. A dictionary stemmer is only as good as its
dictionary. If Hunspell comes across a word that isn't in its dictionary, it
can do nothing with it. Hunspell requires an extensive, high-quality, up-to-date dictionary in order to produce good results; dictionaries of this
caliber are few and far between. An algorithmic stemmer, on the other hand,
will happily deal with new words that didn't exist when the designer created
the algorithm.
If a good algorithmic stemmer is available for your language, it makes sense
to use it rather than Hunspell. It will be faster, will consume less memory, and
will generally be as good or better than the Hunspell equivalent.
If accuracy and customizability is important to you, and you need (and
have the resources) to maintain a custom dictionary, then Hunspell gives you
greater flexibility than the algorithmic stemmers. (See
<<controlling-stemming>> for customization techniques that can be used with
any stemmer.)
[[stemmer-degree]]
==== Stemmer Degree
Different stemmers overstem and understem((("stemming words", "choosing a stemmer", "stemmer degree"))) to a different degree. The `light_`
stemmers stem less aggressively than the standard stemmers, and the `minimal_`
stemmers less aggressively still. Hunspell stems aggressively.
Whether you want aggressive or light stemming depends on your use case. If
your search results are being consumed by a clustering algorithm, you may
prefer to match more widely (and, thus, stem more aggressively). If your
search results are intended for human consumption, lighter stemming usually
produces better results. Stemming nouns and adjectives is more important for
search than stemming verbs, but this also depends on the language.
The other factor to take into account is the size of your document collection.
With a small collection such as a catalog of 10,000 products, you probably want to
stem more aggressively to ensure that you match at least some documents. If
your collection is large, you likely will get good matches with lighter
stemming.
==== Making a Choice
Start out with a recommended stemmer. If it works well enough, there is
no need to change it. If it doesn't, you will need to spend some time
investigating and comparing the stemmers available for language in order to
find the one that best suits your purposes.
- Introduction
- 入门
- 是什么
- 安装
- API
- 文档
- 索引
- 搜索
- 聚合
- 小结
- 分布式
- 结语
- 分布式集群
- 空集群
- 集群健康
- 添加索引
- 故障转移
- 横向扩展
- 更多扩展
- 应对故障
- 数据
- 文档
- 索引
- 获取
- 存在
- 更新
- 创建
- 删除
- 版本控制
- 局部更新
- Mget
- 批量
- 结语
- 分布式增删改查
- 路由
- 分片交互
- 新建、索引和删除
- 检索
- 局部更新
- 批量请求
- 批量格式
- 搜索
- 空搜索
- 多索引和多类型
- 分页
- 查询字符串
- 映射和分析
- 数据类型差异
- 确切值对决全文
- 倒排索引
- 分析
- 映射
- 复合类型
- 结构化查询
- 请求体查询
- 结构化查询
- 查询与过滤
- 重要的查询子句
- 过滤查询
- 验证查询
- 结语
- 排序
- 排序
- 字符串排序
- 相关性
- 字段数据
- 分布式搜索
- 查询阶段
- 取回阶段
- 搜索选项
- 扫描和滚屏
- 索引管理
- 创建删除
- 设置
- 配置分析器
- 自定义分析器
- 映射
- 根对象
- 元数据中的source字段
- 元数据中的all字段
- 元数据中的ID字段
- 动态映射
- 自定义动态映射
- 默认映射
- 重建索引
- 别名
- 深入分片
- 使文本可以被搜索
- 动态索引
- 近实时搜索
- 持久化变更
- 合并段
- 结构化搜索
- 查询准确值
- 组合过滤
- 查询多个准确值
- 包含,而不是相等
- 范围
- 处理 Null 值
- 缓存
- 过滤顺序
- 全文搜索
- 匹配查询
- 多词查询
- 组合查询
- 布尔匹配
- 增加子句
- 控制分析
- 关联失效
- 多字段搜索
- 多重查询字符串
- 单一查询字符串
- 最佳字段
- 最佳字段查询调优
- 多重匹配查询
- 最多字段查询
- 跨字段对象查询
- 以字段为中心查询
- 全字段查询
- 跨字段查询
- 精确查询
- 模糊匹配
- Phrase matching
- Slop
- Multi value fields
- Scoring
- Relevance
- Performance
- Shingles
- Partial_Matching
- Postcodes
- Prefix query
- Wildcard Regexp
- Match phrase prefix
- Index time
- Ngram intro
- Search as you type
- Compound words
- Relevance
- Scoring theory
- Practical scoring
- Query time boosting
- Query scoring
- Not quite not
- Ignoring TFIDF
- Function score query
- Popularity
- Boosting filtered subsets
- Random scoring
- Decay functions
- Pluggable similarities
- Conclusion
- Language intro
- Intro
- Using
- Configuring
- Language pitfalls
- One language per doc
- One language per field
- Mixed language fields
- Conclusion
- Identifying words
- Intro
- Standard analyzer
- Standard tokenizer
- ICU plugin
- ICU tokenizer
- Tidying text
- Token normalization
- Intro
- Lowercasing
- Removing diacritics
- Unicode world
- Case folding
- Character folding
- Sorting and collations
- Stemming
- Intro
- Algorithmic stemmers
- Dictionary stemmers
- Hunspell stemmer
- Choosing a stemmer
- Controlling stemming
- Stemming in situ
- Stopwords
- Intro
- Using stopwords
- Stopwords and performance
- Divide and conquer
- Phrase queries
- Common grams
- Relevance
- Synonyms
- Intro
- Using synonyms
- Synonym formats
- Expand contract
- Analysis chain
- Multi word synonyms
- Symbol synonyms
- Fuzzy matching
- Intro
- Fuzziness
- Fuzzy query
- Fuzzy match query
- Scoring fuzziness
- Phonetic matching
- Aggregations
- overview
- circuit breaker fd settings
- filtering
- facets
- docvalues
- eager
- breadth vs depth
- Conclusion
- concepts buckets
- basic example
- add metric
- nested bucket
- extra metrics
- bucket metric list
- histogram
- date histogram
- scope
- filtering
- sorting ordering
- approx intro
- cardinality
- percentiles
- sigterms intro
- sigterms
- fielddata
- analyzed vs not
- 地理坐标点
- 地理坐标点
- 通过地理坐标点过滤
- 地理坐标盒模型过滤器
- 地理距离过滤器
- 缓存地理位置过滤器
- 减少内存占用
- 按距离排序
- Geohashe
- Geohashe
- Geohashe映射
- Geohash单元过滤器
- 地理位置聚合
- 地理位置聚合
- 按距离聚合
- Geohash单元聚合器
- 范围(边界)聚合器
- 地理形状
- 地理形状
- 映射地理形状
- 索引地理形状
- 查询地理形状
- 在查询中使用已索引的形状
- 地理形状的过滤与缓存
- 关系
- 关系
- 应用级别的Join操作
- 扁平化你的数据
- Top hits
- Concurrency
- Concurrency solutions
- 嵌套
- 嵌套对象
- 嵌套映射
- 嵌套查询
- 嵌套排序
- 嵌套集合
- Parent Child
- Parent child
- Indexing parent child
- Has child
- Has parent
- Children agg
- Grandparents
- Practical considerations
- Scaling
- Shard
- Overallocation
- Kagillion shards
- Capacity planning
- Replica shards
- Multiple indices
- Index per timeframe
- Index templates
- Retiring data
- Index per user
- Shared index
- Faking it
- One big user
- Scale is not infinite
- Cluster Admin
- Marvel
- Health
- Node stats
- Other stats
- Deployment
- hardware
- other
- config
- dont touch
- heap
- file descriptors
- conclusion
- cluster settings
- Post Deployment
- dynamic settings
- logging
- indexing perf
- rolling restart
- backup
- restore
- conclusion