转 读“应对万亿数据上亿并发！字节跳动的图数据库研发实践 ”，

文章来源：

http://news.sohu.com/a/436996958_411876

图数据库的开发设计，是对点、边、属性这些数据内容的存储。

典型的存储数据模型理解：

需要用户完成类似的数据模型抽象，但图的数据抽象更加简单，基本上是把数据之间的关系“翻译”成有向属性图，我们称之为“构图”过程

如果想把用户关系存入 ByteGraph，第一步就是需要把用户抽象为点，第二步把"关注关系”、“好友关系”抽象为边就完全搞定了。

典型的架构分层可以包括：查询层、内存存储层、磁盘存储

针对字节的特有场景：万亿数据、上亿并发

关注了几个重要的针对性设计：

1. 热点数据同时读写
2. 热点读
3. 热点写
4. 图索引

一些针对性后续研发考虑

• 从图存储到图数据库：对于一个数据库系统，是否支持 ACID 的事务，是一个核心问题，目前 ByteGraph 只解决了原子性和一致性，对于最复杂的隔离性还完全没有触碰，这是一个非常复杂的问题；另外，中国信通院发布了国内图数据库功能白皮书，以此标准，如果想做好一个功能完备的“数据库”系统，我们面对的还是星辰大海；
• 标准的图查询语言：目前，图数据库的查询语言业界还未形成标准（GQL 即将在 2020 年发布），ByteGraph 选择 Apache、AWS 、阿里云的 Gremlin 语言体系，但目前也只是支持了一个子集，更多的语法支持、更深入的查询优化还未开展；
• Cloud Native 存储架构演进：现在 ByteGraph 还是构建与 KV 存储之上，独占物理机全部资源；从资源弹性部署、运维托管等角度是否有其他架构演进的探索可能，从查询到事务再到磁盘存储是否有深度垂直整合优化的空间，也是一个没有被回答的问题；
• 现在 ByteGraph 是在 OLTP 场景下承载了大量线上数据，这些数据同时也会应用到推荐、风控等复杂分析和图计算场景，如何把 TP 和轻量 AP 查询融合在一起，具备部分 HTAP 能力，也是一个空间广阔的蓝海领域。

待续....