这几天一直在学习elasticsearch，很多地方不是太明白，于是去官方网站上查看说明文档，发现真的很不方便查看，一是由于文档布局排版不好，查看不同的API还得必须跳到不同页面上，最重要一点是需要翻墙才能看文档，很是烦恼，今天忽然在一个网站上发现了一个把elasticsearch官方2.3.3的java elasticsearch 文档翻译了，而且我看了一下，还是不错的，于是分享给大家，果断收藏啊：
Elasticsearch 2.3.3 JAVA api说明文档

 最近 MongoDB 的安全事件闹得沸沸扬扬，应该不少人都听说了吧，事情大概是，因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据，想了解的，这里有几个链接：
http://www.jianshu.com/p/48d17a69e190
http://mt.sohu.com/20170107/n478047698.shtml​ 
http://bbs.tianya.cn/post-itinfo-503786-1.shtml​ 
 
安全从来不是等到出事才要注意的事情，可以说安全是第一重要的事情，不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师，都应该有安全意识，好了，废话不多说了，Elasticsearch 的用户现在越来越多了，有些已经成为公司的基础服务，所以数据的安全非常重要，今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项：
 
下载安装
 
     请使用正规渠道下载 Elasticsearch，首选官方网站，下载完成，记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比，避免下载过程中被人拦截破坏文件，甚至注入恶意代码。
不要随便安装第三方的插件，插件有可能引入安全漏洞甚至本身自带后门，需谨慎使用。
    链接君：https://www.elastic.co/downloads 
 
 
使用最新的 Elasticsearch
 
    请关注 Elastic 网站，及时更新升级 Elasticsearch 的最新版本，Elasticsearch 每次版本发布都会优化和改进一部分功能，尤其是安全漏洞的补丁，仔细阅读 Elasticsearch 的更新记录，Elasticsearch 的版本遵照 语义化版本 ，所以小版本间应该是能够无缝升级的，建议及时本地测试和线上更新，升级前，记得 snapshot 做好备份。
    链接君：https://www.elastic.co/downloads
 
 
修改默认的 Elasticsearch 集群名称
 
     Elasticsearch 默认的集群名称是 elasticsearch，请在生成环境上一定要修改成其他的名称，并且不同的环境和不同的集群要保证不相同，监控集群节点情况，如果有未知节点加入，一定要及时预警。
    文档君：https://www.elastic.co/guide/e ... .name
 
 不要暴露 Elasticsearch 在公网上
 
      Elasticsearch 默认端口是9200，绑定的是本机127.0.0.1的这个 ip，这个默认参数其实很安全，但是有很多人想要绑定其他的 lan 口或者公网的 ip，可以修改相应参数，记住，修改有风险，如果确实需要将 Elasticsearch 暴露在公网环境，请修改特定的端口绑定IP，不要直接修改参数： network.host，而是要分别修改：http.port 来绑定 HTTP 协议9200 端口的 IP（RESTful 接口调用），修改：transport.tcp.port 对应的 TCP 9300 端口的 IP（集群内通信），如果你不需要 http 端口，你干脆禁用掉，另外还需要在 Elasticsearch 之上加上成熟的安全防护措施（注意是成熟的！），在这里提供几种方案：

1. 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证，辅助 SSL 证书进行传输层的加密，Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
2. 使用 Elastic 的 X-Pack 插件，同样提供了 Http Basic-Auth 和 SSL 传输层的加密，X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密，避免旁路攻击。

 
     文档君：https://www.elastic.co/guide/e ... tings 
 
禁用批量删除索引
 
Elasticsearch 支持通过_all（全部）和通配符（*）来批量删除索引，在生产环境，这个有点危险，你可以通过设置： action.destructive_requires_name: true 来禁用它。

安全使用动态脚本

     Elasticsearch 的脚本很方便的可以对数据进行操作，不过如果你暂时没有用上，还请禁用它（Elasticsearch 在1.2.x 以后已经默认禁用了），如果你已经在使用动态脚本，比如 Groovy，它不是沙盒机制的脚本引擎，启用 inline 或 store 类型的groovy 有安全风险，请限制脚本的接触方，比如通过模板的方式来限制脚本的调用，只需要执行特定预先定义好的脚本，对调用参数进行过滤和参数值的检测，做好验证，同时各种日志都必须要保留好，方便进行日志分析，异常的调用和请求一定要有发现和预警机制。
      Elasticsearch 默认启用了  Java Security Manager ，但还请正确配置其白名单。
      使用 Groovy 或者JavaScript 等脚本的用户，尽快迁移到 Painless 脚本，Painless 更快更安全。
      文档君：https://www.elastic.co/guide/e ... .html
 
给 Elasticsearch 服务器加固
 
     服务器加固是一个必备流程，不管上面运行的是什么服务；
     首先，请开启防火墙，请设置防火墙规则，只开启必备的端口，完成之后，使用扫描工具扫描服务器，检查端口开发情况；
     如果可能，不要用密码的方法来远程登录服务器，使用公私钥的方式来 ssh 登录服务器，如果只能使用密码，请妥善保管好你的用户名和密码，禁用 root 用户，不用使用弱密码。
     关注 Java 最新的漏洞，使用安全的 JVM 运行时。
     服务器及时更新最新的软件，使用安全的 repo 软件源，绑定软件源的 host和 ip，避免 dns 污染造成的攻击，关注服务器软件漏洞，及时打上补丁。
     收集系统日志和安装相应的入侵检测软件，及时发现服务器是否有异常行为。
 
不要以 root 身份运行 Elasticsearch

    如果你的运维人员打算以 root 身份来运行某个服务，这个运维人员一定是一个不合格的运维人员，记住一定不要以 root 身份来运行 Elasticsearch，另外，要不和其他的服务公用相同的用户，然后还要保证该用户的权限要最小化。
     范例君：

sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m"  /opt/elasticsearch/bin/elasticsearc

 
正确设置 Elasticsearch 的数据目录
 
     请确保 Elasticsearch 的目录分配了合理的读写权限，避免使用共享文件系统，确保只有 elasticsearch 的启动用户才能访问，同理，日志目录也一样需要正确配置，避免泄露敏感信息。
     文档君：https://www.elastic.co/guide/e ... tings
 
定期对 Elasticsearch 进行备份
 
     使用 Elasticsearch 提供的备份还原机制，定期对 Elasticsearch 的数据进行快照备份，以备不时之需。
     文档君：https://www.elastic.co/guide/e ... .html
 
加上监控和预警
 
     Elasticsearch 提供了很好的默认参数，对参数方面还做了正确性检测，bootstrap 启动检查，不准确的参数，直接不允许 Elasticsearch 启动，以至于有很多人抱怨，怎么现在部署到线上默认就需要做这么多设置才能使用呢，是的，以前启动就默认绑定了所有的网卡，集群见自动发现和相连，现在需要手动绑定局域网网卡，默认只是绑定的本机127.0.0.1的 ip，对上线来说麻烦了一点，做了这些检查也就是为了保证数据安全，以前很多的公网都能直接访问的 Elasticsearch 实例，都是因为默认设置就绑定了公网 ip，但是这些还不够，作为用户，你还需要收集各种日志和系统监控信息，及时主动掌握服务健康和资源使用情况，发现异常情况要及时处理，这里提供一些方案:

1. 使用开源的 Elastic Stack 收集这些日志，可以使用 Filebeat 收集日志，Metricbeat收集系统监控信息，存进 Elasticsearch，一旦发现异常的波动，使用 Watcher 来进行预警，通过邮件或者 webhook 调用短信、微信或者电话。
2. 使用其他厂商的安全监控产品。
3. 使用托管的 Elasticsearch 云的产品，如 Elastic Cloud等等。

是的，把安全这个事情考虑进去之后，很多事情都要比没考虑要变得更加复杂和麻烦，千里之堤毁于蚁穴，一个不起眼的忽视就有可能造成全部数据的丢失和泄露，出来混迟早是要还的，安全问题千万不能忽视。
 
以上几点建议举例针对 linux 平台，其他平台思路基本上一样，仅供参考，安全是一个包含很多方方面面的学科，抛砖引玉，希望大家有用。 

最后，Elastic 非常关心我们的产品安全，如果您发现有任何安全方面的问题，还请在这里上报：
https://www.elastic.co/community/security
企业用户需要 X-Pack 及 Elastic 官方技术支持，请访问下面的链接：
https://www.elastic.co/cn/contact

elasticsearch 2.x mapping tips

作者：杨振涛  首发于：Elasticsearch 中文社区  日期：2017-1-10

如果把elasticsearch中的mapping类比为关系型数据库中的schema的话，那么我们可能重点强调了两者之间的共性，而忽略了elasticsearch里mapping很不相同的部分 —— 这恰恰是实践中最容易被坑的地方。这里总结了几点实践中的小心得，希望对你所有帮助。

mapping 基础
创建索引库index

curl -XPOST "http://192.168.9.19:9200/vivo_vimc"

查看指定索引库的mapping:

curl -XGET "http://192.168.9.19:9200/vivo_ ... ot%3B
 

PS: 这时你获得的结果为空，因为刚建的库，没有mapping信息。

创建索引类型type并指定mapping :

curl -XPOST http://192.168.9.19:9200/vivo_vmic/apps/_mapping -d '{

  "apps" : {

    "properties" : {

      "appName" : {

        "type" : "string",

        "index" : "not_analyzed",

        "fields" :{

         "cn": {

           "type"  : "string",

           "index" : "analyzed",

           "analyzer": "ik"

          },

          "en": {

           "type"  : "string",

          }

        },

        "store":"yes"

      },

      "status" : {

        "type" : "boolean"

      },

      "type" : {

        "type" : "integer"

      },

      "onsaleDate" : {

        "type" : "date"

      },

    }

  }

}'

更新mapping （只能增加字段，不能删除字段，也不能修改字段类型，或者说无法增加一个不同类型的同名字段）:

增加属性 score：

curl -XPOST "http://192.168.9.19:9200/vivo_ ... ot%3B -d '{

    "apps": {

        "properties": {

            "score":{

                "type":"float"

                }

        }

    }

}'

   
更新成功会返回：

{

  "acknowledged" : true

}

删除mapping :
2.4版本开始ES已经不支持mapping的删除了。

tip1 dynamic 模式

动态mapping是ES的一个重要特性，这个配置的可选值及含义如下：

• true  ：支持动态扩展，新增数据有新的属性时，自动添加，索引成功
• false ：不支持动态扩展，新增数据有新的属性时，直接忽略，索引成功
• strict: 不支持动态扩展，新增数据有新的属性时，会报错，索引失败

tip2 主要数据类型及注意事项

• string

    分词和不分词的值都需要，中英文都需要 ，
    长度截取，超长过滤 ，
    大小写问题（不分词时索引数据不会转小写，搜索都会转小写）    
    analyzer: analyzed, not_analyzed, no（表示该属性不能用来做搜索和聚合）
    properties ： .raw, .en/.cn
    

• date :           如果不明确指定，那么默认的date格式是："strict_date_optional_time||epoch_millis"，这是官网的表述，意思是可以是一个字符串类型的输入，也可以是数值类型的输入，前者可以是日期或者日期加上时间，后者则是毫秒数。关于时区信息：不管业务上是否需要时区信息，我们建议依然保存，以防万一。另外，data类型在明确指定 format 参数时，也有很多坑，对于format: epoch_second, epools_millis ,如果你想用来排序，那么为了性能，我们强烈建议你使用 epoc_second，差距很大哟，你可以亲自做一个对比测试。

 

•  long, integer, short, byte, double ,float 希望此类字段参与搜索和聚合的话，就不能设置not_analyzed。

 

• boolean, binaryboolean类型比较特殊，在ES里面只定义了false类的值（ false, "false", "off", "no", "0", "" , 0, 0.0 ），其他所有都认为是true。实践中，我们建议优先使用 0（编程和性能友好），其次使用 true（兼容json默认的类型）。

 

•  ipv4 type:ip 日志分析等最常用的数据类型，注意这里的是ipv4，ipv6目前暂不支持（ES 2.x）；赋值时其实传递的是字符串，但ES内部其实保存的是一个long类型。

 

• geo type:geo_point ， type:geo_shape  LBS服务的必选数据类型，但不建议完全依赖此特性，业务层面要尽可能地缩小范围，或者在使用围栏类功能时，只要业务容忍，使用正方形代替圆形。

 

• 数组，对象，内嵌将一个复杂对象放在一个属性中，其中数组最常用。

 

• completion主要是用来做自动完成和拼写纠错的。

tip3 id设置  

在不设置id的情况下，默认的ES会给一个类似HASH串的随机ID；如果业务上需要且可以保证索引数据的唯一性，也可以使用业务ID作为索引ID，好处就是可以根据业务ID轻松地GET到索引数据，而无需维护索引ID和业务ID的关系。

同时，设置mapping的时候也可以指定ID的生成策略，比如UUID：

curl -s -XPUT http://192.168.9.19:9200/vivo_vimc -d '

{

    "mappings": {

        "apps": {

            "_id": {

                "path": "uuid"

            },

            "properties": {

                "cnName": {

                    "type":   "string",

                    "index":  "analyzed"

                }

            }

        }

    }

}'

tip4 index和type规划

index的别名这个特性就不再强调了，不管是否用到，第一时间设置别名是最佳实践！ schema 比较相似的type，放在同一个index里；schema差异非常大的type，建议放在不同的index里；原因是跟搜索引擎的segment以及lucene有关，本质上同一个index里的type底层是同样的存储结构，差异越大意味着type a的属性在type b里大部分都是空值，那么最终会得到一个非常稀疏的矩阵，影响计算效率并浪费存储空间。

关于滚动index的问题，对于日志类的搜索应用，按天或其他维度做滚动index是非常好必要的，这样可以更好地区分冷热数据。比如：

index                        alias
vivo_appstore_log_20160108  
vivo_appstore_log_20160109  vivo_appstore_log
vivo_appstore_log_20160110  vivo_appstore_log
vivo_appstore_log_20160111  vivo_appstore_log
...

如果只需要查询最近3天的数据，那么只需要对3天前的index remove alias即可，然后每天循环滚动。一个细节是，对于这种场景下的索引，写入的时候必须使用原始的index name，而不能使用alias；查询的时候则使用alias。


另一个问题，就是index容量的规划，副本数直接决定需要多少冗余空间；另外，索引数据本身也会有膨胀的现象，尤其是基于中文的全文搜索应用，term集可能会比较大。比如有10000个docs，占用100MB空间时，并不能简单认为100000个docs就占用约1GB。


tip5 测试分词器

如果使用的是基于词典的分词器，比如IK这类，那么线上系统可能会需要按需添加自定义词，或者同义词等，技术上我们可以暴露该类功能给搜索引擎运营人员使用。所以，需要提供一个测试分词器的接口，方便对比和验证。ES默认就提供这样的REST接口的。

按指定分词器分词指定文本：

GET /vivo_vimc/apps/_analyze?text=Hello, vivo 移动互联网&analyzer=ik

按指定索引库的属性测试分词效果：

GET /vivo_vimc/apps/_analyze

{

  "field": "appName",

  "text": "Pokemon Go"

}

以上关于 mapping 的几点心得，并非金科玉律，需要根据不同的业务需求场景来区别分析和应对。如果你有更多心得，欢迎回复本文分享。


关于作者：
杨振涛，vivo移动互联网 搜索架构师，关注实时搜索，搜索广告，以及大数据的存储、索引、搜索和可视化。