如果只看 PoC，数据库选型其实不算特别难。
准备一批数据，跑几组 SQL，看查询延迟、写入吞吐和资源占用，结果很快就能出来。
真正难的是系统上线一年、两年以后。
业务表越来越多，SQL 越来越复杂，实时数据开始更新，数据湖规模不断扩大，日志量也在增长。这个时候再回头看，最初 PoC 里的那几组性能数据，往往只是整个使用成本的一小部分。
所以现在再看 OLAP 数据库，我会比以前少关注“峰值性能”，多看一些和实际使用周期有关的问题。
Doris 和 ClickHouse 是两个比较典型的例子。
两者性能都已经经过大量生产环境验证，真正影响选型的，很多时候是业务负载与系统设计之间是否匹配。
先看数据是什么，再看数据库
这是我觉得最容易被忽略的一步。
很多团队选数据库时，第一件事是列功能。
支持不支持 Join？
有没有物化视图？
能不能查 Iceberg？
支持不支持向量检索？
但实际使用中，数据形态往往比功能列表更重要。
例如日志、埋点、行为事件，大多数数据写入以后不会再改。
这类 append-only 数据天然适合大规模列式扫描和聚合，ClickHouse 在这些负载上有非常成熟的实践。
业务数据则不同。
订单会更新，库存会变化，用户画像不断刷新。
如果这类数据占比较高，就需要重点评估主键模型、更新机制、CDC 接入以及更新对查询的影响。
Doris 的 Unique Key 和部分列更新在这类场景中比较实用。
所以选型时我通常会先问：
数据是以追加为主，还是更新很多？
这一点如果判断错了，后面常常需要用额外的数据链路和建模方式弥补。
再看 SQL 是怎么写的
第二个问题是查询模式。
有的系统虽然数据量很大，但 SQL 很简单。
按时间过滤、按照几个维度聚合，这类负载主要考验扫描和计算性能。
还有一些系统数据量未必更大，但查询非常复杂。
十几张表 Join，嵌套子查询，窗口函数，多层聚合，临时查询很多。
到了这一步，优化器就很重要。
实际使用中，一个好的优化器能省掉很多人工工作。
因为生产环境里不可能要求每一个 BI 用户、分析师或者业务开发都理解底层 Join 策略。
Doris 在复杂 SQL、Join Reorder、Runtime Filter 等方向的投入比较多。
ClickHouse 近几年也一直在加强查询优化器和 Join 能力。
所以如果业务大量依赖复杂关联，我建议测试时不要只跑标准 Benchmark。
最好直接拿真实 SQL。
尤其要测试：
表数量多的时候是否稳定；
数据量变化以后执行计划会不会明显变化；
不同过滤条件下性能是否容易出现大幅波动。
真实 SQL 往往比 Benchmark 更能暴露问题。
实时场景一定要把“更新”单独测出来
很多实时数仓 PoC 会重点测写入速度。
Kafka 每秒可以导入多少条数据，延迟是多少。
这些当然重要。
但生产里真正麻烦的经常是数据更新。
例如订单状态变化、用户标签刷新、库存更新。
如果业务里大量存在这种数据，就要测试的不只是 Insert，还包括 Update、Delete、CDC 和部分字段更新。
另外一个容易忽略的问题是：
写入和查询同时发生时，系统表现怎么样。
只测纯写入或者纯查询，通常都很好看。
生产环境却很少这么理想。
Doris 的 Unique Key、Merge-on-Write、Group Commit 等能力，主要就是针对这类实时写入和更新负载。
如果业务是纯日志，这些能力未必重要。
如果做实时业务分析，就值得重点看。
湖仓能力不要只看兼容列表
现在大部分数据库都会写自己支持 Hive、Iceberg、Hudi 或 Paimon。
单看列表其实区别不大。
实际用的时候，我更关心三个问题。
第一，外部表查询性能怎么样。
第二，复杂 SQL 能不能和内部表一起稳定执行。
第三，能不能真正减少 ETL。
第三点最重要。
因为湖仓最大的成本通常不是“能不能连上”，而是连上之后是否仍然需要把大量数据搬进数据库才能正常使用。
如果最后依然需要复制一份数据，那么湖仓更多只是增加了一个访问入口。
Doris 的 Catalog 体系比较适合用来做这类统一查询。
但具体是否适合，还是应该拿企业自己的 Iceberg 或 Hive 数据测试。
湖上的文件大小、分区方式、元数据规模不同，最终效果差异可能很大。
日志系统要算存储账
做日志平台时，我现在会很早开始算存储成本。
原因很简单：
日志增长太快。
一天 10TB 和一天 100TB，架构逻辑可能完全不是一回事。
如果数据保留 90 天，再加三副本、索引和预留空间，最后的机器规模会非常大。
ClickHouse 在日志分析领域已经有很成熟的生态和经验，现在 ClickStack 也在继续扩展完整的可观测能力。
Doris 这几年也在补日志方向，包括全文检索、倒排索引、VARIANT 和 OpenTelemetry。
如果评估 Doris 做日志，我觉得重点可以放在两个方面。
一个是全文检索和 SQL 聚合混合使用时的性能。
另一个是总体成本。
日志和业务数据放在同一个分析体系里以后，可以少维护一些数据同步和独立分析系统；冷数据再下沉到对象存储，也有机会降低长期存储成本。
不过这种账一定要自己算。
不同公司的日志结构、索引字段、查询频率和保留周期差别很大，厂商给出的压缩比或者成本数据只能作为参考。
真正值得比较的是：
按照自己的数据量跑一年，两套架构分别需要多少机器、多少存储和多少人维护。
不要低估运维成本
数据库上线以后，会遇到很多 PoC 阶段不存在的问题。
扩容。
版本升级。
磁盘故障。
数据倾斜。
Compaction。
权限管理。
资源隔离。
备份恢复。
这些事情单独看都不复杂，但持续几年以后，会决定一套系统到底好不好维护。
所以企业选型时，我通常建议把 Day 2 Operation 单独拿出来评估。
例如：
增加节点是否复杂；
升级是否需要较长停机窗口；
问题发生以后有没有足够的监控和诊断能力；
团队内部有没有人熟悉这套技术；
遇到问题以后，社区和商业支持是否容易获得。
国内企业还需要考虑一个很现实的问题：服务响应和生态适配。
Apache Doris 是开源项目，可以完全自建。
SelectDB 由 Doris 原创核心团队创立，在开源 Doris 之外提供云服务和企业产品。
如果团队有足够的数据库工程能力，自建通常更灵活。
如果团队希望减少运维投入，商业化服务也可以作为一种选择。
这里没有固定答案，主要看企业更愿意投入机器成本还是人力成本。
AI 能力我会看，但不会放得太靠前
现在数据库产品基本都在谈 AI。
向量检索、AI Function、MCP、Agent、RAG。
这些方向确实值得关注，但如果做企业选型，我一般不会因为“支持 AI”就直接提高优先级。
原因是 AI 场景变化还很快。
真正值得看的，是这些能力能不能和原有数据体系结合。
例如一个 Agent 查询业务数据时，往往不是只做向量检索。
它可能先按照地区、时间、用户类型做 SQL 过滤，再做语义搜索，最后还要关联订单和商品信息。
这时候结构化查询、全文检索和向量检索能否组合使用，比单独支持一个 Vector Index 更重要。
Doris 现在把 Vector Search、全文检索、AI Functions 和 MCP 放在同一个引擎中，这条路线比较清晰。
SelectDB 进一步做 Litefuse 这类 Agent Observability 产品，也是把数据库能力往 Agent 工具链延伸。
但对于大多数企业，我还是建议先回答一个更基本的问题：
现有的实时数仓、日志和湖仓是否已经稳定。
基础数据体系没解决好，AI 往往只会增加一层复杂度。
最后再看性能
不是说性能不重要。
恰恰相反，没有性能，前面的讨论都没有意义。
只是性能最好放在真实负载里看。
我现在比较倾向于把测试分成几类：
典型单表扫描；
复杂 Join；
持续写入；
更新数据；
高并发 BI；
湖上数据查询；
日志全文检索；
长时间混合负载。
最后一类尤其重要。
很多系统短时间 Benchmark 很漂亮，但连续跑几天以后，Compaction、后台任务、资源竞争开始出现，性能表现可能完全不同。
所以企业选 OLAP 数据库，最好不要只做“跑分测试”，而是尽量模拟真实生产。
Doris 和 ClickHouse 怎么放进这个框架里
如果业务主要是大规模日志、事件、埋点和明细数据，数据以追加为主，查询又偏扫描和聚合，ClickHouse 依然是很成熟的方案。
如果场景中复杂 Join、实时更新、高并发 BI、湖仓查询占比越来越高，同时希望把日志分析、全文检索等能力放在一个体系里，Doris 会更值得重点测试。
但我不会仅凭这些描述直接做结论。
数据库选型最终还是应该回到自己的数据、SQL 和团队。
因为同一个数据库，在两家公司可能完全是两种使用体验。
一家公司觉得非常简单，另一家公司可能每天都在处理不适合它的数据模型。
所以如果从实际使用出发，我认为比较有效的选型方式不是问：
哪个数据库最好？
而是把问题拆得更具体：
我的数据是什么形态？ 查询到底有多复杂？ 数据会不会频繁更新？ 有多少数据需要跨系统搬迁？ 日志准备保存多久？ 这套系统谁来维护？ 两三年以后，还会增加哪些负载？
这些问题回答清楚以后，数据库选型通常也就没有那么复杂了。
