Jeffrey Zhou 的专栏

当收到一个建立索引请求时，ElasticSearch首先要做的事就是决定在哪一个shard上对其进行索引。ElasticSearch使用djb2哈希算法对指定或者默认的key进行哈希，然后mod索引中shard数量 n       hash(key)mod n hash(key)modn djb2并不复杂, 但是这样的哈希算法有啥好处呢？？？？？？    unsigned

默认的Elasticsearch Azure插件只支持向一个Azure存储账号(storage account)写入/读出集群快照(snapshot)数据。这个限制对于大型Elasticsearch集群（例如：数据量很大TB， 数据节点>30）而言，会导致过载单一的storage account以至于snapshot失败或者PARTIAL失败。通过扩展Elasticsearch Azure Plugin，可以让它支持多个读/写snapshot到多个storage account，这样就避免到了过载一个sto

在项目中使用ElasticSearch作为后台服务端的搜索引擎已经快一年，从年初的1.1.1版本到1.2.2，再到最新的1.4.1，Elasticsearch是在一步步的快速迭代进步，而跟随它的进步，我们对它也是有了更进一步的了解。坦白地讲，开源软件使用的启动成本计较，但要真正能使它很好地用于产品环境中，学习和运维经验的积累成本还是相当高的，一路的坎坎坷坷一年来经历了不老少。特别是如何能够在Mic

Elasticsearch有很多附带的和第三方的插件用于扩展其功能，其中elasticsearch-cloud-azure插件提供了在Azure storage上的进行索引备份的功能，它是将Elasticsearch用于生产环境必不可少的利器。但Azure Blob细分为三种：Page，Block和Append，每种类型有着各自不同的适用场景。那么究竟elasticsearch-cloud-a

最近在一个集群上发现snapshot restore功能失灵，GET ~/_snapshot一直返回如下的内容：{  "auto-restore-repo" : {    "type" : "azure",    "settings" : {      "container" : "snapshot-0401-72d8",      "location_mode" :

Elastic官方今天这是发布了Elasticsearch 2.0版本，Release, we have。较之前的1.X版本改进还是蛮大的，更重视数据完整性和可靠性。同时Mavel也免费了(管理第一个集群)，Sense也开源了！

Elasticsearch是建立在Apache Lucene 基础上的实时分布式搜索引擎，Lucene为了提高搜索的实时性，采用不可再修改（immutable）方式存储一个个segment。也就是说，segment文件在写入到存储系统之后，将不可以再修改。那么Lucene是如何从一个segment中删除一个被索引的文档呢？简单的讲，当用户发出命令删除一个被索引的文档#ABC时，该文档并不会被马

为了克服 Arrays of Inner Objects 扁平化内部对象丢失对象内部数据之间的关联信息的不足，Elasticsearch提供了Nested object。Nested object把每个内部对象做为一个独立的隐藏文件存储，从而保存了对象之间的独立性。当然，鱼和熊掌也可皆得 。如果你既需要nested object同时也要扁平的object，在mapping中加入 include_in_parent即可。

Quora上一个关于Elasticsearch和Hadoop关系的讨论，内容比较丰富和全面，值得学习Elasticsearch和Hadoop处理大数据的同学一看，Why do people use Hadoop or Spark when there is ElasticSearch?

最近将Elasticsearch由1.2.2升级到1.4.4后，sense工具无法使用了，它发到Elasticsearch集群的请求没有任何的响应。阅读了Elasticsearch的文档才了解到，这是1.4.X版本新增加的设置，参看Configuration Options。简单的讲，需要在.yml配置文件中添加如下的配置， 这样才能启动 Cross-origin resource shari

Elasticsearch是构建在Java之上的、开源的、分布式搜索和分析引擎，因此JVM的性能对Elasticsearch性能至关重要。在负载超出节点所能承受的情况下，JVM垃圾内存回收的“Stop-The-World”会造成节点被踢出Elasticsearch集群。如果只是偶尔发生，Elasticsearch的冗余设计可以克服。如果是经常出现节点被踢出的情况，则会对整个集群的稳定造成影响。

一般情况下，Elasticsearch会自动将shard分配到各个数据节点上，但有些特殊的情况下，也会有shard未被分配的情况，整个集群处于Yellow状态。在你有足够的replica shard备份的情况下， yellow并不影响整个集群的性能，特别是很多时候会自动回复，不需要任何人工干预，比如：某个数据节点被自动重新启动。       也有些情况下，shard会长期处于未分配状态， 这就

参考资源1. Lucene Scoring and elasticsearch’s _all Field

_analyze, _explain和_search_shards是Elasticsearch提供的3个辅助API，经常不为人所知和所用。_explain用来帮助你分析指定文档的score是如何计算出来的；_search_shards则是用来分析某个搜索请求将会访问到哪些节点以及shard，这在性能调优的时候还是很有用的；而_analyze是Elasticsearch一个非常有用的API，它可以帮助你分析每一个field或者某个analyzer/tokenizer是如何分析和索引一段文字的。