资料来源：加米谷大数据
除了
序言
Elasticsearch、名称直译弹性搜索、单个qsdwx内部分片级别的弹性搜索外，还支持跨qsdwx周围的分片弹性搜索，与其他分布式数据产品相比，这一特性本文将探讨以下问题：
为什么需要跨越qsdwx进行查询？ 十字查询中有哪些经典的APP场景？ 跨越qsdwx的查询技术的原理是什么？ qsdwx查询有哪些注意事项？
图： qsdwx图像多个qsdwx查询效果图
为什么需要跨qsdwx查询
技术限制
Elastic Searchq SDWX本身有一些指标限制，是大多数初学者最容易忽视或滥用的。Elastic qsdwx的数据量有大小限制； 各个瓷砖的数据容量官方推荐在50GB以下，合理范围在20GB~40GB之间的单片数据条数约为21亿条(2的32次方)以下，这个值一般很难达到，几乎可以忽略。 背后的原理可以参照源代码和其他； qsdwx平铺太多，分布式资源消耗越多，查询的响应越慢。 基于以上限制，qsdwx在制作前需要根据业务场景进行估算，设定合理的瓷砖数量，不能过多也不能过少。
在基于
技术便利
关系数据库的APP场景中，数据量太大，一般采用分库表策略，查询数据时基于第三方中间件，限制较多的MongoDB等no sodb 如果数据量过大，则采用数据产品本身提供的分片特性，在查询数据时基于自己的路由机制。无论是库分表还是瓷砖，它们只解决了一维数据的保存和查询，在二维上是不可能的。 例如，在电子商务公司订单系统的场景中，数据库由多个分库多表分割，在容量设计超出预期的情况下，需要通过二次分割继续分库分表； MongoDB采用了多个分块，一旦容量超过了预想，就需要继续扩展分块节点。
对于以上的Elasticsearch，也可以不这样做。 提供两个维度的分割方式，第一个维度采用多个qsdwx命名分割，第二个维度采用qsdwx多切片。 对于查询来说，可以灵活地与qsdwx匹配，一次指定一个qsdwx，也可以一次指定多个qsdwx。
图： ES查询的图像多qsdwx多片图像
在
跨qsdwx查询应用场景
IT应用中，除了技术本身的限制问题外，很多问题都是耦合造成的，“高凝聚、低耦合”是我们IT工作者的座右铭。 应用系统耦合成为单体应用，然后扩展微服务架构的理念。 同样，数据合并也必须基于一定维度的微服务化、垂直、水平或混合垂直水平。
业务系统
以特定的商业场景、实时数据和历史数据的保存和查询问题为例，假设日均数据量超过千万件，则每月数量将超过3亿件，全年也将超过36亿件。使用Elasticsearch存储，可以按月、季、年创建qsdwx，因此实时数据更新只影响当前的qsdwx，不影响历史记录的qsdwx。 对于查询，也是如此，根据查询条件指定qsdwx名称，并根据需要扫描查询。 没有必要每次都扫描所有的数据。 这比传统的数据产品灵活得多。
图标：实时数据和历史数据的业务场景
大数据
Elasticsearch在大数据的应用场景中备受欢迎，成为大数据平台对外提供结果查询的标配。 大数据平台需要定期计算数据，将结果数据批量写入Elasticsearch查询业务系统，由于部分业务规则的设定，Elasticsearch的原始qsdwx数据全部删除，重新写入大数据平台每次进行全量计算的成本很大，在Elasticsearch平台的情况下，超大qsdwx数据经常被删除重构，成本也很大。据此，采用多qsdwx方式，按月分解时，根据需要删除的月qsdwx数据。 同样的问题是，业务系统查询时，通过非常灵活地指定所需的月qsdwx数据，确保了存储和查询的平衡。
toutiaoimg.com/origin/pgc-image/073371b563e04aeda8be490569dc6ec0?from=pc">图示：大数据平台写数据到 Elastic 平台示意图
日志
Elasticsearch 应对这个日志场景非常擅长，诞生了著名的 ELK 组合，比如一个大中型的业务系统，每天日志量几十 TB/ 几百 TB 很正常，可按天或者按小时或者更小粒度创建qsdwx，通常查询日志只会查询最近时间的，过去很久的日志，偶然需要查询几次，甚至会删除。所以对于此场景，Elasticsearch 的跨qsdwx查询非常便利，程序编写也很简单。
跨qsdwx查询应用方式
Elasticsearch 跨qsdwx查询的方式可依据业务场景灵活选择，下面介绍几种：
直接型
明确指定多个qsdwx名称，这种方式一般应用在非常精确的查询场景下，便于查询qsdwx范围，性能平衡考虑，若qsdwx不存在会出现错误，如下：index_01,index_02
GET /index_01,index_02/_search { "query" : { "match": { "test": "data" } } }模糊型
不限定死qsdwx名称，这种方式一般采用通配符，无需判断该qsdwx是否存在，支持前匹配、后匹配，前后匹配，如下：index_* 匹配前缀一样的所有qsdwx
GET /index_*/_search { "query" : { "match": { "test": "data" } } }计算型
qsdwx名称通过计算表达式指定，类似正则表达式，也可以同时指定多个qsdwx，如下：logstash-{now/d}表示当前日期
# qsdwx名称如：index-2024.03.22 # GET /<index-{now/d}>/_search GET /%3Cindex-%7Bnow%2Fd%7D%3E/_search{ "query" : { "match": { "test": "data" } } }跨qsdwx查询技术原理
Elasticsearch 能够做到跨qsdwx查询，离不开其架构设计以及相关实现原理。
qsdwx分片
图示：qsdwx由分片组成
qsdwx是一个虚拟的数据集合，qsdwx由多个分片组成；分片存储实际的数据；qsdwx分片数量不限制。查询过程
图示：qsdwx查询阶段
图示：取回数据阶段
查询过程简单说来就是分发与合并：
查询分发，客户端发送请求到协调节点，协调节点分发查询请求到qsdwx分片节点；数据合并，qsdwx分片节点将数据发送到协调节点，协调节点合并返回客户端。所以说，Elasticsearch 提供跨qsdwx查询的能力，实际上与原来单qsdwx查询时一样，本质上是跨多个分片查询，然后合并。
跨qsdwx查询注意事项
qsdwx与分片等价关系
qsdwx与分片等价的关系，1 个qsdwx 20 分片与 4 个qsdwx每个qsdwx 5 个分片理论上是等价的，鉴于qsdwx分片的容量限制与性能平衡，在面对需要跨qsdwx业务场景时，qsdwx的数量与分片的数量尽量的少，既要保障qsdwx热点数据的实时处理能力，也要平衡历史数据的查询性能。
协调节点分离
鉴于 Elastic 查询过程，在跨多个qsdwx查询时，协调节点承担了所有分片查询返回的数据合并，需要消耗很大资源，在应对高并发场景，建议部署独立的协调节点，将集群的数据节点与协调节点分离，以达到最佳的性能平衡。
路由机制
Elasticsearch 写入数据分布默认是基于qsdwx主键 _id 的 Hash 值，此机制在数据分布上很均衡，但也没有什么规律，对于跨qsdwx查询场景，若自定义指定路由键，可以在搜索时避开不需要的qsdwx分片，有效减少分片查询的分片数量，达到更高的性能。
总结
Elasticsearch 由于其架构设计的弹性能力，小小的一个跨qsdwx查询特性，就能给我们应用系统带来很多架构设计的便利，解决很多实际场景问题，这是其它数据产品目前还做不到的。Elasticsearch 还有更厉害的跨多个集群跨多个版本，详情可继续关注笔者下一篇文章的探讨。
还是那句话，Elastic 用得好，下班下得早。