数据库的选型以及mysql的特点_图数据库有哪些有点特点，如何选择图数据库？...

自荐下 Nebula Graph：一个开源的分布式图数据库，主要特点

存储计算分离

对于 Nebula Graph 来讲，有这么几个技术特点：第一个就是采用了存储计算分离的架构。这样架构主要的考虑其实前面几个 Talk大家都已经讨论了很多，主要好处就是为了上云或者说 弹性 ， 方便单独扩容 。上午的 Talk：HBase on Cloud 也有提到，业务水位总是很难预测的，一段时间存储不够了，有些时候计算不够了。在云上或者使用容器技术，计算存储分离的架构运维起来会比较方便，成本也更好控制。大家使用 HBase 那么久，这方面的感触肯定很多。

查询语言 nGQL

Nebula Graph 的第二个技术特点是它的查询语言，我们称为 nGQL，比较接近 SQL。唯一大一点的语法差异就是 不用嵌套 (embedding)。大家都知道嵌套的 SQL，读起来是非常痛苦的，要从里向外读。

支持多种后端存储

第三个特点就是 Nebula Graph 支持多种后端存储，除了原生的引擎外，也支持 HBase。因为很多用户，对 HBase 已经相当熟悉了，并不希望多一套存储架构。从架构上来说，Nebula Graph 是完全对等的分布式系统。

计算下推

和 HBase 的 CoProcessor 一样，Nebula Graph 支持数据计算下推。数据过滤，包括一些简单的聚合运算，能够在存储层就做掉，这样对于性能来讲能提升会非常大。

多租户

多租户，Nebula Graph是通过多 Space 来实现的。Space 是物理隔离。

索引

除了图查询外，还有很常见的一种场景是全局的属性查询。这个和 MySQL 一样，要提升性能的主要办法是为 属性建立索引 ，这个也是 Nebula Graph 原生支持的功能。

图算法

最后的技术特点就是关于图算法方面。这里的算法和全图计算不太一样，更多是一个子图的计算，比如最短路径。大家知道数据库通常有 OLTP 和 OLAP 两种差异很大的场景，当然现在有很多 HTAP 方面的努力。那对于图数据库来说也是类似，我们在设计 Nebula Graph 的时候，做了一些权衡。我们认为全图的计算，比如 Page Rank，LPA，它的技术挑战和 OLTP 的挑战和对应的设计相差很大。我们希望 Nebula Graph 能够在 OLTP 这块提供最好的表现。

目前只是 alpha 版，可以上到生成环境的 beta 版本将在下个月发布，欢迎给我们的 GitHub 提 issue 来和我们交流~vesoft-inc/nebula​github.com