需求来源：客户现场redis内存飙升，由于无法远程连接客户现场环境，进而分析redis的内存中占用较大的key，无法进行问题精确定位，所以需要一个组件或者方法来查看redis内存占用大的key的列表，进而定位问题解决方案：依赖：redis持久化的rdb文件，以及开源的Redis Data Reveal（rdr）组件rdb文件：该文件有两个来源：redis配置的持久化策略，定期会生成一个rdb文件，

type属性的由来从Elasticsearch的第一个发布版本以来，每一个document都被存储在一个单独的index里，并被赋予了一个type，一个mapping代表一个type相关的数据类型以及索引类型。例如，一个twitter索引可能有一个user类型和tweet类型。每种type都有他自己的字段，所以user类型可能有一个full_name字段，一个user_name字段和一个email

前言说起x-pack这个组件，不是什么新鲜的功能，其实在elasticsearch早期版本就已经有了，而且x-pack在功能对于elasticsearch的安全性来说也毋庸置疑，但是俗话说得好，一分钱难倒英雄汉，更何况花销的单位可能是数万甚至更多，所以早期在中国并没有被大规模普及，能用的要么是财大气粗的金融、银行以及运营商等重量级客户；要么是通过“其他渠道”偷偷使用的中小客户。“菜谱哥”可能注意到

环境信息：HBase 1.2.X，Zookeeper，3.4.X问题描述：HBase的regionserver进程挂掉，查看日志，发现如下报错：FATAL [main-EventThread] regionserver.HRegionServer: ABORTING region serverorg.apache.zookeeper.KeeperException$SessionExpiredEx

环境信息：HBase 1.2.2，Hadoop 2.7.2使用需求：为什么需要合并Region呢？这个需要从Region的Split来说。当一个Region被不断的写数据，达到Region的Split的阀值时（由属性hbase.hregion.max.filesize来决定，默认是10GB），该Region就会被Split成2个新的Region。随着业务数据量的不断增加，Region不...

需求来源公司当前使用的elasticsearch&kibana是6.0.0版本，这已经是快三年前的古老版本了，最新的7.9.X，出于性能上的提升以及漏洞的修复（客户爸爸对于漏洞扫描的结果表示了深切的担忧-_-！），所以近期将elasticsearch&kibana升级提上日程，由于我们公司是elasticsearch&kibana的重度用户，而且绝大多数有价值的数据都存在e

预留足够的offheap内存在一般情况下，应用程序的读写都会被操作系统“cache”（除了direct方式）,cache保存在系统物理内存中（线上应该禁用swap），命中cache可以降低对磁盘的直接访问频率。搜索很依赖对系统 cache 的命中，如果某个请求需要从磁盘读取数据，则一定会产生相对较高的延迟。在Elasticsearch中，使用的内存分为onheap以及offheap部分，onhea

追求极致的写入速度时，很多是以牺牲可靠性和搜索实时性为代价的。有时候，业务上对数据可靠性和搜索实时性要求并不高，反而对写入速度要求很高，此时可以调整一些策略，最大化写入速度如果是集群首次批量导入数据，则可以将副本数设置为0，导入完毕再将副本数调整回去，这样副分片只需要复制，节省了数据同步的过程。如果是实时数据写入，综合来说，提升写入速度从以下几方面入手：加大translog flush间隔，目的是

环境信息：CentOS 6.5现象：同事启动程序发现端口被占用，netstat查看之后发现如下现象：发现端口处于FIN_WAIT1状态以及CLOSE_WAIT状态，无法释放问题分析：FIN_WAIT1以及CLOSE_WAIT状态的原理以及产生的原因大家自行baidu，下面就说下怎么解决上述问题，释放端口FIN_WAIT1：1、sysctl -a |grep tc...

报错信息：Caused by: java.lang.IllegalStateException: availableProcessors is already set to [8], rejecting [8]问题排查：原因是因为SpringBoot的netty和elasticsearch的netty相关jar冲突，导致程序抛出异常问题解决：在SpringBoot的入口类Application的m