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

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

HBase 读取性能优化HBase服务端优化读请求是否均衡如果数据吞吐量较大，且一次查询返回的数据量较大，则Rowkey 必须进行散列化处理，同时建表必须进行预分区处理。对于以get为主的查询场景，则将表进行hash预分区，均匀分布；如果以scan为主，则需要兼顾业务场景设计rowkey，在满足查询需求的前提下尽量对数据打散并进行负载均衡。BlockCache 设置是否合理一个通用的规则就是：如果

前言在计算机的世界中，数据计算和处理都是准确无误的，这在大多数人看来是理所当然的，确实也应该是这样的。但是在某些场景下完全的准确无误意味着很高的代价，不管是时间上还是空间上。于是大家都在考虑，能不能有一些方法能在很小的错误率的前提下，能大幅度提高效率减少资源消耗，而对于小概率误判的场景，能通过容错机制将窟窿补上。显然有，在这种背景下，咱们本文的主角，一个“不靠谱”的二愣子Bloom Filter（

一般来说，如果我们刚开始用es，都是先在自己的笔记本电脑上，或者是几个虚拟机组成的小集群上，安装一个es，然后开始学习和试用其中的功能。但是如果我们要将es部署到生产环境中，那么是由很多额外的事情要做的。需要考虑我们部署的机器的内存、CPU、磁盘、JVM等各种资源和配置。1、内存es是很吃内存的，es吃的主要不是你的jvm的内存，一般来说es用jvm heap（堆内存）还是用的比较少的，主...

数据分布均匀对于数据量较小（100GB以下）的index，往往写入压力查询压力相对较低，一般设置3~5个shard，numberofreplicas设置为1即可（也就是一主一从，共两副本） 。对于数据量较大（100GB以上）的index：一般把单个shard的数据量控制在（20GB~50GB）让index压力分摊至多个节点：可通过index.routing.allocation.totalshar

ElasticSearch在当今NOSQL中也算独树一帜的存在了，借助于强大的全文搜索能力以及本身具备的多维度搜索以及聚合能力，再加上母公司Elastic公司的良好运作以及ELK体系的普及，使得ElasticSearch在很多场景下都是NOSQL不二的选择。但是所谓人红是非多，再加上NOSQL数据库都有自己的优缺点和适用场景，没办法做到One Stack to Rule Them All，所以El

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

标准访问elasticsearch的方式kibana正常情况下，使用kibana访问elasticsearch是最佳的选择，界面化操作加上界面化的显示，能将elasticsearch管理的井井有条，所以有kibana的话直接选kibanacurl刚才说了正常情况，如果某些非正常情况，包含但不限于系统使用客户的共用集群，权限控制，在这些情况下，可能无法访问kibana，这个时候只能使用curl来进行

一）text字段和keyword字段的区别以下给出一个例子：首先建立一个索引和类型，引入一个keywork的字段：PUT my_index{"mappings": {"products": {"properties": {"name": {"type": "keyword"}}}}}然后查询是否有索引：GET _cluster/state可以看到已经创建