OpenSearch 与 ClickHouse/Doris 接入边界：何时从搜索转向分析
都有 SQL 和聚合能力，搜索引擎与分析数据库为什么不能互相替代？ 这不是某个 DSL 参数没调好，而是数据身份、索引结构、分布式执行与资源治理没有被放进同一张设计图。选型依据是主查询形状、更新模型、延迟目标和数据治理，而不是产品功能清单。全文相关度属于搜索，宽表扫描与大规模聚合属于分析，强事务点查仍属于事实数据库。
先守住搜索系统的三个事实
第二，可搜索不等于已提交。OpenSearch/Elasticsearch 依赖倒排索引、doc values 与 shard fan-out；ClickHouse 以排序键组织 part 和 granule，用稀疏主索引跳过范围；Doris 的 Key Model、分区分桶、Rollup 与倒排索引组合服务不同明细和聚合形状。 因而需要分别观测“事实源已提交”“投影事件已消费”“索引已接收”“refresh 后可见”四个水位。只报一个写入成功率，不能证明用户已经能搜到新状态。
一条记录怎样跨过事实、投影和查询边界
建立查询分类表：全文、条件筛选、点查、明细扫描、维度聚合、去重更新、实时性。双引擎架构通过同一事实事件投影，分别维护水位、版本和核对账本，不在请求链上同步双写。
用搜索承载无限高基数报表会挤占在线检索；用分析库实现逐字相关度会制造复杂索引与不可控延迟；把任一派生引擎当唯一事实源，会让重建、去重和审计失去锚点。
这类错误的危险之处在于，正常样本往往完全正确。只有在动态字段持续增长、事件乱序、深页访问、某个 shard 变慢或迁移追平时，隐藏的复杂度才突然显现。架构验证因此必须制造反向实验，而不是只跑 happy path。
运行链不是黑盒：从入口到 Segment
OpenSearch/Elasticsearch 依赖倒排索引、doc values 与 shard fan-out；ClickHouse 以排序键组织 part 和 granule，用稀疏主索引跳过范围；Doris 的 Key Model、分区分桶、Rollup 与倒排索引组合服务不同明细和聚合形状。
[ Disk_{peak} ge Source imes IndexRatio imes (Primary+Replica) imes GenerationOverlap + MergeReserve ]
查询放大要在请求进入集群之前计算
[ CandidateAmplification = rac{Shards imes (from + size)}{size} ]
两层失败必须分开处理
可运行模型一：把放大或局部失败变成数字
javac --release 17 -Xlint:all -Werror EngineFitDemo.java
java EngineFitDemo预期输出：
queries=6 fullText=2 pointLookup=1 aggregations=3 routedSearch=2 routedDatabase=1 routedAnalytics=3 misrouted=0可运行模型二：证明乱序、重放或切换仍收敛
javac --release 17 -Xlint:all -Werror SparseIndexDemo.java
java SparseIndexDemo预期输出：
rows=1000000 granule=8192 marks=123 selectedMarks=4 rowsReadUpperBound=32768 skipRatio=0.967 bounded=true第二个模型故意制造反向条件：重复、乱序、并发插入、漏投影或引擎误路由。只要 invariant 依赖“事件总会顺序到达”或“迁移期间不会写入”，它就不是工程约束。可交付的机制必须在反向输入下拒绝旧版本、保持稳定视图、补齐差异或明确降级。
新鲜度不是一个平均延迟
观测必须能回答“哪个边界坏了”
安全、删除与审计不能交给查询约定
脚本查询、正则、通配符、runtime field 和高亮都属于受控能力。它们应按接口白名单开放，设置超时、复杂度和并发预算。让外部调用者提交任意 Query DSL，相当于把集群 CPU、heap 与数据访问边界一起交给客户端。
Schema 演进必须以 generation 为单位
回滚也不能只把 alias 指回旧索引。如果切换后新写入只进入新 generation，旧索引已经落后。可回滚方案要么保持旧代增量同步，要么能根据切换水位重放缺口。所谓“旧索引还在”不等于“旧索引可安全接流”。
架构决策记录应该留下什么
一份可复审的记录至少包含：主查询形状、数据事实源、文档身份、版本规则、字段职责矩阵、分片与 routing 依据、峰值容量测量、查询预算、失败分类、降级语义、迁移状态机、回滚窗口和数据删除路径。每个数字标明样本、压测方法或监控来源。
选型依据是主查询形状、更新模型、延迟目标和数据治理，而不是产品功能清单。全文相关度属于搜索，宽表扫描与大规模聚合属于分析，强事务点查仍属于事实数据库。 对这个主题，最终必须守住的条件是：每类查询进入与其数据结构匹配的引擎，所有派生结果都能回到同一事实版本核对。如果团队无法通过运行模型、指标和核对账本证明它，就还没有完成架构设计。
查询限制覆盖 shard fan-out、深分页、bucket、脚本、超时、并发和响应体。所有查询、聚合、suggest、导出和缓存路径执行同一权限约束。指标能区分事实水位、消费水位、索引接收与 refresh 可见水位。
新旧索引以版本、缺失主键和摘要核对，不只比较文档数量。降级响应标明来源与新鲜度，不把派生结果冒充权威事实。旧 generation 保留到回滚窗口结束，删除与隐私擦除覆盖全部副本。
两个 Java 17 模型通过严格编译并产生与文中一致的输出。
以下资料用于核对 API 语义和引擎数据结构；架构结论仍需结合实际版本、数据分布与压测结果验证：
OpenSearch Index data。ClickHouse sparse primary indexes。Apache Doris Data Model