lorenzoalvisi演讲中文翻译.pdfVIP

非常荣幸来到这里。现在我唯一感到遗憾的就是你们看不到自己的样子，那是多 么的美丽。我现在有一些学生，他们几年前就坐在你们的位置上。我问他们想听 什么内容，他们让我说点刺激的。 所以我想给你们讲一个恐怖的故事。想象你被绑在地下深处的一张桌子上，你能 听到的唯一声音就是一个巨大钟摆在你头上来回摆动的嗖嗖声。还有一个麻烦就 是钟摆的底端有一块刀片，而且离你越来越近。这是埃德加·爱伦·坡经典小说里 的一个场景，他是一位大师级的恐怖小说作家 ，来自美国。 我跟大家说这个并不仅仅是因为它是一个不错的万圣节故事，更是因为这样的景 象反映了如今所有数据库程序员所面临的处境。他们同样任由大摆钟摆布，有时 候在他们头上，有时候在他们脑海里，在两个看起来不可调和的目标之间摆动 ——编程简易性和性能。 这个摆钟一开始是偏向编程简易性这边的，以可串行化 ACID 事务等结构为代表。 然后摆钟开始摆动。在过去的十年里，由于 NoSQL 数据库的崛起，它已明显偏 向于性能这边，直至人们发现，在这些模型中编程实在是太难了。于是钟摆再次 往回摆动。但这个位置仍然无法让我们的数据库程序员感到满意。所以现在让我 们再深入一点，看一下究竟是什么导致了钟摆的摆动。 我先从 ACID 事务和它的简易性和通用性说起。是的，我们必须承认，ACID 的 确提供了很好的保证。你需要做的就是把编码放入一个事务当中，然后你就可以 安心地等待事务完成，并且这个事务与其他事务是隔离的。它的影响是持久的。 另外，当你在验证你的代码是否正确时，你只需要确保执行每个单独的事务后， 数据库的状态会从一个稳态转变为另一个稳态，而无需担心系统其他所有事务的 内在逻辑。所以说，ACID 可以提供很好的保证。但问题是，换取这种保证所需 付出的代价我们能否承担得起 ？这也是我们为之纠结了好长一段时间的问题。实 际上，做数据库的社区 ，在他们探索隔离概念的时候，已经倾向于让摆钟摆向性 能一边了，在这方面你可以找到一些例子，它们的可串行性较低，愿意放弃一些 编程方面的简易性 ，来换取更好的性能。但在过去的十年里，由于开发了一种叫 做 BASE 的方法，这种趋势显得更加猛烈。BASE 表面上是 Basically Available （基本可用）、Soft state （软状态）和Eventually consistent （最终一致）的 缩略词。但实际上它只是发明人开的一个玩笑罢了。对不对？他们只是想说，这 不是 ACID （酸），而是它的反义词BASE （碱）。事实上，他们对ACID 并没 有太大的耐心。他们将事务保证的特性拿了过来，然后就将 ACID 一脚踢开。他 们抛弃了 ACID 存储方式，然后用简化了的界面替代它 ，比如关键值存储顶层使 用 Put 和 Get。他们所做的一切都是为了让程序员能够通过编写自定义代码发挥 最大的性能。但问题是，在这种情况下，能力越大，复杂性就越大。在缺少事务 存储保证的情况下，必须由开发者来决定是否在应用层实现一致性保证，以确保 应用正确运行。这样做其实是很难的，因为在没有事务的情况下，你必须全盘考 虑所有可能操作之间的交叉存取。而从整个应用的大小来说，要考虑的交叉存取 数量将呈指数级增长。然后你很快就无法控制它的复杂性了。 让我们回到我们的故事。今天我想跟大家分享的是，我和我的学生在帮助上述人 员摆脱困境的过程中学到了什么东西。当然，我也希望你们学习的不仅是我们现 成的技术解决方案，更应该学习我们是如何找到这些解决方案的。所以这里面的 的挑战就是，找出一种提升性能的方法，这个方法就是提高并发性，但这会让编 程变得困难。 我举一个例子。比如有一个简单的事务：在确认支票账户的余额足够后，从这个 支票账户转账 10 美元到一个储蓄账户。你可能会想，将这个事务分为两部分来 提高并发性。其中一部分只负责支票账户，另一部分只负责储蓄账户。我的想法 是，为了提高并发性，我并非按顺序执行转账操作的两个实例，而是采用交迭执 行的策略。我可以让转账的其中一个实例的第二部分与它的第二个实例的第一部 分交迭。那么哪个地方可能出错呢？假如有另外一个事务，我们暂且叫它做 “余 额”，它要同时访问支票账户和储蓄账户，以便计算这位客户的账户总额是多少。 过去往往是在转账事务完成前或完成后执行计算余额事务的。这样的话就可以正 确计算出余额。但现在将转账事务拆分为两部分了，这样的话余额就多了一个中 间状态，这在之前是看不到。所以余额事务就可能计算出错误的结果。这里面让 人纠结的是，在我们试图提高并发性时，即使我们只是动了一个事务，也可能迫 使我们重新考虑其他所有事务的正确性。因为我们要想一下