曾经 ， 针对图数据库查询语言问题 ， 处于江湖混战的局面 。 比如：开源届主要是支持Apache Tinkerpop的Gremlin,但Gremlin太过复杂 ， 导致用户写起来很痛苦 。 用户的使用习惯 ， 一直更偏向于SQL ， 为了让用户快速上手 ， TigerGraph选择使用GSQL进行查询的路线 ， 这是一种类SQL的语言 ， 真正实现了语言的标准化 。
【对话TigerGraph郁介斌博士：图数据库在5-10年后取代关系型数据库】众所周知 ， 继SQL之后 ， GQL（图形查询语言）成为ISO/IEC国际标准数据库语言 。 那么 ， GQL是怎么形成的呢？其实 ， 从2016年开始 ， Oracle、TigerGraph、Neo4j就在美国标准委员会开始讨论扩展SQL ， 支持图属性 。 到2019年9月 ， 国际标准（ISO）正式批准立项 ， 把GQL定性为图查询语言的标准 。 其中 ， TigerGraph的GSQL多图、模式匹配等相关的创新被采纳 ， GSQL完全支持GQL 。 GQL的标准化 ， 进一步证明了TigerGraph查询语言选择的正确性 。
除了查询语言问题 ， 底层的系统层面要做好支撑 ， 这是实现规模化扩展的前提 。 图数据库不像传统的关系型数据库 ， 可以灵活地替换底层的数据库厂商 ， 图数据库项目一旦进入方案设计 ， 就无法平滑替换底层架构 ， 除非重构 。 大部分图数据库厂商都在应用层面做相关部署 ， 而在底层技术上却少有投入 ， 这也是即使是头部图数据库厂商 ， 也无法跨越性能瓶颈的最根本原因 。 TigerGraph的核心团队很多是来自Teradata,在大规模并行处理数据库方面有着深厚的经验积累 。 这也是TigerGraph更具性能优势的最根本原因 。
TigerGraph还进一步简化了工作负载的处理 ， 带来了大规模集群处理能力 。 TigerGraph的图数据库解决方案 ， 具有批量导入的性能特点 ， 每台机器可以每秒实时加载 ， 能快速更新几千个点和边 ， 可以满足图算法和存储需求；TigerGraph 的产品具有实时分析能力 ， 能在亚秒时间里执行 10 多步查询 ， 大大提高了数据分析的时效性；TigerGraph提供的解决方案 ， 能深度理解复杂业务场景需求 ， 可以支持数据图谱相关的完整工作流 。 在大数据时代 ， 可获得的数据越来越多 ， 单机容量有限 ， 只有具备一定存储和查询能力的图数据库 ， 才能从根本上满足用户在性能、容量、计算以及灵活扩展方面的需求 ， TigerGraph在简化应用以及可扩展性方面 ， 做了大量创新 。
时代在发展 ， 数据库也在不断演进 ， 传统关系型数据库一统天下的时候 ， 没人想到NoSQL、NewSQL会出现 。 现如今的图数据库 ， 正走着NoSQL、NewSQL走过的路；只不过 ， 图数据库更能代表未来！
5-10后取代传统关系型数据库
“5-10年后 ， 图数据库可能会彻底取代传统关系型数据库！” 郁介斌博士给出一个大胆预测 ， 他认为所有关系型数据以及非关系型数据 ， 都可以用图谱来表达 ， 因为灵活性是推动图数据库激增的关键因素 。 尤其遇到多对多、高价值关系以及有大规模低延时需求的场景 ， 图数据库带来了无与伦比的差异化优势 。
多对多场景：在《设计数据密集型应用程序》一本书中提到 ， 如果问题中频繁出现多对多的关系 ， 建议使用图表 ， 因为关系型数据库难以处理好这些关系 。 比如：在金融业务领域 ， 有一个反洗钱的交易 ， 从A到B ， B到C ， C到E ， E到D和F ， D又到B 。 洗钱的过程更像是一个环 ， 每一笔交易点都会关联两个人 ， 如果把交易都记录在一张表格上 ， 这叫关系型数据 ， 我们很难看出这个环 ， 因为每个数据都是独立的 。 如果跳出表格 ， 从节点来看 ， 假如每一步操作都相同 ， 我们很自然地看到整个链路过程 ， 这就是图来表达的数据形式 。 尤其在跨度很大的反洗钱行动中 ， 交易数据急剧增加 ， 表格计算根本检测不出来 ， 而图数据库能快速识别和防范多样化的欺诈行为 。