问题一：SLS Scan为什么选择基于event_time模型存储？
SLS Scan为什么选择基于event_time模型存储？
参考回答：
SLS Scan选择基于event_time模型存储，是因为在搜索、分析场景中按业务时间处理是天然的需求。特别是在日志到达服务端迟到的场景下，通过receive_time模型获取完整结果会引入更大的代价。SLS Scan通过索引下推、协程化IO、分页处理等技术，使用户在event_time模型下享受到便利性的同时，也在性能表现上取得平衡。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/655447
问题二：SLS Scan的语法是如何定义的？
SLS Scan的语法是如何定义的？
参考回答：
SLS Scan的语法定义为两段式：
{Index Query} | {Scan Query: where <bool_expression>}，
其中管道符后是SQL语法中的where子句，用于定义扫描查询的条件。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/655448
问题三：SLS Scan的三段式工作机制是什么？
SLS Scan的三段式工作机制是什么？
参考回答：
SLS Scan设计为三段式工作机制，包括：
L1按时间做过滤，L2按业务字段做过滤，L3在索引命中的结果集上做硬扫描过滤。
L1：按时间做过滤
时间是天然的日志主键，例如存储周期 30 天 100 TB 的数据，查询时间窗口选择为最近 6 小时，则数据量缩减到 1 TB。且时间过滤只需要根据索引（时间字段引入的膨胀比低到可忽略）、meta skip 就可以快速完成。
L2：按业务字段做过滤
这里所说的业务字段可理解为 Loki 的 Label 概念，但更为灵活，可以在日志到达 SLS 之后再自由选择。一般是选择可缩小下一步搜索范围或是被高频访问的字段，例如 K8s 日志可以将 namespace、image、node hostname、log path 设置索引。能匹配业务查询需求的字段索引，将大大地降低需要硬扫描的数据量，降低扫描费用和响应延迟。
L3：硬扫描做过滤
在索引命中的结果集上做最后的硬计算，SLS Scan 用 C++ 实现避免性能表现在数据规模上涨后衰减（Loki 受 GC 影响），部分高频算子做向量化加速。另外，SLS Scan 使用一个大的计算池（几百台 x86 多核服务器）来爆发算力，计算的并发度按照 Logstore（日志库）的 Shard（存储分片）数水平扩展。
这种机制通过逐步缩小搜索范围，提高查询效率和响应速度。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/655449
问题四：SLS Scan在UI上有哪些新特性？
SLS Scan在UI上有哪些新特性？
参考回答：
SLS Scan在UI上的新特性包括Scan模式开关、Scan翻页与快进、以及Scan查询结果页。这些特性提供了更加便捷和直观的日志查询体验，支持用户高效地进行日志搜索和分析。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/655450
问题五：SLS Scan的搜索能力相较于经典搜索语句有哪些扩展？
SLS Scan的搜索能力相较于经典搜索语句有哪些扩展？
参考回答：
SLS Scan的搜索能力相较于经典搜索语句扩展了JSON字段提取、字符串函数和正则函数、模糊匹配、类型转换等多种算子支持。这些扩展功能使得Scan模式能够应对更加复杂和多样化的日志查询场景。
关于本问题的更多回答可点击原文查看：
