修改密码

请输入密码
请输入密码 请输入8-64长度密码 和 email 地址不相同 至少包括数字、大写字母、小写字母、半角符号中的 3 个
请输入密码
提交

修改昵称

当前昵称:
提交

申请证书

证书详情

Please complete this required field.

  • Ultipa Graph V4

Standalone

Please complete this required field.

Please complete this required field.

服务器的MAC地址

Please complete this required field.

Please complete this required field.

取消
申请
ID
产品
状态
核数
申请天数
审批时间
过期时间
MAC地址
申请理由
审核信息
关闭
基础信息
  • 用户昵称:
  • 手机号:
  • 公司名称:
  • 公司邮箱:
  • 地区:
  • 语言:
修改密码
申请证书

当前未申请证书.

申请证书
Certificate Issued at Valid until Serial No. File
Serial No. Valid until File

Not having one? Apply now! >>>

ProductName CreateTime ID Price File
ProductName CreateTime ID Price File

No Invoice

搜索
    中文

      RDBMS/SQL的问题

      关系型数据库RDBMS的查询语言SQL出现于上世纪80年代,并且已经迭代了很多版本(平均每3-4年一次大迭代),其中最知名的非SQL-92、99莫属,例如:

      • 92版中在FROM语句中增加了子查询(subquery)功能
      • 99版中增加了CTE(Common Table Expression)功能
      SQL-92 的子查询功能(左)和 SQL-92 的 CTE 功能(右)

      上述两项功能虽然在原先基础上极大的增加了关系型数据库的灵活性(如上图所示),但SQL始终有一个很突出的弱点,就是对递归型数据结构(Recursive data structures),即关联关系的查询的支持非常差。由此引发的关系型数据库系统RDBMS与SQL的问题可以归纳总结如下:

      • 多维关联、递归查询的SQL代码极为复杂
      • 多表关联查询效率极低,很难实时进行
      • 复杂查询可解释性差,存储进程“黑盒”
      • 由集中式改造为分布式架构也很难应对金融场景中的“长链”交易、复杂查询等
      关系型数据库(数仓、数湖)遇到的问题

      以上这些问题的本质是关系型数据库在实现关联查询时不得不依赖表连接(table-join)操作,每一次多表关联都意味着潜在的表扫描操作,以及因为“笛卡尔积”问题而导致的性能的指数级下降和SQL语句、代码的复杂度的直线上升。特别是在牵涉到大表时的笛卡尔积问题,会让计算复杂度以乘积的方式增长。

      举个具体而常见的例子,在银行业中的指标计算与归因分析,会涉及明细数据、分行-支行、条线、客户经理、指标子项、客户账户信息等多个维度的综合计算。用SQL和关系型数据库来计算的复杂度是个天文数字;而用图计算来建模和实现,是加和而非乘积的关系——两者之间存在着指数级的性能差异。换言之,用SQL来实现,会耗费大量的计算、存储资源,并且效率非常低下,甚至无法完成。但是用图计算来实现,可以做到实时,并且耗费很少的资源——更低的TCO,更高的ROI。这就是图数据库的颠覆性优势之一:性能。

      关系型数据库(数仓、数湖)中表连接导致的笛卡尔积
      请完成以下信息后可下载此书
      *
      公司名称不能为空
      *
      公司邮箱必须填写
      *
      你的名字必须填写
      *
      你的电话必须填写
      *
      你的电话必须填写