我们正在评估NEsper。我们的重点是在企业环境中监视数据质量。在一个应用程序中,我们将记录很多字段上的所有更改-例如,以“顺序”记录。所以我们有类似
的字段....以及更多其他字段。您可以想象,日志文件将越来越大。
由于数据是由不同的客户发送并导入到应用程序中的,因此我们想分析将多少个字段从“无值”更新为“一个值”(仅作为示例)。>
我尝试仅使用字段构建测试用例 - 订单参考 -栏位名称 -字段值
对于我的测试用例,我添加了两个带有上下文信息的语句。第一个应该只计算每个订单的总体变化:
epService.EPAdministrator.CreateEPL("create context RefContext partition by Ref from LogEvent");
var userChanges = epService.EPAdministrator.CreateEPL("context RefContext select count(*) as x, context.key1 as Ref from LogEvent");
第二条语句应将更新从“无值”计数为“一个值”:
epService.EPAdministrator.CreateEPL("create context FieldAndRefContext partition by Ref,Fieldname from LogEvent");
var countOfDataInput = epService.EPAdministrator.CreateEPL("context FieldAndRefContext SELECT context.key1 as Ref, context.key2 as Fieldname,count(*) as x from pattern[every (a=LogEvent(Value = '') -> b=LogEvent(Value != ''))]");
要读取测试日志文件,请使用csvInputAdapter:
CSVInputAdapterSpec csvSpec = new CSVInputAdapterSpec(ais, "LogEvent");
csvInputAdapter = new CSVInputAdapter(epService.Container, epService, csvSpec);
csvInputAdapter.Start();
我不想使用更新侦听器,因为我只对所有事件的结果感兴趣(可能这是不可能的,这是我的失败)。
因此,在读取csv(csvInputAdapter.Start()返回)之后,我读取了所有事件,这些事件存储在语句NewEvents-Stream中。
在CSV文件中使用10个条目,一切正常。使用一百万行需要很长时间。我尝试不使用EPL声明(因此仅导入CSV)-大约花费了5秒钟。对于第一个语句(不是复杂的模式语句),我总是在20分钟后停止-因此我不确定会花费多长时间。
然后,我更改了第一条语句的EPL:我引入了group by而不是上下文。
select Ref,count(*) as x from LogEvent group by Ref
现在真的非常快-但是在CSVInputAdapter返回之后,NewEvents流中没有任何结果...
我的问题:
是我要使用NEsper的方式是受支持的用例,还是这是我失败的根本原因?
如果这是一个有效的用例:我的错误在哪里?如何以高效的方式获得想要的结果?
为什么在使用“分组依据”而不是“上下文”时我的EPL语句中没有NewEvent?
非常感谢您的帮助
霍尔格
答案 0 :(得分:1)
到1),是
对于2)这是有效的,您的EPL设计可能效率不高。您可能想通过使用过滤器索引和索引条目来了解模式的工作原理,这些索引创建起来成本较高,但丢弃不必要事件的速度非常快。 读: http://esper.espertech.com/release-7.1.0/esper-reference/html_single/index.html#processingmodel_indexes_filterindexes以及 http://esper.espertech.com/release-7.1.0/esper-reference/html_single/index.html#pattern-walkthrough 尝试“上一个”。分别衡量每个语句的性能。 另外,我不认为CSV适配器已针对处理大文件进行了优化。我认为CSV可能无法流式传输。
要3)检查您的代码?请勿将CSV文件用于大型内容。确保已连接侦听器。