前言说起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

环境信息：Hadoop 2.7.2+HBase 1.2.2现象：下午前端的同事使用scan查询HBase数据，代码执行到Table.getScanner(scan)方法时卡住了，无法返回结果直到超时，查看控制台，出现如下报错：java.lang.NoClassDefFoundError：org.apache.hadoop.hbase.util.ByteStringer问题分析：...

说到HBase数据压缩，在HBase中有两种方式可以达到该目的，一个就是column family的compress，HBase支持none/snappy/lzo/lz4/gz等几种压缩方式来压缩数据，最后降低数据总量的大小；另一个是data block 的encoding，通过对data block中的KeyValue中key的相同部分进行处理来减少存储的占用，目前支持prefix/diff/f