现在很多公司只是要展示出个图的样子展示在页面上就选择图数据库在我看来是不明智的，因为图数据库目前正在发展阶段，语句什么的都没有形成标准，引入的话势必造成很多不确定性。更因为展示和数据表示其实是分离的，使用关系型数据库同样可以表达出图形式的关系。真正使你下定决心使用图数据库的应该是你要探寻数据之间的联系，也就是多跳下的搜索，或者说探寻现有数据中隐含的关系的这种业务场景。
介绍下我做知识图谱在选型方面的经历 开始一脸懵逼，开始百度，直接就搜到了neo4j，实际使用中，文档以及相关的技术博客都比较多，可以说是比较成熟的技术了，但是开源版不支持多schema，以及分布式，我想的是这可能为以后数据量大了，造成扩展性方面的问题。
各种搜这期间接触到了neo4j，janusgraph，dgraph，hugegraph，oriantdb等等，也看了多篇文章，期间也重点研究了hugegraph，dgraph，neo4j，janusgraph。其中排除了hugegraph因为社区不够活跃，问题解决的速度不是非常迅速，感觉百度不是特别重视似的。后续又排除了dgraph，因为dgraph是国外的框架，虽然还不错而且使用了graphql，说实话还是挺有吸引力的，但是如果引入的话由于国内社区不是非常完善，很多资料需要翻墙才能获取，会给我自己和同事造成困扰，犹豫再三还是放弃使用了。最后再说janusgraph这个框架有点年头了，看了看它的整体架构，部署起来非常复杂，是建立在很多第三方组件上的，运维部署负担很重，用起来肯定会心累所以也没有选择。
最终一次偶然搜索，发现了nebulaGraph，期间看了看成立时间说实话还是有点担忧，毕竟成立时间不是很长，使用上功能点不够齐全势必会发生。但是看到社区非常活跃，大佬们回答问题都非常积极，以及开源支持的功能点，目前还是非常满足我的需求的，在进行了大致的业务方面测试后还是果断选用了，有的话后续进展以后会更新。。
