Chat with Milvus (1) 问答实录

本周二咱们在线上与 Milvus 的朋友们进行了一场精彩的问答。咱们也为不能参加的朋友们作了一个完整的文字实录。以为字数多看起来很累的朋友们能够根据本身想了解的内容观看影片回放。[影片请看这里！]

也想加入咱们的讨论吗？咱们会按期在每周二 8:00PM 举办这个活动， 快与zilliz 小助手（微信：zilliz-tech）报名下周的活动， 或是扫描 QR 码直接报名！

Q&A 影片/文字实录

* 语音转文字可能会有些许差别，实际内容以影音为准

User 1:  你好， 我目前也在作特征检索这个东西，我想了解一下：你刚刚说的有个特征分析，而后大家近期会作一些混合查询的功能。大家未来会支持标准的 SQL 吗？

Milvus：标准的 SQL 这一块，由于咱们如今在作 DSL 设计，因此咱们可能会先去支持像是 ElasticSearch 那样的一种描述语言。SQL 这部分的话相对来讲可能暂时会放在优先级比较低一点的顺序。我不知道在您的场景下面你如今是怎么作的呢？

User 1: 咱们的话也计划作这个东西， 但可能会考虑结合其余有已有的数据库譬如 PostgreSQL 这些东西来改一下。

Milvus：那您这边的话也是作向量类似度搜索而后但愿把它整合到一个关系型的数据库里是吗？

User 1: 是的。

Milvus：这部分的话其实在阿里云上他们有作这样的一个尝试，可是其实若是你仔细思考它向量数据背后的存储的和边缘计算的方式，和结构化数据的那种方式其仍是差别挺大的。

由于在整个传统的结构化数据库当中他比较精华的部分多是一个这种 B+ 树的索引， 而后基于 B+ 树的索引怎么去作这个 SQL 的优化器的访问路径的生成、优化，但在向量这部分其实都用不上，因此可复用的部分我感受是比较少的。

User 1: 由于目前 PG（PostgreSQL）不是出了一个相似类似性检索的插件嘛，他们也就是为了推广 PG 作了一些相似于这样的索引。

Milvus：以前有一个叫 PG-ANN 的项目可是如今这项目好像感受有点不怎么活跃， 当时作了时间也不长，因此这块的探索确实会有一些挑战。

User 1: 我看过我们的代码，我们是否没有用一些其余的存储引擎？

Milvus：是的，目前的话并无用。由于数据库的存储引擎其实仍是根据这种数据库自己的形式去作的存储引擎，像那些交易型的数据库他多是按照页来组织它的数据文件作的存储引擎。还有像这种 KV 型的，那可能就是 KV 格式的。但向量其实会和他们的需求不太同样，向量有点像 KV 但又不那么像，由于咱们在索引的时候好比聚类的索引，有的IVF索引实际上是须要带一些聚类的信息在里面的。 

因此这部分确实和目前已有的数据存储引擎会有比较大的差别。因此这部分确实是咱们本身作的，可是底层承载这个数据文件的这部分，咱们接下来的版本是但愿对接到S3的存储当中。这样的话数据文件放在 S3 的存储上作高可用和分布式都会比较容易一些。

User 1: 有没有考虑过以后结合 HBase or HDFS 这样的数据库？

Milvus：HBase 的这块暂时尚未想过，由于可能场景会太同样。 由于像 HBase 和 HDFS 的话它都是一个一个数据块嘛，可是在一个向量检索的场景下面，

其实咱们的文件你也能够把它说是一个数据块， 可是咱们这个数据块它实际上是会承载更多的信息的。首先他有聚类的信息，若是是 IVF 索引的话。而后呢，为了这个 IO 的效率和检索效率呢其实咱们也是但愿这个数据块可以尽量的大一点， 那和 HDFS这部分考虑的因素可能就不太同样。HDFS 可能就是为一个文件分红若干块，而后每块可能要128MB大小分布在多个机器上面。那若是咱们的文件这样分的话，在不少状况下可能个人这个聚类信息都是在最初的那个块上。

那不少状况下我一个文件都是但愿在一块儿读的，若是要去到不一样的节点上读的话，不一样的节点载入不一样的分片以后又没有那个聚类的信息，那就会比较尴尬。

User 1: 咱们如今有一些业务场景， 譬如除了类似检索还有一些特征聚类的业务还有一些其余分类的业务。咱们的特征已经存进去了，想把咱们本身的聚类、分类这样的一些算子集成在这个项目（Milvus）里头，这个项目提供这些开放的接口吗？

Milvus：是这样的，就是说其实在咱们如今的现有的用户端场景当中， Milvus 就是负责存向量特征这部分的；用户的应用和模型都是在上层本身去构建的， 在目前这个阶段。因此对于大家来说的话也是同样的，你的算子也行你的应用也好都是在上层的，而后你把特征存到 Milvus 当中而后作一个索引和搜索加速就能够了。 

User 1: 那目前只提供检索这一个功能？

Milvus：您是但愿（好比说你有100万的向量）把这个向量建完索引后聚类的信息可以得到吗？

User 1: 是的，这些聚类的信息好比果动态的一些聚类，好比天天入10万的向量进去而后我就天天发就算是更新这样的一些算子，基本上就是存储，而后上面算子是一层也有检索的算子还有分类的一些算子。

Milvus：我大概明白你的意思，可是它的实现是这个样子：好比说原始的 FAISS 当中， 假定你有10万的数据先做预训练，他会预训练出一个大的分类， 那么你后续插入的数据那就是根据这个原来训练出来的大的分类而后把这个数据放在那里面。那么，这种状况你能够说你是作了一个分类也好或是聚类也好， 可是在咱们的这种向量搜索引擎，由于提供向量就更进一步的向量数据管理的状况下，实际上是这个样子：就说你这边假定有了100万条个向量过来，那可能这100万假定他们放在了同一个文件里面，那这100万条向量，他在这个文件里面他就是造成了一个好比说 IVF 的这个分类的结果。

明天你又来了100万条向量，它可能也在一个文件里面，那个文件又是单独的。另外一个就是这个索引会训练另外一套分类的结果，因此其实你不断的有新的东西进来，它们会新建新的索引文件，当它达到预值以后。因此在这种状况下，若是说你要去把它作聚类或分类的话，那你就须要在这个东西上面一层（业务层）你须要有个大的整体的分类指导的一个件， 好比说就这个东西过来它和最初的， 譬如说你有100个分类， 那和最初的100个分类去比较它和哪一个最近。因此这个会有点不太同样。由于咱们把流式更新进来的数据分红了若干个文件，而后每一个文件的聚类信息都不同，因此回给你的东西可能就不会是一个统一的一个东西。目前 Milvus 的定位就是一个比较基础的为 AI 服务的一个向量搜索引擎。

User 1: 在后期没有考虑集成更多的机器学习的算子？譬如 SVM，逻辑回归等。

Milvus：这一部分的话目前尚未计划放在里面。咱们如今目前在作的一些集成有像是一些新的 ANN 算法。譬如，咱们本来没有 HNSW 或是 ANNOY，咱们后续会把他们集成进去。

User 1: Milvus 有的现有的应用场景？

Milvus：深度学习方面，好比说这种安防类的智慧城市、智慧零售，也有这种互联网的一些作SaaS平台的，作这种智能海报生成，它会有不少基础的图片的元素而后根据用户需求去搜索图片库，造成一个个性化的海报。还有一部分是作这个推荐系统的，就是给用户推荐一些视频、短视频这些场景， 还有一部分是天然语言处理方向。由于像你们如今可能比较多的用了这种 Bert 的模型，生成的也是这种高维的向量。在咱们 Milvus 的网站上面咱们还有一个化合物分子分析的 demo，那部分它不是一个 AI 的模型，它是一个基于规则的模型转换成一个特征向量，而后呢咱们用这种计算谷本类似度。

User 2: 您刚才这边说大家的这个索引固件是文件分块以后从新训练码本，这样的话会不会存在说这个码本不统一？

Milvus：是的， 由于每一个分片他都是从新训练的分类，因此其实每一个文件当中的分类信息都不同，那其实这样作呢它固然由于从新训练它会有必定的代价。固然若是 GPU 的话会很快。它的一个好处在于说他后续进来的数据分布若是和原来不同的话其实不会形成太大的影响，由于像好比说我用20%的数据训练出来一个分类的话，那其实后续的数据可能和先前训练的数据的分布状况不同，那就可能会出如今某一个聚类当中的数据特别多，那你索搜某些地方的时候时间的响应就会不太均衡。

像咱们如今这种模式的好处就是， 后进来的数据反正它也都是从新训练的， 因此当我去索搜固定空间大小的时候，它的响应时间相对来讲是比较一致的。

User 2: 个人想法是咱们要不要就是采用这个分布式的结构而后对全局的数据加码本，这样的话码本是统一的，还有一个就是使用数据分部监控的方式会不会对精度会更好一些？

Milvus：先回答以前的第一个问题：若是假定我有两个节点，在两节点上共享这个码本，但其实仍是没办法解决以前讲到的那个问题。就是你训练的集合你真实进来的, 它可能分布上是不同的。它可能会出现一些分类的不均，形成性能波动， 这个其实问题没法避免。另一种状况是像 Facebook 当中他作的那个用 FAISS 当集群的时候他是把， 好比说他分200个类好了，他弄个20台机器，2 台一组， 那每一组他去 host 200个类中的10%，好比20个类就在那个机器上面，那你新来的数据呢他根据你的所属的类的去插入到具体的某一组机器上面。

那其实这个也是同样的问题，就是当你后来的系数据他分布发生了比较显着的变化的时候，那你可能就是在这10组机器有一些可能特别的忙，存的向量数据特别的多，仍是会形成问题。而后当在这种状况下咱们若是对全局的全部的向量数据作一次从新的分类的训练的话，其实代价会比较大。这个就有点像传统数据库表当中你老往里面插数据，而后不停的删数据以后你的索引就乱了，就必须作一些全局的索引的重建，而这个是会形成必定时间的向量搜索服务的不可用。

因此也是由于这个缘由，咱们如今考虑下来的这种模式也算是一种权衡吧。FAISS 在他们论文当中讲的那种模式，可能就是20台机器，两台一组，每组分一些分类（以及其余方式）在理论上来说它可以提供很是好的查询的性能，可是在实际实操的时候尤为当你不断数据进去的时候他的维护成本实际上是比较比较大的。

第2个问题：统一码本的另外一个挑战就像是传统数据库同样的，须要有个实时的统计信息而后按期去查看，由于这些好比说聚类型的索引它最基础的算法都是 K-means，那 K-means 的含义就是 K 个 means， 但愿均匀分红 K 个类，因此就是若是是个统一码本就须要不停的去监控这些东西，而后必定确保说当这个数据在不一样类当中的这个分布不均匀到必定程度的时候是须要去触发从新建索引、从新计算全部分类的这个操做。因此其实就个是这种监控它会给用户带来一个更更加容易的一种方式去发现潜在的性能问题。可是当你重建整个分类的时候所形成的这种维护成本和不可用的时间其实仍是在那，只是当用户是有意识的去触发这个事情的时候，他能够放在一个相对来讲业务低谷的时候，那不可用形成的影响能够降到比较小。

User 1: 如今这个系统的单机容量最大的多少？实测的单机容量

Milvus：是这样的，就是在咱们本身的这个物理机上咱们实测的一个最大的数据集是来自于sift-1b，它是128维的数据10亿条，那咱们测试的机器那是一个 512G内存的一个双路的机器。可是经过咱们由于在 IVF 索引中能够用一种 scalar quantization 转 SQ8 索引， 那它实际的内存消耗是在140G 左右。而后在咱们一些实际部署的一些用户的产品下面由于他们是1024维的向量，基本上每一台作个千万上亿级的也是没有问题。就人脸的那种1024维的向量通常的这种512GB内存或256GB内存的机器支持到上亿条是没有问题。

User 3: 算子扩展怎么支持？

Milvus：若是是指 ANNS 的算子扩展的话那其实在咱们的代码结构当中有一些说明。由于以前有一个作智慧零售的用户有问到说他们若是想增长一些咱们如今尚未的索引应该怎么作。在咱们 index 的相关目录下有一个开发的说明。若是您这边有兴趣的话的话会后咱们把连接发给你， 咱们也能够在群里交流。

欢迎加入Milvus社区

Milvus 源码
github.com/milvus-io/milvus

Milvus 官网
milvus.io

Milvus Slack 社区
milvusio.slack.com

© 2020 ZILLIZ™