Martin Kleppman是剑桥大学的一名研究员，致力于CRDT和算法的形式验证。 他于2017年出版的《
设计数据密集型应用程序》一书已成为数据存储和处理领域的畅销书。
微软首席技术官凯文·斯科特（Kevin Scott）曾经
说过 ：“这对于开发工程师来说是必不可少的。 “这是一种将理论与实践相结合的稀有资源，可帮助开发人员更深入地思考基础架构和数据处理系统的设计与实现。” Apache Kafka的创始人兼首席执行官Confluent的Jay Kreps说了类似的话。
在开始学术研究之前，Martin从事该行业，并共同创立了两家成功的初创公司：Rapportive（2012年被LinkedIn收购）和Go Test It（被RedGate收购）。
这个habrapost是Martin的详细访谈。 样本讨论主题：
- 从商业向学术研究过渡；
- 编写设计数据密集型应用程序的先决条件；
- 反对虚假宣传和广告工具的常识；
- CAP定理和其他行业错误的必要性；
- 权力下放的作用；
- 区块链，Dat，IPFS，Filecoin，WebRTC;
- 新的CRDT。 伊莎贝尔（Isabelle）的正式验证；
- 关于事件源的讨论。 低级方法。 XA交易
- Apache Kafka，PostgreSQL，Memcached，Redis，Elasticsearch;
- 在现实生活中使用它；
- 进入马丁报告和Hydra会议的门槛。
采访是由
Oadoklassniki Platform公司团队的领先开发人员
Vadim Tsesko （
@incubos ）进行的。 Vadim的科学和工程兴趣涉及分布式系统和数据仓库以及软件系统的验证。
从商业到学术研究
瓦迪姆 ：我想从一个对我个人来说非常重要的问题开始。 您创建了Go Test It和Rapportive，并在LinkedIn上长期从事大型系统的开发，但随后决定退出商业开发并在大学进行研究。 你能告诉我是什么促使你这么做的吗？ 在大学工作有什么好处，您为此付出了什么？
马丁 ：这是一个非常有趣的过渡。 据我了解，您对我的决定很感兴趣，原因是有相当多的人正从商业发展中转而从事学术研究，而通常情况是相反的趋势。 这是可以理解的，因为大学的收入大大低于商业的收入。 我本人可以自己决定要从事的课题，因此我个人被研究人员所吸引，并且即使对某个课题进行研究并不能保证在接下来的6年中获利，我还是会根据对我而言有趣且重要的事情做出选择。几个月。 您在公司工作的所有物品都必须以一种或另一种形式出售。 目前，我正在研究对Internet和软件的未来至关重要的主题，但是我们对它们的理解还不够深入，无法创建出最终产品。 到目前为止，我们甚至对这些技术的工作原理还没有一个大致的了解。 由于这些研究是基础研究，因此我决定最好在大学而不是在公司进行研究：大学拥有更大的自由度，在那里您可以做一些事情，再十年都不会带来任何收益。 规划范围更广。
书籍设计数据密集型应用程序
瓦迪姆（Vadim） ：我们一定会回到研究的主题，但现在让我们谈谈您的书《
设计数据密集型应用程序》 。 我认为，这是有关现代分布式系统的最佳指南之一，几乎是一本百科全书：它列出了当今存在的所有最重要的成就。
马丁 ：谢谢你，我很高兴它派上了用场。
Vadim ：我们的读者不太可能还不熟悉它，但是以防万一，让我们讨论一下您正在撰写的分布式系统领域中最重要的成就。
马丁 ：实际上，在编写本书时，我并没有设定描述某些技术的目标。 相反，我想对用于存储和处理数据的系统的世界进行指导。 现在有大量的数据库，流处理器，批处理工具，各种复制工具等，因此很难全面地了解这一领域。 而且，如果您需要一个数据库来解决特定问题，则很难从许多现有数据库中选择一个。 在这种情况下，许多有关此类系统的书籍都毫无用处。 例如，在一本有关Apache Cassandra的书中，可能会写出Cassandra的出色之处，但对于不适合它的任务将一言不发。 因此，在我的书中，我尝试确定编写大型系统时需要问自己的基本问题。 对这些问题的答案将有助于确定哪种技术最适合解决当前问题，哪些不是很好。 最主要的是，没有什么技术可以做所有事情。 我试图显示不同技术在不同环境下的优缺点。
瓦迪姆（Vadim） ：确实，许多技术具有共同的特征和功能，并提供相同的数据模型。 同时，人们不能信任广告，要了解系统的内部结构，不仅要阅读技术报告和文档，甚至还要阅读源代码。
常识与人工炒作和工具广告
马丁（Martin） ：而且，您经常必须仔细阅读这些内容，因为文档没有说明数据库不太适合什么任务。 实际上，任何数据库都有其自身的局限性，因此您应该始终知道哪些局限性。 通常，您必须阅读部署指南并重建系统的内部操作。
瓦迪姆 ：是的，这是一个很好的例子。 您是否不认为在该领域中没有足够的通用词汇表或一套标准，可以用来比较一个任务的不同解决方案？ 现在，相同的事物使用了不同的名称，并且根本没有提及应清楚阐明的许多方面，例如，保证交易性。
马丁 ：是的，的确如此。 不幸的是，在我们的行业中，经常会在不同的乐器周围过分兴奋。 这是可以理解的，因为这些工具是由有兴趣推广其产品的公司创建的。 因此，这些公司派人参加会议，从本质上讲，他们谈论这些产品的优点。 这伪装成技术报告，但从本质上讲，它是广告。 更诚实地了解我们产品的优点和缺点不会损害我们这个行业。 对此的要求之一是通用术语；没有它，就无法进行比较。 但是除此之外，还需要一些方法来分析各种技术的优缺点。
不必要的CAP定理和其他行业错误
瓦迪姆 ：我的下一个问题很敏感。 您能告诉我们您在职业生涯中遇到的任何行业常见错误吗？ 例如，关于您早就应该摆脱的一些高估的技术或广泛使用的解决方案？ 这可能不是最好的示例，但是我想到可以在HTTP / 1.1上使用JSON，而不是在HTTP / 2上使用gRPC。 也许您不同意这种观点？
马丁 ：通常，在创建系统时，为了实现一件事，您需要牺牲一些东西，在这里我不想谈论错误。 如果要在HTTP / 1.1上的JSON和HTTP / 2上的协议缓冲区之间进行选择，则这两个选项都有权存在。 如果决定使用协议缓冲区，则需要定义一个方案，它很有用，因为它有助于准确确定系统的行为。 但是在某些情况下，这种方案只会引起烦恼，特别是在开发初期，即数据格式经常更改的时候。 同样，这里为了实现某个目标，必须牺牲一些东西，在某些情况下这是有道理的，但在另一些情况下则没有。 真正可以称为错误的解决方案并不多。 但是，由于我们正在谈论这一点，所以我们来谈谈CAP定理-我认为，绝对没有任何好处。 当在系统设计中使用它时，要么对CAP定理的含义有误解，要么借助它证明了不言而喻的陈述。 它使用一个非常狭窄定义的一致性模型-线性化和一个非常狭窄定义的可访问性模型-每个副本都必须是完全可访问的，即使它无法与任何其他副本建立连接。 一方面，这些定义非常正确，但另一方面，它们又过于狭窄：许多应用程序根本不需要这种一致性或可访问性的定义。 而且，如果应用程序对这些单词使用了不同的定义，则CAP定理对他来说是无用的。 因此，我认为应用它没有多大意义。 顺便说一句，自从我们开始谈论行业中的错误以来，让我们坦诚地说，加密货币采矿完全是电力的浪费。 我不明白您怎么能认真做到这一点。
Vadim ：此外，大多数存储技术现在都可以针对特定任务进行自定义，即 您可以在出现故障时选择适当的操作模式。
马丁 ：是的。 而且，这些技术的很大一部分都不受CAP定理的一致性和可访问性的严格定义，即它们不是CP，不是AP也不是CA，只有P。没有人会直接写这个软件，但实际上它可以做一个完美合理的发展策略。 这就是为什么我认为分析软件时CAP弊大于利的原因之一：绝大部分的设计决策都没有以任何方式呈现，并且可以说是相当合理的解决方案，但是CAP不允许对其进行描述。
分权化的好处
Vadim ：现在开发数据密集型应用程序时最严重的问题是什么？ 最积极探讨哪些主题？ 据我所知，您是分散式计算和分散式数据仓库的支持者。
马丁 ：是的。 我在研究中证明的观点之一是，目前我们过于依赖服务器和集中化。 在Internet的早期，它是从ARPANET演变而来的，它被设计为高度稳定的网络，在其中可以沿各种路由发送数据包，而这些数据包仍然可以达到其目标。 在美国任何城市发生核爆炸的情况下，网络的幸存部分将继续运行，将仅使用替代路线绕过故障区域。 这是冷战产生的计划。 但是后来我们决定将所有内容都放置在云中，因此现在几乎所有内容都以某种方式通过了美国东部弗吉尼亚州某个地方的AWS中心之一。 在某个时候，我们放弃了分散使用网络各个部分的理想，而确定了现在一切都依赖的服务。 我认为重要的是要回到分散的方法，在该方法中，对数据的更多控制将不属于服务，而是最终用户。
当涉及到去中心化时，它们通常指的是加密货币之类的东西，因为它们具有交互代理网络，没有像银行这样的集中管理机构。 但这不是我在说的去中心化，因为我认为加密货币也非常集中：如果您需要与比特币完成交易，则必须通过比特币网络完成，因此一切都围绕该网络进行。 从没有单个组织中心的意义上说，网络结构是分散的，但是整个网络是极其集中的，因为每笔交易都必须通过该网络进行，而别无其他。 我相信这也是集中化的一种形式。 在加密货币的情况下，这是不可避免的，因为必须确保不存在双重成本，而如果没有一个网络就完成交易等达成共识的情况下，这是很难实现的。 但是有许多应用程序不需要像区块链这样的系统；它们可以使用更加灵活的数据模型。 这些分散的系统使我最感兴趣。
瓦迪姆（Vadim） ：既然您提到了区块链，您能否告诉我们有关分散系统领域中有前途或不知名的技术的信息？ 我本人曾参与IPFS，但您在这方面有更多经验。
马丁 ：实际上，我并不积极地采用这种技术。 我读了一些有关IPFS的信息，但我自己还没有使用过。 我们与
Dat进行了一些合作，
Dat与
IPFS一样，是一种分散式存储技术。 区别在于
Filecoin加密货币与IPFS绑定，并且用于支付数据存储费用，而Dat则没有区块链。 Dat只允许您基于P2P将数据复制到多台计算机，对于我们正在从事的项目，Dat很棒。 我们编写了供用户在文档，数据或数据库上进行协作的软件，并将此数据中的每个更改发送给拥有数据副本的每个人。 在这样的系统中，可以根据P2P原理使用Dat，以确保在网络级别进行操作，即NAT穿越并通过防火墙，这是一项相当困难的任务。 最重要的是，我们从CRDT编写了一个关卡，借助该关卡，几个人可以编辑文档或数据集，从而可以快速方便地共享编辑内容。 我认为可以在IPFS之上编写类似的系统，而忽略Filecoin并仅使用P2P复制。
Vadim ：但是这样的系统不会变得没有那么快响应了，因为WebRTC直接将节点彼此连接，而IPFS更像是一个分布式哈希表。
马丁 ：事实是，WebRTC的堆栈级别略有不同。 它主要用于视频通话-很可能在我们现在通过其进行通信的软件中使用。 此外，WebRTC提供了一个通道，您可以通过该通道发送任意二进制数据。 但是在其之上创建复制系统可能很困难。 但是在Dat和IPFS中，您无需为此做任何事情。
您提到了响应能力，这是要牢记的一个非常重要的因素。 假设我们要分散下一个Google文档的权限。 在Google文档中，更改单位是单个按键，并且每个新字符都可以实时发送给使用同一文档的其他人。 一方面，这确保了快速的协作，另一方面，这意味着在编写大型文档时，您需要发送成千上万个单字符更改，并且许多现有技术都无法很好地应对这种数据压缩。 即使我们假设每次击键仅需要发送一百个字节，对于一个100,000个字符的文档，也将需要发送10 MB的数据，尽管这样的文档通常不超过几十KB。 在发明了一些巧妙的压缩方法之前，这种数据同步需要大量的额外资源成本。 许多P2P系统还没有有效的方法来创建状态快照，以使其可以用于类似Google Docs的系统。 我正在研究的就是这个问题，试图为多个用户创建一种更有效的文档同步算法。 这应该是一种不会存储每个按键的算法，因为这需要太多的资源，并且应该可以更有效地利用网络。
新的CRDT，在Isabelle进行了正式验证
瓦迪姆 ：您能告诉我们更多有关此的信息吗？ 您是否成功实现了100倍以上的数据压缩？ 您是在谈论新的压缩技术还是特殊的CRDT？
马丁 ：是的。 到目前为止，我们只有一个原型；尚未完全实现。 还需要进行其他实验，以了解其实际效果。 但是我们的一些方法很有希望。 在我的原型中，我能够将单个编辑的大小从100减少到1.7字节。 但是，我重复一遍，到目前为止，这只是一个实验版本，该指标可能会略有变化。 一种或另一种方式，这方面有很大的优化机会。
瓦迪姆 ：那么您在九头蛇会议上的报告将与此有关吗？
马丁 ：是的。 我将简要介绍CRDT，协作软件以及在此情况下出现的一些问题。 然后，我将讨论我们在这一领域所做的研究-它们处理许多不同的问题。 在应用程序方面，我们在JavaScript中实现了这些算法，在此基础上，我们创建了可运行的程序以更好地了解算法的行为。 同时，我们还在研究形式化方法以证明这些算法的正确性，因为其中一些方法不太明显，我们希望确保它们始终达到一致的状态。 在某些临界情况下，许多先前开发的算法无法提供一致性。 为了避免这种情况，我们转向了证明正确性的正式方法。
瓦迪姆 ：您是否为此系统使用定理证明如Coq或Isabelle？
马丁 ：是的，
伊莎贝尔 。
编者注：马丁将在《怪圈》上阅读有关伊莎贝尔的演讲 。
瓦迪姆 ：您打算发布此证据吗？
马丁 ：是的，我们一年半前
发布了第一批证据以及CRDT验证框架。 我们使用此框架测试了三个CRDT，其中最重要的是RGA（可
复制可复制数组 ），CRDT用于共同编辑文本。 该算法不是太复杂，而是很明显，因为目前尚不清楚它是否正确，因此需要形式上的证明。 我们还致力于证明几个现有CRDT的正确性，而我们在这一领域所做的最后一件事就是为新数据模型创建自己的CRDT。
瓦迪姆 ：形式证明的数量比算法本身的代码大小多多少？ 有时会有困难。
马丁 ：确实有足够的困难，我们必须做大量的证据工作。 : 60 , , 800 . , 12 . , . , . , . . , .
: , ? ?
: , . , . : TCP, Git . , , . , . . , .
Event sourcing, , XA-
:
, . , event sourcing. , - . event sourcing ? - , .
: . Event sourcing , , . , event sourcing . , , , . , event sourcing () .
event sourcing . Apache Kafka. Event sourcing Apache Kafka, , . event sourcing Apache Kafka , , , event sourcing. , , , . Apache Kafka , , , , , . Apache Kafka . Apache Kafka , . , Elasticsearch, Memcached Redis.
, , event sourcing. , . , , . — , . , event sourcing. : PostgreSQL , . , Kafka. , , .
: . , , , , .
: , , JSON (, PostgreSQL ) . , . . , .
: event sourcing. , . , (, ), : Elasticsearch, ; , key-value Memcached; , . .
: , , , — ?
: . , , , , , 404, .
: . (causal consitency) . , . , : , , . , , - . . , , , Elasticsearch Memcached. , , , . , snapshot isolation: , , . . , , . Memcached Elasticsearch . , , Memcached, Redis, Elasticsearch , . , , . , . . , . , , — , . . , . , - , .
: ,
Multiversion Concurrency Control .
: , . XA-, , , . , , . , , . XA . , , . .
: , - .
: , . , , , . , . - , . , . - , : , , , . . , .
: , . , . - , , , - .
: . . , , . , .
: , . event sourcing. , , , . , . , , , . , , , , , . ?
: , . , , . , , , , . . , . , , .
: , , , .
: . , . , . , , , . (, - ), . . - , . — , . , , , , 100%, .
: . .
: .
: , , . , — , . .
Hydra 2019,
: , Hydra? , , , .
: , , , , « » « ». . . , , - ; , , , , .
: , , , ? . , , ?
: , . , . , . - . , - , - . , . : , . — , — . , , , .
: . ? , - , , ?
: . . , . , , , . - — . , , . : . , , Slack ,
. , , . , , , .
: .
: , .
: ,
!
我想提醒您，这是预先录制的采访。 当您写评论时，请记住，马丁不会阅读它们。 我们只能传达一些最有趣的东西。 如果您真的想与作者交谈，他将在2019年7月11日至12日在圣彼得堡举行的Hydra 2019会议上作“在用户设备之间同步数据以进行分布式协作”的演讲。 门票可以在官方网站上购买。