1. 谈谈 TiDB

    正如我 23 号讨论时所说, 我们团队也在学习 TiDB 代码,在我们看来,TiDB 代码是一个优秀的实现。 我于今年 5 月份开始,跟 TiDB 的核心骨干,如黄东旭,mengjie、刘寅、邓佺等,都有很好的沟通。 UCloud 也和 PingCap 一起,推出了 UCloud TiDB 这款产品。 UDDB 团队,和 TiDB 团队,合作也是非常愉快的。 比如,我们为 UCloud TiDB 推荐了 2 位客户, 而 UCloud TiDB 为我们推荐了 1 位客户。 在我们看来,一切以客户价值为皈依。假如客户的业务,更贴合 TiDB,我们则会推荐 TiDB 产品,加入客户业务更贴合 UDDB,则我们向客户推荐 UDDB(其实客户也很聪明,在充分了解两款产品差异性后,自己也知道哪款产品最合适)。

    这是我们实际的情况, 需要的话我们可以提供信息进行证明。

  • 1.OLTP 的问题(续)

    TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。

    我认为这是 TiDB 一个非常好的产品宣传策略。但是这不影响我的观点:

    我的理解是在讨论一个概念时,需要结合实际的应用场景才有意义。 HTAP 从概念上理解,是 OLTP+OLAP, 但技术需要结合具体的产品讨论才有意义。 正如我当时举得一个阿里云 Hybrid MySQL 的例子,阿里云 Hybrid MySQL 也称之为 HTAP,但假如你看过阿里 Hybrid MySQL 的产品文档,你就会发现,他们文档里面写得很清楚,针对的场景就是物联网、大数据分析等领域,并不是涵盖 OLTP+OLAP(所以我当时反问过你: 如果 Hybrid MySQL 能涵盖 OLTP+OLAP,那就是阿里下一代产品了,又为何定位在物联网和大数据分析领域?)。 假如你对分布式数据库产品多去了解一点,这个结论是不难得出的。

    1. OLTP 的问题

    我先不说别的,阿里云的 Hybrid for HTAP 在 Sharding 上还做了分区键。要是阿里云的 Hybrid for HTAP 连 OLTP 都做不到,你个中间件做 reduce 的玩意也敢说自己能做到 OLTP?阿里云怕杀鸡用牛刀说「针对的场景就是物联网、大数据分析等领域」,到你嘴里就变成除了这个就干不了别的了,我也是佩服得不行。

    ” 你个中间件做 reduce 的玩意 “: 你可能不知道,阿里云 Hybrid MySQL,就是基于一个中间件发展起来的。 你可以去找今年云栖大会上,Hybrid MySQL 负责人的 ppt 和视频。他全面介绍了 Hybrid MySQL 的演进路程。而 UDDB 也是基于一个中间件,在演进。

    1. 形式化验证的问题

    首选必须要指出的是, 你回帖的内容:

    这里面有一个明显的细节错误。 红框中的内容(分布式事务有关的),跟形式化验证没有关系,但是你在这里贴出来了。

    个人而言,我认为这是一个不注重细节的表现。

    回到 23 号关于形式化验证的讨论。 当时我在给另外一为客户,讲解 UDDB 架构的问题。旁边的你突然插问测试的问题。我当时问:是不是指 SQL 覆盖性测试。然后你说是,并说 TiDB 做了形式化(确切地说,你当时用的是 Formal Verification,我翻译成形式化验证是不会有错的)。 我当时表达了这不可能。 因为如果能够对 SQL 解析和执行的代码做形式化验证,那么大部分公司都应该不需要测试人员了。

    1. 首先,你把分片内多副本一致性,和 ACID 一致性混为一谈。 ACID 是 Jim Gray 提出来的。我们先来看一下 Jim Gray 在其著作《事务处理:概念和技术》是怎么定义 ACID 中的一致性的:

    ACID 中的 C,是指在操作语义上,所有操作的结果对数据库数据造成的影响,必须是一致的。 而分片内多副本一致性,是指在分布式系统里(出于容灾或读性能提升考虑,需要多副本),需要多副本部署。这就产生的多副本一致性的问题。

    两种办法各有其解决方案。 多副本一致性的解决,一般采用 Paxos、Raft 算法,而分布式事务中 C 的保证,目前主流的方法也是采用二阶段提交。如果要细究的话,两阶段提交的方法,对分布式事务中 C 的保证,也是存在局限的。但我相信上面的信息,已经足够解释清楚, 为什么分片内多副本一致性, 和 ACID 中的一致性,是两个完全不同的概念了。

  • 您好,我就是当天分享的 ucloud 研发工程师,有十年多的技术工作经历,目前负责 uddb 的研发。帖子所描述的发生于演讲结束后的 4-5 人小范围的技术讨论,您所谈到的技术点我想有必要说明清楚。

    1、首先,是几点我觉得细节上描述的不够清楚的地方

    1.1 您说的我没听到过客户用 migration 这种东西,没有把 ruby china 当回事: 当时在和您讨论时您提到的 ruby schema-migration,这个知识点我确实不了解。在您给出解释后,我当时所说是:这个插件的作用是动态做 DDL,但一般而言,DDL 都是由 DBA 在初始化阶段和维护阶段手工做的,所以业务里面直接 DDL 的场景较少。 正所谓闻道有先后,术业有专攻。 我们和客户的探讨都是双向的。 相互之间会传递各自擅长的技术点给到对方,和客户的讨论过程也是学习的过程。这次了解了 ruby schema-migration,对我来说是一次学习。

    1.2 您说的保证分布式一致性的质疑

    当时的情况,是我和另外一位客户(我们组总共有 4 位客户)在讨论 UDDB 如何实现分布式事务,所以我介绍了二阶段提交的做法。您在中间插问了节点间多副本一致性的问题,因为当时我们在探讨分布式事务的问题,而多副本一致性问题跟分布式事务无关(是完全独立的两个问题),所以当时我说的是:这并不是我们讨论问题(分布式事务)的范畴。

    1.3 针对 TiDB 的几点质疑

    您提到 TiDB 对 SQL 解析代码做了形式化的验证,然后发现了几个 bug,同时提到 aws 也有这样的方法。 我认为的是, 对 SQL 解析的代码做形式化验证,这是一个不可能有解的问题。UDDB 只是收集了很多 SQL 测试用例来做测试,而 TiDB 这块也是这么做的。

    1. 另外澄清跟技术有关的几个点:

    2.1 关于这个产品的完成度非常低的问题,包括 Sharding 需要手动设计

    Sharding 手动设计,具体而言是需要在 Create Table 语句里面,指定分区信息。这是很多分布式数据库的特点。比如,OceanBase、腾讯云 TDSQL 等。而 TiDB,最近也在支持分区。我们认为,Sharding 手动设计是一种给客户更加灵活度的策略,而不是技术上的妥协。

    2.2 关于 OLTP 和 HTAP 之争:

    我的理解是在讨论一个概念时,需要结合实际的应用场景才有意义。 HTAP 从概念上理解,是 OLTP+OLAP, 但技术需要结合具体的产品讨论才有意义。 正如我当时举得一个阿里云 Hybrid MySQL 的例子,阿里云 Hybrid MySQL 也称之为 HTAP,但假如你看过阿里 Hybrid MySQL 的产品文档,你就会发现,他们文档里面写得很清楚,针对的场景就是物联网、大数据分析等领域,并不是涵盖 OLTP+OLAP(所以我当时反问过你: 如果 Hybrid MySQL 能涵盖 OLTP+OLAP,那就是阿里下一代产品了,又为何定位在物联网和大数据分析领域?)。 假如你对分布式数据库产品多去了解一点,这个结论是不难得出的。

    总结:

    本来我觉得这次会议是 4-5 人的一次技术上的小规模的探讨,大家可以放开谈技术的看法和观点,但是引起这些风波是我意料不到的。不过我们还是挺欢迎这种技术上的探讨,客户对我们的批评也是对我们的鞭策和成长,也希望我们后边能针对分布数据领域的技术点有更多更深入的探讨。