向量检索选型：我们算了一笔账，最后没上专业向量库 十月份做知识库检索重构，团队里争论要不要上 Milvus 或者 Qdrant。我们已经在用 PostgreSQL（存业务数据 + 元数据），pgvector 扩展是顺手的选择，但大家都担心性能不行。 最后我们做了完整的压测和成本核算，结论是继续用 p
知识库从 5 万文档涨到 320 万，第一版设计撑不住了 我们公司的知识库最早是给客服用的，5 万篇 FAQ，存储设计得很随意：一张 kb_doc 表，切片直接以 JSON 数组的形式塞在 chunks 字段里，向量存在 Milvus 里，两边用 doc_id 关联。 这个设计在 5 万篇的时候完全
我们的交易系统原来用定时任务把 MySQL 数据同步到数据仓库，每 5 分钟跑一次，分析师看到的总是"5 分钟前的旧账"。业务方要实时大屏，等不了。于是用 Kafka 搭了一条 CDC 驱动的实时数据管道，端到端延迟从 5 分钟压到 800 毫秒。 CDC 接入：让数据库自己说变化 定时拉全量太低效
背景：我们一套跑了五年的订单分析系统，主库是 MySQL 8.0，平时扛交易，月底还要跑 T+1 报表。一次月底大查询把从库 CPU 打到 100%，复制延迟一度飙到 47 秒，运营看板直接瘫痪。那一刻我意识到，把 OLTP 和重分析塞在同一套实例里，迟早出事。 为什么盯上 TiDB 当时评估了三个
告警：凌晨三点的慢查询邮件 四月某天早上，运维把一封告警邮件转给我：「日志检索接口 P95 超过 8 秒，ES 集群 CPU 打满」。我们的应用日志一直存在 Elasticsearch 里，单日写入约 30 亿条，随着业务量涨，ES 的堆内存和查询延迟都快撑不住了。老板提了个方向：能不能把明细日志搬
