ElasticSearch Tune for disk usage Translation
PUT index
{
"mappings": {
"_doc": {
"properties": {
"foo": {
"type": "integer",
"index": false
}
}
}
}
}
text:该属性在索引中存储了作为文档计分所需要的基本的因素,如果你索引的只是文本而不关注文本分数,那么你可以配置该索引不使用norms参数
PUT index
{
"mappings": {
"_doc": {
"properties": {
"foo": {
"type": "text",
"norms": false
}
}
}
}
}
text:默认情况下该属性还存储了frequencies和positions两个属性,第一个属性在积分系统中被使用到,第二个在短语查询中使用到。如果你不需要执行短语查询,那么你可以禁用positions属性
PUT index
{
"mappings": {
"_doc": {
"properties": {
"foo": {
"type": "text",
"index_options": "freqs"
}
}
}
}
}
另外,如果你不关心计分系统,你可以配置es在每个查询中仅仅索引文档。当然你也可以索引这个字段,但是短语查询将会报错并且计分系统会假定每次查询在每个文档中只会出现一次
PUT index
{
"mappings": {
"_doc": {
"properties": {
"foo": {
"type": "text",
"norms": false,
"index_options": "freqs"
}
}
}
}
}
2.不要使用默认动态字符串映射
PUT index
{
"mappings": {
"_doc": {
"dynamic_templates": [
{
"strings": {
"match_mapping_type": "string",
"mapping": {
"type": "keyword"
}
}
}
]
}
}
}
3.关注你的分片大小

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
ElasticSearch Tune for indexing speed Translation
1.使用块查询 块查询一般来说比单文档查询表现出更好的性能。为了获取快查询最佳新能,你可以在单节点地单分片上运行一个基准,第一次100个文档,第二次200个文档,然后400个,以此类推。每次基准运行的数量都是两倍于前一次的数量。当索引速度达到峰值的时候你就知道你的数据索引最佳的块文档数量。如果峰值存在于两个数量上,最好还是以最少的数量去索引。块查询数量越大也就意味着在进行同步查询的时候对内存压力也就越大。建议大家每次发送请求时不要超过几十兆尽管有时更大的请求表现地更好。 2.使用多线程发送数据到es中 使用单个线程不可能将es集群的索引性能最大化。为了充分利用es集群的资源,你应该使用多线程或进程发送数据。除了最大化集群的资源使用,这也会帮助减少非同步的成本。 注意TOO_MANY_REQUESTS(429)返回码(在java客户端中报EsRejectedExecutionException错误),这是告诉你es目前无法跟上你的索引速率。当这种情况发生时,你应该在下次发送请求之前先暂停下。理想情况下,它会自动恢复。 跟确定最佳bulk请求数量类似,只有通过测试才能知道最佳的调用者数量...
-
下一篇
阿里云Elasticsearch 智能化运维实践
背景 Elasticsearch作为一个开箱即用的搜索引擎,其丰富的功能和极低的使用门槛吸引着越来越多的公司和用户选择它作为搜索和数据分析的工具。用户在运维Elasticsearch集群时往往会遇到很多难题,具体来说有下面列举的几点: 使用方式往往比较粗糙,默认的设置并不适合每一个集群和业务,非精细化的设计将会极大的增加集群隐患; 集群出现问题,无法及时定位原因、寻找解决方案,低效的沟通或者解决问题的方式可能会使得问题变得愈发严重; ES提供的监控指标繁杂,指标多,意义不明确,需要一定的专业知识才可以理解,缺乏全局视角; 此外,集群潜在的异常无法发现,更不能及时规避风险。 随着越来越多的用户选择使用阿里云ES服务来支持搜索和分析业务,上述这些问题越发明显,用户和实例数量的快速增长,让我们没有太多的精力去逐一对接所有用户的问题,这无形中
相关文章
文章评论
共有0条评论来说两句吧...