总结下来，传统降噪算法只能处理稳态噪声，非稳态突发噪声处理能力弱，但数据驱动类的算法稳态噪声及瞬时 非稳态噪声均可处理。在性能消耗上，传统算法是比较小的，数据驱动类算法会相对耗一些，为此，我们设计了小模型使用简单结构 以更好的发挥MNN的优化效果的策略为主，在实用性上，传统算法经验参数多，场景适应性差，而数据驱动类算法，场景适应性是比较好。
对于 lucene 而言，其使用的是堆外内存
• Page Cache：lucene 读写段文件时会依赖操作系统的 page cache 缓存，如果多次查询都涉及到读取某个段文件的同一部分内容，就直接使用 page cache 进行读取，无需再从磁盘获取数据。page cahce 由操作系统管理，淘汰策略类似LRU。
ES 的一个分片就是一个 lucene 实例，实例由一个或多个 segment 构成。lucene 每次 flush 操作都会对一个 segment 进行持久化操作（会将内存中的 segment 写到文件，但不执行 FileChannel::force，即存在数据丢失的可能），其内容为期间有变更的文档，同一个段涉及到的文件前缀都是相同的 generation（36进制的一个数字，每次 flush 会加一），每个段可能涉及到的文件如下表所示。
lucene 文件功能说明备注
• tip 和 fdx 类型的文件在 ES 7.3 以前都是常驻 JVM 堆内存的，ES 7.3 之后将 fst 移至堆外，交由系统的 page cache 管理，若某个索引的 fst cache 不幸被置换出去，理论上会给搜索带来较大的抖动，对于使用 7.x 版本的用户，建议多关注 tip 文件的 cache 情况；
上述文件中占用存储空间较多的是 tim、doc、fdt、dvd 以及 cfs 这几类数据文件，除 cfs 以外的几类文件加载情况和查询条件密切相关；
range 查询即可能使用 dim BKD 索引，也可能使用 dvd DocValue，其背后是一个基于代价的优化器处理逻辑 ，如有兴趣，细节逻辑可自行参考 IndexOrDocValuesQuery。
lucene 文件的读取方式将影响磁盘 IO 调用，以及 page cache 中缓存的内容，常用的主要是如下两种类型：
• niofs：通过 NIO 的方式读取文件内容，基于 Java 提供的 FileChannel::read 方法读取数据，支持多线程读取同一个文件，按需读取，需要注意的是 niofs 模式下读取到的内容在系统层面也会进 page cache。
mmapfs：通过mmap读写文件，会比常规文件读写方式减少一次内存拷贝的过程，因此对于命中 page cache 的文件读取会非常快，该模式即零拷贝的一种实现（可减少内核态和用户态间的数据拷贝）。
不过 mmap 系统调用在内核层面会产生预读，对于 .fdt 这类文件，预读读到的内容后续命中的概率极低，还容易引起page cache的争用，进而产生频繁的缺页中断
异常查询请求定位
有时集群的整体响应突然变慢，却不知道是由哪个索引、或哪个查询引起的？
