Elasticsearch是一个分布式、Restful的搜索及分析服务器，和Apache Solr一样，它也是基于Lucence的索引服务器，而Elasticsearch对比Solr的优点在于：

[]轻量级：安装启动方便，下载文件之后一条命令就可以启动；[/][]Schema free：可以向服务器提交任意结构的JSON对象，Solr中使用schema.xml指定了索引结构；[/][]多索引文件支持：使用不同的index参数就能创建另一个索引文件，Solr中需要另行配置；[/][]分布式：Solr Cloud的配置比较复杂。[/]

 

环境配置

启动Elasticsearch，访问端口在9200，通过浏览器可以查看到返回的JSON数据，Elasticsearch提交和返回的数据格式都是JSON.

>> bin/elasticsearch -f

 安装官方提供的Python API

>> pip install elasticsearch

索引操作

对于单条索引，可以调用create或index方法。

from datetime import datetimefrom elasticsearch import Elasticsearches = Elasticsearch() #create a localhost server connection, or Elasticsearch("ip")es.create(index="test-index", doc_type="test-type", id=1,    body={"any":"data", "timestamp": datetime.now()})

 Elasticsearch批量索引的命令是bulk，利用Python API提交

from datetime import datetimefrom elasticsearch import Elasticsearchfrom elasticsearch import helperses = Elasticsearch("10.18.13.3")j = 0count = int(df[0].count())actions = while (j < count):     action = {               "_index": "tickets-index",               "_type": "tickets",               "_id": j + 1,               "_source": {                           "crawaldate":df[0][j],                           "flight":df[1][j],                           "price":float(df[2][j]),                           "discount":float(df[3][j]),                           "date":df[4][j],                           "takeoff":df[5][j],                           "land":df[6][j],                           "source":df[7][j],                           "timestamp": datetime.now()}               }    actions.append(action)    j += 1    if (len(actions) == 500000):        helpers.bulk(es, actions)        del actions[0:len(actions)]if (len(actions) > 0):    helpers.bulk(es, actions)    del actions[0:len(actions)]

 实践过程中发现Python API序列化JSON时对数据类型支撑比较有限，原始数据使用的NumPy.Int32必须转换为int才能索引。此外，现在的bulk操作默认是每次提交500条数据，我修改为5000甚至50000进行测试，会有索引不成功的情况。

#helpers.py source codedef streaming_bulk(client, actions, chunk_size=500, raise_on_error=False,        expand_action_callback=expand_action, **kwargs):    actions = map(expand_action_callback, actions)    # if raise on error is set, we need to collect errors per chunk before raising them    errors =     while True:        chunk = islice(actions, chunk_size)        bulk_actions =         for action, data in chunk:            bulk_actions.append(action)            if data is not None:                bulk_actions.append(data)        if not bulk_actions:            returndef bulk(client, actions, stats_only=False, **kwargs):    success, failed = 0, 0    # list of errors to be collected is not stats_only    errors =     for ok, item in streaming_bulk(client, actions, **kwargs):        # go through request-reponse pairs and detect failures        if not ok:            if not stats_only:                errors.append(item)            failed += 1        else:            success += 1    return success, failed if stats_only else errors

 对于索引的批量删除和更新操作，对应的文档格式如下，更新文档中的doc节点是必须的。

{    '_op_type': 'delete',    '_index': 'index-name',    '_type': 'document',    '_id': 42,}{    '_op_type': 'update',    '_index': 'index-name',    '_type': 'document',    '_id': 42,    'doc': {'question': 'The life, universe and everything.'}}

常见错误

[]SerializationError：JSON数据序列化出错，通常是因为不支持某个节点值的数据类型[/][]RequestError：提交数据格式不正确[/][]ConflictError：索引ID冲突[/][]TransportError：连接无法建立[/]

 

性能 

上面是使用MongoDB和Elasticsearch存储相同数据的对比，虽然服务器和操作方式都不完全相同，但还是可以看出批量写入数据，单纯的数据库还是比索引服务器更具备优势。

Elasticsearch的索引文件是自动分块，达到千万级数据对写入速度也没有影响。但在达到磁盘空间上限时，Elasticsearch出现了文件合并错误，并且大量丢失数据（共丢了100多万条），停止客户端写入后，服务器也无法自动恢复，必须手动停止。在生产环境中这点比较致命，尤其是使用非Java客户端，似乎无法在客户端获取到服务端的Java异常，这使得程序员必须很小心地处理服务端的返回信息。

闲来无事，看看创业抄袭体

在中国做产品，有的人抄源码，有的人抄UI，有的人抄功能，现在竟然还有人连竞争对手的新闻稿都要抄袭！而这么没品的事情，竟然是一家号称要做中国的Oracle的公司干出来的，待我细说端详。

事情的起因是酱紫的，我在一家电子商务公司负责移动端，因为产品接了很多第三方API，如友盟的统计，微信的登陆，百度的定位，还有支付宝和银联的支付，所以一直在用监控宝API监控功能。前段时间监控宝对这个功能进行产品升级，所以特别关注了一下这块内容。

云智慧官方微信文章

恰好AWS宣布要正式进军国内，在看新闻的时候发现搜狐上有一篇关于API的文章《透过 AWS 峰会看未来 API 监控市场》（http://mt.sohu.com/20151218/n431798253.shtml ），顺手点进去，天啦撸，竟然跟前几天监控宝的微信文章一模一样，顺藤摸瓜，在这家叫OneAPM的公司官网上也找到了这篇文章（http://news.oneapm.com/aws-api/ ）。

OneAPM搜狐自媒体平台文章列表

OneAPM官网文章列表

下面就让我们看看这两篇几乎一样的文章

云智慧官方微信文章截图如下：

OneAPM官网文章截图如下：

监控宝文章开篇在讲API生态的发展历程和典型API方案架构，而OneAPM开篇先抱AWS大腿，随后开抄，因为监控宝的两张配图有明显水印，所以图片不见了，但文字就显得莫名其妙。

第二段讨论国内API监控发展的内容，继续全文照抄，只是把最后的云智慧监控宝替换成OneAPM。

后面两段关于监控宝“API监控原理”和“API监控新版介绍”的内容 ，因为涉及监控宝API可用性和响应时间策略，所以OneAPM进行了大篇幅的删减，只保留了一张还带着云智慧微信残缺水印的API通信原理图和少量文字，最后一段监控宝产品使用估计抄袭难度太大，所以也得以幸免。

既然连新闻稿都要抄袭，产品是不是也是抄的呢，本着生命不息，八卦不止的精神，上百度搜索“OneAPM 抄袭”，果然看到一个扒皮贴和一篇扒皮文章。先来看看V2EX上的扒皮帖子（链接：http://www.v2ex.com/t/125736）：

有人（目测是OneAPM的托）在V2EX发帖说OneAPM家的Python Agent好用，然后网友留言“其实就是 NewRelic 的汉化版嘛”，于是@dreampuf 、@vvvboy认真比较了OneAPM和NewRelic的Agent代码，竟然又是一模一样。

OneAPM的人先是拒不承认抄袭，被扒皮后又说产品开源的目的就是为了让人抄，实在是“见仁见智”。对了，他们还在媒体上说《Blueware何晓阳，不做中国的New Relic》（CSDN专访：http://www.csdn.net/article/2014-07-10/2820605-APM-Software-Service ）。

接着看到另一篇《OneAPM何晓阳的美丽人生》（http://news.3news.cn/html/news/cj/2015/0813/23053.html ），原来抄袭只是OneAPM的一项技能，他们还Get了好多Duang~Duang~Duang~的特技：吹牛逼、客户造假、数据造假、融资夸大。

看到这里，至少我是不敢把纯粹抄来的玩意往我家产品里接的，万一出了啥问题，你又搞不定，算谁的？！

结语

我是流氓我怕谁，创客时代，不少创业者，创业公司不择方法。抄袭已经很常见了，很值得思考。

风口上的猪，希望是一只正直、实在、努力的猪。不希望是懒惰、抄袭、拿来主义者。

Elasticsearch是一种先进的，高性能的，可扩展的开源搜索引擎，提供全文搜索和实时分析的结构化和非结构化数据。 它的特点是可以使用RESTful API over HTTP，因此很容易融入现代网络架构。 
 
由于NGINX具有出色的性能非常高并发率,再加上负载平衡的HTTP流量功能，这是非常适合用作为您扩展到多个Elasticsearch服务器的反向代理负载均衡。 
 

部署NGINX加上与Elasticsearch的优势

Elasticsearch有专为可扩展性的一些功能，但卸载请求开源NGINX产品或商业的负载均衡Nginx Plus产品，这更加具有企业级的功能，节省了资源Elasticsearch服务器上。
 
把NGINX或NGINX Plus加在一个Elasticsearch服务器的前端提供福利，如请求 日志记录，但真正的价值是当你扩展到多个Elasticsearch服务器。

这种架构除了记录每个API请求，NGINX加NGINX Plus还有如下优势：

[]支持大量的客户端连接，不管有没有启用keepalives，比长连接（使用keepalives）到elasticsearch服务器小的多[/][]负载均衡的请求Elasticsearch服务器[/][]缓存数据，减少同一内容再次请求Elasticsearch服务器。NGINX Plus 还提供HTTP API 对缓存数据的清除接口[/][]提供主动健康检测（仅nginx plus），不断检测后端Elasticsearch服务器是否正常，并主动的进行切换。[/][]报告丰富的监控指标（仅nginx plus），提供监控和管理。[/][]支持通过HTTP API动态的配置上游服务器组（仅nginx plus），可以从上游服务器组中添加和删除，上线或下线，改变权重。[/]

下表比较Elasticsearch 、Elasticsearch + nginx F/OSS、Elasticsearch + NGINX Plus 的功能：


当使用NGINX Plus高可用性主动或被动配置负载均衡的Elasticsearch 服务器集群时，Elasticsearch 客户端通过nginx plus请求，而不是直接连接到Elasticsearch服务器，这意味着，根据需要，而无需更新客户端，你可以任意的扩展Elasticsearch服务器。

部署NGINX Plus + Elasticsearch

部署NGINX Plus与Elasticsearch是非常简单的。在下面的示例NGINX Plus配置的指令定义负载均衡两台Elasticsearch服务器设置：

[]upstream - 负载均衡请求的是两台Elasticsearch服务器，地址分别是192.168.187.132和192.168.187.133的9200端口。[/][]proxy_cache_valid – 有效缓存有效时间10分钟[/][]health_check - 主动的健康监测、状态收集，把他们从负载平衡轮训的时候，把它们放下来，然后再将它们重新加入到轮训中中，再恢复健康。健康检查资料的匹配块，这不仅可以确保服务器返回200状态码，但检查的响应是JSON，它返回字符串预期Elasticsearch格式化，”状态“：200”。[/][]Final server block - 收集统计并监听8080端口的请求为status.html页面显示统计，或状态，它告诉nginx plus返回JSON格式的原始数据。[/]

 

proxy_cache_path /var/cache/nginx/cache keys_zone=elasticsearch:10m inactive=60m;

upstream elasticsearch_servers {

    zone elasticsearch_servers 64K;

    server 192.168.187.132:9200;

    server 192.168.187.133:9200;

}

match statusok {

    status 200;

    header Content-Type ~ "application/json";

    body ~ '"status" : 200';

}

server {

    listen 9200;

    status_zone elasticsearch;

    location / {

        proxy_pass http://elasticsearch_servers;

        proxy_http_version 1.1;

        proxy_set_header Connection "";

        proxy_cache elasticsearch;

        proxy_cache_valid 200 302 10m;

        proxy_cache_valid 404 1m;

        proxy_connect_timeout 5s;

        proxy_read_timeout 10s;

        health_check interval=5s fails=1 passes=1 uri=/ match=statusok;

    }

    # redirect server error pages to the static page /50x.html

    error_page 500 502 503 504 /50x.html;

    location = /50x.html {

        root /usr/share/nginx/html;

    }

    access_log logs/es_access.log combined;

}

server {

    listen 8080;

    root /usr/share/nginx/html;

    location / {

        index status.html;

    }

    location =/status {

        status;

    }

}

总结

Elasticsearch是一个强大而灵活的搜索引擎，和NGINX Plus一个企业级的应用交付平台自然契合在一起，作为一个现代化的可扩展的网络架构的组件。 作为软件产品，他们提供的只要你安装这些相同的特性和功能：在裸机服务器，在虚拟机中，在云中，或在容器中。

进一步阅读

Playing HTTP Tricks with Nginx
Securing Elasticsearch with Nginx
分享英文原文：https://www.nginx.com/blog/nginx-elasticsearch-better-together/

自定义一下nginx的访问日志格式，可以方便工作中的对日志的分析。主要要使用到几个指令，分别是log_format和access_log、error_log
 
Example：

#WebLog

log_format weblog	'$remote_addr - $remote_user [$time_local] "$request" '

			'$status $body_bytes_sent "$http_referer" '

			'"$http_user_agent" $http_x_forwarded_for';

 

access_log  /data/logs/domain_access.log  access;

error_log  /data/logs/domain_error.log error;

log_format指令：

-------------------------------------

语法	log_format name string ...

-------------------------------------

默认值	combined "..."

-------------------------------------

使用字段	http

-------------------------------------

参数说明：

[]$remote_addr 和 $http_x_forwarded_for：记录客户端的ip地址。[/][]$remote_user：记录客户端用户名称。[/][]$time_local：记录访问时间与时区。[/][]$request：记录请求的URL与HTTP协议。[/][]$status：记录请求状态；成功是200。[/][]$body_bytes_sent：记录发送给客户端文件主体内容大小。[/][]$http_referer：记录从那个页面链接访问过来的。[/][]$http_user_agent：记录客户端浏览器的相关信息。[/]

access_log指令：

--------------------------------------------------------

语法	access_log path [ format [ buffer = size ]]

        access_log off

--------------------------------------------------------

默认值	logs/access.log combined

--------------------------------------------------------

使用字段	http

            server

            location

            if in location

            limit_except

---------------------------------------------------------

记录的日志格式如下：

66.249.73.68 - - [17/Dec/2015:17:03:52 +0800] "GET /2011/11/1659.html HTTP/1.1" 200 9028 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

115.28.133.87 - - [17/Dec/2012:17:03:53 +0800] "GET /2012/03/8907.html HTTP/1.1" 200 8044 "http://www.baidu.com/s?wd=web%20equation&ie=utf-8" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)"

115.28.133.87 - - [17/Dec/2012:17:03:54 +0800] "GET /favicon.ico HTTP/1.1" 200 1150 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; 360SE)"

正如世界上的语言有多种多样，编程语言同样如此，有些更受欢迎，有些简单易用。随着编 程语言的种类越来越多，它们之间的竞争也日益激烈。而且往往简单的、运行速度快的编程语言并非就是最好的选择，因为不同的程序员对编程语言的选择很有讲究，而且能讲出一大堆道理来解释为什么喜欢某种编程语言 ，不过他们的给出的理由一般都带有太多个人的经历和情感因素。

下面的图表站在客观的立 场，从各个角度对PHP、Ruby、Python三种当前比较流行的语言的优势和劣势进行了对比：Ruby编写的代码精确、强大、表达性好，可用性最高；Python语法简单，最适合初学者学习，也是讨论最为热门的语言；PHP在三者中的流行程度最高；代码效率方面，代码行数PHP表现最好，运行时间上Python最短......,就如下图所示：

更过精彩分析，可以到Youtube观看视频：https://www.youtube.com/watch?v=VBm5m1-Eonw​ 

自动化不单单在IT互联网上已经开始普及，我们的生活，家居，衣食住行都会慢慢智能、自动化起来，这只是一个开始。
 
在智能自动化的趋势下，值得我们思考，我们应该提升自己的能力，要不你就会面临下岗的可能，如果你的水平达不到，我没有理由要你了。当今互联网，工资就是一个大泡沫。刚没有工作几年的人，培训学了点本事，张口就要1w+,当然这也不是求职者的错，是互联网的市场造成的。现在一大批一大批的创业公司，天天都有公司死，有公司起。这么多公司，都需要招人来干活，为了做出个产品，要不连吹牛拿投资的资本都没有。这是很明显的自动化和非智能不达标很的很好的体现。如果当今互联网智能化水平达到了，也就不会导致IT从业人才的工资泡沫。
 
好好享受当下吧，以后可能失业的就是你，智能、自动化社会，值得你思考！