Milvus与Qdrant双雄对决：电商语义检索场景实测选型
在商品标题向量检索场景下，我用真实数据对比Milvus 2.4.1与Qdrant 1.9.0。部署上Milvus用Helm三节点集群，Qdrant用Docker单节点+WAL。实测300万条768维向量，Qdrant纯查询P99 8ms优于Milvus的15ms，但Milvus在混合过滤（标签+向量）场景下召回率稳定在0.93，Qdrant降至0.81。资源占用上Qdrant内存峰值低37%，但M
猞猁喜欢开源日记
Lv.1擅长围观技术变化，也愿意亲手验证。关注开源技术，主要分享开发效率提升、性能优化和日常踩坑；更关注能够真正落地的方法。技术会变化，解决问题的方法值得长期积累。
4文章
0粉丝
0关注
1获赞
最新文章
asyncio重构Flask接口，QPS从187到1520的并发改造实录
在一次电商订单导出服务中，我遇到CPU空闲但接口超时的诡异场景。通过cProfile定位到90%耗时阻塞在第三方API调用上，使用asyncio+httpx重写核心链路后，单机QPS从187提升至1520（8.1倍），P99延迟从2.3s降至340ms。本文将完整记录这次改造过程，包括asyncio.Semaphore限流的正确姿势、与Flask同步生态的集成方案，以及协程池+线程池混合调度的性能
React 19与Vue 3.5下从Context到Zustand/Pinia的迁移实录与性能对比
接手一个维护了两年的中后台项目，组件树深度超过8层，Context频繁触发全树渲染，导致列表页输入卡顿（实测输入延迟从180ms飙升至600ms）。本文记录从React Context（或Vue Provide/Inject）迁移至Zustand 4.5（或Pinia 2.1）的完整过程，包含方案选型对比、分步迁移策略（按模块灰度切换）、核心代码改造示例，以及迁移前后的Performance面板数
React 19与Vue 3.5跨框架状态管理迁移：从Prop Drilling到Pinia/Zustand的工程化改造
在维护一个拥有87个路由页面、月活30万的中后台项目时，我们遇到了组件树层级超过12层的状态传递地狱。本文记录了从原生Context/Props迁移到Zustand v4.5.5（React 19.0.0）与Pinia v2.2.6（Vue 3.5.12）的全过程。通过具体对比三种方案的渲染性能（Context导致重渲染次数增加340%，迁移后FCP提升21.7%），并给出可复制的迁移步骤与性能优