• Elasticsearch Index Monitoring(索引监控)之Index Stats API详解


    索引状态统计。默认情况下,该API会返回所有类型的统计信息,Indices Stats返回如下类型的统计信息。

    docs

    文档总数量(包含已删除的文档),调用文档删除API后并不会立即将文档物理删除,会保留一段时间,受refreshing the index的影响。其返回示例如下:

    1. 1"docs" : {
    2. 2 "count" : 1286,
    3. 3 "deleted" : 0
    4. 4 }

    复制

    store

    索引存储的总大小,其返回示例如下:

    1. 1"store" : {
    2. 2 "size_in_bytes" : 459254
    3. 3}

    复制

    其返回字段说明如下:

    • size_in_bytes 索引大小,单位为字节。

    indexing

    新增、更新、删除索引操作的统计信息,其返回示例如下:

    1. 1"indexing" : {
    2. 2 "index_total" : 0,
    3. 3 "index_time_in_millis" : 0,
    4. 4 "index_current" : 0,
    5. 5 "index_failed" : 0,
    6. 6 "delete_total" : 0,
    7. 7 "delete_time_in_millis" : 0,
    8. 8 "delete_current" : 0,
    9. 9 "noop_update_total" : 0,
    10. 10 "is_throttled" : false,
    11. 11 "throttle_time_in_millis" : 0
    12. 12 }

    复制

    其返回字段说明如下:

    • index_total 索引操作总次数。
    • index_time_in_millis 索引操作总耗时。
    • index_current 当前正在执行索引操作的个数。
    • index_failed 失败的索引操作次数。
    • delete_total 执行删除索引操作的次数。
    • delete_time_in_millis 删除索引操作总耗时。
    • delete_current 当前正在执行删除索引操作的个数。
    • noop_update_total 空更新总次数(检测到空更新的次数)。
    • is_throttled 索引是否处在merge throttling control(合并节流控制状态)。
    • throttle_time_in_millis 索引处在merge throttling control(合并节流状态)的时间开销。

    get

    get api 统计信息,其返回示例如下:

    1. 1"get" : {
    2. 2 "total" : 0,
    3. 3 "time_in_millis" : 0,
    4. 4 "exists_total" : 0,
    5. 5 "exists_time_in_millis" : 0,
    6. 6 "missing_total" : 0,
    7. 7 "missing_time_in_millis" : 0,
    8. 8 "current" : 0
    9. 9}

    复制

    其返回字段说明如下:

    • total get api总调用次数。
    • time_in_millis get api总耗时。
    • exists_total 命中的次数。
    • exists_time_in_millis 命中的操作总耗时。
    • missing_total 未命中的总次数。
    • missing_time_in_millis 未命中的操作的总耗时。
    • current 当前正在执行的个数。

    search

    查询API的统计信息,其返回示例如下:

    1. 1 "search" : {
    2. 2 "open_contexts" : 0,
    3. 3 "query_total" : 0,
    4. 4 "query_time_in_millis" : 0,
    5. 5 "query_current" : 0,
    6. 6 "fetch_total" : 0,
    7. 7 "fetch_time_in_millis" : 0,
    8. 8 "fetch_current" : 0,
    9. 9 "scroll_total" : 0,
    10. 10 "scroll_time_in_millis" : 0,
    11. 11 "scroll_current" : 0,
    12. 12 "suggest_total" : 0,
    13. 13 "suggest_time_in_millis" : 0,
    14. 14 "suggest_current" : 0
    15. 15 },

    复制

    其返回字段说明如下:

    • open_contexts 正在打开的查询上下文个数。
    • query_total 查询出来的总数据条数。
    • query_time_in_millis 查询阶段所耗费的时间。
    • query_current 当前正在查询个数。
    • fetch_total Fetch操作的次数。
    • fetch_time_in_millis Fetch阶段总耗时时间。
    • fetch_current 正在fetch的次数。
    • scroll_total 通过scroll api查询数据总条数。
    • scroll_time_in_millis 通过scroll api总耗时时间。
    • scroll_current 当前滚动API调用次数。
    • suggest_total 通过suggest api获取的推荐总数量。
    • suggest_time_in_millis suggest总耗费时间。
    • suggest_current 正在执行suggest api的个数。

    merges

    合并相关的统计信息,其输出示例如下:

    1. 1 "merges" : {
    2. 2 "current" : 0,
    3. 3 "current_docs" : 0,
    4. 4 "current_size_in_bytes" : 0,
    5. 5 "total" : 0,
    6. 6 "total_time_in_millis" : 0,
    7. 7 "total_docs" : 0,
    8. 8 "total_size_in_bytes" : 0,
    9. 9 "total_stopped_time_in_millis" : 0,
    10. 10 "total_throttled_time_in_millis" : 0,
    11. 11 "total_auto_throttle_in_bytes" : 104857600
    12. 12 }

    复制

    其返回字段说明如下:

    • current 总发生的合并次数。
    • current_docs 当前正在发生合并的文档数。
    • current_size_in_bytes 当前合并参与的文档总大小,单位字节。
    • total 总发生的合并次数。
    • total_time_in_millis 合并的总耗时(单位毫秒)。
    • total_docs merge(合并)时总处理的文档个数。
    • total_size_in_bytes merge(合并)时总处理的文档总大小(字节)。
    • total_stopped_time_in_millis merge(合并)时总停止时间(吞吐率为0)。
    • total_throttled_time_in_millis 超过指定吞吐率而暂停的时间(节流)。
    • total_auto_throttle_in_bytes 自动进行流控的阔值,默认速率20m/s。

    refresh

    刷新索引相关的统计。

    1. 1 "refresh" : {
    2. 2 "total" : 15,
    3. 3 "total_time_in_millis" : 0,
    4. 4 "listeners" : 0
    5. 5 }

    复制

    其返回字段说明如下:

    • total 执行刷新的总次数。
    • total_time_in_millis 执行刷新总耗时。
    • listeners 等待刷新侦听器的数量。

    flush

    刷盘的统计信息。

    1. 1"flush" : {
    2. 2 "total" : 5,
    3. 3 "periodic" : 0,
    4. 4 "total_time_in_millis" : 0
    5. 5 }

    复制

    其返回字段说明如下:

    • total 执行刷盘操作的次数。
    • periodic 当translog超过刷新阈值时周期性触发的刷新次数。
    • total_time_in_millis 刷盘操作总耗时时间。

    warmer

    索引分片(shard)预热统计信息,分片预热是指为索引创建一个分片节点时,是否对该索引预热(为索引创建一bitSet位图)。其统计示例如下:

    1. 1"warmer" : {
    2. 2 "current" : 0,
    3. 3 "total" : 5,
    4. 4 "total_time_in_millis" : 0
    5. 5 }

    复制

    其返回字段说明如下:

    • current 当前正在预热的个数。
    • total 总共发生的预热次数。
    • total_time_in_millis 分片预热总耗时。

    query_cache

    查询缓存统计信息,其示例如下:

    1. 1"query_cache" : {
    2. 2 "memory_size_in_bytes" : 0,
    3. 3 "total_count" : 0,
    4. 4 "hit_count" : 0,
    5. 5 "miss_count" : 0,
    6. 6 "cache_size" : 0,
    7. 7 "cache_count" : 0,
    8. 8 "evictions" : 0
    9. 9 }

    复制

    其返回字段说明如下:

    • memory_size_in_bytes 查询缓存占用的内存空间,单位为字节。
    • total_count 缓存中查询的总次数,等于hit_count + miss_count。
    • hit_count 查询缓存命中的次数。
    • miss_count 查询缓存未命中的次数。
    • cache_size 当前查询缓存中缓存文档的个数。
    • cache_count 查询缓存总缓存文档个数(包含已经被换出evictions的文档个数)。
    • evictions 查询缓存被逐出的总数。

    fielddata

    fielddata统计信息,fielddata主要用加快text字段排序与聚合的性能,存储词根与文档的映射关系存储在在内存,在内存中进行排序与聚合。

    1. 1"fielddata" : {
    2. 2 "memory_size_in_bytes" : 0,
    3. 3 "evictions" : 0
    4. 4 }

    复制

    其返回字段说明如下:

    • memory_size_in_bytes 当前占用内存的大小。
    • evictions 被逐出词根的个数。

    completion

    completion(自动填充)相关统计,其输出示例为:

    1. 1"completion" : {
    2. 2 "size_in_bytes" : 0
    3. 3 },

    复制

    其返回字段说明如下:

    • size_in_bytes 自动提示占用字节数。

    segments

    检索打开段的内存使用情况。可选地,设置include_segment_file_size=true(默认为false),将输出每个Lucene索引文件的聚合磁盘使用情况,其返回示例如下:

    1. 1"segments" : {
    2. 2 "count" : 32,
    3. 3 "memory_in_bytes" : 38078,
    4. 4 "terms_memory_in_bytes" : 23838,
    5. 5 "stored_fields_memory_in_bytes" : 9984,
    6. 6 "term_vectors_memory_in_bytes" : 0,
    7. 7 "norms_memory_in_bytes" : 2048,
    8. 8 "points_memory_in_bytes" : 32,
    9. 9 "doc_values_memory_in_bytes" : 2176,
    10. 10 "index_writer_memory_in_bytes" : 0,
    11. 11 "version_map_memory_in_bytes" : 0,
    12. 12 "fixed_bit_set_memory_in_bytes" : 0,
    13. 13 "max_unsafe_auto_id_timestamp" : -1,
    14. 14 "file_sizes" : { }
    15. 15 },

    复制

    其返回字段说明如下:

    • count 该索引目前拥有的总段数。
    • memory_in_bytes 该索引缓存在内存中字节数。
    • terms_memory_in_bytes 倒排索引(term)缓存在内中所占字节数。
    • stored_fields_memory_in_bytes 该索引定义为stored_fields字段在内存中缓存的字节数。
    • term_vectors_memory_in_bytes 该索引term_vectors(词向量)在内存中所占字节数量。
    • norms_memory_in_bytes 该索引存储对应norms=true的字段当前在内存中缓存字节数。
    • points_memory_in_bytes 与地理位置相关的缓存数据。
    • doc_values_memory_in_bytes 设置为doc_values缓存在内存中的字节数(doc_values,列式存储)。
    • index_writer_memory_in_bytes 用于优化索引写的缓存(减少写磁盘的频率)。
    • version_map_memory_in_bytes 关于文档的版本映射所占内存大小。
    • fixed_bit_set_memory_in_bytes fixed_bit_set内存,专门用来做nested查询的。
    • max_unsafe_auto_id_timestamp es内部当前的自增ID。
    • file_sizes 其中如果设置为true,则file_sizes主要包含如下统计信息:

    translog

    translog统计信息(有点类似于Innodb的redo日志),其输出示例如下:

    1. 1"translog" : {
    2. 2 "operations" : 0,
    3. 3 "size_in_bytes" : 1100,
    4. 4 "uncommitted_operations" : 0,
    5. 5 "uncommitted_size_in_bytes" : 1100,
    6. 6 "earliest_last_modified_age" : 0
    7. 7 }

    复制

    其返回字段说明如下:

    • operations 写translog的次数(索引文档、更新文档、删除文档的总操作数量)。
    • size_in_bytes translog实例管理的translog文件总大小。(一个索引引擎(InternalEngine)示例包含一个Translog实例)。
    • uncommitted_operations 当前还未提交到lucene中的操作次数(索引文档、更新文档、删除文档的操作数量)。
    • uncommitted_size_in_bytes translog中未提交到Lucene中的字节数。
    • earliest_last_modified_age 以秒为单位返回translog文件中最老条目的年龄。

    request_cache

    请求缓存的统计信息,其输出示例如下:

    1. 1"request_cache" : {
    2. 2 "memory_size_in_bytes" : 0,
    3. 3 "evictions" : 0,
    4. 4 "hit_count" : 0,
    5. 5 "miss_count" : 0
    6. 6},

    复制

    其返回字段说明如下:

    • memory_size_in_bytes 请求缓存占用内存总大小。
    • evictions 请求缓存被剔除出次数。
    • hit_count 请求缓存被命中次数。
    • miss_count 请求缓存未命中次数。

    recovery

    recovery(恢复)相关的统计信息,其输出示例:

    1. 1"recovery" : {
    2. 2 "current_as_source" : 0,
    3. 3 "current_as_target" : 0,
    4. 4 "throttle_time_in_millis" : 0
    5. 5}

    复制

    其返回字段说明如下:

    • current_as_source 作为源分片,正在执行恢复的分片数量 。
    • current_as_target 作为目标分片,正在执行恢复的分片数量。
    • throttle_time_in_millis 恢复过程总等待时间。

    Indices Stats返回的结果是在索引级别的聚合,包含三个维度:primaries(所有主节点进行聚合)、total(所有主节点、副本节点进行聚合)、indices(索引级别)。

    下面给出在JAVA中使用Index Stats示例来结束本篇的讲解。

    ElasticSearch Index Stats JAVA示例如下:(当前elasticsearch6.4.0 High Rest Client未提供对应API的封装)

    1. 1public static final void test_Indices_StatsIndex() {
    2. 2 TransportClient client = EsClient.getTransportClient();
    3. 3 try {
    4. 4 IndicesStatsRequest request = new IndicesStatsRequest();
    5. 5// request.indices("aggregations_index02");
    6. 6// request.indices("logs_write");
    7. 7// request.includeSegmentFileSizes(true);
    8. 8 ActionFuture<IndicesStatsResponse> responseFuture = client.admin().indices().stats(request);
    9. 9 IndicesStatsResponse response = responseFuture.get();
    10. 10 System.out.println(response);
    11. 11// System.out.println(result);
    12. 12 } catch (Throwable e) {
    13. 13 e.printStackTrace();
    14. 14 } finally {
    15. 15 EsClient.close(client);
    16. 16 }
    17. 17 }

    复制

    其返回的结果:

    1. 1{
    2. 2 "_shards" : {
    3. 3 "total" : 172,
    4. 4 "successful" : 86,
    5. 5 "failed" : 0
    6. 6 },
    7. 7 "_all" : {
    8. 8 "primaries" : {
    9. 9 "docs" : {
    10. 10 "count" : 4166,
    11. 11 "deleted" : 0
    12. 12 },
    13. 13 "store" : {
    14. 14 "size_in_bytes" : 929840
    15. 15 },
    16. 16 // ... 省略部分选项
    17. 17 },
    18. 18 "total" : {
    19. 19 "docs" : {
    20. 20 "count" : 4166,
    21. 21 "deleted" : 0
    22. 22 },
    23. 23 "store" : {
    24. 24 "size_in_bytes" : 929840
    25. 25 },
    26. 26 // ... 省略部分选项
    27. 27 }
    28. 28 },
    29. 29 "indices" : {
    30. 30 "aggregations_index04" : {
    31. 31 "uuid" : "2_6WutahTHa6iK52E7CwZQ",
    32. 32 "primaries" : {
    33. 33 // ... 省略部分选项
    34. 34 },
    35. 35 "total" : {
    36. 36 // ... 省略部分选项
    37. 37 }
    38. 38 },
    39. 39 "alias_demo" : {
    40. 40 "uuid" : "EltFD6Y6TA-lpfntx00naw",
    41. 41 "primaries" : {
    42. 42
    43. 43 },
    44. 44 "total" : {
    45. 45
    46. 46 }
    47. 47
    48. 48 } // 省略其他索引
    49. 49 }
    50. 50}

    复制

    本文详细介绍了Index Stats API的使用,特别在结合源码的基础上给出该API响应结果中各个字段含义的解读,包含docs、store、indexing、get、search、merges、refresh、flush、warmer、query_cache、fielddata、completion、segments、translog、request_cache、recovery。

    本文参与 腾讯云自媒体分享计划,分享自微信公众号。

    原始发表:2019-05-04,如有侵权请联系 cloudcommunity@tencent.com 删除

    缓存

    api

    http

    评论

    登录后参与评论

    推荐

    【ES私房菜】Filebeat安装部署及配置详解

    go

    Filebeat是Beat成员之一,基于Go语言,无任何依赖,并且比logstash更加轻量,非常适合安装在生产机器上,不会带来过高的资源占用,轻量意味着简单。

    张戈

    2017-09-29

    22.5K3

    【ES私房菜】Filebeat安装部署及配置详解

    部署 Kubernetes 集群日志插件 Fluentd、Elasticsearch、Kibana

    dockerkubernetes

    目录 Kubernetes 日志架构介绍 环境、软件准备 启动 Fluentd 启动 Elasticsearch 启动 Kibana 浏览器添加证书 RBAC 认证模式介绍 1、Kubernetes 日志架构介绍 对于任何基础架构或者服务系统,日志重要性不言而喻,当然 Kubernetes 也少不了对 Logging 的支持,集群中各个资源以及服务日志如何很好的集中查看并分析,官方给出了 Cluster-level Logging 的架构,其中就提供使用 EFK 框架作为集群日志解决方案。当然 EF

    哎_小羊

    2018-01-02

    6.7K0

    部署 Kubernetes 集群日志插件 Fluentd、Elasticsearch、Kibana

    Apache Zeppelin 中 Elasticsearch 解释器

    apache

    概述 Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它允许您快速,实时地存储,搜索和分析大量数据。它通常用作为具有复杂的搜索功能和要求的应用程序提供的底层引擎/技术。 配置 属性 默认 描述 elasticsearch.cluster.name elasticsearch 群集名称 elasticsearch.host localhost 集群中节点的主机 elasticsearch.port 9300 连接端口(重要提

    片刻

    2018-01-05

    1.1K0

    Apache Zeppelin 中 Elasticsearch 解释器

    Elasticsearch使用REST API实现全文检索

    es 2api

    通过rest api添加检索数据,阅读官方文档可以发现,elasticsearch支持动态映射,但是其中有不少问题,且听慢慢详解。 本文主要讲述三点内容: 1 Elasticsearch常用的rest api 2 Elasticsearch使用bulk命令添加索引数据 ES REST API   elasticsearch支持通过http请求响应服务,因此通过curl命令,可以发送http请求,并得到json返回内容。   常用的rest请求包括:   检查ES集群状态: curl localh

    用户1154259

    2018-01-17

    8630

    Elasticsearch使用REST API实现全文检索

    Elasticsearch+Logstash+Kibana教程

    云数据库 Redis数据处理es 2

    参考资料 累了就听会歌吧! Elasticsearch中文参考文档 Elasticsearch官方文档 Elasticsearch 其他——那些年遇到的坑 Elasticsearch 管理文档 Elasticsearch集群配置以及REST API使用 Elasticsearch集群管理 Elasticsearch 数据搜索篇·【入门级干货】 Elasticsearch使用REST API实现全文检索 Windows下elasticsearch插入数据报错! Kibana中doc与search策略的区别 E

    用户1154259

    2018-01-17

    2.2K0

    如何开发自己的搜索帝国之ES图形化Kibana安装与使用

    大数据机器学习

      在如何开发自己的搜索帝国之Elasticsearch中已经介绍安装好了ES,下面就Kibana对ES的查询监控作介绍,就是常提到的大数据日志处理组件ELK里的K。   什么是Kibana?现引用园友的一段对此的介绍,个人觉得比较全。   Kibana是一个针对Elasticsearch的开源分析及可视化平台,用来搜索、查看交互存储在Elasticsearch索引中的数据。使用Kibana,可以通过各种图表进行高级数据分析及展示。   Kibana让海量数据更容易理解。它操作简单,基于浏览器的用户界面可以

    欢醉

    2018-01-22

    1.2K0

    如何开发自己的搜索帝国之ES图形化Kibana安装与使用

    ElasticSearch详解与优化设计

    其他

    1、简介 ElasticSearch(简称ES)是一个分布式、Restful的搜索及分析服务器,设计用于分布式计算;能够达到实时搜索,稳定,可靠,快速。和Apache Solr一样,它也是基于Lucence的索引服务器,而ElasticSearch对比Solr的优点在于: 轻量级:安装启动方便,下载文件之后一条命令就可以启动。 Schema free:可以向服务器提交任意结构的JSON对象,Solr中使用schema.xml指定了索引结构。 多索引文件支持:使用不同的index参

    用户1263954

    2018-01-30

    1.5K0

    ElasticSearch详解与优化设计

    开源搜索和分析引擎Elasticsearche在Bay的性能优化实践,单集群日搜索请求超4亿

    apache开源

    摘要:Elasticsearch是基于Apache Lucene的开源搜索和分析引擎,允许用户以近乎实时的方式存储,搜索和分析数据。虽然Elasticsearch专为快速查询而设计,但其性能在很大程度上取决于用于应用程序的场景,索引的数据量以及应用程序和用户查询数据的速率。这篇文章概述了挑战和调优过程,以及Pronto团队以战略方式构建应对挑战的工具。它还以各种图形配置展示了进行基准测试的一些结果。以下是正文。 Elasticsearch是基于Apache Lucene的开源搜索和分析引擎,允许用户以近乎实

    CSDN技术头条

    2018-02-06

    1.2K0

    开源搜索和分析引擎Elasticsearche在Bay的性能优化实践,单集群日搜索请求超4亿

    ELK 集群 Kibana 使用 X-Pack 权限控制,监控集群状态,实时的生成,警报,监视,cpu,内存,磁盘空间,等等一系列,报告和的可视化图形

    Elasticsearch Servicehtml

    简述 ELK实际上是三个工具的集合,ElasticSearch + Logstash + Kibana 这三个工具组合形成了一套实用、易用的监控架构,很多公司利用它来搭建可视化的海量日志分析平台。 X-Pack X-Pack Elastic Stack X-Pack是一个Elastic Stack的扩展,将安全,警报,监视,报告和图形功能包含在一个易于安装的软件包中 搭建集群 1.X-Pack 安装 https://www.elastic.co/guide/en/x-pack/current/index.h

    搜云库

    2018-02-09

    2K0

    ELK 集群 Kibana 使用 X-Pack  权限控制,监控集群状态,实时的生成,警报,监视,cpu,内存,磁盘空间,等等一系列,报告和的可视化图形

    深入内核:CBO对于Cost值相同索引的选择

    sqloracle

    崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 编辑手记:感谢崔华授权我们独家转载其精品文章,也欢迎大家向“Oracle”社区投稿。 这里我们稍微讨论一下CBO对于Cost值相同的索引的选择,可能会有朋友认为在同样Cost的情况下,Oracle会按照索引名的字母顺序来选择索引,实际上并不完全是这样,CBO对于Cost值相同的索引的选择和Oracle的版本有关。 原理说明 MOS上文章“Handling of equally ranked (RBO) or cos

    数据和云

    2018-03-05

    8930

    深入内核:CBO对于Cost值相同索引的选择

    性能优化:监控索引的使用情况

    oracle数据库

    黄玮(Fuyuncat),资深 Oracle DBA,从事 Oracle 数据库管理、维护与开发工作十余年,有丰富的大型数据库设计、开发与维护方面的经验,博客www.HelloDBA.com, 一个系统,经过长期的运行、维护和版本更新后,可能会产生大量的索引,甚至索引所占空间远远大于数据所占的空间。很多索引,在初期设计时,对于系统来说是有用的。但是,经过系统的升级、数据表结构的调整、应用的改变,很多索引逐渐不被使用,成为了垃圾索引。这些索引占据了大量数据空间,增加了系统的维护量,甚至会降低系统性能。因此

    数据和云

    2018-03-06

    5420

    性能优化:监控索引的使用情况

    简单分析percona-zabbix-templates(r10笔记第6天)

    zabbix开源运维云数据库 SQL Server

    当Zabbix和Percona两者相遇,会擦出不少的开源火花来,众人拾柴火焰高,最终受益的还是大部分运维人员。 我很早就用过Percona提供的MySQL监控模板,但是却没有刨根问底,只是简单使用而已,自从定制了Orabbix之后,我还是信心满满,MySQL的数据字典相对要少很多,监控起来可能想必Oracle要少很多,不过关于Percona的这个插件,我还是带着好奇之心,内部是否有很多独门秘籍,我想好好学学那些监控项对应的SQL,好好弥补我对于MySQL监控的一些空缺,所以简单分析这个模板就

    jeanron100

    2018-03-19

    6240

    简单分析percona-zabbix-templates(r10笔记第6天)

    一个SQL性能问题的优化探索(二)(r11笔记第38天)

    sql数据库

    继续前几天的一个案例一个SQL性能问题的优化探索(一)(r11笔记第33天) 如下的SQL语句存在索引字段CARD_NO,但是执行的时候却走了全表扫描,因为这是一个核心表,数据量很大,导致数据库负载很高。 SQL_FULLTEXT ---------------------------------------------------------------------------------------------------- SELECT ID,CN,CARD_NO,TO_CHAR(CHARGE_DAT

    jeanron100

    2018-03-21

    6250

    一个SQL性能问题的优化探索(二)(r11笔记第38天)

    干货 |《从Lucene到Elasticsearch全文检索实战》拆解实践

    其他

    1、题记 2018年3月初,萌生了一个想法:对Elasticsearch相关的技术书籍做拆解阅读,该想法源自非计算机领域红火已久的【樊登读书会】、得到的每天听本书、XX拆书帮等。 目前市面上Elasticsearch的中文书籍就那么基本,针对ES5.X以上的三本左右;国外翻译有几本,都是针对ES1.X,2.X版本,其中《深入理解Elasticsearch》还算比较经典。 拆书的目的: 1)梳理已有的Elasticsearch知识体系; 2)拾遗拉在角落的Elasticsearch知识点; 3)通过手敲动代码

    铭毅天下

    2018-04-24

    3.1K0

    DevOps 漫谈:基于OpenCensus构建分布式跟踪系统

    devops分布式

    随着互联网技术的高速发展,以往单应用的服务架构已经很难处理如山洪般增长的信息数据,随着云计算技术的大规模应用,以微服务、RESTful 为代表的各种软件架构广泛应用,跨团队、跨编程语言的大规模分布式系统也越来越多。相对而言,现在要理解系统行为,追踪诊断性能问题会复杂得多。

    RiboseYim

    2018-04-28

    1.8K0

    DevOps 漫谈:基于OpenCensus构建分布式跟踪系统

    Oracle数据库该如何着手优化一个SQL

    oracle数据库sql

    这是个终极问题,因为优化本身的复杂性实在是难以总结的,很多时候优化的方法并不是用到了什么高深莫测的技术,而只是一个思想意识层面的差异,而这些都很可能连带导致性能表现上的巨大差异。 所以有时候我们应该先搞清楚需求到底是什么,SQL本身是否合理,这些思考很可能会使优化工作事半功倍。而本文是假设SQL本身合理,从Oracle提供给我们的一些技术手段来简单介绍下Oracle数据库,该如何使用一些现有的技术来优化一个SQL执行的性能。 确定需要优化的SQL文本及当前SQL执行计划 确定SQL涉及的所有表及其索引的相

    Alfred Zhao

    2018-05-11

    7860

    12-部署EFK插件

    其他

    配置和安装 EFK 官方文件目录:cluster/addons/fluentd-elasticsearch $ ls *.yaml es-controller.yaml es-service.yaml fluentd-es-ds.yaml kibana-controller.yaml kibana-service.yaml efk-rbac.yaml 同样EFK服务也需要一个efk-rbac.yaml文件,配置serviceaccount为efk。 已经修改好的 yaml 文件见:EFK 配置 es

    8420

    ElasticSearch介绍

    其他

    什么是搜索? 如果使用数据库做搜索会怎样? 什么是全文检索和Lucene 什么是ElasticSearch1. 什么是搜索? 百度、google上查询任何需要的内容信息。这种是通用的搜索。但是百度只是一个通用的搜索引擎,并不等于搜索。 垂直搜索(站内搜索): 在指定领域或内容区域搜索内容, 互联网的搜索:​ 比如淘宝,拉钩,今日头条等。 IT系统的搜索:​ OA软件,办公自动化软件,会议管理,日程管理,项目管理等。 搜索:就是在任何场景下,找寻你想要的信息,这个时候,会输入一段你想要的关键字,然后就

    5340

    死磕 Elasticsearch 方法论:普通程序员高效精进的 10 大狠招!

    es 2人工智能大数据开源

    人工智能、大数据快速发展的今天,对于 TB 甚至 PB 级大数据的快速检索已然成为刚需。Elasticsearch 作为开源领域的后起之秀,从2010年至今得到飞跃式的发展。 Elasticsearch 以其开源、分布式、RESTFul API 三大优势,已经成为当下风口中“会飞的猪”。

    1.4K0

    如何监控Elasticsearch

    es 2开源分布式存储

    Elasticsearch是一个开源的分布式文档存储和搜索引擎,可以近乎实时地存储和检索数据结构,它很大程度上依赖于Apache Lucence--一个用Java编写的全文搜索引擎。

  • 相关阅读:
    NoClassDefFoundError: org/tukaani/xz/FilterOptions
    Apache APISIX 2.12.0 版本发布, 新功能更适配新一年
    如何使用积分系统增强用户留存?会员积分体系建设方式介绍
    Mac电脑窗口管理Magnet中文 for mac
    C Primer Plus(6) 中文版 第5章 运算符、表达式和语句 5.3 其他运算符
    操作系统之零拷贝
    大数据开发语言Scala入门:新手小白学习指南
    【JS学习】字符串的replace方法
    解锁云原生新场景 | 云原生加速云边端一体化发展
    蓝桥杯双周赛算法心得——通关(哈希+小根堆)
  • 原文地址:https://blog.csdn.net/qq_36763348/article/details/133159532