ElasticSearch 初次使用小结，一起学习进步哈~ · Ruby China
本帖已被设为精华帖！
主要原因有：实时性能优越；安装配置简单；RESTful API 和 JSON 格式的文档型数据，降低开发调试的难度。
另外，Tire 这个 Gem 可以简单方便的与 ActiveRecord 整合。
测试中发现：ES 自带了中文分词，支持中文搜索，但是，可以换用更高效精确的分词插件。
业界资讯：GitHub searches 20TB of data using Elasticsearch, including 1.3 billion files and 130 billion lines of code.
ElasticSearch 是开源搜索平台领域的一个新成员。
ElasticSearch（简称 ES） 是一个基于 Lucene 构建的开源，分布式，RESTful 搜索引擎。
设计用于云计算中，能够达到搜索实时、稳定、可靠和快速，并且安装使用方便。
支持通过 HTTP 请求，使用 JSON 进行数据索引。
（1）Open Source（开源）
（2）Apache Lucene（基于 Lucene）
（3）Schema Free(模式自由)
（4）Document Oriented(面向文档型的设计)
（5）Real Time Data & Analytics（实时索引数据）
（6）Distributed（分布式）
（7）High Availability（高可靠性）
（8）其他特性：RESTful API；JSON format；multi-tenancy；full text search；conflict management；per-operation persistence
在 Mac OS X 上安装配置步骤（linux 上应该也适用），请参考:
Tire Github 地址：
Tire 是一个丰富的 Ruby API 工具包，封装了一系列与 ES 进行接口请求，JSON 数据处理的功能。
而且，针对 ActiveRecord 写了很多处理索引，搜索的实现，非常简单方便的与 Model 进行集成。
英文原话介绍：Tire is a rich Ruby API and DSL for the Elasticsearch search engine.
It exposes easy-to-use domain specific language for fluent communication with Elasticsearch.
It easily blends with your ActiveModel/ActiveRecord classes for convenient usage in Rails applications.
贴出一部分代码，实现了基本的搜索，地理位置排序，实时更新索引。命名为学校（School）只是为了用来交流，实际应用在商户模型上。
接下来，仍然需要研究 ES 的架构和实现原理；
配置测试更高效的中文分词插件：ik，mmseg，smartcn等；
同样还有部分酷的功能没有使用，如：facet等。
class School & ActiveRecord::Base
include Tire::Model::Search
attr_accessor :location
attr_accessible :name, :address, :latitude, :longitude
state_machine :status, initial: :active do
state :active
state :deleted
event :set_active do
transition all =& :active
event :set_deleted do
transition all =& :deleted
after_save do
if self.active?
tire.update_index
self.index.remove self
def self.search(params)
longitude = params[:lng].to_f
latitude = params[:lat].to_f
params[:page] ||= 1
params[:per_page] ||= 20
tire.search(page: params[:page], per_page: params[:per_page], load: true) do
boolean do
must { string params[:keyword], default_operator: "AND" } if params[:keyword].present?
if latitude != 0 && longitude != 0
by :_geo_distance, { location: [longitude, latitude], order: "asc", unit: 'km' }
def location
{ longitude: longitude.to_f, latitude: latitude.to_f }
self.include_root_in_json = false
def to_indexed_json
name: name,
address: address,
location: location
mapping do
indexes :id, :type =& 'integer', :index =& 'not_analyzed'
indexes :name, :boost =&
100, analyzer: "snowball"
indexes :address, :boost
=& 5, analyzer: "snowball"
indexes :location, :type
=& 'geo_point'
博客上有进一步的讲解：
Github 源代码
Fog Creek Software 如何使用 Elasticsearch 使Kiln的搜索速度提升了1000倍（非常值得借鉴）：
Realtime Search: Solr vs Elasticsearch（图形并茂，很有说服力）：
ElasticSearch 不仅用于全文搜索, 还有非常强大的统计功能 (facets) , 现在系统中的需要实时处理的统计功能从 MySQL 转接到 ElasticSearch , 准确性一致, 速度从原来 1900ms -& 50-ms
非常感谢分享，我们项目里目前商户数据，只有上海的5千条，还没有第一手的性能对比数据。
但是，坚信选用 ElasticSearch 不后悔，哈哈~
我是在 70+w 的订单销量数据中进行的计算.
反正很靠谱就是.
:thumbsup: 吃午饭去咯~以后多交流~
如果是Mac安装的话，直接用Homebrew就好
有一个, ready to fly, 配置好了常用的中文相关的插件，
我发现因为这家伙很快, 我测试都是直接链接到真实服务器, 额外创建一个测试专用的 type 索引, 没有安装本地 - -||
3Q~:thumbsup:。看到了，值得参考，还是想自己安装配置，加深一下理解~
用过，Tire 的 DSL 比较反人类，ElasticSearch 的文档页面设计让人眼瞎
后面换回 Solr 了
请教一下，如果10亿document的量级性能如何？
确实花了不少时间，看 Tire 和 ElasticSearch 的文档（亟待整理完善），包括二者的 Github 源代码。感觉有必要总结一下，让其他人，少走弯路~~用还是不用 Solr，纠结好久，先用 ES 跑跑吧~
Tire 已经 retire 了，作者也去了 ElasticSearch ，并开发了官方的 Ruby Client （较为底层，基于官方 Client 的 AR 适配器应该很快就有了）
朋友如果有这样的大数据，方便跑一下 ES，做一下性能测试吗？
可以看一下这篇文章： 用 ES 去索引维基百科的数据
此外这本 Exploring ElasticSearch 还有一些 Review，例如与 GitHub 负责搜索的工程师聊天：
专业，非常感谢！
现在没有，只有几千万的数据而已。
70+w 的数据索引一次需要多久?
默认支持中文吗？记得上次用的时候不支持，我当时用的9.0.0，现在是9.0.6，可能是哪儿没搞对。
Solr vs Elasticsearch那篇文章真不错~ 多谢楼主分享
索引了 2 个 70+w 的数据, 通过 EM + bulk api 写的索引脚本, 跑到 20~40% CPU(4core)
8~10 分钟.
主要是他的目录太不好看, 一级一级看了好久才弄明白目录是怎么回事, 最后弄个了 xmind 图才折腾清楚.
我现在都是写好一个 Hash 然后直接 http 去抓了没用库
我还在百万级别, 正在准备下一个 300~800w 级别索引 type , 上亿的还没啥经验哈
给的连接比较靠谱.
如果权限做控制，谁有经验分享一下。
估计用nginx或者是apache来做反向代理吧
数据间的关联性大吗? 这个速度还是比较理想的.
我是说数据里的权限，例如不通用户组产生的文档不能被相互搜索出来。
哪篇？能给个链接吗？
good, 感觉像一个nosql。
这应该是你服务器的逻辑控制的把
没有传统 DB 的关联查询啥的, 就是一堆文档在一个 type 下, 一堆 type 在一个 index 下, 然后根据 index/type + query dsl 去查, 所以现在我要查询不同的 model 的数据才有了两个 70+w 的 type
这个我觉得你给 document 添加个 field 用来标示权限, 搜索的时候根据权限过滤出特定的 term 也可以呀.
ElasticSearch 本身没有提供数据的权限控制吧.
关于 document 上的 field 和 term , 把 jd.com 搜索产品的时候那么多得条件想象成一个一个的 term 值比较像
好像这样也只能解决部分需求。一些比较复杂的情况是用户离开了某个组，那么这个组的文档不能被他再搜索了，组虽然可以过滤这些文档是否可以搜索，但如果太多组的话，构造的搜索条件会非常庞大，我猜为了比较这些条件会降低性能。
elasticsearch-jetty 这个插件ms可以提供权限控制， 未用过，纯搜索得知。
不过用这个搜索引擎大部分还是放着可以公开的数据吧。
es早些时间用的时候还不很成熟，配分词等的时候有些小问题要自己折腾点时间。
model里面设置搜索的代码多了臃肿，可以都提出来另外放再include进来。
官网插件里面的监控用起来不错
es这个东西，换个角度可以直接用来当数据存储（类似mongo），只是时间有限没有去深入看有什么适用的地方或者受限的地方。
索引的 document 设计
因为 ES 索引的文档 db 存储的东西是没有关系的, 所以我们可以随意将不同 model 中的数据组合成合适搜索的 document , 像这个组非常多得情景的话. 可以把 document 设置为拥有 "组 field" 和 "内容 field" 这是索引用的的元数据, 如果还有其他搜索的需求, 可以针对性的为 document 添加 field, 例如查找的 model 的 id
搜索条件的编写
ES 的 Query DSL 真的是太灵活了, 所以搜索的时候可以有很多方式. 因为组信息在用户身上, 这样在生成查询的时候, 是实时变化的, 比如原本其加入了 101 个组, 突然退出一个组, 剩下了 100 个组, 那么生成 ES 查询语法算法不用便, 值变而已
指定 "组 field" 然后 "组1 组2 ... 组100" 这样搜索
指定 "组 field": [组1, 组2, 组3, ... 组100]
这个貌似比较直观
将所有组添加到 should 中.
除了正向的 query 还有反向的 filter
所以, 当需要索引的文档确定好后, 查询语法相比在数据库中搜索, 灵活太多太多. 右侧目录,
这个我猜测是 ES 多 shards 存储数据而弄出来的, 默认情况搜索时 size=10, 这是返回 10 个 document, 当改变一下搜索类型仍然是 size=10 , ES 可以返回 shards 数量 * size 个结果 (默认 5 个 shards, 返回 50 个结果), 这个特性存在我觉得比较奇葩~
因为有一次被 ES 坑在这里特别记得 - -||
这个我就不好打包票了, 复杂搜索语法对于整个搜索所增加的时间是多少得到真实环境下测试下了. 这里我想到的比较重要的需要参考的因素有, 索引的文件的数量, elasticsearch cluser 中 node 的数量, 每个 node 的 shards 的数量.
再从细节中挣脱出来看一下, 在 ES 中的搜索都是以 ms 计时的, 增加的时间应该不会超出太多数量级吧.
非常赞！受教啦
据一个在elasticsearch群的人说,他们10亿数据的搜索,优化后时间大概是1.x秒
谢谢。。。能否告知哪个群啊？？因为数据可能明年就上亿了，后年几亿没有问题，怕到时候有很大的问题。所以想先知道一下有没有什么坑。。
ES 2-3亿应该没有问题吧？？
必须顶！哈哈
Blah, blah, blah...
感觉tire不如elasticsearch-api+json_builder好用
用tire的时候,查了es的文档,还得再看在tire上是怎么写的.
不像elasticsearch-api那么贴近es原生的json
谢谢分享啊~
刚刚看了一下 elasticsearch-api 是 elasticsearch-ruby Gem 里一个模块。
可以单独使用，与 ES 进行通信，比较直接。但是需要手动解析响应的 JSON 数据。
Tire 的文档不全，实例也比较少，一些特殊需求，开发的时候比较别扭。
tire的语法基本是和es的json格式一一映射的，学用es最先应该熟悉es的json api，然后再用第三方库就不会那么痛苦了。
顺便推一个自用的rtf: 添加了ansj分词，已经在暴走漫画上线。
谢谢分享:thumbsup:
最近正好在用ES + tire，只是目前数据量不大，性能还没有亲测
打算写一个gem, tire的dsl反人类..
昨天测 70+w （mysql 1.2G左右数据量）生成索引， 相比Solr, 需要近两小时
看项目用了tire , tire的作者已经跑去
elasticsearch-ruby ，或许还是他主推的。
tire是一个典型的ruby dsl式的库，自定义多有不便。
elasticsearch更新很快，新功能让tire有点跟不上。
如果是新项目，建议用 elasticsearch-ruby 吧，毕竟写个hash也不会多困难。
请问一下ES的统计功能是如何实现的，是在一边索引数据一边进行数据的统计吗?
我导入了1000W条左右的日志记录，按时间段统计某些数据(5分钟一段切分)，用mongodb的aggregate大概要40S，用ES的fact histogram直接2-3s就返回了，很好奇他是如何实现的~~~
以后可以考虑用这个了
貌似最近快出稳定版本了。
正在寻找ruby下的全文检索方案，支持中文分词。谢谢分享。
谢谢分享，刚好找工作要用到
ElasticSearch和Mysql配合使用的话，同一个数据是不是必须在ElasticSearch和Mysql各存一份？
可以这样理解的。
MySQL 保存的是用户产生的原始数据，ES 存储的是基于原始数据，建立的索引。
后方可回复, 如果你还没有账号请点击这里 。
共收到 56 条回复Ubuntu 14.04
JDK 1.8.0_66
Elasticsearch 2.3.1
Elasticsearch-jdbc 2.3.1.0
Elasticsearch单节点环境
进入es目录~/cluster/elasticsearch-2.3.1
$ wget http://xbib.org/repository/org/xbib/elasticsearch/importer/elasticsearch-jdbc/2.3.1.0/elasticsearch-jdbc-2.3.1.0-dist.zip
$ unzip elasticsearch-jdbc-2.3.1.0-dist.zip
数据库中的数据
数据位于10.110.1.47:3306下的ispider_data数据库，表名为es_test
共三条数据如下：
编辑数据导入脚本import.sh
vi import.sh
bin=/home/es/cluster/elasticsearch-2.3.1/elasticsearch-jdbc-2.3.1.0/bin
lib=/home/es/cluster/elasticsearch-2.3.1/elasticsearch-jdbc-2.3.1.0/lib
echo '{
&type& : &jdbc&,
&url&:&jdbc:mysql://10.110.1.47:3306/ispider_data&,
&user&:&root&,
&password&:&123456a?&,
&sql&:&select * from es_test&,
&index& : &customer&,
&type& : &external&
}}' | java \
-cp &${lib}/*& \
-Dlog4j.configurationFile=${bin}/log4j2.xml \
org.xbib.tools.Runner \
org.xbib.tools.JDBCImporter
上述，将MySQL中的数据建立为es中索引为customer，类型为external中。
es@search1:~/cluster/elasticsearch-2.3.1$ curl 'localhost:9200/customer/external/_search?pretty&q=*'
结果显示：
&took& : 6,
&timed_out& : false,
&_shards& : {
&total& : 5,
&successful& : 5,
&failed& : 0
&hits& : {
&total& : 3,
&max_score& : 1.0,
&hits& : [ {
&_index& : &customer&,
&_type& : &external&,
&_id& : &AVQ8--xAkvh0m5n1OUEo&,
&_score& : 1.0,
&_source& : {
&id& : &4&,
&name& : &zhangsan&
&_index& : &customer&,
&_type& : &external&,
&_id& : &AVQ8--xBkvh0m5n1OUEq&,
&_score& : 1.0,
&_source& : {
&id& : &3&,
&name& : &wangwu&
&_index& : &customer&,
&_type& : &external&,
&_id& : &AVQ8--xBkvh0m5n1OUEp&,
&_score& : 1.0,
&_source& : {
&id& : &2&,
&name& : &lisi&
可见，_source中的各个字段field，与数据库中的各列对应。
注意，_source中的id是es_test表中的id列，索引中document的id是自动生成的，二者并不一样。
至此，从数据库MySQL导入ES建立索引的过程就完成了。
阅读(...) 评论()日处理20亿数据，实时用户行为服务系统架构实践
作者丨陈清渠
责编丨钱曙光
携程实时用户行为服务作为基础服务，目前普遍应用在多个场景中，比如猜你喜欢（携程的推荐系统）、动态广告、用户画像、浏览历史等等。
以猜你喜欢为例，猜你喜欢为应用内用户提供潜在选项，提高成交效率。旅行是一项综合性的需求，用户往往需要不止一个产品。作为一站式的旅游服务平台，跨业务线的推荐，特别是实时推荐，能实际满足用户的需求，因此在上游提供打通各业务线之间的用户行为数据有很大的必要性。
携程原有的实时用户行为系统存在一些问题，包括：1）数据覆盖不全；2）数据输出没有统一格式，对众多使用方提高了接入成本；3）日志处理模块是Web Service，比较难支持多种数据处理策略和实现方便扩容应对流量洪峰的需求等。
而近几年旅游市场高速增长，数据量越来越大，并且会持续快速增长。有越来越多的使用需求，对系统的实时性，稳定性也提出了更高的要求。总的来说，当前需求对系统的实时性/可用性/性能/扩展性方面都有很高的要求。
这样的背景下，我们按照如下结构重新设计了系统：
图1 实时用户行为系统逻辑视图
新的架构下，数据有两种流向，分别是处理流和输出流。
在处理流，行为日志会从客户端（App/Online/H5）上传到服务端的Collector Service。Collector Service将消息发送到分布式队列。数据处理模块由流计算框架完成，从分布式队列读出数据，处理之后把数据写入数据层，由分布式缓存和数据库集群组成。
输出流相对简单，Web Service的后台会从数据层拉取数据，并输出给调用方，有的是内部服务调用，比如推荐系统，也有的是输出到前台，比如浏览历史。系统实现采用的是Java+Kafka+Storm+Redis+MySQL+Tomcat+Spring的技术栈。
Java：目前公司内部Java化的氛围比较浓厚，并且Java有比较成熟的大数据组件
Kafka/Storm：Kafka作为分布式消息队列已经在公司有比较成熟的应用，流计算框架Storm也已经落地，并且有比较好的运维支持环境。
Redis： Redis的HA，SortedSet和过期等特性比较好地满足了系统的需求。
MySQL: 作为基础系统，稳定性和性能也是系统的两大指标，对比NoSQL的主要选项，比如HBase和ElasticSearch，十亿数据级别上MySQL在这两方面有更好的表现，并且经过设计能够有不错的水平扩展能力。
目前系统每天处理20亿左右的数据量，数据从上线到可用的时间在300毫秒左右。查询服务每天服务8000万左右的请求，平均延迟在6毫秒左右。下面从实时性/可用性/性能/部署几个维度来说明系统的设计。
二、实时性
作为一个实时系统，实时性是首要指标。线上系统面对着各种异常情况。例如如下几种情况：
突发流量洪峰，怎么应对；
出现失败数据或故障模块，如何保证失败数据重试并同时保证新数据的处理；
环境问题或bug导致数据积压，如何快速消解；
程序bug，旧数据需要重新处理，如何快速处理同时保证新数据。
系统从设计之初就考虑了上述情况。
首先是用Storm解决了突发流量洪峰的问题。Storm具有如下特性：
图2 Storm特性
作为一个流计算框架，和早期大数据处理的批处理框架有明显区别。批处理框架是执行完一次任务就结束运行，而流处理框架则持续运行，理论上永不停止，并且处理粒度是消息级别，因此只要系统的计算能力足够，就能保证每条消息都能第一时间被发现并处理。
对当前系统来说，通过Storm处理框架，消息能在进入Kafka之后毫秒级别被处理。此外，Storm具有强大的scale out能力。只要通过后台修改Worker数量参数，并重启Topology（Storm的任务名称），可以马上扩展计算能力，方便应对突发的流量洪峰。
对消息的处理Storm支持多种数据保证策略，at least once，at most once，exactly once。对实时用户行为来说，首先是保证数据尽可能少丢失，另外要支持包括重试和降级的多种数据处理策略，并不能发挥exactly once的优势，反而会因为事务支持降低性能，所以实时用户行为系统采用的at least once的策略。这种策略下消息可能会重发，所以程序处理实现了幂等支持。
Storm的发布比较简单，上传更新程序jar包并重启任务即可完成一次发布，遗憾的是没有多版本灰度发布的支持。
图3 Storm架构
在部分情况下数据处理需要重试，比如数据库连接超时，或者无法连接。连接超时可能马上重试就能恢复，但是无法连接一般需要更长时间等待网络或数据库的恢复，这种情况下处理程序不能一直等待，否则会造成数据延迟。实时用户行为系统采用了双队列的设计来解决这个问题。
图4 双队列设计
生产者将行为纪录写入Queue1（主要保持数据新鲜），Worker从Queue1消费新鲜数据。如果发生上述异常数据，则Worker将异常数据写入Queue2（主要保持异常数据）。
这样Worker对Queue1的消费进度不会被异常数据影响，可以保持消费新鲜数据。RetryWorker会监听Queue2，消费异常数据，如果处理还没有成功，则按照一定的策略（如下图）等待或者重新将异常数据写入Queue2。
图5 补偿重试策略
另外，数据发生积压的情况下，可以调整Worker的消费游标，从最新的数据重新开始消费，保证最新数据得到处理。中间未经处理的一段数据则启动backupWorker，指定起止游标，在消费完指定区间的数据之后，backupWorker会自动停止（如下图）。
图6 积压数据消解
三、可用性
作为基础服务，对可用性的要求比一般的服务要高得多，因为下游依赖的服务多，一旦出现故障，有可能会引起级联反应影响大量业务。项目从设计上对以下问题做了处理，保障系统的可用性：
系统是否有单点？
DB扩容/维护/故障怎么办？
Redis维护/升级补丁怎么办？
服务万一挂了如何快速恢复？如何尽量不影响下游应用？
首先是系统层面上做了全栈集群化。Kafka和Storm本身比较成熟地支持集群化运维；Web服务支持了无状态处理并且通过负载均衡实现集群化；Redis和DB方面携程已经支持主备部署，使用过程中如果主机发生故障，备机会自动接管服务；通过全栈集群化保障系统没有单点。
另外系统在部分模块不可用时通过降级处理保障整个系统的可用性。先看看正常数据处理流程（如下图）：
图7 正常数据流程
在系统正常状态下，Storm会从Kafka中读取数据，分别写入到Redis和MySQL中。服务从Redis拉取（取不到时从DB补偿），输出给客户端。DB降级的情况下，数据流程也随之改变（如下图）。
图8 系统降级-DB
当MySQL不可用时，通过打开DB降级开关，Storm会正常写入Redis，但不再往MySQL写入数据。数据进入Reids就可以被查询服务使用，提供给客户端。另外Storm会把数据写入一份到Kafka的Retry队列，在MySQL正常服务之后，通过关闭DB降级开关，Storm会消费Retry队列中的数据，从而把数据写入到MySQL中。Redis和MySQL的数据在降级期间会有不一致，但系统恢复正常之后会通过Retry保证数据最终的一致性。Redis的降级处理也类似（如下图）：
图9 系统降级-Redis
唯一有点不同的是Redis的服务能力要远超过MySQL。所以在Redis降级时系统的吞吐能力是下降的。这时我们会监控db压力，如果发现MySQL压力较大，会暂时停止数据的写入，降低MySQL的压力，从而保证查询服务的稳定。
为了降低故障情况下对下游的影响，查询服务通过Netflix的Hystrix组件支持了熔断模式（如下图）。
图10 Circuit Breaker Pattern
在该模式下，一旦服务失败请求在给定时间内超过一个阈值，就会打开熔断开关。在开关开启情况下，服务对后续请求直接返回失败响应，不会再让请求经过业务模块处理，从而避免服务器进一步增加压力引起雪崩，也不会因为响应时间延长拖累调用方。
开关打开之后会开始计时，timeout后会进入Half Open的状态，在该状态下会允许一个请求通过，进入业务处理模块，如果能正常返回则关闭开关，否则继续保持开关打开直到下次timeout。这样业务恢复之后就能正常服务请求。
另外，为了防止单个调用方的非法调用对服务的影响，服务也支持了多个维度限流，包括调用方AppId/ip限流和服务限流，接口限流等。
四、性能&扩展
由于在线旅游行业近几年的高速增长，携程作为行业领头羊也蓬勃发展，因此访问量和数据量也大幅提升。公司对业务的要求是可以支撑10倍容量扩展，扩展最难的部分在数据层，因为涉及到存量数据的迁移。
实时用户行为系统的数据层包括Redis和MySQL，Redis因为实现了一致性哈希，扩容时只要加机器，并对分配到新分区的数据作读补偿就可以。
MySQL方面，我们也做了水平切分作为扩展的准备，分片数量的选择考虑为2的n次方，这样做在扩容时有明显的好处。因为携程的MySQL数据库现在普遍采用的是一主一备的方式，在扩容时可以直接把备机拉平成第二台（组）主机。假设原来分了2个库，d0和d1，都放在服务器s0上，s0同时有备机s1。扩容只需要如下几步：
确保s0 -& s1同步顺利，没有明显延迟
s0暂时关闭读写权限
确认s1已经完全同步s0更新
s1开放读写权限
d1的dns由s0切换到s1
s0开放读写权限
迁移过程利用MySQL的复制分发特性，避免了繁琐易错的人工同步过程，大大降低了迁移成本和时间。整个操作过程可以在几分钟完成，结合DB降级的功能，只有在DNS切换的几秒钟时间会产生异常。
整个过程比较简单方便，降低了运维负担，一定程度也能降低过多操作造成类似GitLab式悲剧的可能性。
前文提到Storm部署是比较方便的，只要上传重启就可以完成部署。部署之后由于程序重新启动上下文丢失，可以通过Kafka记录的游标找到之前处理位置，恢复处理。&
另外有部分情况下程序可能需要多版本运行，比如行为纪录暂时有多个版本，这种情况下我们会新增一个backupJob，在backupJob中运行历史版本。
Serverless一词越来越热，已经成为一种新型的软件设计架构，即Serverless Architecture。作为一种原生于公共云的架构，会成为未来改变云计算的中坚力量吗？
-11日，SDCC 2017·深圳站火热开启，拥有互联网应用架构实战峰会、大数据技术实战峰会两大峰会，精彩不容错过！
GCC是由GNU开发的编程语言编译器，目前发布了7.1版本。
5月18-19日，北京 o 朝阳门悠唐皇冠假日酒店，CSDN主办的中国云计算技术大会将围绕最热门、最前沿的云计算技术与行业实践重磅登场。
本文将展示一个超级简单的点对点聊天程序，并阐释到底什么是VPN以及怎样实现它。
Bandit算法常用于解决推荐系统里的两个经典问题：EE和冷启动，本文将介绍Bandit及一系列升级版，以及对推荐系统这两个经典问题的思考。
5月18日的CCTC 2017人工智能专场上，来自阿里、京东、IBM、PPmoney、第四范式的五位人工智能研究资深专家将为与会者带来顶级技术分享会。
pygit是一个大约500行Python代码工具，实现了一些git功能，包括创建库、将文件添加到索引、提交、将自身推送到GitHub上去。 本文给出了一些代码编写过程，并详细介绍了相关代码。
TPS是大家最为关心的性能测试指标，获取过程较为复杂，需经历需求调研、环境准备、脚本开发、数据预埋、场景设计等多个环节。本文将选取场景设计环节做详细说明。
本封面报道汇聚来自百度、阿里、小米、美丽联合、58同城等公司的技术专家，分享实践过程中的开发经验、行业的发展与前沿技术方向，展示这项技术如何才能“为我所用”。
说点农村实际事，看看农村啥社会，现在农村太疯狂，结婚要车要楼房，一个儿子就别讲，家里再好看不上，有姐有妹再商
材料十 材料十
【材料+】说： 《自然》重大突破！全球首创3.3GPa最强镁合金。 香港城市大学吕坚教授团队近日在材料研究取得重大突破，全球首次制备出了超纳镁合金材料。这种结构使得镁合金具备3.3GPa的超高强度，达到了近理论值E/20（其中，E为材料的...
2017北京国际长跑节暨北京半程拉松即将开赛，今年都有哪些亮点？我们先睹为快！
延川县东关小学 延川风讯 延川风讯
提示点上方蓝字↑订阅“延川教育资讯” 3月是学雷锋活动月，为进一步丰富孩子们的课余生活，弘扬雷锋精神，引导孩子们树立“无私奉献、勤劳勇敢、自强不息、乐于助人”的良好品质，延川县东关小学组织开展了以“雷锋在我身边”为主题的...
中山猛料 中山猛料 小伙伴有没有试过？ 买了一款新手机， USIM卡插进去却用不了， 你可能碰到了阉割机！！！！！ 问了手机大神以后， 他和我说： “你买的是XX定制版手机…… 从此只能受某运营商控制了……” 我就一脸懵逼了，在这个性的时代， 每个人都拥有自...
山东嗨生活 山东嗨生活 张晴晴今年24岁，比我大了7岁。她长得很漂亮，将近一米七的高挑身材，瓜子脸，柳叶眉，水杏眼，细腰长腿，而且皮肤非常的白皙细腻，跟电视上那个美女明星范冰冰有的一拼。而且，因为她是一名二中女教师，平日喜欢穿白衬衫黑套裙之类的职装，再搭配着...
就是明天，《金刚：骷髅岛》就要在内地上映了！一想到马上就要在大荧幕上欣赏我抖森的颜和大长腿，一想到要看到穿粉
微信群里发红包，为什么有人总是能第一个抢到？仿佛他们的眼睛和手，从来都没离开过手机屏幕。其实，抢微信红包也暗
点击蓝字↑关注山西焦点！点赞+转发
更多精彩内容，敬请关注权健肿瘤医院官网及微博！官方网址：官方微博：weibo.c
CSDN精彩内容每日推荐。我们关注IT产品研发背后的那些人、技术和故事。
感谢您的支持，请按照如下步骤取消屏蔽ABBAO的广告()：}