MyScaleDB

一款让向量搜索变得"平平无奇"的数据库——MyScaleDB 深度解读

痛点故事：为什么 AI 工程师需要一个"全能型"数据库？

当你正在构建一个 RAG（检索增强生成）系统时，往往需要同时维护多个数据基础设施：PostgreSQL 存结构化业务数据、ElasticSearch 做全文检索、Pinecone 或 Milvus 处理向量相似度搜索、Redis 缓存热点数据。每增加一个系统，就意味着多一份运维负担、多一层数据同步延迟、多一组 API 学习成本。更痛苦的是，当用户搜索"找一款适合程序员的中档价位笔记本电脑"时，关键词"笔记本电脑"需要 ElasticSearch 的倒排索引精准匹配，而"适合程序员"这个语义意图则需要向量数据库捕捉——你需要写胶水代码把两个系统的结果拼接起来，权重如何调、排序如何融合，全是坑。

MyScaleDB 的出现，就是为了终结这种"数据巴别塔"。它基于 ClickHouse 的列式分析引擎，把向量索引、全文搜索、SQL 查询三种能力熔铸进同一套 SQL 接口——你不需要学任何新 API，只需要会写 SQL，就能完成从元数据过滤到向量相似度排序的全流程查询。

项目起源：ClickHouse 为什么是最佳基座？

选择 ClickHouse 作为向量数据库的底座，是 MyScaleDB 团队经过深思熟虑的技术决策。向量搜索中的核心操作——过滤搜索（Filtered Search）——要求先对标量字段（如分类、时间戳）做条件筛选，再对剩余数据做向量最近邻检索。列式存储配合预过滤机制，是保证这种"先筛后搜"管道高效执行的关键，而这恰恰是 ClickHouse 架构最擅长的领域。相比之下，行式存储的 PostgreSQL（pgvector）和 Elasticsearch 在处理高维向量过滤时，性能损耗明显。

MyScaleDB 团队并非闭门造车。项目中大量通用 SQL 处理能力（如并行查询优化、物化视图增强）已反向贡献给 ClickHouse 开源社区（GitHub Issues #37893、#38048 等），形成了良好的技术回流循环。

核心功能：从"增删改查"到"语义理解"

向量搜索是 MyScaleDB 的核心能力。用户通过 ALTER TABLE ADD VECTOR INDEX 语法在已有 SQL 表上追加向量索引字段，支持 SCANN（Scaling-friendly Causal aNN）和 HNSW（Hierarchical Navigable Small World）两种主流 ANN 算法，距离度量支持余弦相似度和欧氏距离。与专用向量数据库不同，MyScaleDB 的向量搜索完全融入 ClickHouse 的查询优化器——你可以写一条 SQL，JOIN 结构化业务表和向量表，在 WHERE 子句里混合使用普通过滤条件和向量距离排序，一条命令搞定传统方案需要三个系统协同才能完成的工作。

全文搜索集成 Tantivy（Rust 写的 Lucene-like 引擎），支持倒排索引和 BM25 排序算法。FULL_TEXT_SEARCH 索引类型让用户可以对文本字段建立分词索引，MATCH 语法支持多词组合、精确短语等查询模式。

混合搜索是 MyScaleDB 区别于大多数竞品的杀手锏。向量搜索擅长语义理解但对精确关键词"脸盲"，全文搜索精准但不懂语义——MyScaleDB 的混合搜索引擎自动将两个分数流通过 RRF（Reciprocal Rank Fusion）算法融合，用户只需在 SQL 的 ORDER BY 里指定权重比例，(1 - alpha) * text_score + alpha * vector_score，即可实现"既有语义相关性、又有关键词精准度"的搜索结果。

技术架构：如何把向量能力"焊接"进 ClickHouse？

MyScaleDB 对 ClickHouse 内核的改动集中在 src/VectorIndex/ 目录。整体思路是"最小侵入式集成"：复用 ClickHouse 原生的 Parser（解析 SQL）、Planner（生成执行计划）、Processor（算子流水线）体系，向量索引用插件形式挂载到 Processor 管道中。这种设计的好处是：现有 ClickHouse 生态（HDFS 存储、Prometheus 监控、Kerberos 认证）全部可复用，迁移成本极低。

向量计算层面完全基于 CPU SIMD（AVX2/AVX-512）指令集加速，无需 GPU。SCANN 算法在开源版本中通过内存索引（全部驻留 RAM）提供高吞吐搜索，适合百万到千万级向量规模；MSTG（Multi-scale Tree Graph）算法则在 MyScale Cloud 商业版提供，支持磁盘存储和十亿级向量搜索。

部署体验：Docker 一键启动，无需懂运维

MyScaleDB 提供开箱即用的 Docker 部署方案。官方维护 myscales/myscaledb 镜像，包含预编译好的二进制文件，docker run --net=host myscale/myscaledb:1.8.0 即可启动，监听 8123（HTTP 查询）、9000（TCP 客户端）两个端口，零配置、无需密码。本地开发场景下，推荐使用 docker-compose 编排，可同时挂载数据卷、配置文件，并限制容器资源（文档示例配置了 16 核 32GB 内存上限），与生产环境部署模式一致。

没有 Docker 环境也没关系——Ubuntu 22.04 环境下，官方提供 install_deps.sh + build_on_linux.sh 脚本自动安装 LLVM 15 工具链、Rust 编译器，自动化构建整个 ClickHouse+向量引擎项目。

在线体验方面，MyScale Cloud 提供免费 Pod，支持最高 500 万条 768 维向量，适合快速验证和小规模原型开发，无需本地安装任何软件。

局限与争议：不完美，但透明

作为开源项目，MyScaleDB 的局限也是显而易见的。首先，开源版本不支持磁盘持久化向量索引（需要 MyScale Cloud 商业版），大规模部署时内存成本不容忽视。其次，相比 Faiss/hnswlib 等纯向量库，ClickHouse 内核本身较为重量级，冷启动时间较长，轻量级场景下有杀鸡用牛刀之嫌。再次，ClickHouse 生态的强项是 OLAP 分析，短连接高并发小查询（典型 Web 应用的"查一条"场景）并非其设计目标。

不过，MyScaleDB 团队对这些限制的态度非常坦诚——文档中明确标注了开源版与商业版的边界，GitHub Issues 活跃且响应迅速，这种透明度在商业开源项目中难能可贵。

行业意义：向量数据库赛道的"第三条路"

向量数据库赛道近年来热闹非凡：Pinecone、Weaviate、Qdrant 等专用向量数据库各领风骚，pgvector、ElasticSearch 等"数据库+扩展"路线也圈了不少用户。MyScaleDB 代表的是第三条路——基于 OLAP 分析引擎的融合路径，用 ClickHouse 的列式存储和 SIMD 加速能力，给向量搜索装上高性能引擎。对于已有 ClickHouse 技术栈的团队，MyScaleDB 几乎是无缝升级；对于正在评估向量数据库的企业，MyScaleDB 的 SQL 原生接口和 docker-compose 一键部署降低了很大的试错门槛。