首页 文章 精选 留言 我的

精选列表

搜索[Elasticsearch],共4100篇文章
优秀的个人博客,低调大师

elasticsearch的store属性跟_source字段——如果你的文档长度很长,存储了_source,从_source中获取fiel...

转自:http://kangrui.iteye.com/blog/2262860 众所周知_source字段存储的是索引的原始内容,那store属性的设置是为何呢?es为什么要把store的默认取值设置为no?设置为yes是否是重复的存储呢? 我们将一个field的值写入es中,要么是想在这个field上执行search操作(不知道具体的id),要么执行retrieve操作(根据id来检索)。但是,如果不显式的将该field的store属性设置为yes,同时_source字段enabled的情况下,你仍然可以获取到这个field的值。这就意味着在一些情况下让一个field不被index或者store仍然是有意义的。 当你将一个field的store属性设置为true,这个会在lucene层面处理。lucene是倒排索引,可以执行快速的全文检索,返回符合检索条件的文档id列表。在全文索引之外,lucene也提供了存储字段的值的特性,以支持提供id的查询(根据id得到原始信息)。通常我们在lucene层面存储的field的值是跟随search请求一起返回的(id+field的值)。es并不需要存储你想返回的每一个field的值,因为默认情况下每一个文档的的完整信息都已经存储了,因此可以跟随查询结构返回你想要的所有field值。 有一些情况下,显式的存储某些field的值是必须的:当_source被disabled的时候,或者你并不想从source中parser来得到field的值(即使这个过程是自动的)。请记住:从每一个stored field中获取值都需要一次磁盘io,如果想获取多个field的值,就需要多次磁盘io,但是,如果从_source中获取多个field的值,则只需要一次磁盘io,因为_source只是一个字段而已。所以在大多数情况下,从_source中获取是快速而高效的。 es中默认的设置_source是enable的,存储整个文档的值。这意味着在执行search操作的时候可以返回整个文档的信息。如果不想返回这个文档的完整信息,也可以指定要求返回的field,es会自动从_source中抽取出指定field的值返回(比如说highlighting的需求)。 你可以指定一些字段store为true,这意味着这个field的数据将会被单独存储。这时候,如果你要求返回field1(store:yes),es会分辨出field1已经被存储了,因此不会从_source中加载,而是从field1的存储块中加载。 哪些情形下需要显式的指定store属性呢?大多数情况并不是必须的。从_source中获取值是快速而且高效的。 如果你的文档长度很长,存储_source或者从_source中获取field的代价很大,你可以显式的将某些field的store属性设置为yes。缺点如上边所说:假设你存储了10个field,而如果想获取这10个field的值,则需要多次的io,如果从_source中获取则只需要一次,而且_source是被压缩过的。 还有一种情形: reindex from some field,对某些字段重建索引的时候。从source中读取数据然后reindex,和从某些field中读取数据相比,显然后者代价更低一些。这些字段store设置为yes比较合适。 总结: 如果对某个field做了索引,则可以查询。如果store:yes,则可以展示该field的值。 但是如果你存储了这个doc的数据(_source enable),即使store为no,仍然可以得到field的值(client去解析)。 所以一个store设置为no 的field,如果_source被disable,则只能检索不能展示。 本文转自张昺华-sky博客园博客,原文链接: http://www.cnblogs.com/bonelee/p/6428768.html ,如需转载请自行联系原作者

优秀的个人博客,低调大师

Elasticsearch压缩索引——lucene倒排索引本质是列存储+使用嵌套文档可以大幅度提高压缩率

注意:由于是重复数据,词法不具有通用性!文章价值不大! 摘自:https://segmentfault.com/a/1190000002695169 Doc Values 会压缩存储重复的内容。给定这样一个简单的 mapping mappings = { 'testdata': { '_source': {'enabled': False}, '_all': {'enabled': False}, 'properties': { 'name': { 'type': 'string', 'index': 'no', 'store': False, 'dynamic': 'strict', 'fielddata': {'format': 'doc_values'} } } } } 插入100万行随机的重复值 words = ['hello', 'world', 'there', 'here'] def read_test_data_in_batches(): batch = [] for i in range(10000 * 100): if i % 50000 == 0: print(i) if len(batch) > 10000: yield batch batch = [] batch.append({ '_index': 'wentao-test-doc-values', '_type': 'testdata', '_source': {'name': random.choice(words)} }) print(i) yield batch 磁盘占用是 size: 28.5Mi (28.5Mi) docs: 1,000,000 (1,000,000) 把每个word搞长一些,同样是插入100万行 words = ['hello' * 100, 'world' * 100, 'there' * 100, 'here' * 100] def read_test_data_in_batches(): batch = [] for i in range(10000 * 100): if i % 50000 == 0: print(i) if len(batch) > 10000: yield batch batch = [] batch.append({ '_index': 'wentao-test-doc-values', '_type': 'testdata', '_source': {'name': random.choice(words)} }) print(i) yield batch 磁盘占用不升反降 size: 14.4Mi (14.4Mi) docs: 1,000,000 (1,000,000) 这说明了lucene在底层用列式存储这些字符串的时候是做了压缩的。这个要是在某个商业列式数据库里,就这么点优化都是要大书特书的dictionary encoding优化云云。 Nested Document 实验表明把一堆小文档打包成一个大文档的nested document可以压缩存储空间。把前面的mapping改成这样: mappings = { 'testdata': { '_source': {'enabled': False}, '_all': {'enabled': False}, 'properties': { 'children': { 'type': 'nested', 'properties': { 'name': { 'type': 'string', 'index': 'no', 'store': False, 'dynamic': 'strict', 'fielddata': {'format': 'doc_values'} } } } } } } 还是插入100万行,但是每一千行打包成一个大文档 words = ['hello', 'world', 'there', 'here'] def read_test_data_in_batches(): batch = [] for i in range(10000 * 100): if i % 50000 == 0: print(i) if len(batch) > 1000: yield [{ '_index': 'wentao-test-doc-values2', '_type': 'testdata', '_source': {'children': batch} }] batch = [] batch.append({'name': random.choice(words)}) print(i) yield [{ '_index': 'wentao-test-doc-values2', '_type': 'testdata', '_source': {'children': batch} }] 磁盘占用是 size: 2.47Mi (2.47Mi) docs: 1,001,000 (1,001,000) 文档数没有变小,但是磁盘空间仅仅占用了2.47M。这个应该受益于lucene内部对于嵌套文档的存储优化。 本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6269604.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

elasticsearch best_fields most_fields cross_fields从内在实现看区别——本质就是前两者是以f...

1.最佳字段(Best fields):: 假设我们有一个让用户搜索博客文章的网站(允许多字段搜索,最佳字段查询),就像这两份文档一样: PUT /my_index/my_type/1 { "title": "Quick brown rabbits", "body": "Brown rabbits are commonly seen." } PUT /my_index/my_type/2 { "title": "Keeping pets healthy", "body": "My quick brown fox eats rabbits on a regular basis." } // SENSE: 110_Multi_Field_Search/15_Best_fields.json 用户输入了"Brown fox",文档2匹配的更好一些,因为它包含了用户寻找的两个单词。 { "multi_match": { "query": "Quick brown fox", "type": "best_fields", <1> "fields": [ "title", "body" ], "tie_breaker": 0.3, "minimum_should_match": "30%" <2> } } 2.多数字段(Most fields):: 一个用来调优相关度的常用技术是将相同的数据索引到多个字段中。它用来尽可能多地匹配文档。 考虑一下most_fields查询是如何执行的:ES会为每个字段生成一个match查询,然后将它们包含在一个bool查询中。 我们可以将查询传入到validate-query API中进行查看: GET /_validate/query?explain { "query": { "multi_match": { "query": "Poland Street W1V", "type": "most_fields", "fields": [ "street", "city", "country", "postcode" ] } } } // SENSE: 110_Multi_Field_Search/40_Entity_search_problems.json 它会产生下面的解释(explaination): (street:poland street:street street:w1v) (city:poland city:street city:w1v) (country:poland country:street country:w1v) (postcode:poland postcode:street postcode:w1v) 你可以发现能够在两个字段中匹配poland的文档会比在一个字段中匹配了poland和street的文档的分值要高。 3.跨字段(Cross fields):: 对于一些实体,标识信息会在多个字段中出现,每个字段中只含有一部分信息: Person:first_name和last_name Book:title,author, 和description Address:street,city,country, 和postcode 此时,我们希望在任意字段中找到尽可能多的单词。我们需要在多个字段中进行查询,就好像这些字段是一个字段那样。 用户也许会搜索名为"Peter Smith"的人,或者名为"Poland Street W1V"的地址。每个查询的单词都出现在不同的字段中。 如果你在索引文档前就能够自定义_all字段的话,那么使用_all字段就是一个不错的方法。但是,ES同时也提供了一个搜索期间的解决方案:使用类型为cross_fields的multi_match查询。cross_fields类型采用了一种以词条为中心(Term-centric)的方法,这种方法和best_fields及most_fields采用的以字段为中心(Field-centric)的方法有很大的区别。它将所有的字段视为一个大的字段,然后在任一字段中搜索每个词条。 为了阐述以字段为中心和以词条为中心的查询的区别,看看以字段为中心的most_fields查询的解释(译注:通过validate-query API得到): GET /_validate/query?explain { "query": { "multi_match": { "query": "peter smith", "type": "most_fields", "operator": "and", <1> "fields": [ "first_name", "last_name" ] } } } // SENSE: 110_Multi_Field_Search/50_Cross_field.json <1> operator设为了and,表示所有的词条都需要出现。 对于一份匹配的文档,peter和smith两个词条都需要出现在相同的字段中,要么是first_name字段,要么是last_name字段: (+first_name:peter +first_name:smith) (+last_name:peter +last_name:smith) 而以词条为中心的方法则使用了下面这种逻辑: +(first_name:peter last_name:peter) +(first_name:smith last_name:smith) 换言之,词条peter必须出现在任一字段中,同时词条smith也必须出现在任一字段中。 cross_fields类型首先会解析查询字符串来得到一个词条列表,然后在任一字段中搜索每个词条。仅这个区别就能够解决在以字段为中心的查询中提到的3个问题中的2个,只剩下倒排文档频度的不同这一问题。 幸运的是,cross_fields类型也解决了这个问题,从下面的validate-query请求中可以看到: GET /_validate/query?explain { "query": { "multi_match": { "query": "peter smith", "type": "cross_fields", <1> "operator": "and", "fields": [ "first_name", "last_name" ] } } } // SENSE: 110_Multi_Field_Search/50_Cross_field.json <1>cross_fields使用以词条为中心(Term-centric)进行匹配。 它通过混合(Blending)字段的倒排文档频度来解决词条频度的问题: +blended("peter", fields: [first_name, last_name]) +blended("smith", fields: [first_name, last_name]) 换言之,它会查找词条smith在first_name和last_name字段中的IDF值,然后使用两者中较小的作为两个字段最终的IDF值。因为smith是一个常见的姓氏,意味着它也会被当做一个常见的名字。 提示:为了让cross_fields查询类型能以最佳的方式工作,所有的字段都需要使用相同的解析器。使用了相同的解析器的字段会被组合在一起形成混合字段(Blended Fields)。 如果你包含了使用不同解析链(Analysis Chain)的字段,它们会以和best_fields相同的方式被添加到查询中。比如,如果我们将title字段添加到之前的查询中(假设它使用了一个不同的解析器),得到的解释如下所示: (+title:peter +title:smith) ( +blended("peter", fields: [first_name, last_name]) +blended("smith", fields: [first_name, last_name]) ) 当使用了minimum_should_match以及operator参数时,这一点尤为重要。 摘自:https://es.xiaoleilu.com/110_Multi_Field_Search/50_Cross_field.html 本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6827068.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

elasticsearch 索引搜索和索引性能优化配置——思路:去掉不必要的数据,减小数据的磁盘空间占用,同时提升性能

压缩配置: index.codec: best_compression 合并索引: curl –XPOST localhost:9200/hec_test3/_forcemerge’ 配置mapping: curl -XPUT 'http://localhost:9200/hec_test3' -d ' { "mappings": { "hec_type3": { "_source": { "enabled": false }, "_all": { "enabled": false }, "properties": { “fieldxxx": { "type": "string", “norms”: {“enabled”: false}, “store”: false, "doc_values": false, "index_options": "docs" }, …. } } } } ' 注意:同时将原始数据放在DB里,ES里通过doc id去DB里获取。_all搜索时候使用cross_fields。.tim文件较大,可以采用降低shard个数来瘦身。 总之,上述设置后可以将es的索引数据磁盘占用降低为原始数据的50%以内。 本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6934125.html,如需转载请自行联系原作者

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册