A-A+

关于事务的一点琐碎思考

2017年05月06日 数据库 评论 4 条 阅读 1,484 次

最近又零散地看了一些mvcc/snapshot的东西,有了一些新的理解和观点,记录一下,内容比较碎,不一定正确,欢迎大家讨论拍砖。

在某些实现下,2PC会影响MVCC ?

MVCC相比lock-based的并发控制,可以使得写不阻塞读。不过如果如果使用基于时间戳的行级多版本,在有分布式事务时,有可能遇到类似于下面的问题:2PC中参与者prepare之后收到协调者的commit/abort通知之前是未决的状态,该参与者不知道事务是提交还是回滚,新的读事务拿了v1作为快照读版本,v1可能大于该分布式事务的提交版本,这种情况下可能出现等待。

这个问题在按事务粒度实现MVCC下(例如HANA、InnoDB)不会出现。在有全局授时服务器的设计下似乎也避免不了。

 

HANA支持外部一致性?

HANA支持分布式快照。在假设系统出现分布式事务数量比较少的前提下,使用了一个中心协调节点。HANA单机写事务优化成无需经过中心协调节点,分布式快照(类似于InnoDB的ReadView)使用global tid和local tid两组事务集合表示。HANA没有明确说明该方案是不是支持外部一致性,按照分析应该是不支持的。

数据库或者说存储系统是不是要支持外部一致性,这个可能大家的观点并不统一。我个人比较赞同这个观点:用户在使用存储系统的时候,可能默认就是认为系统要支持外部一致性,反而是不支持外部一致性的系统需要明确告知用户。

没有找到明确的理论分析,不过我觉得,分布式数据库要支持外部一致性,则必须对单机事务提交也要显式或隐式地进行同步。Google Spanner可以依赖TrueTime,像Percolator/TiDB可以依赖全局授时服务器,这些中心化的组件(硬件/软件),本质上还是做单机操作的同步。

之前读Lamport的Time Clock and Order of Event这篇经典论文,有一段系统外部事件序的内容(物理时钟一节)。我的理解是,分布式系统内部的happen-before关系是可以完全追踪的,无非是成本高低,但是系统外部的happen-before关系(论文里面举例发完消息之后打电话通知)要想被分布式系统支持,必须通过某种方式从外部引入。论文提出了如果外部的happen-before关系的两个事件发生时间间隔越大,本地时钟离绝对时钟越接近,越不容易出异常(很符合直觉),并给出了定量的理论分析

 

1024个核上MVCC算法的瓶颈在哪?

读了一篇论文,评估了几种并发控制算法在硬件扩展到1024核的时候的表现。多看了一下基于时间戳的MVCC算法,算法的瓶颈是分配时间戳!?

该论文结论是目前的并发控制算法都不靠谱,将来的方向是……软硬件协同设计~

我觉得,硬件扩展到1024核之后,恐怕不只是数据库会有巨大的挑战,从CPU Cache间通信,到OS调度,到数据库,到业务层线程模型,估计处处都是挑战吧。

 

分布式数据库的技术趋势

目前比较显著的一个趋势,新的硬件可能会极大地影响数据库系统的架构。比如,RDMA等技术可能影响分布式系统,尤其是分布式事务的设计,将来或许会促进分布式事务在业务上的进一步使用。还有非易失内存NVM等,也会有比较大的影响。HTM等对数据结构的设计实现上的影响可能也会越来越多吧。

另外,DPDK等绕过OS内核的一些改善软件栈的思路,已经在一些基础软件中有应用了(补充,腾讯开源了f-stack框架)。

持续关注这个话题。

 

4 条留言  访客:0 条  博主:0 条

  1. wutiangan

    即使有全局授时服务器,读需要等待 未确定状态的写 依然存在吧?

    • LoopJump

      你说的对,commit阶段由协调者确定提交时间戳,此时参与者上有新开启的读事务,读事务是要等待。

    • LoopJump

      原文已经修改,感谢。

  2. HelloCode

    关于多核背景下并发控制的scalability,在CMU database的课程里也有提到。
    背景是内存数据库,采用不同的时间戳分配策略,效果确实不一样。比如最简单的用一个原子变量,多核之间维护cache coherence的开销太大;用一些预分配的策略会好一些。
    如果CPU有了1024核,恐怕确实如他所说,memory会变成现在的cache,disk会变成现在的memory

给我留言