40345人阅读
elasticsearch（3）
本次分享主要包含两个方面的实战经验：索引性能和查询性能。
一. 索引性能（Index Performance）
首先要考虑的是，索引性能是否有必要做优化？
索引速度提高与否？主要是看瓶颈在什么地方，若是 Read DB（产生DOC）的速度比较慢，那瓶颈不在 ElasticSearch 时，优化就没那么大的动力。实际上 Elasticsearch 的索引速度还是非常快的。
我们有一次遇到 Elasticsearch 升级后索引速度很慢，查下来是新版 IK 分词的问题，修改分词插件后得到解决。
如果需要优化，应该如何优化？
SSD 是经济压力能承受情况下的不二选择。减少碎片也可以提高索引速度，每天进行优化还是很有必要的。在初次索引的时候，把 replica 设置为 0，也能提高索引速度。
bulk 是不是一定需要呢？
若是 Elasticsearch 普通索引已经导致高企的 LA，IO 压力已经见顶，这时候 bulk 也无法提供帮助，SSD 应该是很好的选择。
在 create doc 速度能跟上的时候，bulk 是可以提高速度的。
记得 threadpool.index.queue_size ++，不然会出现索引时队列不够用的情况。
indices.memory.index_buffer_size:10% 这个参数可以进行适当调整。
调整如下参数也可以提高索引速度：index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查询性能（Query Perofrmance）
王道是什么？routing，routing，还是 routing。
我们为了提高查询速度，减少慢查询，结合自己的业务实践，使用多个集群，每个集群使用不同的 routing。比如，用户是一个routing维度。
在实践中，这个routing 非常重要。
我们碰到一种情况，想把此维度的查询（即用户查询）引到非用户routing 的集群，结果集群完全顶不住！
在大型的本地分类网站中，城市、类目也是一个不错的维度。我们使用这种维度进行各种搭配。然后在前端分析查询，把各个不同查询分别引入合适的集群。这样做以后，每个集群只需要很少的机器，而且保持很小的 CPU Usage 和 LA。从而查询速度够快，慢查询几乎消灭。
分别（索引和routing）查询和合并（索引和routing）查询，即此分合的意思。
索引越来越大，单个 shard 也很巨大，查询速度也越来越慢。这时候，是选择分索引还是更多的shards？
在实践过程中，更多的 shards 会带来额外的索引压力，即 IO 压力。
我们选择了分索引。比如按照每个大分类一个索引，或者主要的大城市一个索引。然后将他们进行合并查询。如：http://cluster1:9200/shanghai,beijing/_search?routing=fang，自动将查询中城市属性且值为上海或北京的查询，且是房类目的，引入集群 cluster1，并且routing等于fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引，我们使用城市做 routing，如本例中同时查询济南和临沂城市。
http://cluster1:9200/_all/_search，全部城市查询。
再如：&http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查询上海和北京在小分类汽车、整租的信息，那我们进行如上合并查询。并将其引入集群 cluster2。
使用更多的 shards？
除了有 IO 压力，而且不能进行全部城市或全部类目查询，因为完全顶不住。
Elastic 官方文档建议：一个 Node 最好不要多于三个 shards。
若是 &more shards”，除了增加更多的机器，是没办法做到这一点的。
分索引，虽然一个 Node 总的shards 还是挺多的，但是一个索引可以保持3个以内的shards。
我们使用分索引时，全量查询是可以顶住的，虽然压力有点儿高。
索引越来越大，资源使用也越来越多。若是要进行更细的集群分配，大索引使用的资源成倍增加。
有什么办法能减小索引？显然，创建 doc 时，把不需要的 field 去掉是一个办法；但是，这需要对业务非常熟悉。
有啥立竿见影的办法？
根据我们信息的特点，内容（field:description）占了索引的一大半，那我们就不把 description 索引进 ES，doc 小了一倍，集群也小了一倍，所用的资源（Memory, HD or SSD, Host, snapshot存储，还有时间）大大节省，查询速度自然也更快。
那要查 description 怎么办？
上面的实例中，我们可以把查询引入不同集群，自然我们也可以把 description 查询引入一个非实时（也可以实时）集群，这主要是我们业务特点决定的，因为description查询所占比例非常小，使得我们可以这样做。
被哪些查询搞过？第一位是 Range 查询，这货的性能真不敢恭维。在最热的查询中，若是有这货，肯定是非常痛苦的，网页变慢，查询速度变慢，集群 LA 高企，严重的时候会导致集群 shard 自动下线。所以，建议在最热的查询中避免使用 Range 查询。
Facet 查询，在后续版本这个被 aggregations 替代，我们大多数时候让它在后端进行运算。
线程池我们默认使用 fixed，使用 cached 有可能控制不好。主要是比较大的分片 relocation时，会导致分片自动下线，集群可能处于危险状态。在集群高压时，若是 cached ，分片也可能自动下线。自
1.4 版本后，我们就一直 fixed，至于新版是否还存在这个问题，就没再试验了。
两个原因：一是 routing王道带来的改善，使得集群一直低压运行；二是使用fixed 后，已经极少遇到自动下线shard了。
我们前面说过，user 是一个非常好的维度。这个维度很重要，routing 效果非常明显。其他维度，需要根据业务特点，进行组合。
所以我们的集群一直是低压运行，就很少再去关注新版本的 使用 cached 配置问题。
hreadpool.search.queue_size&这个配置是很重要的，一般默认是够用了，可以尝试提高。
每天优化是有好处的，可以大大改善查询性能。max_num_segments 建议配置为1。虽然优化时间会变长，但是在高峰期前能完成的话，会对查询性能有很大好处。
3) JVM GC的选择：选择 G1还是 CMS？
应该大多数人还是选择了 CMS，我们使用的经验是 G1 和 CMS 比较接近；但和 CMS 相比，还是有一点距离，至少在我们使用经验中是如此。
JVM 32G 现象？
128G内存的机器配置一个 JVM，然后是巨大的 heapsize （如64G）？
还是配多个 JVM instance，较小的 heapsize（如32G）？
我的建议是后者。实际使用中，后者也能帮助我们节省不少资源，并提供不错的性能。具体请参阅 “Don’t Cross 32 GB!& （https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#compressed_oops）
跨 32G 时，有一个现象，使用更多的内存，比如 40G，效果还不如31G！
这篇文档值得大家仔细阅读。
JVM 还有一个配置 bootstrap.mlockall: true，比较重要。这是让 JVM 启动的时候就 锁定 heap 内存。
有没有用过 较小的 heapsize，加上SSD？我听说有人使用过，效果还不错，当然，我们自己还没试过。
4）插件工具
推荐 kopf，是一个挺不错的工具，更新及时，功能完备，可以让你忘掉很多 API :)。
索引，查询，和一些重要的配置，是今天分享的重点。
Q1：您建议生产环境JVM采用什么样的参数设置？FULL GC频率和时间如何？
CMS 标准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS=&$JAVA_OPTS -XX:+UseCondCardMark&
JAVA_OPTS=&$JAVA_OPTS -XX:CMSWaitDuration=250&
JAVA_OPTS=&$JAVA_OPTS -XX:+UseParNewGC&
JAVA_OPTS=&$JAVA_OPTS -XX:+UseConcMarkSweepGC&
JAVA_OPTS=&$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75&
JAVA_OPTS=&$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly&
Full GC 很少去care 它了。我们使用 Elasticsearch 在JVM上花的时间很少。
Q2：生产环境服务器如何配置性价比较高？单机CPU核数、主频？内存容量？磁盘容量？
内存大一些，CPU 多核是必要的，JVM 和 Elasticsearch 会充分使用内存和多核的。 关于内存容量的问题，很多是 JVM Tunning 的问题。 磁盘容量没啥要求。
Q3： 分组统计(Facet 查询或 aggregations )大多数时候让它在后端进行运算，怎么实现？应用如果需要实时进行统计而且并发量较大，如何优化？
因为我们是网站系统，所以对于 Facet 请求，引导到后端慢慢计算，前端初始的时候可能没数据，但是此后就会有了。
如果是精确要求的话，那就只能从 提高 facet 查询性能去下手，比如 routing、filter、cache、更多的内存...
Q4：存进Elasticsearch的数据，timestamp是UTC时间，Elasticsearch集群会在UTC 0点，也就是北京时间早上8点自动执行优化？如何改参数设置这个时间？
我们没有使用Elasticsearch的自动优化设置。自己控制优化时间。
Q5：我的Java程序，log4j2 Flume appender，然后机器上的Flume agent ，直接Elasticsearch 的sink avro到 es节点上，多少个agent 连在单个Elasticsearch节点比较合适 ？
ElasticSearch本身是一个分布式计算集群，所以，请求平均分配到每个 node 即可。
Q6：我代码里直接用 Java API 生成Flume appender 格式，Flume agent 里interceptor去拆分几个字段，这样是不是太累了？比较推荐的做法是不是还是各业务点自己控制字段，调用Elasticsearch API 生成索引内容？
业务点自己控制生成的文档吧？如果需要产生不同routing，并且分了索引，这些其实是业务相关的。routing和不同索引，都是根据业务情况哪些查询比较集中而进行处理的。
Q7：您见过或管理过的生产环境的Elasticsearch数据量多大？
我们使用 Elasticsearch 进行某些业务处理，数据量过亿。
Q8：SSD性能提升多少？
SSD 对索引帮助非常大，效果当当的，提高几十倍应该是没问题。不过，我们没有试过完全使用SSD顶查询，而是使用内存，内存性价比还是不错的。
Q9：我们现在有256个shard，用uid做routing，所有查询都是走routing。每个shard有30多G，每次扩容很慢，有什么建议？
可以考虑使用分合查询吗？ 或者使用更多的维度？ 256个 shard 确实比较难以控制。但是如果是分索引和查询，比more shards(256) 效果应该会好不少。
Q10：Elasticsearch排序等聚合类的操作需要用到fielddata，查询时很慢。新版本中doc values聚合查询操作性能提升很大，你们有没有用过？
Facet 查询需要更大的内存，更多的 CPU 资源。可以考虑routing、filter、cache等多种方式提高性能。
Aggs 将来是要替换 Facet，建议尽快替换原来的facet API。
Q11：Elasticsearch配置bootstrap.mlockall，我们在使用中发现会导致启动很慢，因为Elasticsearch要获取到足够的内存才开始启动。
启动慢是可以接受的，启动慢的原因也许是内存没有有效释放过，比如文件 cached了。 内存充足的情况下，启动速度还是蛮快的，可以接受。 JVM 和 Lucene 都需要内存，一般是JVM 50%, 剩下的50% 文件cached 为Lucene 使用。
Q12：优化是一个开销比较大的操作，每天优化的时候是否会导致查询不可用？如何优化这块？
优化是开销很大的。不会导致查询不可用。优化是值得的，大量的碎片会导致查询性能大大降低。 如果非常 care 查询，可以考虑多个集群。在优化时，查询 skip 这个集群就可以。
Q13：Elasticsearch适合做到10亿级数据查询，每天千万级的数据实时写入或更新吗？
10亿是可以做到的，如果文档轻量，10亿所占的资源还不是很多。
ELK 使用 Elasticsearch ，进行日志处理每天千万是小case吧？
不过我们除了使用 ELK 进行日志处理，还进行业务处理，10亿级快速查询是可以做到，不过，需要做一些工作，比如索引和shards的分分合合：）
Q14：Elasticsearch相比Solr有什么优势吗？
我们当年使用 Solr 的时候，Elasticsearch 刚出来。他们都是基于 Lucene的。 Elasticsearch 相对于 solr ，省事是一个优点。而且现在 Elasticsearch 相关的应用软件也越来越多。Solr 和 Lucene 集成度很高，更新版本是和Lucene一起的，这是个优点。
很多年没用 Solr了，毕竟那时候数据量还不大，所以折腾的就少了，主要还是折腾 JVM。所以，就不再过多的比较了。
Q15：分词用的什么组件？Elasticsearch自带的吗？
我们使用 IK 分词，不过其他分词也不错。IK分词更新还是很及时的。而且它可以远程更新词典。：）
Q16：&reindex有没有好的方法？
reindex 这个和 Lucene 有关，它的 update 就是 delete+ add。
Q17：以上面的两个例子为例
： 是存储多份同样的数据么？
是两个集群。第一个集群使用大城市分索引，不过，还有大部分小城市合并一个索引。大城市还是用类目进行routing，小城市合并的索引就使用城市进行routing 。
第二个集群，大类分得索引，比如fang、che，房屋和车辆和其他类目在一个集群上，他们使用 city+二级类目做routing。
Q18：集群部署有没有使用
Docker ？ 我们使用的时候 ，同一个服务器 节点之间的互相发现没有问题 ，但是跨机器的时候需要强制指定network.publish_host 和discovery.zen.ping.unicast.hosts&才能解决集群互相发现问题。
我们使用puppet进行部署。暂没使用 Docker。 强制指定network.publish_host 和discovery.zen.ping.unicast.hosts&才能解决集群，跨IP段的时候是有这个需要。
Q19：您建议采用什么样的数据总线架构来保证业务数据按routing写入多个Elasticsearch集群，怎么保证多集群Elasticsearch中的数据与数据库中数据的一致性？
我们以前使用 php在web代码中进行索引和分析 query，然后引导到不同集群。 现在我们开发了一套go rest系统——4sea，使用 redis + elastic 以综合提高性能。
索引时，更新db的同时，提交一个文档 ID 通知4sea 进行更新，然后根据配置更新到不同集群。
数据提交到查询时，就是分析 query 并引导到不同集群。
这套 4sea 系统，有机会的可以考虑开源，不算很复杂的。
Q20： 能介绍一下Elasticsearch的集群rebanlance、段合并相关的原理和经验吗？
“段”合并？，我们是根据业务特点，产生几个不一样的集群，主要还是 routing 不一样。
shards 比较平均很重要的，所以选择routing 维度是难点，选择城市的话，大城市所在分片会非常大，此时可以考虑 分索引，几个大城市几个索引，然后小城市合并一个索引。
如果 shards 大小分布平均的话，就不关心如何 allocation 了。
Q21：关于集群rebalance，其实就是cluster.routing.allocation配置下的那些rebalance相关的设置，比如allow_rebalance／cluster_concurrent_rebalance／node_initial_primaries_recoveries，推荐怎么配置？
分片多的情况下，这个才是需要的吧。
分片比较少时，allow_rebalance disable，然后手动也可以接受的。
分片多，一般情况会自动平衡。我们对主从不太关心。只是如果一台机器多个 JVM instance （多个 Elasticsearch node）的话，我们写了个脚本来避免同一shard 在一台机器上。
cluster_concurrent_rebalance 在恢复的时候根据情况修改。正常情况下，再改成默认就好了。
node_initial_primaries_recoveries，在保证集群低压的情况下，不怎么care。
kopf 上面有好多这种配置，你可以多试试。
Q22：合并查询是异步请求还是同步请求？做缓存吗？
合并查询是 Elasticsearch 自带 API。
Q23：用httpurlconnection请求的时候，会发现返回请求很耗时，一般怎么处理？
尽可能减少慢查询吧？我们很多工作就是想办法如何减少慢查询，routing和分分合合，就是这个目的。
Q24：生产环境单个节点存储多少G数据？
有大的，有小的。小的也几十G了。不过根据我们自己的业务特点，某些集群就去掉了全文索引。唯一的全文索引，使用基本的routing（比较平衡的routing，比如user。城市的话，就做不到平衡了，因为大城市数据很多），然后做了 快照，反正是增量快照，1小时甚至更短时间都可以考虑！！！去掉全文索引的其他业务集群，就小多了。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：531016次
积分：4386
积分：4386
排名：第7211名
原创：44篇
转载：58篇
评论：42条
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'后使用快捷导航没有帐号？
解析如何利用ElasticSearch和Redis检索和存储十亿信息
查看: 21176|
评论: |来自:
摘要: 每隔几个月，发送、存储和索引的信息就会翻一番，在过去几个月HipChat进入了一个指数增长周期。如此多流量的暴增对哪个初创来说都不轻松，这里我们看HipChat的解决之道。
如果从企业应用的生存率来看，选择企业团队信息作为主要业务，HipChat的起点绝非主流；但是如果从赚钱的角度上看，企业市场的高收益确实值得任何公司追逐，这也正是像JIRA和Confluence这样的智能工具制造商Atlassian于2012年收购HipChat的原因。同时，或许你不知道的是，在Atlassian资源和人脉的帮助下，。12亿的信息存储意味着他们现在每隔几个月的信息发送、存储和索引量都会翻一番。如此快速的增长给曾经充足的基础设施带来了很大的压力，HipChat给我们展示了一个通用的扩展思路。从简单开始，经历流量高峰，然后思考现在怎么办？使用更大的计算机通常是第一个和较好的答案，他们也是这样做的。这给了他们一些喘息空间去考虑下一步怎么做。在AWS上，在某一个拐点之后，你开始走向云特性，也就是横向扩展，这就是HipChat所做的事情。然而HipChat的发展也并未是顺风顺水，安全性的担忧推动了HipChat的云（SaaS）版本之外内部部署版本的发展。即使HipChat没有谷歌那么大规模，我们仍能从中学到好东西，比如他们如何及时索引和搜索十亿信息，这也是IRC之类和HipChat之间的关键区别。在负载下索引和存储信息，丢失信息是一个艰巨的挑战。这是HipChat选择的路，我们一起展开……统计每秒60条消息12亿文档存储4TB的EBS RAID在AWS上8个ElasticSearch服务器26个前端代理服务器，是后端应用服务器的一倍18个人0.5TB的搜索数据平台主机：AWS EC2 East上的75个实例全部使用Ubuntu 12.04 LTS&数据库：目前用于聊天记录的CouchDB，过渡到ElasticSearch。My-RDS用于其它的一切缓存：搜索：ElasticSearch队列/Worker 服务器：Gearman（队列），Curler（Worker）语言：Twisted Python（XMPP Server）和PHP（Web前端）系统配置：开源Chef+Fabric代码部署：Capistrano监控：Sensu和monit将警告抽送至Pagerduty图：statsd + Graphite产品流量突发。在周末和假期将是安静的。在高峰负荷期间每秒有几百个请求。实际上占用大部分流量的并不是聊天信息，而是状态信息（away、idle、available），人们连接/断开等。因此每秒60条消息似乎很少，但是它只是一个平均水平。通知中心HipChat，在这里与团队合作，并得到来自工具和其他系统的所有信息。有助于使每个人都在消息圈内，特别是远程办公。使用HipChat而不是IRC之类，很大的原因是HipChat存储和索引每一次对话，以便你以后搜索它们。强调搜索，这个特性的好处是你可以在任何时候做回溯，了解发生了什么和同意了什么。如果在发送一条信息时，你的设备无法访问，它也会将消息路由到同一个用户的多台设备中，并做临时消息缓存/重试。更多的用户带来更快的增长，他们在各个方面使用产品而带来的更多预定，也可以从他们的API集成中看到增长。存储和搜索信息是系统中主要的可扩展性瓶颈。HipChat使用XMPP协议，因此任何XMPP客户端都可以连接到系统中，这点非常有利于采用。他们已经建立了自己的本地客户端（Window、、Mac、iOS、Android），并带有类似PDF浏览、自定义表情符号、自动用户注册等扩展。在以前，将Wiki这样的工具引入到企业文化是几乎不可能的。现在，企业级的工具多已在企业落脚，这是为什么？基于文本通信已被广泛接受。我们有短信、IM和Skype的形式，所以现在使用聊天工具是自然的事情。异地工作模式的崛起。团队越来越分散，我们不能只是坐在一起进行一个讲座，一切文档化的需要意味着组织通信将有一笔巨大的财富。增强的功能。把像内嵌图片、GIF动画等功能做得生动有趣，会吸引更广泛的群体。HipChat有一个API，这使得它可以编写类似这样的工具。例如使用Bitbucket提交——在10:08开发者X提交一些代码来修复一个漏洞。代码发送通过HipChat直接连接到代码提交和提交日志，完全的自动化。Bitbucket提交会击中一个web hook，并使用一个addons来张贴信息。Addons帮助编写bots，转入你的Bitbucket账户。比如我有我的API令牌，我想在每次提交发生时张贴到这个API上，工作原理类似GitHub。在客户端Adobe Air启动时，内存泄露会导致宕机，因此将其移动到本地应用上。这是个麻烦，也是机遇。同一个公司中都存在许多跨平台跨部门的用户，你需要站在用户的角度思考。希望用户在所有的系统中都有很好的体验，用户不仅仅是技术人员。XMPP服务器架构HipChat是基于XMPP协议的，XMPP节里的内容就是消息，可能是一行文本或者日志输出的长段等等。他们不想谈论自己的XMPP架构，所以没有很多的细节。他们没有使用第三方的XMPP服务器，而是利用Twisted Python和XMPP库建立了自己的服务器。这使得可以创建一个可扩展的后端、用户管理，并轻松的添加功能而不用在其它代码库上修改。AWS上的RDS用于用户身份验证和其它使用事务及SQL的地方。这是一个稳定、成熟的技术。对于内部部署的产品，则使用MariaDB。Redis用于缓存。信息，如哪些用户在哪些房间，状态信息，谁在线等都是信息。所以，你连接的是哪个XMPP服务器并不重要，XMPP服务器本身并不是一个限制。痛点是Redis（还）没有集群，因此使用了高可用性的hot/cold模式，所以，一个从属节点已经准备就绪。故障转移从主节点到从属节点大概需要7分钟，从属节点的发布是手动的，不是自动的。提高负载可以发现代理服务器中的弱点所在，也可以清楚能支撑多少个客户端。这是一个真正的问题，正如不丢失信息是一个很大的优势。显而易见，不丢失信息比低延迟更重要——用户更愿意晚点接收信息，而不是根本没有信息。使用6个XMPP服务器系统运作良好，然而随着连接点的增加，他们开始看到不可接受的延迟。连接不仅来自客户端，还来自bots支持他们的程序设计界面。在第一遍的时候，他们分离出前端服务器和应用服务器。代理服务器处理连接，后端应用程序处理的stanza。前端服务器数量由有效收听客户数量驱动，而不是由信息发送数量驱动。保持那么多的连接打开，同时提供及时的服务是一个挑战。修复数据存储问题之后的计划是调查如何优化连接管理。Twisted的效果很好，但是他们有很多的连接，所以必须弄清楚如何更好地处理这些连接。存储架构向HipChat发送的消息已达10亿条，同时还在不停增长，他们将CouchDB和Lucene对存储和搜索信息的解决方案推向极限。认为Redis将会是故障点，而Couch/Lucene会足够好。没有做合适的容量计划和查看信息增长率。增长速度比他们想象的更快，不应该集中那么多精力在Redis上，而应该专注于数据存储。当时他们相信通过增加容量来扩展，向上移动到越来越大的亚马逊实例。他们发现一点，随着不断地增长，他们利用这种方法只能再工作两个月。所以，他们不得不采用其他的办法。Couch/Lucene超过一年没有更新，它不能做分类。这是采用其他办法的另一个原因。在亚马逊上大约10亿消息的一半是一个临界点。用一个专用的服务器和200G的RAM，他们之前的架构可能仍能工作，但在有限资源的云上就不能工作了。他们想留在亚马逊。喜欢AWS的灵活性，性能的添加只需要通过租用实例完成。亚马逊的片状。不要把你所有的鸡蛋都放到一个篮子里，如果一个节点出现故障，你必须要处理它，否则一些用户将会失去流量。使用动态模型。可以快速关闭一个实例，并带来新的实例。云原生类型的东西。可以随时关闭节点。关闭一个Redis主节点，可以在5分钟内恢复。目前美国东岸分割4个可用地区，但是还没有多区域。EBS只让你拥有1TB的数据。在遇到之前，他们并不知道这个限制。使用Couch时他们遇到了EBS磁盘大小限制。HipChat的数据是0.5TB。为了压缩，Couch必须将数据复制到有双倍容量的压缩文件中。2TB的RAID在周末压缩过程中遇到了限制，不想使用RAID解决方案。不选择亚马逊的DynamoDB，因为他们创建了一个HipChat服务器，在防火墙后面的托管服务。HipChat服务器驱动技术堆栈的决定。私人版是建立在自己主机上的解决方案。某些客户不能使用云/SaaS解决方案，比如银行和金融机构，国家安全局已经吓坏了国际客户，因此聘请了两名工程师创建产品的安装版本。Redis集群可以自托管，也可以像ElasticSearch那样工作在AWS上。在内部部署版本中他们使用MariaDB，而不是RDS。不能考虑一个完整的SaaS解决方案，因为那会是一个锁定。现在过渡到ElasticSearch移动到ElasticSearch作为他们的存储和搜索后端，因为它可以储存他们的所有数据，它是高度可用的，它可以通过简单增加更多的节进行扩展，它是多用户的，它可以通过分区和复制透明的处理节点损失，并且它建立在Lucene之上。并不真的需要一个MapReduce功能。看着BigCouch和Riak的搜索（表现一般），但ES在GET上的表现是相当不错的。喜欢坏了就扔，省去了故障检测。 ES HA已令他们在系统的坚固性上感到非常有信心。Lucene的兼容是一个巨大的胜利，因为所有的查询都已经兼容Lucene，因此它是一个自然的迁移路径。客户数据是相当多样的，从聊天记录到图像响应类型的差别也随处可见，他们需要能够快速地直接从12亿文档中查询数据。此举正变得越来越普遍，HipChat也使用ElasticSearch作为他们的key-value存储，减少需要数据库系统的数量，从而降低整体的复杂性。既然性能和响应时间都不错，那完全没有不用的理由。 10ms到100ms的响应时间。在没有任何缓存的情况下，某些领域仍然超过Couch。那为什么还要用多个工具？使用ES，一个节点故障不会引起任何人的注意。在它再平衡时你会得到CPU使用率过高的警报，但是系统仍然运行。用8个ES去处理流量的增长。基于的产品JVM调整可能非常棘手。要使用ES，必须有堆空间容量计划。测试缓存。ES可以缓存过滤结果，这是非常快速的，但是你需要很大的堆空间。虽然8个主机拥有22G的内存，但还会随着缓存的打开被耗尽。所以如果不需要就关闭缓存。缓存有问题，因为它会遇到内存不足的错误然后失败。集群会在几分钟内恢复，只有少数用户会注意到这个问题。因为网络的不可靠，Amazon的故障转移也可能存在问题。在集群中可能会引起错误的选举发生。使用ElasticSearch会遇到这些问题。原本有6个ES节点作为主节点选举运行，一个节点可能会耗尽内存或者遇到一个GC暂停并在网络中丢失。那么其他人就不会看到这个主节点，进行选举，并宣布自己是主节点。他们选举架构中的缺陷是他们不需要法定人数。因此就会出现Split Brain问题，从而引起很多问题。解决方案是在专用的节点上运行ElasticSearch主节点，那么需要做的事情就是成为主节点，从而避免了后续问题。主节点处理分片的分配是完成，谁是主要的，并且完成复制分片分布图。实现再平衡要容易的多，因为主节点可以性能优良的处理所有的再平衡。可以查询任何节点，并会做内部路由。使用月索引，每个月是一个单独的索引。每个初级索引有8个分片，然后有两个副本。如果一个节点丢失，系统仍能工作。不要把RDS移动到ES中。需要使用SQL的数据一般储存在RDS/MariaDB中，典型的是用户管理数据。在Redis集群被释放之前，Redis中大量的缓存是主/从设置。有一个Redis统计服务器，处于离线状态。Redis历史缓存的最后75条消息，用于防止在第一次加载对话时不间断的访问数据库。也有内部状态或快速数据的状态，比如登入用户数量。常规Gearman用于异步工作，比如iOS的推送和传递电子邮件。AWS West用于灾难恢复，一切都会备份到AWS West。Chef用于所有配置。ElasticSearch有一个很好的Chef手册，轻松上手。像Chef，因为你可以开始写Ruby代码而不是使用风格的DSL，它也有一个很好的活跃的社群。收购经验。他们现在已经进入公司的核心资产和人才，但Atlassian不干扰工作，之所以相信，是有原因的。可以在内部要求，例如，如何扩大ElasticSearch ，当别人在Atlassian需要帮助时，他们可以加入帮忙的队伍。良好的整体体验。扁平的团队结构。仍然是一个小团队，目前大约有18人。两个人在DEVOPS，少数平台，IOS、Android的开发人员在服务器端，一个Web开发工程师（在法国）。Capistrano用于部署所有的主机。Sensu用于监控应用程序。让你无需监视堆空间ElasticSearch节点，然后在没有任何通知的情况下解决OOM问题。目前堆的使用率为75％，这正是他们想要的状态。Bamboo用于持续集成。客户端版本还不正规，开发者驱动，有一个临时区域进行测试。集团标志。可以控制哪些群体得到了一个功能、测试特性能及缓慢释放特性，除此之外还能帮助控制主机的负载。功能标志。有利于ElasticSearch部署过程中的保护。例如，如果他们发现一个漏洞，他们可以关闭一个功能，并回去找Couch。用户不会注意到差别。在Couch和ElasticSearch之间的过渡阶段，他们都有应用复制到两个存储。新的API版本将使用Oauth，因此，开发人员可以使用HipChat API在自己的服务器上部署。有客户使用自己的服务器是一个更具扩展性的模式。未来未来几个月将会达到20亿条消息，估计ElasticSearch可以处理大约20亿条消息。不确定如何处理负载的预期增长。预计要到Amazon West以获得数据心更多的的可用性和可能在不同的数据中心投入更多的用户。AWS自动扩展能力移动到语音，私人一对一视频、音频聊天、基本的会议将来可能使用RabbitMQ来传递消息与Confluence更大的集成。使用HipChat聊天，然后使用Confluence页面来捕捉细节。经验教训1. 企业应用程序是摇钱树。卖入一个企业是很痛苦的，销售周期长意味着太多的不确定性。但是如果你成功卖出，那就会获得丰厚的利润，所以你应该考虑企业市场。时代在变，企业却可能是滞后的，但是他们仍然采用新工具和新的做事方式，这其中就有机会。2. 隐私在产品给企业推销时变得越来越重要，它会直接影响到产品的选择与否。HipChat正在做他们产品的备用版本，以使那些不相信公共网络的客户满意。对于一个程序员来说，云作为一个平台非常有意义。对于一个企业来说，云可以是魔鬼。这意味着你必须做出灵活的技术堆栈选择。如果你在服务上100%依靠AWS，那你的系统移动到另一个数据中心将变得几乎不可能。这对Netfix也许并不重要，但是如果你想卖入企业市场，它就很重要了。3. 纵向扩展以获得喘息的空间。当你等待弄清楚架构中下一步要做什么的时候，可以花很少的钱去纵向扩展，给自己几个月的喘息之机。4. 选择不会失败的。HipChat做出了不会丢失用户聊天记录优先级，所以他们的架构将这个优先级反映给保存聊天记录到磁盘，在宕掉后系统恢复时会重新加载。5. 进入本地。你的客户在许多不同的平台上，一个本地的应用将会提供较好的体验。对于一个初创公司，那是很多的资源，太多了。所以，卖给拥有更多资源的公司在某种程度上是说得通的，这样你可以建立更好的产品。6. 功能和群组标志做出更好地发布惯例。如果你可以选择哪些组看到一个功能，如果你能在生产和测试中关闭功能，那么你就不用担心发布新的构建项目了。7. 选择你真正自信的技术。ElasticSearch应对增长的横向扩展能力让HipChat很放心，同样也会有一个很好的用户体验，这才是最重要的。8. 成为该流程的一部分，你变得更有价值，难以消除。HipChat作为人和工具之间的天然契合点，也是来编写实现各种有用工作流bots的天然点。这使得HipChat在企业中有发挥的平台，它使本来不可建造的功能得以实现。如果你能做到同样的事情，那么大家都会很需要你。9. AWS需要在总线上存在一个单独的节点，这个要求看起来有点荒谬，但是在云环境下却非常重要，因为机器可用信息在第三方目的源中并不可见。如果着眼机架就会发现它经常有一个单独存在的总线插槽，如果其他插槽可用，他就会知道。这样，你就不必去猜测。在云中，软件采用基于原始TCP的连接技术和心跳，去猜测另一个节点是否发生故障，从而导致Split Brain问题及启用备库时产生数据丢失。这需要时间去演变，到达完全可靠还需要迈一大步。10. 产品决策驱动堆栈的决定，HipChat服务器驱动技术堆栈的决定：Redis集群可以自托管；不选择亚马逊的DynamoDB，是因为HipChat在防火墙的后面创建一个托管服务。11. 你需要打开视野。你需要容量规划，即使是在云中。除非你的架构从一开始就完全是原生云，否则任何架构都会有负荷的拐点，在拐点他们的架构将不再能够处理负载。看看增长速度，项目出来了。会打破什么？你将会做什么？而且不要再犯同样的错误。HipChat将如何处理40亿条消息？当下还无法知晓。12. 了解系统的限制。EBS有1TB的存储限制，这是很大的限制，但如果你的存储已接近那个限制，就需要有一个计划了。同样，如果你的数据库，例如Couch，在压缩阶段要使用双倍的磁盘空间，那将会影响你的系统限制。13. 这个世界会令你大吃一惊。六个月前HipChat认为Redis将会是最弱的环节，但现在它依旧很强壮，而Couch和EBS才是最薄弱的环节。