因此行存储大多用在SQL的TP场景 , 而列存储基本用在NoSQL的AP场景 。 这背后的原因也很简单 , 还是以银行业的情况为例 , 联机交易的TP场景下比如当客户取款时 , 会校验用户、账号、密码、余额等信息 , 这些信息都是以行为单位存储的 , 联机交易中数据是经常是以行为单位访问的 , 把数据放在一行就会有访问速度的优势 。 但是在统计、分析营业报表 , 进行数据挖掘等AP场景下 , 往往只需要关注交易金额、账户余额等少量几个维度的信息 , 而不需要用户、账号、密码等这些数据 , 而在这种场景下将同一维度信息放在一起的列存储方案就有很大的速度优势了 。
将行列进行混存 , 综合两者的优势 , 这方面业界倒也有不少尝试 , 但往往都不很成功 。 其最大的问题还是在于对于联机TP交易场景来说 , 列式存储的写入性能太低了 , 所以一般来说传统的方案往往还是退化成为行式存储TP数据库在交易量少的日终时刻 , 将数据吐给列式存储AP数据库进行数据挖掘 。
TiDB数据库没有用双写方案 , 而创造性的将行存储与列存储做成一个基于一致性协议的集群 , 这样的做法使TiDB数据库行列混存的方案避免了之前列存储写入带来的性能损失 。 而且一致性集群还保证了列存储与行存储之间的数据差距不会太大 。 而且这种方案还把任务分配的工作完全封装在了管理节点内部 , 用户根本不用关心数据库的机制 , 更不用关心SQL到底是AP还是TP任务就能享受到混合负载的双重优势 。
Hubble:HTAP进化版的AI原生数据库
2021年以来 , 与AI相结合成为数据库的重要发展方向 , 但传统的关系型数据库在应用到DB for AI的场景时经常会出现性能问题 , 因为数据库经典技术优化不好的话将导致机器学习性能下降 。
正如前文所说 , 在目前很多社交、直播等连接的场景 , 传统的关系型数据库或者数据仓库根本不适用 , 这时候只能靠图数据库大展神威 , 在解决节点相似度计算 , 多跳关联计算等问题时 , 利用图论的框架体系比较容易解决 。 但是 , 传统的数据库模型则力不从新 , 因此图数据库也被称为AI原生数据库 , 图数据库厂商Neo4j也在今年获得了4.25亿美元的F轮融资 。
图数据库的使用场景往往和传统的交易场景互相融合 , 因此业界正在呼唤一款能够综合关系型数据库、数据仓库以及图数据库等各方面性能达到平衡的产品 , 使混合式HTAP数据库走向进一步的超融合 , 而这方面Hubble数据库今年取得的进展最大 。
Hubble的技术方案其实还是通过RAFT协议将TP库中的数据以异步的方式同步到图数据库当中 , 并针对图数据库的存储模型进行了大量的优化 。 在联机交易完成进行数据分析时 , Hubble的MPP 层通过智能优化器来生成最优的执行计划 , 并分配计算任务 。 Hubble系统内的Coordinator会对表级的元数据进行管理和存储 , 在进行SQL解析时 , 会基于执行计划和数据分布 , 提供最佳的数据存储格式 。 如对聚合类的分析场景 , 优化器通过对SQL计划的解析 , 提取出相关的聚合算子 , 自动选择列存模式;对于记录级的修改和查询操作 , 会转变成行存模式 , 实现数据的点查、修改操作 。
针对用户的分析计算场景 , 通过不同的优化器选择不同的数据存储格式 , 提供最佳的分析性能 。 而这样的创新点也给Hubble带来了实时大屏 , 这样一个可以提供实时多维数据分析结果的杀手级应用 。
数牍科技:隐私计算的集大成者
如果 目前图数据库是AI原生的数据库 , 那么隐私计算就是AI应用与数据挖掘的最强加速器 。 近年来各种AI模型规模按照以摩尔定律描述的方式不断扩大 , 从谷歌T5破百亿开始到GPT-3破千亿用了近2年 , 但从GPT-3到盘古的2000亿却只用了大半年的时间 。
特别声明:本站内容均来自网友提供或互联网,仅供参考,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
