milvus是数据库存储还是目录存储

今天我会跟大家再来介绍一下适量数据库的对比和选择的这样的一个话题，因为也有网友在问我， 像是呃，像这个 lm 大模型加本地知识库，质量数据库也是比较重要的，那么他到底应该怎么样的一个选型啊？有哪些可选择的解决方案，我跟大家来介绍一下，把我一些实践的经验也跟大家聊一聊。 这个使量数据库呢，它目前分成这几大类，有五大类，一种专门是新兴的纯的这种使量数据库，像那个中国的 mirrors 啊，我原来也是经常讲的 mirrors 为代表的啊， 包呃，包括现在那个呃就是在全球很著名的叫 chroma 啊，这个也是非常有名的这样的一个史量的这个数据库，因为因为人工智能大模型的这个崛起，让这些史量数据库的这个新生的这些力量，他们目前都拿到了 大量的融资啊。那么使量数据库呢，它本质上来讲呢，它可以存存储各种各样非结构化或者结构化的数据啊，它都是可以来存储的啊，包括图片啊，文本啊，声音啊，视频啊等等一些非结构化的数据，通过一个 in bed 的这样一个操作，把它变成使量存在这个使量数据库里面，他作为一个知识去结合大模型再做一些推理和一些向量的运算啊，他主要是做这个 这个纯使量的这个数据库呢，它有个天然的缺，缺陷就是在于呃，它基本上没有一些 c 口的支持啊，如果你要它大部分都是一些 restful 的一些 a p i 啊，如果你是纯粹对项链做一些操作，这个是可以的，但是如果你要再做一些 类似的过滤查询，包括 c 口的一些相关的操作的话，那么这种数据库就不太合适了啊。用纯食量的这个数据库，用纯限量的数据库就不太合适了，那 那么有些人还会结合了一些文本，他们会结合一些什么全文检索的数据库啊，那么这个就是第二类，以以 elastic 设置为代表的这样的一个，他也能够支持一定的那个限量的这个计算，因为他也有限量的这个计算库啊，他也有啊， 而且他也能支持一些全文检索关键词，呃，包括一些，呃条件过滤等等一些的东西啊，所以这个是第二类啊，用的也是比较多的，如果你有全文检索啊，你也要同时要用到一些限量的，用 elastic 摄取这一类的 全文检索，加上向量库的支持啊，这个会比较合适一点啊。第三类呢，主要是一些开源的一些史量库啊，像那个 fairs 为代表，这个是 facebook 开源的 f， a， i， s， s 啊，包括 a， n， n， o， y 等等， h， n， s， w 这些内裤，他们都是一些开源的一些食量数据库，很多现 现在的一些史量数据库呢，它其实都是基于这种开源的这种史的史量数据库上进行创建的。那么但是呢，那个 face 他们这些开源的限量数据库呢，它有一个不好的地方，就是它主要是都是单机版，如果你要有一个集群，或者你要有很多的福气，同时共享 去存取这个项量的话，那么用项量数据库会更合适一点，这个比较适合用一些轻量级的，本地化的一些啊，用开源的这些食量库啊，就可以了啊。这个是第二种，第三种是基于这个 no c 口的这种数据库，像那个 mango d b， 呃，这个 redis 它们呢？就是原来都是。呃这些企业里面， noseco 它的这个能力，包括 jason 的这种支持力度都会比较强，而且已经在现有的这个生产环境中了，那么它就不需要再增加一些其他的一些基础设施啊，它只要在这个芒果 d b 或者 redis 上 直接用这些像量的这个操作他就可以了啊。但是这种的话呢，就相对来讲啊，他的这个像量效率不是太高，所以的话呢，他的速度不会太快，他这个是他的最最大的一个问题，但是他的好处是在于，因为这些基础设施 在一些企业及或者一些在互联网公司用的是非常频繁，工程师对他的 a p i 会比较了解，所以直接用这些做一些短平块的应用是没有问题。还有最后一类啊，那么就是传统的关系型的 c 口数据库，像以这个 click house 啊，呃， post gray c 口啊，他们也加上了这个 适量的这些功能，那么这些数据库的话呢，就是相对来讲比较强大，功能会比较强大啊，他也能够支持这种各种各样的适量的搜索啊，各种各样的操作啊，包括他也能支持 cicle 的各种各样混合的这种查询，所以他会比较强大一点，但是呢他呢就是消耗的资源会比较多 啊，性能会比较好好一些啊。这个是第一部分啊，我会给大家简单介绍一下目前向量数据库的五大种类啊，和各自的一些优缺点啊，他的也是这样，我们在开发过程当中的话，我们一般都会用那个连线这样的一个开发框架。我们看一下那个连线里面，目前他支持的向量的数据库的话也非常多 啊，前面我讲的这些主流的这些他基本上都能支持啊，像我前面讲的那个 click house 啊，这个也是我后面会呃建议大家去用的啊，包括 elastic 社区。嗯，这个的话呢，我们回头会看一下，它的性能 要比克力 cos 慢很多，所以我们一般一般不太会建议用。还有一个呢，就 fis。 呃， fis 的话，如果你的应用比较轻量级，我们也是建议用的。你只有本地一个应用啊，你做的一个比较轻量级的一个本地数据库的话，我们建议你用这个的，因为 fis 的话，它的性能也是非常好的，你做几亿条的这样一个时时量 数据库，它作为一些检索的话，它一点问题都没有的啊，它的性能还是比较强的，包括像阿拉里的那个 horror grass 啊，它也是能够支持的。国内的这个 mirrors 啊，它也是支持 mango d b。 对啊，所以的话呢，用那个 lanchen， 它有一个比较大的好处，就是它各种各样的质量数据库它都能够支持啊， 包括 post graceco， 增加了一些项量的一些操作，它都是能够支持的。 redis 啊，它也是能支持的啊，这些基本上包括国外一些主流的，基本上都是能支持的啊。好啊，这部分是第二部分啊，我们跟大家讲一下，如果你用那个开发框架，用连线的话，如果你要去把 ps 改成 click house， 它的代码很少，它只要两三行，稍微改一下，你就立刻马上能转成啊，不同的襄阳数据库的支持啊，所以的话，用一个好的开发框架也是比较重要的啊。这是第二部分，第三部分，我们还是要去对比 以下目前这个项链数据库的这个性能，因为主要我们选性，注意技术来讲，性能也是比较重要的。嗯，我们讲的前面五大类，嗯，像传统的 mexico， pre， pregrace， cycle， 对吧？加上项链，包括 cicle， light， mango d b and no cicle 的这种解决方案， elastic search， 包括还有一些就是像 duck d b 啊， click house 啊， 目前看下来，这个 kcox 的性能是最好的。呃，它在整个一个限量数据库里面，包括在 cicle 查询里面，它的性能是最好的，它的性能是 mycicle 的一千倍， 呃，是 paris po pose crisical 的四百零三倍啊，它是 mango d b 的一百二十八倍性能，然后它是 elastic 摄取的三十三倍， 他是一些主流的这个一些，呃，比较流行的一些使量数据库的至少十几倍，他是等于是这样啊，所以的话呢，我们一般如果是企业级，如果你要大规模用这个，要分布式用这个 矢量数据库的话，那么我们一般建议你们用 click house。 还有一个也是蛮好的，是一个国内的叫 star rocket 啊，有些公司因为也是用的用这个作为一个查询的引擎啊，那用这个解决方案也是不错的啊， 如果你用全文检索，你一定要用的话，当然那 click house 也能支持全文检索的，但是如果你的生产环境里面已经要用 呃 elastic 社区作为全文检索的话，你万不得已的话，你也是可以临时的用一用，但是它是比 click house 呃的性能要差呃， click house 的性能是它的三十三倍，它等于是这样，所以的话，我们一般建议的话，从性能角度，从功能角度，我们一般建议两个方案，一个方案的话呢，就是用 fis 啊，就直接用开源的这个内裤在本地上创建使量数据库。另外一个方案的话呢，就用 click house， 这两种方案基本上能够满足你绝大部分的应用场景，而且性能相对来讲 是比较好的啊，他那个是这样好，我们再来看一下，就是有人呃，也是讲有人可能会用那个国内的这个啊 maraus 啊，因为他们也拿到了融资，也是开源的，也是一个非常高性能的这样的一个实量数据库。但是你去看啊，他的底层我也看了一下，他的本质上他用了一 它用了三个开源的库啊，一个呢是 fals 啊，就是我前面讲的 f a r s s 啊，是 facebook 开源的这样一个库。另外一个它是基于图检索的这样的一个锁引，叫 h a s w 这样的一个内裤，它是支持性能非常高啊，但是它会消耗大量的内存的这样的一个开源的一个 基于向量检索的这样的一个内裤。还有一个呢，它是基于这个竖竖向量的这个锁引，它叫 a n n o y 的这样一个内裤。那么这个内裤的话呢，它比较支持一个，就是它的维度比较少的这样的一个使量啊，它是比较适合。 当然他也有一个不好的地方，就是他用的内存虽然比较少，但是他用的资源会比较少，但他还有一个问题，他的那个召回率会比较低，就是召回率是指应该查得到的数据啊，他没有把他给，没有把他正确的给检索出来，所以这种锁引的话一般用的会比较少。 a、 n、 n、 o y 的这种缩影用的比较少，用的最多还是 fierce 的这个缩影用的是最多的。呃，当然它的消耗也会比较大，呃，相对来讲它的消耗也会比较大，但是它有个好处就是啊，它的照顾率会非常高，它都能 检索得出来啊，他等于是啊好这个。所以 maros 他底层也是用了这些开源的这些内裤，但是他呢在这个上面又封装了一些架构啊，相对来讲啊，他的这个架构是比较方便的啊，他可以切片呐，他可以备份呐，实实的啊，他可以跟你的消息对列做对接，他还有一些管理界面啊，这个是目前新 新的这个质量数据库的这样一个好处，但是他的唯一的不好的地方，我前面也是讲的目前这些质量数据库的，他的那个 c 口的功能会比较弱啊，如果你要做一些呃质量数据库跟 c 口结合过滤的一些查询， 这个就不太合适了，适量数据库就会性能就会非常差啊，他等于是这样好了。好，所以我今天这个话题就跟大家就交流到这啊，今天主要还是跟大家讲了一下，如果我们在呃 做一些知识库的话，我们要选择一个时量数据库啊，那么我们应该怎么选型啊？应该怎么用啊？好吧，大概跟大家就介绍这些，如果大家要用可以看一下那个连线的这个框架啊，相对来讲容易用的啊，他还是比较容易，因，因为拍摄的代码本身就很少啊， 他就大概十行代码之内，基本上你就可以把你的这些功能都能做完了。好吧，好，今天的话这个话题就跟大家就聊到这了。

我们知道在麦收扣里面，库对面是文件夹，表对面是文件，对吧？再来看一下安装部落 对他们演讲，还是 d b 六这个苦，我们有一个 com 表，这里就对有两个 com 文件 f r m 我们之前说过是表结构文件， i b d 是表数据文件， 更准确的说应该叫它表空间文件。需要注意的是，在八点零之后的版本，表结构文件就不在 fm 里面了，而是存在的一个 s i d 字典里面， s i d 又仅存在 ibd 表空间文件里面，所以在八点零之后，一张表就只对应了一个文件，就是 ibd 结尾的表空间文件。但在八点零以前，表结构文件和表空间文件就是分开的表结构文件 fm 表空间文件 abd。 当然表空键文件里面除了记录数据之外，所应也是存在表空键文件里面的。 ok， 这个清除之后，我们再来看一下 indeed b 的存储结构，刚刚我们说一张表就对应一个表空键文件，对吧？这叫 table space。 然后每个表空键文件里面又分为多个 segment， 这叫段，然后一个段里面又包含多， 这个叫蛆，然后一个蛆里面又分为多个配置，这个叫液。当然液里面还分为所营养数据液，这个我们后面讲，所有的时候再说，然后一个液里面又分为多个肉，也就是行， 这个行就是我们常说的一行数据，或者说一行记录，然后在一行里面又分为这几个信息。最后一次操作收入的 id， 然后是相关的指针，接着就是断了。在印度地币逻辑结构里面，一个区的大小固定是一兆，然后一个页的大小也是固定的，是十六 k， 所以说一个区可以有六十四页，而且也是印度 db 指盘插座最小单元。 ok， 这就是印度 db 存储结构，你先一个了解。