同花顺图数据库选型：消息面、基本面、技术面原创

呃，刚刚其实前面两位都是从他们的产品角度来介绍，然后我们这边其实是作为一个意向用户的角度说来，呃。介绍一下我们这边是怎样来考虑使用一个数据数据库的产品，以及我们会从哪些方面去做这个去去参考，呃，我们现在的。就自从我们公司呃，开始了这个知持客流战略之后，我们这边使用的是那个后的一数据库，但是就是在现在的一个使用过程中，呃，为了就觉得接接触的业务越来越多吧，然后会发现没有说他可能已经不太能支撑我们线上业务的一个发展趋势。所以不得不在呃数据库和应用层之间加了很多很多的缓存，然后导致呃大家其实如果呃多技术的话，可能也知道加缓存呃除了带来一些性能弹能提高之外，他还会引引入更多的问题，所以就想着说有没有有没有一款一款数据库能够直接来支撑我们的一个业务，所以我们这边就是来做了这么一个转型。

呃，主要是从以下这几个角度来讲一讲，就是我们这边的一个数据库应该怎么选，然后从哪去选，从哪些数据库里去选，以及为什么去选择，我们决定要选择这个，最后是我们的一个，呃，一点思路吧，介绍一下我们自己的团队。呃，选型依据来说，我们这边主要有呃这么一些选型的依据吧，就最重要原来是说功能性能上面是强大，然后呃在三样领域应该是一个成熟的产品，然后它的一个社区必须是活跃的，不是那种呃半死不活的，然后能够支撑的数据量，呃是可以满足我们现在以及未来呃很长一段时间之内的一个发展的。

当然满足以上条件之外，还有一些就是说你最好是开源的，然后国产的话也是好的一些因素，然后可以很方便的得到一个一些技术支持。呃，其实选数据库感觉跟选股票感觉也是有一些类似的，类似的，然后选股票来说，我们这边一般会考虑消什么样的一些消息面啊，或者说他的一些基本面，或者呃，还有一些在技术面，当然当然这个只是套用了技术面，股票的技术面跟我们现在这个技术面可能不是一个含义。就拿呃，消息面。但是呢，一般我们选从数据库来说，选数据库来后来说，一般都会去上一个网站，就是一个BB的一个网站，它里面会有很多很多数据库的一个排名，呃，这是我截出来的和图数据库相关的一个排名，然后主要有30多个。

呃，我们可以看到就是排名第一的一直是中国，这他其实已经大，已经大了已经很多年了，因为他出来的比较早，呃的确他在商务领域是比较成熟的一个产品，但是呃从我一圈调研下来的话，发现其实呃他可能。至少是在营销方面可能是做的非常不错的，比如说你在百度上面或者谷歌上面去搜图数据库，呃，都会在那个页面的右手就会收到他的广告，然后其他的一些可能就是听说的就是会少一些，但是也有一些比较出名的，像group这种也是比较呃开源的比较出名的一些产品，呃，我们要在这么多的一些呃数据库里面去选择我们最终要使用的一个产品，然后那我们会去考虑哪些方面呢？大。这个后面再说，先先先讲讲上面那个他的一些问题，就是D键是他的排序规则，大家可能不是很了解，然后他的排序的依据是有这么几项，一个是呃，不同的网站，这上面的一个P级情况，他参考的是谷歌和那个BNK2个搜索引擎的一个搜索搜索，然后呃。

还有就是呃，谷歌的一个Google的这么一个系统里面的这个这个关键词的一个趋势。或者还有是像还有这种，呃，一些出名的技术，技术网，问答网站的一些关键词的一些数量。还有就是呃，像这种找工作的网站里面的一相关岗位。数量，这这里是在语语音语音里面的一些专呃职位的数量，以及在社交网络里面，主要是推里面的一些具体数量，但是不管你上面哪些哪些产品吧，呃，大家发现一个问题没有。

在这这这些这些产品在国内要么是不存在的网站，要么就是一些非常小众的一些一些网站，所以呃，对于对于上面的这些排名，对于国内的一些呃产品来说，其实是有是偏过的，至少他的数据肯定是不能反映他的一些真实情况的。如果如果考虑到国内的一些使用情况的话，这里面呃，像六是排不出的，以及是会我们公司那那说的他们的排名肯定要上升好多。然后呃，这边是其实是一个就基本的一些筛选通过，呃，参考我P里面的一些呃，基本情况，基本基本消息吧，然后做了一些简单的过滤，就下面这些呃。

数据库其实是，呃，从消息层面来说，就是不满足我们现在的一个需求的。当然也佐证了，就是说。上面这上面的这个排名其实是不是准确，因为排名在我那前面的一些数据库，它的它甚至是已经是一些不活跃的一些一些数据库。有，有些可能已经很久很久没有更新了，但是他的排名还是在在前面，还是非常靠前的。呃，这些信息都是大家那个里面的一些公开的信息。然后呃，过滤了前面的那些数据库之后，上面就呃选择出了这么123456个数据库，然后来加入我们一个基本面的一个筛选。

然后我们主要考虑他是他的一个呃版本的发展情况，他的一些利润的能力，以及他的一个一些活跃程度等等。这边我们看到其实呃。相对来说还是都是比较活跃的一个，呃版本的发布模板。然后他的支持的语言啊，一些系统啊什么的，基本上都是说在我们选择范围之内。这里是呃，他在不同数据库的一个呃能力情况。就我们可以看到，就是至少他在。2007年就成立了，所以他这边的支持上面可能是会更完善一些，然后我们呃这边是按照一个时间排序的，一个时间排序的，然后可以看到右网前面的他其实支持的一些，呃，语言也好，或者他的一些系统也好，其实是会更完善一些，呃这一块可能是我们这边作为一个后起之秀吧，可能需需要去完善的一个地方。

呃，然后这里面其实呃，像是q block也好，还是说这个东西也好，它其实很多能力其实也也也只是在方向版的上面去做，然后这个的话，我们如何去考虑是不是要是不是去使用他们的一个商业版本，以及他们的一些定价版本情况。呃，这。上面还是他们的一个不同，对不同的一些人力的一些支行嘛，然后这个比较有意思，可能是他每一个每一个产品，它支持的一个呃数，支持的一个量级，这边会把它支持的量级给他标了出来，然后比如说它支持的是一个编百，百万级别的一个节点，以及千万级别的一个关系，呃毫毫秒，毫秒级别的一个详细时间。

然后这个滴滴的话，他这边。这可以大家可以看到这个数字比较比较夸张，然后基本上应该是呃。支持支持那个无无无限量的这么一个量级个情况，我我不确定他这个是怎么是怎么做到的。但这这的确是他在官网里面，呃。就是那个官方老师网站里面提到的一个情况。呃，低，他并没有明确的一个说之前的数据量的情况，他只是说提提供一个谷歌的生产级别的一个，呃，支撑，然后。可以支持一个实时的查询。以及TB级别的一个结构化数据。

然后后面两款是一个是百度培养的，一个是我们的贝这边培养出来的两个产品，可以看到贝这边其实还是比较占占有优势的，他提供了千亿个对1万亿条边的一个一个支持循况。OK，呃，这里面还有个问题啊，呃，在那个电里面，呃，可以看到他在这边是支持一个ACD的一个事务的，但是我在官网里面好像看到是说那个这边是不支持事务的，这个可能等会需要这边再线下再沟通一下这个问题。呃上其实从上面的一个分析情况来看，呃并没有一个呃非常明确的一个胜出者，所以我们这边呃又考虑它的一个架构的一个一个情况，然后来看每一个在架构上面是更优的，这边只考架构的一个灵，这一个QB和因为呃。

这边呃，其其实是T的一个是其实是的一个版本，是有尽量把它当对比，以及是以及这个从从他的一个官网以及设施情况来看，其实呃并没有很很强的很好的一个技术支持情况，所以也把它做，把它做忽略了，这里面可能因为编辑问题上面没有没有展示出来。在战斗上面说我们抽奖就说这个说那个，以及呃，Ne做了一做了一个对比。那工具它是它是在架构上面，它是只支持一个重构的部署，呃就是说它不能在在异构的一些机器机群里面，它是不能够搭挥每一个每一台机器它的一些特异性的能力，比如说你有的机器它可能是计算机型的，有的机器可能是呃发用能力是比较强的，那那个东西函数不足的话，可能就需要每一台机器它都是呃都都都是等同的一个一个情况，然后他这边提供的一个分析以提成的能力的话，是通过这两个呃。

呃，他的一个虚拟服务器，它它提供了一个分区，分区的能力，呃，这这些都是三法的一些能力。在架构层面的话，我感觉可能huge gra跟ne他这边，呃，存储计算分别这种架构可能会更优越一些，至少说我们可以针对性的去给每一个不同的不同的模块去给他做一些呃相应的一些机器实别的配置。嗯。比如说这报他这边，呃，他就是存储引擎是可以是任意的，不也不是任意吧，就是很多很多第三方的一些存储引擎，然后他在上面加了一层自己的一个，呃呃计算引擎的框架，在在上面对接了111堆的那个，呃。

这个不是这外的些接构接构层。然后他还包括一些OTP和OOAP的一个，呃，数据分数分析的能力，这个的话也是构用在它底层的一个大ug，就相当于说它的存储引擎，其实用的其实并不是用的他自己的一个存储存储引擎。呃，这一点我感觉就是可能。并没有说可能不会像一样，用一个自己的存储引擎支持来的，呃，会更贴合一擎，比如说他这边假假入这储引擎一个h base的一个引擎，那我们知base它其实它的一个呃。就是实时，实时性其实是非非常差的。

就就会影响到他的上上层的一些一些性能。嗯，Ne这边的话，它其实也是用了这么一个存储计算以及呃，服务分离的一个架构，它每然后这边是一个原数据图，每一层都是可以可以无限扩展。比如说你层层存储不够，那你可以扩展存储层计算，计算里面行，你可以去扩展技术计算层，这个我觉得在架构层面可能应该还是比较新进的一个架构。呃，分析完了呢，就是从价格层面分析完了之后，我们这边呃，参考了友商的一些，呃性能测试，以及我们自己当年年也做过的一些，呃，这个是他们腾讯的团队做的，现场可能也会有腾讯的同学。不知道经不经，我用你们的这个数据来做这么一个产品，呃，他们这边做的可能应该还是比较划算的，但是他们的测试的版本比较早，应该是一点几个版本。

他们就基于那个那个版本去做了这么一个测试，然后。呃，可以看到就是呃，在基本上在不同的数据量级上面，我这边其实都是一个在分的一个情况。呃，测试的这个是他美团话在做的一个一个测试。但是给到他们这边，呃，我们他做的是那个block和block的一个对比，然后在各个在各个对比下里面，其实这边都是一个在的，但是在Q里面，他用的是他用的底层的擎配，然后和这边他用的这擎都是那个呃log log PP，然后就在这里，在这里面那个它其实是不占优势的，就像我刚刚提到的，它在实时查询上面，实时查询的上面其实是其实是不如那个上们两个那个P的一个关现就是那个KB数据库，呃数询能传的，所以他在这边会有一个量子上的差距，如果呃数据库层面的。

如果说这个层面能够达到分中，分中有些层面是一致的话，我觉得他这里面不应该会有这么大一个量级的差距。呃，下面这个是我们自己这边做了一个一个测试，我们这边主要是结合我们呃实际的一个使用产品吧，然后这对于我们的一些线上的数据做了一个编方的测试，然后我们这边呃不仅仅是说对比了各个数据库，我们还对比了嗯，这边他提供了两种查询语言，一种是呃。呃，三是和那个ne，呃，那个如三认识的一个查询语言，是那原生的一个查询语言，然后我们这边就是对比完之后发现，呃。

NGQ原的查询里面，在现能上询会比使用这种open赛的一个查询里面，现能上询会有大概500毫秒的这么一个差距，呃，不知道这这是不是一个正常的现象，这个可能也需要现在等会再那个再沟通一下这个问题。然后那来这的语言的话，呃，可能对三跳五跳这种支持可能呃语法上面学起来会比较复杂，需要用到管道，管道图这样的一些语法，所以我这边就没有去做测试。然后呃，这个是十个线程，这个是20个线程的好，然后他可以看到我们这边现线程数的增加，它的呃产业QPS也好，还产业时间也好，其实都是产一个线增长的趋势，可以看到就是并没有20并没还并没有完全发挥出有的一个一个一个能力，可能还可以继续往上，继继继续往上涨，然后来不断的探索他的一个能力，能力的边界，性能的性能的边界组嘛，但是我并没有往后做，为什么呢？因为呃我发现就是在基本上在20个线程的时候，呃员说这一它其实就已经存在了一些超时的情况，如果如果是无在无效情况下面，因为或者这么上都是一个超时了，就已经没有必要再进行下去，再说再去做最进一步的一个测试了。

呃，这个是我们这边测试的一个情况。呃，可以看到就是我们这边在限制的性能上面，对比这个后续来说，还是有比较大的一个优势的。然后这个结论怎么选，应该应该是不而越的综合考虑，从架构性能或者说一些社区等等情况来看的话，呃。

可能还是会就是使使用一个更更更更适合我们的一个数据库吧。当然在呃使用过程中，我们还还是发现了一些一些小问题，然后比如说他的一些标识服是不是中文，以及以及其他的一些文，或者看了一下，看了一下他的那个那这边的一些源码，发现他是从那个。那就语法那个司法解析层面都不支持了，这个如果后面要做国际化的话，可能这一块我觉得应该是比较重的一个问题，包括其他的一些语言，不只是中文，可能这一块也是需要支持的。然后错误语法提示，提示不够友好，没法很精确的，比如说我有语法错误的时候，没办法很精确的定位到我出错位置。呃，然后呃，使用转va驱动的时候不支持参数法查询，当然这个问题，这个问题倒不大，因为参数法查询自己封装一下也不是什么问题，然后呃，够查询的话，就就是那个NGLNGQ查询的话必须指定一个起点的ID，呃，这个可能不太合我们现在的一个实用场景，因为我们现在都是从一些属性的查找去出发，然后做做几点去查找。

当然这个可能也可以结合像盖这样的一些查询去，再通过广告主的里面去做做这个。就满足我们要求。然后我我们这边是问他呃同行商会团队，日图团队，我们呃主要准备下业务是包括我们呃智能对话，呃推进系统，搜索引擎，投资策略，以及呃无票亮点啊投投资顾问投效多这样的一些业务，呃后面可能接入接入的业务还会有更多，呃当前我们维护了这么几个图谱，一个是产业链的图谱，就呃数据白表是有一些都都是一些公开的这样的数据，然后通过一些呃一的抽取，然后来来构建出来的一个产业面服库。

然后派供应链的祝福。那我们人物关系的图谱以及企业图谱，呃，上述上上述的图谱都是我们这边呃，团队通过一些公开的一些数据来源去抽取来构建，呃，构建出来。呃，满足就满，呃满足我们这边的一些金融投资的一些需求。我这边介绍家，谢谢大家。