按照追加的说法,将下一层级中需要搜索的字段提出来到上一层级中再存一分,我感觉并不能解决此类问题,比如,主楼第一条数据最终还是会存储为 tag:['tags','test'],因为是一对多的结构.所以一样会被主楼这样的条件所查询到.当然可能这个地方我理解的和楼主实现的方式不一样.

不管是 object 还是 nested,或者只是基础的 text, keyword 等等,不管什么类型的数据结构,只要字段总量是确定的,也不用过于担心映射爆炸的问题,映射爆炸主要是对于动态增加的字段来说的,与是否是对象和是否是嵌套无关.比如字段名字叫做 tag1,tag2 这样随着业务不断新增的时候,才会需要考虑这个问题.像我上一楼回复中说的,如果是主楼那样的数据结构,不管有多少个 tag,其实也只有 customFields.key 一个字段而已,字段是数组的话,字段内的数值变多,并不会引起映射爆炸.同样,以上说法也是我记得的情况,可以再找找资料了解一下.

@liangzhe #12 不是大佬,客气了.你所指的 tag 极多是在什么层级呢,以楼主主贴的数据结构看,即使 tag 再多,对于 es 来讲也是 customFields.key 这样一个字段,只是字段里的内容比较长而已.es 对整体的字段数量,以及对单一一个字段里面内容的长度,比如 keyword 类型,也是有限制的,但是这些也都可以按照实际情况进行一定的配置来调大一些.主要看你的数据结构了.

@Saxton #10 嗯,那你需要额外处理下第一条数据那种一对多的关系.

@Saxton #5 简单来说,es 的数据结构存储你这样的数据,如果不使用 nested,实际上会被重新打平拆分的,你的数据的第一条实际上会变为 customFields.key:[tags,test], customFields.value:[灌水,问候] ,所以就会被你在筛选 tags + 问候 时也被筛选到.以上信息源自于我的记忆不保证准确,你自行搜索下.

不出意外的话,你应该是需要 nested.

早年用过 ip138,试了下,还能打开.

@AlexPUBLIC #29 哪里 还能再开么 可以聊聊吗?

@zhoudaiyu #8 等你入职新公司就好了..

@makizcy #2 哈哈 想法一样 ...

直接测试 ip/static/images/xx.jpg 是否可以访问,如果不能,请设置回源 host.

@sxbxjhwm #44 好的 谢谢.

本来想着表达完观点就行了不想在探讨这个话题了,可是你的回复让我看的莫名其妙.
我上个回复全文没有提过 lowcode 一次.也没有说你之前的发帖内容与 lowcode 有什么关系.
我甚至感觉你是不是阅读理解有什么问题,还是我表达的不明白,这没有攻击的意思,就是单纯的疑问.大家应该都听懂了我的意思就你没懂.
既然你非让我说的这么明白,那我就直接说了,如有得罪很抱歉

我对于你 "反对 lowcode 平台" 的观点,既不支持,也不反对,因为我不太了解 lowcode.但是我觉得你这个人双标.

这样听明白了吗?
这下应该表达明白了吧,不再回复了.谢谢.

友情提示,继续讨论的各位可以查阅楼主最近几条发帖纪录.
他想要
"一个可以固定模板来快速替换视频文本图案等元素的方案"
"一个根据建表语句 sql 半自动绘制 ER 图的工具"
"一个可以清晰完整地描述表单的组成、分步、联动等关系的表单描述语言"
"一个可以自动进行前端测试的方案 因为 可以节省人力并提高覆盖率"
以上文字都取材于楼主贴内
但是他却不希望他的老板想要
"一个可以通过拖拽一些组件来快速生成应用的方案"
因为这
"没价值","断后人路"
言尽于此.勿回,不再回复.

@sxbxjhwm #42 只是为了做不阻塞情况下的并发数量限制.

一个新的思路是,既然 curl_multi 的管道复用,会尽可能的使用已有连接,那么对于未超过限制的请求,每次创建一个 curl_multi_init 和 curl_init,并打开 curl_multi 的管道复用,对于超过限制的请求,就使用已存在的 curl_multi_init 再次发送一个新的 curl_init.至此,已经基本可以使用 curl_multi 实现我之前用 tcp 模拟时实现的全部功能.唯一的问题和之前测试结果一样,多个 curl_multi_init 实例同时存在同时执行时效率较差,比使用 tcp 模拟或使用全局唯一的 curl_multi_init 效率下降非常多.
@sxbxjhwm #39 仅供参考.

@sxbxjhwm 主要是使我的工具类可以在项目内尽量通用，尽量复用现有逻辑。而不是将每个地方都做很多修改。

@sxbxjhwm #35 测试时还发现一个有意思的事情,在设置了启用管道时,我的倾向是期望在没有超过并发数之前尽可能使用新的连接,虽然建连也有一点损耗但是由于获取数据比较慢,所以也会比复用已有连接更快.但是 curl 库的默认方式似乎是优先尽可能复用已有的链接,直到一条连接上传输的请求超过阈值之后,才会去开一个新的连接.鉴于这个倾向的不同,所以即使我的 curl 版本符合这个区间,也不是我期望的效果.

@sxbxjhwm #35 找到三个参数,按照 libcurl 文档的描述,搭配使用可以实现通过 http1.1 管道来控制并发的效果.CURLMOPT_PIPELINING,CURLMOPT_MAX_HOST_CONNECTIONS,CURLMOPT_MAX_PIPELINE_LENGTH.但是这三个参数如果搭配使用对 curl 的版本有着严格的要求,需要大于等于 7.30 小于 7.62.我这边版本和线上一致不符合这个区间.所以没有测试出全部效果.不过设置 CURLMOPT_PIPELINING 为 1 来启用管道是可以实现的.