Chat with Milvus 线上问答 #5
Chat with Milvus 线上问答来到了第5期， 本期讨论了不少内容， 建议大家影音/文字可以互相搭配。
跃跃欲试想来和大家分享你对 Milvus 或是近似检索的一些想法吗？ 每周二晚上8点来与我们一起头脑风暴吧！现在就加入Milvus 交流群获得会议信息， 入群方式请拉到文章最底喔。Talk soon！
某位用户在群里提出了一个问题，这个问题是这样的：
他有将近200万向量，300维的，并且他将index_file_size设成64兆，然后在这个情况下他用GPU/CPU都分别搜索了一下，测试了一下效果。
在他的配置下，因为他那个设置下面所有的都是单线程，只有一个CPU去做搜索的，那么在这种情况下基本上Milvus在精度比较高的情况下，基本上如果在单条向量的查询点是在2~3毫秒之间，基本上是QPS做300左右。你可以看到说一个128维100万的，在一个比较理想的情况下，他索引文件比较大的情况下，那么它的性能可能就几个毫秒，大概到200万的64兆这样的小文件的情况下，它的搜索时间就上到了200毫秒。
顾老师 @ Milvus ：
我觉得这当中的一个问题主要是说，因为在比如说IVF的索引下面，如果是index file size设的比较小，那就会有很多个索引文件。然后每一个索引文件，都是因为是独立构建索引的，所以每一个索引文件在搜索的时候，都会先去做一下quantizer的工作，就是他有每个索引文件都有一系列的图形，然后你的产品向量要跟这些图形去匹配，看选择哪个是他最近的，然后在周围再选择你的nprobe个数的，所谓的inverted list，然后再去搜索。
【影片 1:54分- 6:40分】是顾老师的数学课： 跟顾老师来算个数学， 算完你就懂如何能达到Milvus最优性能啦！
| 部分Q&A文字实录
* 以下文字部分由语音转文字，已经过一些调整让句意可以更清楚。
User A： 如果没有到达 index_file_size没建立索引对查询速度影响大吗？
顾老师 @ Milvus ：
这个其实因为没有达到索引建立的速度的时候，就是说它会去做暴搜嘛。在这个例子当中的话，因为刚才说64兆文件大小对应300维的向量的话，一个文件就5400条记录，其实暴搜5400条，我觉得应该还是它的速度不会特别的慢。
User A：
因为我们这边现在那套系统现在是场景是我们要做舆情监控，然后每天大概我们这边会有最高峰的时候，大概会有190万条新闻，然后加上低峰的一天大概总共有200多万新闻，然后估算了一下大概要在差不多每3000条新闻要在5秒内去处理完，也就是3000条的向量要在5秒内处理完。这个处理的过程就是要先搜一遍，先在现在我们的向量库里搜一遍。然后如果说没有找到有重复的向量，就没有找到重复新闻的话，然后再去进行一个插入，然后这就这就有个问题，我们等于是边插入边查询，边查询边插入，应该是这样的。
所以担心index_file_size，我自己看了一下，我们这边导入速度就按照最理想的5秒钟3000条，那么感觉会将近有可能快的就那一两波批次，但是中间可能就会有很多批次，他就处于暴搜状态嘛就担心会影响速度，所以就把这个比较小，也是利用0.7的自动构建索引。
顾老师 @ Milvus ：
是。其实像这样的一个情况的话，其实当然可能新闻和图片还不太一样，因为我们有一些这种之前接触到的用户的话，他们要做这些去重的一些操作的话，他也会分成这样两种情况去做，因为就是说当你有新的数据插入进去的时候，它可能不是还是会有一些延迟，你才能够搜到嘛为了保证这个东西最快的话，他会先这批3000条过来走，先自己里面搜一下，看看有没有重复的。如果有重复的话，那就直接扔掉，如果这一批里面没有重复的，他再去和已经插入到向量的集合当中的一些去比较。
User A：
现在目前暂时先不考虑3000条中间有没有重复的，要保证和库里的至少是没有重复的。现在是这样一个问题。然后又因为相对来说实时性比较高，你边搜边插入，所以就担心index_file_size设置稍微大一点以后，然后中间可能总共有10个批次，然后其中前9批次都属于暴搜，只有最后一个批次快，这整体来说效果也不是很好，速度也不是会很大。
老金 @ Milvus ：
我这边的建议的话，我还是比较建议说你index_file_size肯定设大一些，我们平时其实做实验的话也能看得到，默认的值是16384大小，所以你其实这个事可以设大一些，至于你说暴搜那个事，我建议你可能要做一下实验。
User A：
对，现在现在我们也是准备重新倒入向量了。然后今晚来做下实验，看看效果
老金 @ Milvus ：
对，然后那个我说一下。我们马上会发一个0.7.1，我今天在群里我也回了，我说大概在4月份初的时候。看进度吧现在不好说，因为现在在做测试，如果测试最后所有的测试都通过的话，我们可能会早一点把这个版本发出来。发出来以后，它对于暴搜的性能的影响会有一个比较大的提升。虽然说背后我们用的也是faiss的那套东西，但是faiss那套东西其实它在暴搜的时候，你在某些场景下，其实性能其实很差的。可以这么说，现在肯定是很差的，有的时候，但其实就是在线程的利用和CPU利用率是非常低的，所以我们这里做了一个比较大的更新。在某些场景下，它性能提高了好几倍。
User A：
对，我看官网上你们官网上文档上说有一句话说，是只有当所有索引加载到内存中以后，然后才是性能最高的。对吧？但是我今天下午测试，包括我自己的4000万的以图搜图的系统，也在查询，也下午也会也做了一些测试，发现内存内存一直都是在20个G左右，也上涨不了，也一直没怎么上涨。
老金 @ Milvus ：
对，你就说明你只用了20G。
User A：
那他录入到盘中大小。我看已经有好有将近4个有80个G左右。
老金 @ Milvus ：
盘中有80个G，我觉得可能是有点问题。对，SQ8 的，具体要看，因为我们存的话，它会把原数据都存到盘里面去。
User A：
所以这个原始数据，我还要问能不能导出？
老金 @ Milvus ：
我们现在并没有提供工具做这件事情。
User A：
然后今天下午群里面当时说是建议我们用通过向量ID一条条去取，然后我们刚刚测试了一下，速度非常慢。
老金 @ Milvus ：
对，通过ID取的话就不会快的。
User A：
特别慢，然后我刚刚看Admin里面，那里面有一个，点开collection里面一个，然后里面有好多分区，分区里面点开以后里面可以看到向量，但是这好像是显示不全的这种。因为我看我这里面总共两个分区加起来总共才不到100万，但是我这边总数是有400多万了。
老金 @ Milvus ：
如果是这个问题的话，我觉得就可以报个issue，实际情况下应该是里边的向量的数量应该完全是对齐的。如果你们有几个partition，有多少个向量，它的数量不应该有错。
User A：
对，我就两个partition里面有数据，然后我刚看上面右下角不是有多少items吗？然后一下我加了一下，两个加起来不到100万，但是我总量是有400多万。
老金 @ Milvus ：
有一个获得向量数量的一个接口，它的接口可以把这个数据拿出来看一下。
User A：
我们现在就想数据导出，因为我没有在 Github上找到 admin的源码嘛，然后本来想看看
源码怎么取的数据。
老金 @ Milvus ：
取数据的方式其实跟你现在一样，就是get back by id.
User A：
在Admin里面也是这样显示的吗？
老金 @ Milvus ：
对, 在Admin 里面实现也是这么做的。也就是说我们现在其实并没有一个批量的把这个东西导出来的工具，你提这一点到也是的。
User A：
因为有时候像我们第一次用，也算是初次尝试，然后肯定前期包括后期调整的时候，会有调整有一些比如可能后面公司大力支持，给的钱多了，那时候可能用的索引就可能更放肆一些，对吧？而且要调整一下，但是像我现在4000万导入，我现在还好一点，4000万图像导入大概要用两天，这个就比较耗时。因为等于每次重新提一次向量，因为本人图片就要占1.2T的盘，然后如果单独生成向量文件的话，那也非常大，所以一般也不会自己再存向量。
老金 @ Milvus ：
明白。我们后面会给这样的导出的工具。
User A：
这个还是挺需要的。
顾老师 @ Milvus ：
确实数据导出的工具也是一个，我们以后也是一定会补上那个东西，因为在后续如果升级或者牵涉到这些东西的话，因为大家这个数据弄进去也挺不容易的，确实。
User A：
一般像我们一导就好几天了，我已经往Milvus 里面倒了将近4次数据，然后用了一个多星期已经，不断的改嘛。
顾老师 @ Milvus ：
GPU 去构建索引应该还好吧速度？
User A：
主要是 GPU去提取向量速度还可以，但是因为读图片IO小，IO这块压力就大了。
老金 @ Milvus ：
我这边其实比较建议你这边如果底下还遇到这样的情况的话，先把它存成Numpy的这种数据格式。因为现在毕竟还没有导出工具，估计以后有导出工具可能会好些。
User A：
对。我们现在也在做实验，然后看效果，因为我们公司旗下的一个子平台，然后当时不知道主要是从哪买的一套系统，然后今年我现在是导入了将近有3400万的数据，然后搜索结果和它也是一致的，速度还比较快。然后我今天让领导看着还挺满意的，但就是在这主要考虑到后面并发相关的问题，就怕后面并发大了以后速度方面就有一点问题。
老金 @ Milvus ：
对，新版本出来以后你可以再试一下，我们内部测试了以后，并发还是有比较大的一个改善。
User A：
我到时候看你们这边发版本，我会持续跟进的。
User B：
你好，我想问一下，我们在做图片检索的时候，然后我们想输入图片的时候，我们发现它的返回的这种准确率并不是太高，我不清楚咱有没有优化的方法？同一个图片它可能会有这种它的一个不同角度的图片嘛，但是我在搜索的时候并没有把它不同角度的图片给搜索出来， 不知道这是因为什么？
顾老师 @ Milvus ：
你用的是以搜图示例的代码吗？
User B：
对，是的。
顾老师 @ Milvus ：
因为以搜图示例的代码，他示例用的是一个VGG的模型，它主要是关注整个图片的相似性。
User B：
那我该怎么提高呢？所以说用现有的代码是不行的，是吧？
顾老师 @ Milvus ：
要是模型的关系，关键你是想要搜什么样的一种图片，你根据你需要的效果去调整模型，甚至替换模型，因为如果你是要提取人脸的话，肯定像VGG只是整个图片相似，它并没有去做什么对象识别，也没有做人脸的提取的这种东西。
User B：
我这边发图片里面是不同设备的不同的角度，我该怎么从哪里入手，能不能推荐我们在这边是往哪个方向去优化，是不是不使用VGG这个模型比较好？
顾老师 @ Milvus ：
设备不同的角度，这个我可能真的得要考虑一下，因为你想一个正方体，你从正面和从侧面看的话，它的几何形状是上呈现在一张图片，这种2D的这种几何形状效果应该是完全不一样的，这个可能是需要一些自己再去对模型做一些训练，去让他能够认识到说正面看出来的正方形和侧面看出来的平行四边形，它其实一个就是属于同一个设备的这样子的。
User B：
没错，就像比如说手机的正面，侧面主要它立在这，然后的正面、侧面、侧上方，然后下方。然后这几个拍的照片，实际上对象应该是同一个嘛。我们就想这样子，我在搜索的时候，我希望比如说我们把正面的图像放进去之后，能把它侧面的或者说俯视图也都能搜出来，能不能从你们专业的角度给我一些建议，我该怎么入手这件事情？
顾老师 @ Milvus ：
这我之前也没什么研究过，之前了解到的都是一些针对于特定的物体的一些侦测之后去提取的向量。这一部分的话，我感觉是需要在需要有一些训练的过程，或者我不知道说像你们这种图片有没有可能去打一些标签之类的呢？
User B：
可以打标签，打标签之后该怎么做呢，是不是需要把它给提取出来？把这个对象给提取出来，用什么模型比较合适一些？
顾老师 @ Milvus ：
你们那些设备的话，一般来说会有多少个不同的视角去看这个东西。
User B：
一般会是4、5个角度，前后左右上。上面俯视图。
Ray @ Milvus ：
我想问一下你这个场景的话是要的效果，是不是说我随便任何角度的图片去搜，然后我可以把它各个角度都看明白。
User B：
对就是这个意思。
Ray @ Milvus ：
我觉得如果前面讲你去训练模型是一种方式。你也可以用这种我们Bootcamp里面还有一个，其实就是用标签的方式，比如说你把这5个角度的图片就归成一个档或者是一个标签，然后去返回到比如说你找到他任何一个角度的向量返回之后，把ID对应到标签图里面去，然后你就可以把标签组里所有的照片都拿出来，这样可以比较简单地来实现就这种诉求，你不管它哪个返回的向量，它对应的是一个照片，而不是一张照片，而是一个照片，你就可以把这个照片自动发回来。
大概是这个意思。其实你可以在你前端通过你的Python代码里面做一个简单的标签组就可以了，你一个向量你这8张图片的向量返回的时候，对应的都是这一照片，然后你只要返回来这一个ID，就把这个主照片拿出来就可以了。
User B：
新思路，谢谢。
User A：
刚刚兄弟问题我做一个建议，因为我本人做深度学习嘛，然后从我这边给个不成熟的建议。
我的想法是就比如说这VGG，然后你重新去训练VGG然后你的样本数据你用很多种弄很多张图，你做标签，比如手机的4个角度对吧？4个角度，然后你包括再去做图像增强，就图像旋转，然后这一类东西比如都标注为是手机，然后你去训练，训练以后他其实最后他去做的就是一个图像分类的工作嘛。这样训练完以后，应该是这一类的手机各个方向旋转的这一类的图片，他去用，你在这种情况下，甚至训练模型生成的向量应该是相对来说接近一致的，相对来说比较接近的。
我大概的想法是这样的，然后用向量去导入Milvus里面，然后再去做图像索引，应该就OK了。你先去训练，先去做图片标签，然后训练出一个模型，这个模型是可以分辨出一个物体就是在不同角度下拍摄出来的物体是同一个物体。对于在深度学习方面应该算是比较简单的，应该是比较常见的，因为大家都要做图像增强嘛。然后训练出来的模型去提取向量，然后再去导入Milvus，应该是可以去近似搜索的，我觉得。
User B：
好的，谢谢。
User C：
我们现在也想用Milvus做一个这个东西，就是用户会可能传好多这种文档，它有标记有描述，不知道适不适合这方面，我想把标题和描述生成向量，然后拌进去之后用Milvus做检索。想做一个这样的功能，不知道它适不适合？我也刚研究，刚入门那种。
顾老师 @ Milvus ：
对，在我们的用户场景当中确实是有用类似于Bert的这种自然语言处理模型，他把标题去做向量话，然后就起来之后做一个相似性检索，是有的。之前的一个用户，他是做手机浏览器的信息推流，就是每个新闻它要把标题向量化之后存在里面，然后它因为是一个智能手机厂商，你打开手机上的浏览器的时候，它会根据一些向量检索的结果去推流那些推荐的新闻，你现在每次打开手机浏览器，它都推一堆乱七八糟的就是用这种方式去做。
User C：
然后我在看咱们档案文档的时候，一个索引类型NSG，然后还有几个图索引，所以我索引的选择应该选哪个？
顾老师 @ Milvus ：
这方面的话要考虑一个问题，你的向量的库它更新频繁吗？还是它是比较一个静态的库？然后你的预期的向量的数量会有多少？因为图索引的话它构建起来相对来说时间会比较长一点，它的内存占用也会比较大一点，所以如果你的向量的总量特别大，然后更新的比较频繁的话，那图索引他就可能会有一点挑战。其实图索引对于它搜索的时候会更快，然后CPU消耗会更少。因为它大量的工作都在索引构建的时候已经完成了。
User C：
它在检索的时候不会特别消耗CPU是吗，只是说构建的时候消耗？
顾老师 @ Milvus ：
相对来说图检索在搜索的时候，它的CPU消耗没有IVF检索大，但是它构建的时候会更慢。
User C：
因为知识的变动不是太频繁，因为一旦录入了只有一些过期的知识可能会发现，到时候我会把它删掉，但是我看图索引是不支持删除的。
老金 @ Milvus ：
我们现在这个版本里面，其实对于删除0.7.0里面图索引其实是没有删除的，不支持删除的。在0.8.0的时候，HNSW的删除会支持上，但NSG我们是不做了现在，在0.8.0以上我们也没有，所以如果你要用图索引的话，可以等到0.80用HNSW。
User C：
那0.80大概啥时候发布？
老金 @ Milvus ：
0.8.0的话，按照我们计划的4月中旬。
User C：
我想一下用它应该是可以的，我看官网的例子，我推荐系统可以用它，但是检索这块办应该怎么选...
顾老师 @ Milvus ：
预计会有多少的文档去做向量化的事情呢？是在上百万这种量级上？
User C：
现在库存的文档总共是600G但是最主要是训练完成多少还没有计算过。
顾老师 @ Milvus ：
好的，明白了。所以像你们用这种自然语言模型去做文章的时候，是会把标题生成一个向量，然后再把整篇文档生成一个向量吗？
User C：
文档生成一个向量我觉得没有太大意义， 就是标题和描述生成向量我觉得就够了。
顾老师 @ Milvus ：
明白， 一篇文章出一个标题的向量、出一个简介的向量就可以了是吧？
User C：
对，或者是再把文章提取一个概要出来去拿宣传。
顾老师 @ Milvus ：
觉得这部分可能是要看一下向量的总量，如果向量的量不是很大的话，其实用图索引还是挺便利的。
User C：
可以。现在考虑的是如果说没有升级功能的话，比如说我一上了一条之后，我可能去重新训练所有的在管数据。
顾老师 @ Milvus ：
是的，或者就得自己做一些标签来表示来进行删掉，但是肯定不如人身的能够把它标识为删除，然后在搜索的时候就把它过滤掉，效果肯定是会更好。
User A：
前段时间发现一个问题，我们一般不都像咱们系统不都是官网最近Docker启动吗？然后我们这边主要用GPU来搜比较多一点，然后但是发现有时候GPU突然就像我导入的时候，就在GPU那台机上去本地导入的，然后有时候突然就是说占用显存或比较大的时候，突然占用比较大的时候，然后就会把Milvus挤掉，像是上面像是卡住似的，Docker看那个状态是在线的，但是请求不通。
就刚刚开会那会儿，然后我同事就打包了一个Docker因为做数据迁移嘛，然后打包了一个tables里面一个文件夹，打包完以后莫名其妙的Milvus搜索不了、炸了。
顾老师 @ Milvus ：
你说的情况是指这个系统上还有其他的进程在使用GPU是吗？
User A：
对，因为我现在导入图片流就直接在本地导入的。然后有时候偶尔可能突然占用大了，或者说是有Milvus的占用的显存也是不断也在一点点增大，然后有时候没计算好跑了一夜，然后跑到后半夜时候，可能显存占用到一定程度时候，正好就刚好超了显存量，然后Milvus就卡住了好像。但是看到Docker 状态显示是在线没有掉线的，调接口就调不通，然后刚刚我同事在tables文件夹里面打了个压缩包以后，然后我在Admin里面搜索向量，然后就出现错误。好像超时了。
顾老师 @ Milvus ：
所以是这个图片抽取的进程和Milvus的Docker都跑在同一个GPU的服务器上，然后进程它会占用 Milvus使用的显卡上的这种显存。确实Docker在这方面，资源隔离其实做的不是特别的理想，尤其是牵涉到显卡的时候。
User A：
然后主要就发现Docker突然崩了，连接也联系不上了，然后连接上了，也都做不了那种，什么操作也没法做。
顾老师 @ Milvus ：
明白，因为你是用的是GPU板的话，你再建索引的时候是用的GPU，所以它GPU的时候，它是需要到调显存的。
确实这一部分的话，确实Docker的资源隔离其实做到没有，或者说GPU本身的能力也没有那么的确实就是没有那么的成熟，在这方面被占用的时候，现在确实好像没有什么很好的方法可以侦测到这个问题，让Milvus可以预先的去申请这部分资源，就占住。这个事，内存是可以做这个事情的。我一起来我就先把数据加载进去，然后占满我需要的内存，那显存我们确实好像没办法去做这个事情。
User A：
好吧，然后我现在也是在这边控制，基本上提前算好量，控制显存用量起来。不过现在突然一下不知道为什么搜索不了了，现在。这个问题待会我看一下，然后待会再和你们沟通。
顾老师 @ Milvus ：
看一下日志，保存一下日志，可以分析一下这个问题。
这边的话你觉得说我们如果在启动的时候，占住显存，好像确实因为显存的资源比较宝贵，大家一般不太愿意这样做。
User A：
是不是可以在设置里面，就镜像里面 可以像Tensorflow一样，不就也是可以填占住显存吗？是不是可以有一个设置的比例，说预先占用多少，比如0.3或0.7这样？
顾老师 @ Milvus ：
对，我们显存我要用的话可能会用的比较多一点，因为因为你现在数据本身量会比较大一点，包括建索引的时候还需要有一些交换空间。
User A：
后面具体遇到情况就再待会再给你们再看一下日志吧。
User D：
有个问题想咨询，Milvus 存储索引的数据是处于放在内存中，还是说是内存一部分，然后硬盘一部分，还是说是怎样的？
顾老师 @ Milvus ：
索引是会先存成文件，然后你查询的时候会去调度这些文件载入到内存当中，当然是需要访问的内存文件会载入到内存里。这样子的。
User D：
它是不是全量放到内存中是吧？
顾老师 @ Milvus ：
是对，就是说你也可以配置说在启动的时候把某一些文件全部都读进来。但如果你不这样配置的话，它就是用到哪个文件就把文件放到内存。
User A：
有一个问题，我估计有些朋友也会比较关心，比如我现在是0.7版本导入数据，然后但是像之前0.6导入数据0.7就不能用了。那么咱们这边有没有计划，就是说什么时候可以向下兼容之前的数据呢？就不用重新导入，如果像线上生产的话，不可能说每更新一个版本更新完版本以后，我们都重新导入一遍数据，那是非常耗时的。
顾老师 @ Milvus ：
是这样的，就是说我们会尽量保证数据格式的稳定，但是在某些情况下，比如说我们未来如果要增加属性过滤做向量的话，他的文件不仅要带向量还要看属性，他这个格式肯定是会发生一些变化的。像在数据库升级一样，你升级完之后，它会要求你做一次重组，这样的话能够使用到新的存储引擎提供的一些功能。当然这部分的未来我们会尽量保持稳定，但如果会发生这样的情况的话，我们也会准备好这个工具，让大家能够比较快的去实现转换。
User A：
其实我觉得相对来说，可能数据导出工具的话，可能就相对在这时候也会相对比较实用一些，我个人觉得因为有时候确实好像升级以后有些属性的改变嘛，但这时候其实咱们这边直接导入向量是很快的。所以还是比较希望能尽早有个导出工具，因为导入进去导出来太麻烦了。
顾老师 @ Milvus ：
我们研发团队也听见了
User A：
可能也确实导出数据特别麻烦，尤其是建索引。下午我同事也是提了个想法，不知道咱们这边能不能就是说有实验的可能性，就是说我们就数据保留，但是可以删除索引，就drop时候可以选择去删除索引，然后重建，因为我前面咱们不是也把原始向量也保存下来了吗？
然后是不是可以就是说有一个方式直接把索引给drop掉，然后重新新建一个索引，然后哪怕说是等待索引建立时间也可以。
老金@ Milvus ：
我们现在支持这个功能，你可以把现有的index drop掉，然后重新再建索引，这是可以做到的。
User A：
这个是在SDK里面已经提供了方法了是吗？
老金@ Milvus ：
我们对这功能其实支持比较早，0.6.0里面就已经有了，你可以看一下一个example里面有这些东西，拿一些小相对小一点的数据集可以简单试一下，
User A：
好的。我一会来测试一下，看一下。谢谢。
老金@ Milvus ：
有问题欢迎随时交流。
User A：
感觉都是我在问问题。我下午就怕我再问问题，你们会把我踢出群聊。
老金@ Milvus ：
没事不会很欢迎！我蛮希望从用户这边，从开源社区这边能够听到很多的各种各样的反馈，反馈可能是对产品质量、可能有一些功能的需求，还有一些实际的一些应用场景，那些我们其实很open的，希望能够听到这个声音。
往期回顾
Chat with Milvus #4 回顾 - v0.7.0 的那些事儿
Chat with Milvus #3 回顾 - ANN-Benchmarks 测试结果
Chat with Milvus (1) 问答实录 - 近似搜索、分布式、数据库， 来看看我们都聊了些什么！
| 欢迎加入 Milvus 社区
github.com/milvus-io/milvus | 源码
milvus.io | 官网
milvusio.slack.com | Slack 社区
zhihu.com/org/zilliz-11/columns | 知乎
zilliz.blog.csdn.net | CSDN 博客
扫码进入技术交流群
© 2020 ZILLIZ
608
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
