细说分布式数据库的过去、现在与未来

TiDB
 TiDB
发布于 2017年05月02日
收藏 102

随着大数据这个概念的兴起以及真实需求在各个行业的落地,很多人都热衷于讨论分布式数据库,今天就这个话题,主要分为三部分:第一部分讲一下分布式数据库的过去和现状,希望大家能对这个领域有一个全面的了解;第二部分讲一下TiDB的架构以及最近的一些进展;最后结合我们开发TiDB过程中的一些思考讲一下分布式数据库未来可能的趋势。

一、分布式数据库的历史和现状



1、从单机数据库说起

关系型数据库起源自1970年代,其最基本的功能有两个:

  1. 把数据存下来;  

  2. 满足用户对数据的计算需求。

第一点是最基本的要求,如果一个数据库没办法把数据安全完整存下来,那么后续的任何功能都没有意义。当满足第一点后,用户紧接着就会要求能够使用数据,可能是简单的查询,比如按照某个Key来查找Value;也可能是复杂的查询,比如要对数据做复杂的聚合操作、连表操作、分组操作。往往第二点是一个比第一点更难满足的需求。

在数据库发展早期阶段,这两个需求其实不难满足,比如有很多优秀的商业数据库产品,如Oracle/DB2。在1990年之后,出现了开源数据库MySQL和PostgreSQL。这些数据库不断地提升单机实例性能,再加上遵循摩尔定律的硬件提升速度,往往能够很好地支撑业务发展。

接下来,随着互联网的不断普及特别是移动互联网的兴起,数据规模爆炸式增长,而硬件这些年的进步速度却在逐渐减慢,人们也在担心摩尔定律会失效。在此消彼长的情况下,单机数据库越来越难以满足用户需求,即使是将数据保存下来这个最基本的需求。

2、分布式数据库

所以2005年左右,人们开始探索分布式数据库,带起了NoSQL这波浪潮。这些数据库解决的首要问题是单机上无法保存全部数据,其中以HBase/Cassadra/MongoDB为代表。为了实现容量的水平扩展,这些数据库往往要放弃事务,或者是只提供简单的KV接口。存储模型的简化为存储系统的开发带来了便利,但是降低了对业务的支撑。

(1)NoSQL的进击

HBase是其中的典型代表。HBase是Hadoop生态中的重要产品,Google BigTable的开源实现,所以这里先说一下BigTable。 

BigTable是Google内部使用的分布式数据库,构建在GFS的基础上,弥补了分布式文件系统对于小对象的插入、更新、随机读请求的缺陷。HBase也按照这个架构实现,底层基于HDFS。HBase本身并不实际存储数据,持久化的日志和SST file存储在HDFS上,Region Server通过 MemTable 提供快速的查询,写入都是先写日志,后台进行Compact,将随机写转换为顺序写。数据通过 Region 在逻辑上进行分割,负载均衡通过调节各个Region Server负责的Region区间实现,Region在持续写入后,会进行分裂,然后被负载均衡策略调度到多个Region Server上。

前面提到了,HBase本身并不存储数据,这里的Region仅是逻辑上的概念,数据还是以文件的形式存储在HDFS上,HBase并不关心副本个数、位置以及水平扩展问题,这些都依赖于HDFS实现。和BigTable一样,HBase提供行级的一致性,从CAP理论的角度来看,它是一个CP的系统,并且没有更进一步提供 ACID 的跨行事务,也是很遗憾。

HBase的优势在于通过扩展Region Server可以几乎线性提升系统的吞吐,及HDFS本身就具有的水平扩展能力,且整个系统成熟稳定。但HBase依然有一些不足。首先,Hadoop使用Java开发,GC延迟是一个无法避免问题,这对系统的延迟造成一些影响。另外,由于HBase本身并不存储数据,和HDFS之间的交互会多一层性能损耗。第三,HBase和BigTable一样,并不支持跨行事务,所以在Google内部有团队开发了MegaStore、Percolator这些基于BigTable的事务层。Jeff Dean承认很后悔没有在BigTable中加入跨行事务,这也是Spanner出现的一个原因。

(2)RDMS的救赎

除了NoSQL之外,RDMS系统也做了不少努力来适应业务的变化,也就是关系型数据库的中间件和分库分表方案。做一款中间件需要考虑很多,比如解析 SQL,解析出ShardKey,然后根据ShardKey分发请求,再合并结果。另外在中间件这层还需要维护Session及事务状态,而且大多数方案并不支持跨shard的事务,这就不可避免地导致了业务使用起来会比较麻烦,需要自己维护事务状态。此外,还有动态的扩容缩容和自动的故障恢复,在集群规模越来越大的情况下,运维和DDL的复杂度是指数级上升。

国内开发者在这个领域有过很多的著名的项目,比如阿里的Cobar、TDDL,后来社区基于Cobar改进的MyCAT,360开源的Atlas等,都属于这一类中间件产品。在中间件这个方案上有一个知名的开源项目是Youtube的Vitess,这是一个集大成的中间件产品,内置了热数据缓存、水平动态分片、读写分离等,但这也造成了整个项目非常复杂。

另外一个值得一提的是PostgreSQL XC这个项目,其整体的架构有点像早期版本的OceanBase,由一个中央节点来处理协调分布式事务,数据分散在各个存储节点上,应该是目前PG 社区最好的分布式扩展方案,不少人在基于这个项目做自己的系统。

3、NewSQL的发展

2012~2013年Google 相继发表了Spanner和F1两套系统的论文,让业界第一次看到了关系模型和NoSQL的扩展性在一个大规模生产系统上融合的可能性。 Spanner 通过使用硬件设备(GPS时钟+原子钟)巧妙地解决时钟同步的问题,而在分布式系统里,时钟正是最让人头痛的问题。Spanner的强大之处在于即使两个数据中心隔得非常远,也能保证通过TrueTime API获取的时间误差在一个很小的范围内(10ms),并且不需要通讯。Spanner的底层仍然基于分布式文件系统,不过论文里也说是可以未来优化的点。

Google的内部的数据库存储业务,大多是3~5副本,重要的数据需要7副本,且这些副本遍布全球各大洲的数据中心,由于普遍使用了Paxos,延迟是可以缩短到一个可以接受的范围(写入延迟100ms以上),另外由Paxos带来的Auto-Failover能力,更是让整个集群即使数据中心瘫痪,业务层都是透明无感知的。F1是构建在Spanner之上,对外提供了SQL接口,F1是一个分布式MPP SQL层,其本身并不存储数据,而是将客户端的SQL翻译成对KV的操作,调用Spanner来完成请求。

Spanner和F1的出现标志着第一个NewSQL在生产环境中提供服务,将下面几个功能在一套系统中提供:

  1. SQL支持 

  2. ACID事务 

  3. 水平扩展 

  4. Auto Failover

  5. 多机房异地容灾

正因为具备如此多的诱人特性,在Google内部,大量的业务已经从原来的 BigTable切换到Spanner之上。相信这对业界的思路会有巨大的影响,就像当年的Hadoop一样,Google的基础软件的技术趋势是走在社区前面的。

Spanner/F1论文引起了社区的广泛的关注,很快开始出现了追随者。第一个团队是CockroachLabs做的CockroachDB。CockroachDB的设计和Spanner很像,但是没有选择TrueTime API ,而是使用HLC(Hybrid logical clock),也就是NTP +逻辑时钟来代替TrueTime时间戳,另外CockroachDB选用Raft做数据复制协议,底层存储落地在RocksDB中,对外的接口选择了PG协议。

CockroachDB的技术选型比较激进,比如依赖了HLC来做事务,时间戳的精确度并没有办法做到10ms内的延迟,所以Commit Wait需要用户自己指定,其选择取决于用户的NTP服务时钟误差,这点对于用户来说非常不友好。当然 CockroachDB的这些技术选择也带来了很好的易用性,所有逻辑都在一个组件中,部署非常简单,这个是非常大的优点。

另一个追随者就是我们做的TiDB。这个项目已经开发了两年时间,当然在开始动手前我们也准备了很长时间。接下来我会介绍一下这个项目。

二、TiDB的架构和最近进展

TiDB本质上是一个更加正统的Spanner和F1实现,并不CockroachDB那样选择将SQL和KV融合,而是像Spanner和F1一样选择分离。下面是TiDB的架构图:

这样分层的思想也是贯穿整个TiDB项目始终的,对于测试,滚动升级以及各层的复杂度控制会比较有优势,另外TiDB选择了MySQL协议和语法的兼容,MySQL社区的ORM框架、运维工具,直接可以应用在TiDB上,另外和 Spanner一样,TiDB是一个无状态的MPP SQL Layer,整个系统的底层是依赖 TiKV 来提供分布式存储和分布式事务的支持,TiKV的分布式事务模型采用的是Google Percolator的模型,但是在此之上做了很多优化,Percolator的优点是去中心化程度非常高,整个继续不需要一个独立的事务管理模块,事务提交状态这些信息其实是均匀分散在系统的各个key的meta中,整个模型唯一依赖的是一个授时服务器,在我们的系统上,极限情况这个授时服务器每秒能分配 400w以上个单调递增的时间戳,大多数情况基本够用了(毕竟有Google量级的场景并不多见),同时在TiKV中,这个授时服务本身是高可用的,也不存在单点故障的问题。

上面是TiKV的架构图。TiKV和CockroachDB一样也是选择了Raft作为整个数据库的基础,不一样的是,TiKV整体采用Rust语言开发,作为一个没有GC和 Runtime的语言,在性能上可以挖掘的潜力会更大。不同TiKV实例上的多个副本一起构成了一个Raft Group,PD负责对副本的位置进行调度,通过配置调度策略,可以保证一个Raft Group的多个副本不会保存在同一台机器/机架/机房中。

除了核心的TiDB、TiKV之外,我们还提供了不少易用的工具,便于用户做数据迁移和备份。比如我们提供的Syncer,不但能将单个MySQL实例中的数据同步到TiDB,还能将多个MySQL实例中的数据汇总到一个TiDB集群中,甚至是将已经分库分表的数据再合库合表。这样数据的同步方式更加灵活好用。

TiDB目前即将发布RC3版本,预计六月份能够发布GA版本。在即将到来的 RC3版本中,对MySQL兼容性、SQL优化器、系统稳定性、性能做了大量的工作。对于OLTP场景,重点优化写入性能。另外提供了权限管理功能,用户可以按照MySQL的权限管理方式控制数据访问权限。对于OLAP场景,也对优化器做了大量的工作,包括更多语句的优化、支持SortMergeJoin算子、IndexLookupJoin算子。另外对内存使用也做了大量的优化,一些场景下,内存使用下降75%。

除了TiDB本身的优化之外,我们还在做一个新的工程,名字叫TiSpark。简单来讲,就是让Spark更好地接入TiDB。现在其实Spark已经可以通过JDBC接口读取TiDB中的数据,但是这里有两个问题:1. 只能通过单个TiDB节点读取数据且数据需要从TiKV中经过 TiDB 中转。2. 不能和Spark的优化器相结合,我们期望能和Spark的优化器整合,将Filter、聚合能通过TiKV的分布式计算能力提速。这个项目已经开始开发,预计近期开源,五月份就能有第一个版本。

三、分布式数据库的未来趋势

关于未来,我觉得未来的数据库会有几个趋势,也是TiDB项目追求的目标:

    1、数据库会随着业务云化,未来一切的业务都会跑在云端,不管是私有云或者公有云,运维团队接触的可能再也不是真实的物理机,而是一个个隔离的容器或者「计算资源」,这对数据库也是一个挑战,因为数据库天生就是有状态的,数据总是要存储在物理的磁盘上,而数据移动的代价比移动容器的代价可能大很多。

    2、多租户技术会成为标配,一个大数据库承载一切的业务,数据在底层打通,上层通过权限,容器等技术进行隔离,但是数据的打通和扩展会变得异常简单,结合第一点提到的云化,业务层可以再也不用关心物理机的容量和拓扑,只需要认为底层是一个无穷大的数据库平台即可,不用再担心单机容量和负载均衡等问题。

    3、OLAP和OLTP业务会融合,用户将数据存储进去后,需要比较方便高效的方式访问这块数据,但是OLTP和OLAP在SQL优化器/执行器这层的实现一定是千差万别的。以往的实现中,用户往往是通过ETL工具将数据从OLTP数据库同步到OLAP数据库,这一方面造成了资源的浪费,另一方面也降低了OLAP的实时性。对于用户而言,如果能使用同一套标准的语法和规则来进行数据的读写和分析,会有更好的体验。

    4、在未来分布式数据库系统上,主从日志同步这样落后的备份方式会被Multi-Paxos / Raft这样更强的分布式一致性算法替代,人工的数据库运维在管理大规模数据库集群时是不可能的,所有的故障恢复和高可用都将是高度自动化的。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:细说分布式数据库的过去、现在与未来
资讯来源:DBAplus
加载中

精彩评论

乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

@雷兽 一台百万的Oracle数据库服务器,跑特定OLAP比不过几台普通服务器(十几万成本)做的集群,分布式数据库我觉得一定是未来的方向,而且数据库会变成数据存储+计算的平台,sql语言可能不再是第一梯队。

引用来自“雷兽”的评论

大哥 我貌似觉得你@我说的 却是我的观点。。。。。分布式数据库 一般是说的是oltp向 而oltp向的分布式方案 一般都不会去实现强约束olap向的是数据仓库等 本来速度要求有限 通常可以认为无所谓了sql我这里说的是sql语言 不是关系型数据库那些 sql语言本身可以重新靠解释器解释为任何新东西sql关系数据库 在oltp里的地位 我认为最终是完全被新崛起的方案融合 而不是被替代 或者挤出去目前为止 现在存在的和现在受着教育的将来时的开发人员 的it项目思维方式还是基于关系型数据库为基础的 所以为了几十年 关系数据库的很多本质 都不会退出第一梯队
回复@雷兽 : 看来我和你唯一的不一致的观点就是,就算到了分布式oltp,期望也是强一致性强约束的oltp,而不是通过阉割数据质量控制能力而实现的oltp
乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

点赞,请问TiDB有计划实现外键触发器之类的数据一致性约束吗

引用来自“雷兽”的评论

分布式下整触发器。。。。。。还是外键触发器。。。。我看有了会死的很难看。。。。
脑筋不要太僵化,外键和触发器是什么?就是具有一致性的数据检查功能。
数据库里不做应用层也要在事务里把相关行都锁住来达到一致性前提下的检查数据准确性的功能。只不过数据库里实现效率高一点而已。
如果分布式数据库这种场景都会出问题,何谈NewSQL,应该是MinusSQL(删减功能版)才对?这可是数据管理的基本需求,你如果随便做一些内容型网站确实接触不到这方面,但是ERP等系统里很常用这个功能。
bhzhu203
bhzhu203
图片挂了@zhaiyuan

最新评论(22

雷兽

引用来自“乌龟壳”的评论

@雷兽 一台百万的Oracle数据库服务器,跑特定OLAP比不过几台普通服务器(十几万成本)做的集群,分布式数据库我觉得一定是未来的方向,而且数据库会变成数据存储+计算的平台,sql语言可能不再是第一梯队。

引用来自“雷兽”的评论

大哥 我貌似觉得你@我说的 却是我的观点。。。。。分布式数据库 一般是说的是oltp向 而oltp向的分布式方案 一般都不会去实现强约束olap向的是数据仓库等 本来速度要求有限 通常可以认为无所谓了sql我这里说的是sql语言 不是关系型数据库那些 sql语言本身可以重新靠解释器解释为任何新东西sql关系数据库 在oltp里的地位 我认为最终是完全被新崛起的方案融合 而不是被替代 或者挤出去目前为止 现在存在的和现在受着教育的将来时的开发人员 的it项目思维方式还是基于关系型数据库为基础的 所以为了几十年 关系数据库的很多本质 都不会退出第一梯队

引用来自“乌龟壳”的评论

回复@雷兽 : 看来我和你唯一的不一致的观点就是,就算到了分布式oltp,期望也是强一致性强约束的oltp,而不是通过阉割数据质量控制能力而实现的oltp

引用来自“雷兽”的评论

嗯 oltp下 并发那么大 加上分布式以后 全剧约束 外加上可能重叠的约束 感觉随时都是一种 可以叫 无限地狱。。。。的情况

引用来自“乌龟壳”的评论

甭管是不是无限地狱,外键在某些场景下是需求层面的东西,数据库不做你觉得放哪里做比较好?如果你觉得这个需求绝对不会出现,那应该就是我和你对OLTP期待的关键不同点。如果你说程序里做外键,可以明确地说,比数据库自己做还慢,而且是系统整体性的性能下降,因为外键该有的锁无论在哪里做都必须要有;另外程序里做没有数据库纯粹,很依赖编码时人工去注意维持关系,很难做完善。
你都知道在数据库里很难完善 你在分布式数据库里做一次封装 然后告诉调用者 放心 我搞定了 然后。。。。有什么然后 你应该懂 哈哈哈 就是有这个功能 估计也不可能是主推的 最多是测试性的 还是永远的测试性的那种。。。。支持 不推荐的那种功能
乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

@雷兽 一台百万的Oracle数据库服务器,跑特定OLAP比不过几台普通服务器(十几万成本)做的集群,分布式数据库我觉得一定是未来的方向,而且数据库会变成数据存储+计算的平台,sql语言可能不再是第一梯队。

引用来自“雷兽”的评论

大哥 我貌似觉得你@我说的 却是我的观点。。。。。分布式数据库 一般是说的是oltp向 而oltp向的分布式方案 一般都不会去实现强约束olap向的是数据仓库等 本来速度要求有限 通常可以认为无所谓了sql我这里说的是sql语言 不是关系型数据库那些 sql语言本身可以重新靠解释器解释为任何新东西sql关系数据库 在oltp里的地位 我认为最终是完全被新崛起的方案融合 而不是被替代 或者挤出去目前为止 现在存在的和现在受着教育的将来时的开发人员 的it项目思维方式还是基于关系型数据库为基础的 所以为了几十年 关系数据库的很多本质 都不会退出第一梯队

引用来自“乌龟壳”的评论

回复@雷兽 : 看来我和你唯一的不一致的观点就是,就算到了分布式oltp,期望也是强一致性强约束的oltp,而不是通过阉割数据质量控制能力而实现的oltp

引用来自“雷兽”的评论

嗯 oltp下 并发那么大 加上分布式以后 全剧约束 外加上可能重叠的约束 感觉随时都是一种 可以叫 无限地狱。。。。的情况
甭管是不是无限地狱,外键在某些场景下是需求层面的东西,数据库不做你觉得放哪里做比较好?如果你觉得这个需求绝对不会出现,那应该就是我和你对OLTP期待的关键不同点。如果你说程序里做外键,可以明确地说,比数据库自己做还慢,而且是系统整体性的性能下降,因为外键该有的锁无论在哪里做都必须要有;另外程序里做没有数据库纯粹,很依赖编码时人工去注意维持关系,很难做完善。
雷兽

引用来自“乌龟壳”的评论

@雷兽 一台百万的Oracle数据库服务器,跑特定OLAP比不过几台普通服务器(十几万成本)做的集群,分布式数据库我觉得一定是未来的方向,而且数据库会变成数据存储+计算的平台,sql语言可能不再是第一梯队。

引用来自“雷兽”的评论

大哥 我貌似觉得你@我说的 却是我的观点。。。。。分布式数据库 一般是说的是oltp向 而oltp向的分布式方案 一般都不会去实现强约束olap向的是数据仓库等 本来速度要求有限 通常可以认为无所谓了sql我这里说的是sql语言 不是关系型数据库那些 sql语言本身可以重新靠解释器解释为任何新东西sql关系数据库 在oltp里的地位 我认为最终是完全被新崛起的方案融合 而不是被替代 或者挤出去目前为止 现在存在的和现在受着教育的将来时的开发人员 的it项目思维方式还是基于关系型数据库为基础的 所以为了几十年 关系数据库的很多本质 都不会退出第一梯队

引用来自“乌龟壳”的评论

回复@雷兽 : 看来我和你唯一的不一致的观点就是,就算到了分布式oltp,期望也是强一致性强约束的oltp,而不是通过阉割数据质量控制能力而实现的oltp
嗯 oltp下 并发那么大 加上分布式以后 全剧约束 外加上可能重叠的约束 感觉随时都是一种 可以叫 无限地狱。。。。的情况
乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

@雷兽 一台百万的Oracle数据库服务器,跑特定OLAP比不过几台普通服务器(十几万成本)做的集群,分布式数据库我觉得一定是未来的方向,而且数据库会变成数据存储+计算的平台,sql语言可能不再是第一梯队。

引用来自“雷兽”的评论

大哥 我貌似觉得你@我说的 却是我的观点。。。。。分布式数据库 一般是说的是oltp向 而oltp向的分布式方案 一般都不会去实现强约束olap向的是数据仓库等 本来速度要求有限 通常可以认为无所谓了sql我这里说的是sql语言 不是关系型数据库那些 sql语言本身可以重新靠解释器解释为任何新东西sql关系数据库 在oltp里的地位 我认为最终是完全被新崛起的方案融合 而不是被替代 或者挤出去目前为止 现在存在的和现在受着教育的将来时的开发人员 的it项目思维方式还是基于关系型数据库为基础的 所以为了几十年 关系数据库的很多本质 都不会退出第一梯队
回复@雷兽 : 看来我和你唯一的不一致的观点就是,就算到了分布式oltp,期望也是强一致性强约束的oltp,而不是通过阉割数据质量控制能力而实现的oltp
雷兽

引用来自“乌龟壳”的评论

@雷兽 一台百万的Oracle数据库服务器,跑特定OLAP比不过几台普通服务器(十几万成本)做的集群,分布式数据库我觉得一定是未来的方向,而且数据库会变成数据存储+计算的平台,sql语言可能不再是第一梯队。
大哥 我貌似觉得你@我说的 却是我的观点。。。。。分布式数据库 一般是说的是oltp向 而oltp向的分布式方案 一般都不会去实现强约束olap向的是数据仓库等 本来速度要求有限 通常可以认为无所谓了sql我这里说的是sql语言 不是关系型数据库那些 sql语言本身可以重新靠解释器解释为任何新东西sql关系数据库 在oltp里的地位 我认为最终是完全被新崛起的方案融合 而不是被替代 或者挤出去目前为止 现在存在的和现在受着教育的将来时的开发人员 的it项目思维方式还是基于关系型数据库为基础的 所以为了几十年 关系数据库的很多本质 都不会退出第一梯队
乌龟壳
乌龟壳
@雷兽 一台百万的Oracle数据库服务器,跑特定OLAP比不过几台普通服务器(十几万成本)做的集群,分布式数据库我觉得一定是未来的方向,而且数据库会变成数据存储+计算的平台,sql语言可能不再是第一梯队。
乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

点赞,请问TiDB有计划实现外键触发器之类的数据一致性约束吗

引用来自“雷兽”的评论

分布式下整触发器。。。。。。还是外键触发器。。。。我看有了会死的很难看。。。。

引用来自“乌龟壳”的评论

脑筋不要太僵化,外键和触发器是什么?就是具有一致性的数据检查功能。
数据库里不做应用层也要在事务里把相关行都锁住来达到一致性前提下的检查数据准确性的功能。只不过数据库里实现效率高一点而已。
如果分布式数据库这种场景都会出问题,何谈NewSQL,应该是MinusSQL(删减功能版)才对?这可是数据管理的基本需求,你如果随便做一些内容型网站确实接触不到这方面,但是ERP等系统里很常用这个功能。

引用来自“雷兽”的评论

其实 等这种功能真实现 并且能够被小白开发 透明使用 不出幺蛾子 再说这些比较好
tidb 以及原来Google Spanner和F1 这种 我看让一个小白随手几行代码就能高挂 不是高手或者严格的项目上线前代码检查 审查 根本就没办法用
最近去参加2017中华数据库与运维大会 看到中信银行那套mysql中间件 确实有不错 但是功能也绝对离壳兄的10万光年之远
更不要说 银行的开发 能力再惨通常还有基本保障了 换一般小白开发 天知道会怎么样
不太清楚撒,新东西,如果能代替老牌的数据库是最好的,现在分布式计算的时代老数据库越来越力不从心了。olap领域确实很多方案能代替传统数据库。就是oltp还不行。
雷兽

引用来自“乌龟壳”的评论

点赞,请问TiDB有计划实现外键触发器之类的数据一致性约束吗

引用来自“雷兽”的评论

分布式下整触发器。。。。。。还是外键触发器。。。。我看有了会死的很难看。。。。

引用来自“乌龟壳”的评论

脑筋不要太僵化,外键和触发器是什么?就是具有一致性的数据检查功能。
数据库里不做应用层也要在事务里把相关行都锁住来达到一致性前提下的检查数据准确性的功能。只不过数据库里实现效率高一点而已。
如果分布式数据库这种场景都会出问题,何谈NewSQL,应该是MinusSQL(删减功能版)才对?这可是数据管理的基本需求,你如果随便做一些内容型网站确实接触不到这方面,但是ERP等系统里很常用这个功能。
其实 等这种功能真实现 并且能够被小白开发 透明使用 不出幺蛾子 再说这些比较好
tidb 以及原来Google Spanner和F1 这种 我看让一个小白随手几行代码就能高挂 不是高手或者严格的项目上线前代码检查 审查 根本就没办法用
最近去参加2017中华数据库与运维大会 看到中信银行那套mysql中间件 确实有不错 但是功能也绝对离壳兄的10万光年之远
更不要说 银行的开发 能力再惨通常还有基本保障了 换一般小白开发 天知道会怎么样
雷兽

引用来自“乌龟壳”的评论

点赞,请问TiDB有计划实现外键触发器之类的数据一致性约束吗

引用来自“雷兽”的评论

分布式下整触发器。。。。。。还是外键触发器。。。。我看有了会死的很难看。。。。

引用来自“乌龟壳”的评论

脑筋不要太僵化,外键和触发器是什么?就是具有一致性的数据检查功能。
数据库里不做应用层也要在事务里把相关行都锁住来达到一致性前提下的检查数据准确性的功能。只不过数据库里实现效率高一点而已。
如果分布式数据库这种场景都会出问题,何谈NewSQL,应该是MinusSQL(删减功能版)才对?这可是数据管理的基本需求,你如果随便做一些内容型网站确实接触不到这方面,但是ERP等系统里很常用这个功能。

引用来自“申砾”的评论

外键和触发器暂时没有支持计划,有这个需求的用户很少。触发器有一个变通的方法,TiDB 可以输出 Binlog,通过订阅 Binlog 可以获得数据的变更,这个也是很实时的,目前有用户是这样用的。

引用来自“乌龟壳”的评论

那是因为当前阶段重度依赖Oracle等老牌数据库技术的业务尚未用你们的产品而已,外键约束等是数据处理的标配这和什么用什么数据库无关,甚至不用数据库也要有这些东西。

当然事情也不是那么绝对,不然只需要外键、约束,数据库也不用实现用户自定义的触发器逻辑了。所以只要TiDB能有接口让人接入去实现相关功能也是可以的。只要数据库把基础的功能做好,比如锁之类的。

引用来自“雷兽”的评论

怎么都觉得这些东西放数据库 就是不应该了 哈哈哈 不是我脑子僵化 是你习惯用老的名词

引用来自“乌龟壳”的评论

回复@雷兽 : 这些名词我眼中是原理,你眼中只是经验感觉,所以这地方理解上有出入

引用来自“雷兽”的评论

我的意思只是 这类该在业务逻辑处理的别放数据库 反而容易被小白乱用

引用来自“乌龟壳”的评论

回复@雷兽 : 放数据库肿么了?你在程序里实现外键比数据库里要慢得多。除非你说程序里并不完全实现外键的功能,比如只是定时检查外键关系是否完整,那是另一回事了。
你是作企业应用的吧 我是作互联网应用 也做过网络游戏后端 我们立场不同 争下去也没啥意义。。。。
乌龟壳
乌龟壳

引用来自“乌龟壳”的评论

点赞,请问TiDB有计划实现外键触发器之类的数据一致性约束吗

引用来自“雷兽”的评论

分布式下整触发器。。。。。。还是外键触发器。。。。我看有了会死的很难看。。。。

引用来自“乌龟壳”的评论

脑筋不要太僵化,外键和触发器是什么?就是具有一致性的数据检查功能。
数据库里不做应用层也要在事务里把相关行都锁住来达到一致性前提下的检查数据准确性的功能。只不过数据库里实现效率高一点而已。
如果分布式数据库这种场景都会出问题,何谈NewSQL,应该是MinusSQL(删减功能版)才对?这可是数据管理的基本需求,你如果随便做一些内容型网站确实接触不到这方面,但是ERP等系统里很常用这个功能。

引用来自“申砾”的评论

外键和触发器暂时没有支持计划,有这个需求的用户很少。触发器有一个变通的方法,TiDB 可以输出 Binlog,通过订阅 Binlog 可以获得数据的变更,这个也是很实时的,目前有用户是这样用的。

引用来自“乌龟壳”的评论

那是因为当前阶段重度依赖Oracle等老牌数据库技术的业务尚未用你们的产品而已,外键约束等是数据处理的标配这和什么用什么数据库无关,甚至不用数据库也要有这些东西。

当然事情也不是那么绝对,不然只需要外键、约束,数据库也不用实现用户自定义的触发器逻辑了。所以只要TiDB能有接口让人接入去实现相关功能也是可以的。只要数据库把基础的功能做好,比如锁之类的。

引用来自“雷兽”的评论

怎么都觉得这些东西放数据库 就是不应该了 哈哈哈 不是我脑子僵化 是你习惯用老的名词

引用来自“乌龟壳”的评论

回复@雷兽 : 这些名词我眼中是原理,你眼中只是经验感觉,所以这地方理解上有出入

引用来自“雷兽”的评论

我的意思只是 这类该在业务逻辑处理的别放数据库 反而容易被小白乱用
回复@雷兽 : 放数据库肿么了?你在程序里实现外键比数据库里要慢得多。除非你说程序里并不完全实现外键的功能,比如只是定时检查外键关系是否完整,那是另一回事了。
返回顶部
顶部