NEventStore MongoDB持久化未自动压缩数据的问题咨询

背景 #

我正在使用C#、.NET Core及NEventStore（版本9.0.1）评估其原生持久化方案，发现MongoDB持久化时负载未被压缩，但SQL持久化能正常实现负载压缩。

事件存储初始化代码 #

private IStoreEvents CreateEventStore(string connectionString) 
{ 
    var store = Wireup.Init() 
                    .UsingMongoPersistence(connectionString,  
                         new NEventStore.Serialization.DocumentObjectSerializer()) 
                    .InitializeStorageEngine() 
                    .UsingBsonSerialization() 
                    .Compress() 
                    .HookIntoPipelineUsing() 
                    .Build(); 
    return store; 
}

事件存储代码 #

public async Task AddMessageTostore(Command command) 
{ 
    using (var stream = _eventStore.CreateStream(command.Id)) 
         { 
                stream.Add(new EventMessage { Body = command }); 
                stream.CommitChanges(Guid.NewGuid()); 
         }
} 

临时解决方案 #

已通过实现IPipelineHook中的PreCommit(CommitAttempt attempt)和Select方法，结合Gzip压缩逻辑，实现了MongoDB中事件的压缩。

咨询问题 #

1. 是否存在我遗漏的配置或选项，能通过链式调用.Compress()的方式实现MongoDB持久化时的事件压缩？
2. 上述临时解决方案是否合理，是否会带来性能开销？

解答 #

问题1 #

NEventStore 9.0.1的.Compress()扩展方法仅对SQL持久化实现生效，MongoDB持久化的原生实现并未对接这个压缩管道。从框架源码逻辑来看，Compress()是注册了针对SQL存储的专属压缩Pipeline Hook，MongoDB的持久化组件没有处理该配置的逻辑，因此你当前的链式调用不会对MongoDB存储产生压缩效果，不存在可通过原生配置启用的遗漏选项。

问题2 #

你的临时解决方案是合理的，这完全符合NEventStore设计Pipeline Hook的核心定位——允许开发者扩展自定义处理逻辑。
关于性能开销：压缩和解压操作本身会带来一定的CPU消耗，但需要结合实际场景判断：

• 如果你的事件Payload较大（比如超过几KB），压缩后减少的磁盘存储占用、MongoDB读写IO开销会远大于CPU的额外消耗，整体性能反而会提升；
• 如果事件Payload极小，CPU的额外消耗可能会成为可感知的性能成本。
  建议针对自身业务的事件大小做简单压测，对比压缩前后的写入/读取耗时、MongoDB存储占用量，再确定是否长期使用该方案。另外，若业务场景允许，可采用异步压缩逻辑，避免阻塞主线程。

内容的提问来源于stack exchange，提问作者Jose Francis