"使用的版本为 23 年初的版本 使用 es_open, 及 es_get 等方法取数据，对比 httpfile 的方式， 性能慢 5 倍。 使用 es_get 来取数， 有明显的卡顿， htt .."
使用的版本为 23 年初的版本使用 es_open, 及 es_get 等方法取数据，对比 httpfile 的方式， 性能慢 5 倍。使用 es_get 来取数， 有明显的卡顿， httpfile 基本是毫秒级别的， 就是加上 json 的处理也快很多， 版本的问题吗？
和版本有关的可能性不大，当然试试新版本也可以。
ES 这类外部库，基本就没什么机会用过（很少有这种数据源），只是按文档写出来测试基本正确就完了。httpfile 被用得相对多很多了，如果有问题会及时被发现并完善。
可以提供一些详细性的测试用例，我们有空闲时测试一下找找原因。或者直接看那个外部库的源码也可以，是不是哪里写得不太合适。
感谢及时回复。客户的关系型数据库， sql 跑不动， 需要几千万的数据取出计算， 换数据库成本太大，客户也有要求，不能随便引入数据库， es 原本客户就有， 就选了 es， 验证下来性能还可以， 原本想用集算器文件的方式， 通过读文件的方式来加速， 不过文件怎么分， 怎么检索都不太熟， 而且预估管理工作较大，时间比较紧，就放弃了。
再次感谢。在这里也问一下， 在使用序表 group 时， 遇到的问题：1：几个序表合并后（结构相同）， 使用 group（字段， sum（. 金额））， 行数是对的， 金额 sum 后值不对;2: 还是 group（字段， sum（. 金额））, 后行数也是对的， 金额始终为第一批的值， 也是 sum 的值不对；改为 groups 后就正确了。我记的看过您回复的一篇关于 group 的内容， 是不是内存表， 就是不用使用 group 了？
group 中的聚合是先分组再聚合，相当于 group.new，在 new 的时候要写成 ~.sum，这是为了写出更复杂的聚合运算（不能简单用 sum/count 这些写出来）groups 是同时聚合，不用写 ~，但只能支持几种固定的可以边遍历边聚合的运算。
内外存关系是这样：原则上外存上只能用 groups，但如果对分组键有序时也可以有 group
文件存储的管理运维成本通常是远远低于数据库（以及 ES/HADOOP 之类的大数据方案），有元数据约束的体系管理才麻烦。
SPL 高性能思路与其它体系不一样，自己摸索上手是不太容易的。通常需要支付些成本由官方提供一些咨询服务，带过一两个案子后自己就会了。
和版本有关的可能性不大，当然试试新版本也可以。
ES 这类外部库，基本就没什么机会用过（很少有这种数据源），只是按文档写出来测试基本正确就完了。
httpfile 被用得相对多很多了，如果有问题会及时被发现并完善。
可以提供一些详细性的测试用例，我们有空闲时测试一下找找原因。或者直接看那个外部库的源码也可以，是不是哪里写得不太合适。
感谢及时回复。
客户的关系型数据库， sql 跑不动， 需要几千万的数据取出计算， 换数据库成本太大，客户也有要求，不能随便引入数据库， es 原本客户就有， 就选了 es， 验证下来性能还可以， 原本想用集算器文件的方式， 通过读文件的方式来加速， 不过文件怎么分， 怎么检索都不太熟， 而且预估管理工作较大，时间比较紧，就放弃了。
再次感谢。
在这里也问一下， 在使用序表 group 时， 遇到的问题：
1：几个序表合并后（结构相同）， 使用 group（字段， sum（. 金额））， 行数是对的， 金额 sum 后值不对;
2: 还是 group（字段， sum（. 金额））, 后行数也是对的， 金额始终为第一批的值， 也是 sum 的值不对；
改为 groups 后就正确了。
我记的看过您回复的一篇关于 group 的内容， 是不是内存表， 就是不用使用 group 了？
group 中的聚合是先分组再聚合，相当于 group.new，在 new 的时候要写成 ~.sum，这是为了写出更复杂的聚合运算（不能简单用 sum/count 这些写出来）
groups 是同时聚合，不用写 ~，但只能支持几种固定的可以边遍历边聚合的运算。
内外存关系是这样：原则上外存上只能用 groups，但如果对分组键有序时也可以有 group
文件存储的管理运维成本通常是远远低于数据库（以及 ES/HADOOP 之类的大数据方案），有元数据约束的体系管理才麻烦。
SPL 高性能思路与其它体系不一样，自己摸索上手是不太容易的。通常需要支付些成本由官方提供一些咨询服务，带过一两个案子后自己就会了。