本文共 9283 字，大约阅读时间需要 30 分钟。
大规模数据如何检索？
如：当系统数据量上了10亿、100亿条的时候，我们在做系统架构的时候通常会从以下角度去考虑问题：
1）用什么数据库好？(mysql、sybase、oracle、mongodb、hbase…) 2）如何解决单点故障；(lvs、F5、A10、Zookeep、MQ) 3）如何保证数据安全性；(热备、冷备、异地多活) 4）如何解决检索难题；(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;) 5）如何解决统计分析问题；(离线、近实时)（2）传统数据库的应对解决方案
对于关系型数据，我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈：
解决要点： 1）通过主从备份解决数据安全性问题； 2）通过数据库代理中间件心跳监测，解决单点故障问题； 3）通过代理中间件将查询语句分发到各个slave节点进行查询，并汇总结果
（3）非关系型数据库的解决方案
对于Nosql数据库，以mongodb为例，其它原理类似：
解决要点： 1）通过副本备份保证数据安全性； 2）通过节点竞选机制解决单点问题； 3）先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果
如果完全把数据放入内存怎么样？
我们知道，完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：1PB=1024T=1048576G
节点数=1048576/96=10922个 实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实！从前面讨论我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。
全部放在内存速度问题是解决了，但成本问题上来了。 为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法： 1、存储数据时按有序存储； 2、将数据和索引分离； 3、压缩数据； 这就引出了Elasticsearch。1.3 ES主要解决问题：
1）检索相关数据；
2）返回统计结果； 3）速度要快。1.4 ES工作原理
当ElasticSearch的节点启动后，它会利用多播(multicast)(或者单播，如果用户更改了配置)寻找集群中的其它节点，并与之建立连接。这个过程如下图所示：
ES特点和优势
1）分布式实时文件存储，可将每一个字段存入索引，使其可以被检索到。
2）实时分析的分布式搜索引擎。 分布式：索引分拆成多个分片，每个分片可有零个或多个副本。集群中的每个数据节点都可承载一个或多个分片，并且协调和处理各种操作； 负载再平衡和路由在大多数情况下自动完成。 3）可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。也可以运行在单台PC上（已测试） 4）支持插件机制，分词插件、同步插件、Hadoop插件、可视化插件等。3、ES性能
3.1 性能结果展示
（1）硬件配置：
CPU 16核 AuthenticAMD 内存 总量：32GB 硬盘 总量：500GB 非SSD（2）在上述硬件指标的基础上测试性能如下：
1）平均索引吞吐量： 12307docs/s（每个文档大小：40B/docs） 2）平均CPU使用率： 887.7%（16核，平均每核：55.48%） 3）构建索引大小： 3.30111 GB 4）总写入量： 20.2123 GB 5）测试总耗时： 28m 54s.3.2 性能esrally工具（推荐）
使用参考：
4、为什么要用ES？
4.1 ES国内外使用优秀案例
Elasticsearch 在各大互联网公司大量真实的应用案例！
ElasticSearch在腾讯的应用
ElasticSearch在腾讯的应用非常广泛，主要有三：日志实时分析场景、搜索服务、时序数据分析。
- 搜索服务： 例如像腾讯文档基于 ES 做全文检索，电商客户拼多多、蘑菇街等大量的商品搜索都是基于 ES。
- 日志分析： 这个是 ES 应用最广泛的领域，支持全栈的日志分析，包括各种应用日志、数据库日志、用户行为日志、网络数据、安全数据等等。ES 拥有一套完整的日志解决方案，可以秒级实现从采集到展示。
- 时序分析： 典型的场景是监控数据分析，比如云监控，整个腾讯云的监控都是基于 ES 的。此外还包括物联网场景，也有大量的时序数据。时序数据的特点是写入吞吐量特别高，ES 支持的同时也提供了丰富的多维统计分析算子。
日志实时分析
- 运营日志，比如慢日志、异常日志，用来定位业务问题；
- 业务日志，比如用户的点击、访问日志，可以用来分析用户行为；
- 审计日志，可以用于安全分析。ES 很完美的解决了日志实时分析的需求，它具有如下特点：
Elastic 生态提供了完整的日志解决方案，任何一个开发、运维同学使用成熟组件，通过简单部署，即可搭建起一个完整的日志实时分析服务。
-
在 Elastic 生态中，日志从产生到可访问一般在 10s 级。相比于传统大数据解决方案的几十分钟、小时级，时效性非常高。ES 拥有一套完整的日志解决方案（ELK），可以秒级实现从采集到展示。
-
由于支持倒排索引、列存储等数据结构，ES 提供非常灵活的搜索分析能力。
-
支持交互式分析，即使在万亿级日志的情况下，ES 搜索响应时间也是秒级。
日志是互联网行业最基础、最广泛的数据形式，ES 非常完美的解决了日志实时分析场景，这也是近几年 ES 快速发展的一个重要原因
搜索服务
- 高性能：单个服务最大达到 10w+ QPS，平响 20ms~，P95 延时小于 100ms。
- 强相关：搜索体验主要取决于搜索结果是否高度匹配用户意图，需要通过正确率、召回率等指标进行评估。
- 高可用：搜索场景通常要求高可用性，支持单机房故障容灾。任何一个电商服务，如淘宝、京东、拼多多，只要故障一个小时就可以上头条。
时序数据分析
-
高并发写入：线上单集群最大规模达到 600+节点、1000w/s 的写入吞吐。
-
高查询性能：要求单条曲线 或者单个时间线的查询延时在 10ms~。
-
多维分析：要求灵活、多维度的统计分析能力，比如我们在查看监控的时候，可以按照地域、业务模块等灵活的进行统计分析。
上面通过腾讯的案例我们了解了三大应用场景，
-
日志实时分析场景
-
搜索服务
-
时序数据分析
另外从这三大应用场景我们也可以归纳出ES的几大优势：
1、具有高可用性、高扩展性；
2、查询速度快，性能佳；
3、搜索功能强大，高度匹配用户意图。
因此，可以看出，ES在日志实时分析和搜索方面的应用优势简直是无敌的！起码目前，在这两方面，还没有强劲的对手！
一、京东到家订单中心 Elasticsearch 演进历程
由于较高的性能和较低的使用门槛，京东内部有很多的场景都在使用 Elasticsearch。覆盖了京东多条业务线，同时也覆盖了很多应用场景：
补充关系型数据库的结构化数据查询
主要应用的业务是商品、促销、优惠券、订单、收银台、物流、对账、评论等大数据量查询。此场景的核心诉求是高性能、稳定性和高可用性，部分场景会有检索要求，通常用于加速关系型数据库，业务系统通过 binlog 同步或业务双写完成数据同步。
全文检索功能
主要的应用场景是应用、安全、风控、交易等操作日志，以及京东部分品类商品搜索。此类日志化场景对写要求很高，查询性能及高可用等要求相对较低，大的业务写会达到数千万 / 秒，存储以 PB 为单位来计算。
这些场景对磁盘、内存有比较高的要求，因此，京东也做了相应优化，用于减少内存消耗，提升磁盘整体使用率，使用更廉价的磁盘来降低成本等等。
京东到家订单中心系统业务中，无论是外部商家的订单生产，或是内部上下游系统的依赖，订单查询的调用量都非常大，造成了订单数据读多写少的情况。
京东到家的订单数据存储在MySQL中，但显然只通过DB来支撑大量的查询是不可取的，同时对于一些复杂的查询，Mysql支持得不够友好，所以订单中心系统使用了Elasticsearch来承载订单查询的主要压力。
Elasticsearch 做为一款功能强大的分布式搜索引擎，支持近实时的存储、搜索数据，在京东到家订单系统中发挥着巨大作用，目前订单中心ES集群存储数据量达到10亿个文档，日均查询量达到5亿。
随着京东到家近几年业务的快速发展，订单中心ES架设方案也不断演进，发展至今ES集群架设是一套实时互备方案，很好的保障了ES集群读写的稳定性。
如上图，订单中心ES集群架设示意图。整个架设方式通过VIP来负载均衡外部请求，第一层gateway节点实质为ES中client node，相当于一个智能负载均衡器，充当着分发请求的角色。
第二层为data node，负责存储数据以及执行数据的相关操作。整个集群有一套主分片，二套副分片（一主二副），从网关节点转发过来的请求，会在打到数据节点之前通过轮询的方式进行均衡。集群增加一套副本并扩容机器的方式，增加了集群吞吐量，从而提升了整个集群查询性能。
当然分片数量和分片副本数量并不是越多越好，在此阶段中，对选择适当的分片数量做了近一步探索。
分片数可以理解为Mysql中的分库分表，而当前订单中心ES查询主要分为两类：单ID查询以及分页查询。
分片数越大，集群横向扩容规模也更大，根据分片路由的单ID查询吞吐量也能大大提升，但对于聚合的分页查询性能则将降低。分片数越小，集群横向扩容规模更小，单ID的查询性能也将下降，但对于分页查询，性能将会得到提升。
所以如何均衡分片数量和现有查询业务，我们做了很多次调整压测，最终选择了集群性能较好的分片数。
由于大部分ES查询的流量都来源于近几天的订单，且订单中心数据库数据已有一套归档机制，将指定天数之前已经关闭的订单转移到历史订单库。
架构的快速迭代源于业务的快速发展，正是由于近几年到家业务的高速发展，订单中心的架构也不断优化升级。
架构方案没有最好的，只有最合适的。相信再过几年，订单中心的架构又将是另一个面貌，但吞吐量更大，性能更好，稳定性更强，将是订单中心系统永远的追求。
实时数据分析引擎，形成统计报表
主要应用的业务是物流单的各种分析、订单数据分析、用户画像等。因为业务数据分析纬度较多，flink、storm 等流式分析对于某些报表场景不太适用，批处理实时性又成为问题，所以近实时分析的 Elasticsearch 就成为了这些业务的选择。
二、携程Elasticsearch应用案例
1. 携程酒店订单Elasticsearch实战
选择对分片后的数据库建立实时索引，把查询收口到一个独立的 Web Service，在保证性能的前提下，提升业务应用查询时的便捷性。
最终我们选择了 Elasticsearch，看中的是它的轻量级、易用和对分布式更好的支持，整个安装包也只有几十兆。
http://developer.51cto.com/art/201807/579354.htm
2. 携程机票ElasticSearch集群运维驯服记
这个是比较通用的数据的流程，一般会通过Kafka分离产生数据的应用程序和后面的平台，通过ETL落到不同的地方，按照优先级和冷热程度采取不同的存储方式。
一般来说，冷数据存放到HDFS，如果温数据、或者热数据会采用Database以及Cache。一旦数据落地，我们会做两方面的应用
第一个方面的应用是传统BI，比如会产生各种各样的报表，报表的受众是更高的决策层和管理层，他们看了之后，会有相应的业务调整和更高层面的规划或转变。
这个使用路径比较传统的，在数据仓库时代就已经存在了。现在有一种新兴的场景就是利用大数据进行快速决策，数据不是喂给人的，数据分析结果由程序来消费，其实是再次的反馈到数据源头即应用程序中，让他们基于快速分析后的结果，调整已有策略，这样就形成了一个数据使用的循环。
这样我们从它的输入到输出会形成一种闭环，而且这个闭环全部是机器参与的，这也是为什么去研究这种大规模的，或者快速决策的原因所在。
如果数据最终还会给人本身来看的话，就没有必要更新那么快，因为一秒钟刷新一次或者10秒钟刷新一次对人是没有意义的，因为我们脑子不可能一直转那么快，基于数据一直的做调整也是不现实的，但是对机器来讲，就完全没有问题。
http://www.sohu.com/a/199672012_411876
3. 携程：大规模 Elasticsearch 集群管理心得
目前，我们最大的日志单集群有120个data node，运行于70台物理服务器上。数据规模如下:
-
单日索引数据条数600亿，新增索引文件25TB (含一个复制片则为50TB)
-
业务高峰期峰值索引速率维持在百万条/秒
-
历史数据保留时长根据业务需求制定，从10天 - 90天不等
-
集群共3441个索引、17000个分片、数据总量约9300亿, 磁盘总消耗1PB
https://www.jianshu.com/p/6470754b8248
三、去哪儿：订单中心基于elasticsearch 的解决方案
15年去哪儿网酒店日均订单量达到30w+，随着多平台订单的聚合日均订单能达到100w左右。
原来采用的热表分库方式，即将最近6个月的订单的放置在一张表中，将历史订单放在在history表中。history表存储全量的数据，当用户查询的下单时间跨度超过6个月即查询历史订单表，此分表方式热表的数据量为4000w左右，当时能解决的问题。但是显然不能满足携程艺龙订单接入的需求。
如果继续按照热表方式，数据量将超过1亿条。全量数据表保存2年的可能就超过4亿的数据量。所以寻找有效途径解决此问题迫在眉睫。
由于对这预计4亿的数据量还需按照预定日期、入住日期、离店日期、订单号、联系人姓名、电话、酒店名称、订单状态……等多个条件查询。所以简单按照某一个维度进行分表操作没有意义。
Elasticsearch分布式搜索储存集群的引入，就是为了解决订单数据的存储与搜索的问题。
对订单模型进行抽象和分类，将常用搜索字段和基础属性字段剥离。DB做分库分表，存储订单详情；Elasticsearch存储搜素字段。
订单复杂查询直接走Elasticsearch，基于OrderNo的简单查询走DB，如下图所示。
系统伸缩性：Elasticsearch 中索引设置了8个分片，目前ES单个索引的文档达到1.4亿，合计达到2亿条数据占磁盘大小64G，集群机器磁盘容量240G。
https://elasticsearch.cn/article/6197
四、Elasticsearch 在58集团信息安全部的应用
全面介绍 Elastic Stack 在58集团信息安全部的落地，升级，优化以及应用。
包括如下几个方面：接入背景，存储选型，性能挑战，master node以及data node优化，安全实践，高吞吐量以及低延迟搜索优化；kibana 的落地，本地化使其更方便产品、运营使用。
https://elasticsearch.cn/slides/124
五、滴滴Elasticsearch多集群架构实践
滴滴 2016 年初开始构建 Elasticsearch 平台，如今已经发展到超过 3500+ Elasticsearch 实例，超过 5PB 的数据存储，峰值写入 tps 超过了 2000w/s 的超大规模。
Elasticsearch 在滴滴有着非常丰富的使用场景，例如线上核心的打车地图搜索，客服、运营的多维度查询，滴滴日志服务等近千个平台用户。
先看看滴滴 Elasticsearch 单集群的架构：滴滴在单集群架构的时候，写入和查询就已经通过 Sink 服务和 Gateway 服务管控起来。
1. Sink服务
滴滴几乎所有写入 Elasticsearch 的数据都是经由 kafka 消费入到 Elasticsearch。kafka 的数据包括业务 log 数据、mysql binlog 数据和业务自主上报的数据，Sink 服务将这些数据实时消费入到 Elasticsearch。
最初设计 Sink 服务是想对写入 Elasticsearch 集群进行管控，保护 Elasticsearch 集群，防止海量的数据写入拖垮 Elasticsearch，之后我们也一直沿用了 Sink 服务，并将该服务从 Elasticsearch 平台分离出去，成立滴滴 Sink 数据投递平台，可以从 kafka 或者 MQ 实时同步数据到 Elasticsearch、HDFS、Ceph 等多个存储服务。
有了多集群架构后，Elasticsearch 平台可以消费一份 MQ 数据写入多个 Elasticsearch 集群，做到集群级别的容灾，还能通过 MQ 回溯数据进行故障恢复。
2. Gateway 服务
所有业务的查询都是经过 Gateway 服务，Gateway 服务实现了 Elasticsearch 的 http restful 和 tcp 协议，业务方可以通过 Elasticsearch 各语言版本的 sdk 直接访问 Gateway 服务
Gateway 服务还实现了 SQL 接口，业务方可以直接使用 SQL 访问 Elasticsearch 平台。
Gateway 服务最初提供了应用权限的管控，访问记录，限流、降级等基本能力，后面随着平台演进，Gateway 服务还提供了索引存储分离、DSL 级别的限流、多集群灾备等能力。
六、Elasticsearch实用化订单搜索方案
搜索引擎中，主要考虑到Elasticsearch支持结构化数据查询以及支持实时频繁更新特性，传统订单查询报表的痛点，以及Elasticsearch能够帮助解决的问题。
订单搜索系统架构
整个业务线使用服务化方式，Elasticsearch集群和数据库分库，作为数据源被订单服务系统封装为对外统一接口；各前、后台应用和报表中心，使用服务化的方式获取订单数据。
4.2 我们也需要
实际项目开发实战中，几乎每个系统都会有一个搜索的功能，当搜索做到一定程度时，维护和扩展起来难度就会慢慢变大，所以很多公司都会把搜索单独独立出一个模块，用ElasticSearch等来实现。
近年ElasticSearch发展迅猛，已经超越了其最初的纯搜索引擎的角色，现在已经增加了数据聚合分析（aggregation）和可视化的特性，如果你有数百万的文档需要通过关键词进行定位时，ElasticSearch肯定是最佳选择。当然，如果你的文档是JSON的，你也可以把ElasticSearch当作一种“NoSQL数据库”， 应用ElasticSearch数据聚合分析（aggregation）的特性，针对数据进行多维度的分析。
Elasticseach 是做搜索引擎出家的，但是到现在已经进化成了一个全能型的数据产品。因此你的思维决不能限制在搜索引擎上。
【知乎：热酷架构师潘飞】ES在某些场景下替代传统DB
个人以为Elasticsearch作为内部存储来说还是不错的，效率也基本能够满足，在某些方面替代传统DB也是可以的，前提是你的业务不对操作的事性务有特殊要求；而权限管理也不用那么细，因为ES的权限这块还不完善。 由于我们对ES的应用场景仅仅是在于对某段时间内的数据聚合操作，没有大量的单文档请求（比如通过userid来找到一个用户的文档，类似于NoSQL的应用场景），所以能否替代NoSQL还需要各位自己的测试。 如果让我选择的话，我会尝试使用ES来替代传统的NoSQL，因为它的横向扩展机制太方便了。5. ES的应用场景是怎样的？
通常我们面临问题有两个：
1）新系统开发尝试使用ES作为存储和检索服务器；
2）现有系统升级需要支持全文检索服务，需要使用ES。 以上两种架构的使用，以下链接进行详细阐述。一线公司ES使用场景：
1）新浪ES 如何分析处理32亿条实时日志
2）阿里ES 构建挖财自己的日志采集和分析体系 3）有赞ES 业务日志处理 4）ES实现站内搜索总结
什么时候应该用ElasticSearch?
1、典型搜索场景：闭着眼用它！
2、典型日志分析场景：闭着眼用它！
3、关系型数据库查询有瓶颈：考虑下用它！为啥是考虑？ES的优点在于查询，然而实践证明，在被作为数据库来使用，即写完马上查询会有延迟。
4、数据分析场景：考虑下用它！为啥是考虑？简单通用的场景需求可以大规模使用，但在特定业务场景领域，还是要选择更加专业的数据产品，如复杂聚合，ClickHouse相比 Elasticserach 做亿级别数据深度聚合需求会更加合适。
ElasticSearch有什么优势呢？
1、很简便的横向扩容，分布式的架构，可以轻松地对资源进行横向纵向扩缩容，可以满足不同数据量级及查询场景对硬件资源的需求。能由数百台到万台机器搭建满足PB级的快速搜索，也能搭建单机版服务小公司。
2、查询速度快：ES底层采用Lucene作为搜索引擎，并在此之上做了多重优化，保证了用户对数据查询数据的需求。可"代替"传统关系型数据库，也可用于复杂数据分析，海量数据的近实时处理等。
3、相关性高：ES内部提供了完善的评分机制，会根据分词出现的频次等信息对文档进行相关性排序，保证相关性越高的文档排序越靠前。另外还提供了包括模糊查询，前缀查询，通配符查询等在内的多种查询手段，帮助用户快速高效地进行检索。
4、功能点多但使用比较简便，开箱即用，性能优化比较简单
5、生态圈丰富，社区活跃，适配多种工具。如下图，处理日志和输出到Elasticsearch，您可以使用日志记录工具，如Logstash（www.elastic.co/products/logstash），搜索和可视化界面分析这些日志，你可以使用Kibana（www.elastic.co/产品/ kibana），即传说中的ELK技术栈。另外当前主流的大数据框架也几乎都支持ES，比如Flink和ES就是个完美搭档。