数据密集型应用系统设计 pdf_设计数据密集型应用程序的未来

剑桥大学研究员马丁·克莱普曼(Martin Kleppmann)的《设计数据密集型应用程序》对于那些想要了解不同数据库如何工作以及如何在它们之间进行选择的人来说是一本好书。 但这不仅仅是系统地解释技术细节。 该书还概述了用于管理数据的工具和技术的现状，以及塑造未来的新兴趋势。 在本文中，我们将分析其中提出的一些有趣的想法：

· 非关系数据库和关系数据库(甚至消息系统和数据库)之间的区别如何变得不太清晰

· 现代数据库一般如何处理事务和保持一致性

· 不再推荐使用哪种方式处理大数据，而应该怎么做

· 如何使用多语言持久性(用于不同目的的不同数据库)而不会遇到问题

· 如何组织客户端与服务器之间的通信，以使客户端应用程序具有响应能力，并且不会向用户显示过时的信息

融合数据模型

最初，术语" NoSQL"仅被理解为" no-SQL"或" no-relational"。 您可能会认为几乎没有妥协的地方。 当前，它被广告宣传为"不仅是SQL"，而且从营销的角度来看有一个很好的理由：人们对支持多种访问数据的数据库的兴趣正在增长。

例如，文档数据库RethinkDB引入了关系数据库领域的一项功能-表联接。 良好的旧SQL标准获得了JSON支持，您可以在流行的商业数据库和开放源代码(MySQL，PostgreSQL)数据库引擎中使用它。

结果，关系数据库和非关系数据库之间的区别不再像以前那样尖锐，如果您已了解如何应用这些新功能，则可以为数据建模提供更大的灵活性。 有关在PostgreSQL中存储JSON的实际案例研究的概述，请阅读Leigh Halliday撰写的综合文章。

当我们更广泛地看待数据处理系统而不仅仅是数据库时，也可以看到融合。 有一些消息传递系统可以像数据库一样提供持久性保证(Kafka)，也可以将数据库视为消息队列(Redis)。

在消息传递系统领域，Apache Pulsar(书中未提及)声称既提供高性能事件流(以Kafka方式)又提供传统队列。

一致性更重要

不久前，当围绕" NoSQL"一词的炒作不断增长时，您可以轻松地找到人们在博客或推特上发布有关关系数据库"过时"的信息。 如果您问过在哪里可以找到交易，您可能听说过您不了解"现代"数据库。 而且，如果您怀疑在高流量下数据是否正确，那么流行的答案是您需要学习"最终一致性"。

正如马丁所指出的，时代已经改变。 事实证明，如果数据库的一致性差，那么您最终只能自己解决困难的分布式编程问题，而且容易出错。 现在的期望是数据库将解决您的一些问题，以便您可以专注于业务模型，而将分布式编程留给专门从事该模型的人员(即数据库创建者)使用。

随着"最终一致性"的口号不再是可以接受的借口，数据库创建者终于开始更加清楚自己的一致性方法。 Datomic和Fauna DB等广告在宣传其产品时会突出显示"交易"和"一致性"。 在MongoDB版本4的公告中，您可以看到的第一件事是"多文档ACID事务"。

思考一致性的新方法

越来越多的新数据库试图提供ACID保证，而又不需要太多协调，这会降低分布式系统的速度。 他们尝试使用与传统数据库引擎不同的方法，例如，通过确保事务非常简短和确定性，并在单个线程(如VoltDB)中执行它们，来进行尝试。

我们讨论一致性的方式甚至有所变化。 研究人员认为SQL标准定义的事务隔离级别是有缺陷的。 曾经广受欢迎的" CAP定理"也遭到马丁的严厉批评，因为它令人困惑(他的博客上有一篇帖子，请停止呼叫数据库CP或AP)。 事情开始有所改善，也许数据库创建者在描述他们的产品时会采用更精确的词汇，并且我们将能够谈论"读自己的文章"的一致性，因果一致性等。

信任但要验证

直到最近，问题不仅仅在于数据库生产者还没有明确说明他们提供的一致性保证，而且他们的声明也没有得到验证。 这种情况只是在最近才改变，这似乎令人感到震惊，因为我们正在谈论的是可能花费很多钱的系统。

各种分布式系统(例如Cassandra和Elasticsearch)的创建者都使用开源工具Jepsen来发现其实现中的错误。 分析报告向公众开放。

如前所述，数据库是用来照顾我们以外的一些协调工作的，并且是解决数据共享问题的可靠解决方案。 现实有点令人恐惧：您无需将数据库分散在网络上就可以遇到错误-某些系统即使在单台计算机上运行时，其行为也不正确。

Martin Kleppmann测试了流行的关系数据库以进行事务隔离(请参阅github.com/ept/hermitage中的结果)，并发现了多个问题。 例如，"可重复读取"隔离级别意味着不同数据库中的概念不同，或者某些异常出现了，尽管从定义上讲不应该。

您可能会认为关系模型非常成熟，以至于一切都已经被发现，而这些时候已存在很久的SQL数据库只是在细化细节并添加诸如JSON集成之类的额外功能。 这本书表明，对该主题的研究仍然很活跃，并且具有实际意义。 我们不仅可以了解某些产品的交易实现中的错误，而且有时还可以找到解决旧问题的新方法。

2008年，有出版物对著名的快照隔离进行了改进，该隔离解决了一些异常情况，而不会降低典型可序列化隔离中使用的锁的性能。 三年后，在PostgreSQL中实现了这种"可序列化的快照隔离"功能(目前还没有其他流行的实现方式)。 该数据库长期以来一直宣称自己是"世界上最先进的开源关系数据库"，但是现在也许现实是，如果从声明中删除"开源"，它仍然是正确的。

MapReduce的现代替代品

让我们暂时离开"典型"数据库，专注于处理大量数据。 该书着重说明了Hadoop之类的工具所代表的MapReduce范式的局限性。 整个想法源自Google，2014年Google承认他们不再使用MapReduce。 这种处理方式强制将每个中间结果存储在磁盘上，这会增加大量开销。 令人发疯的是，MapReduce仍然是一种非常受欢迎的解决方案，其设计如此欠佳，因为它是作为Google论文中描述的方法的开源实现而创建的，而不是针对非常具体的Google环境(其中MapReduce- 例如作业经常被杀死以让位给更重要的任务，因此将数据转储到磁盘上很有意义。

因此，现代大数据处理应选择更高级和更优化的解决方案，例如Spark和Flink。

处理派生数据

在构建具有多种访问数据方式的大型系统时，仅使用一种数据库就很难实现高性能。 最好使用多个数据系统，每个数据系统都针对特定的访问模式进行了优化，例如用于存储所有信息的"常规"数据库和用于某些部分高效全文本搜索的ElasticSearch。

本书强烈建议不要使用应用程序代码来更新各种数据存储。 风险太大，以致于更改快速发生，一个数据库将以与另一种类型的数据库不同的方式应用它们，从而创建两个相互矛盾的视图。

建议的解决方案是使用Kafka和Change Data Capture分发更新。 Kafka的耐用性和订购保证将确保派生数据保持一致。 由于存在许多流行数据库的连接器，因此无需编写任何自定义代码即可进行流式更改。

以这种方式构造派生数据，使我们能够通过纯粹基于事件和异步进行通信，从而在微服务体系结构中构建耦合较少，性能更高的系统。 然后，服务可以通过读取Kafka的更新来拥有一个保持最新状态的本地数据库。 结果，该服务将能够快速查询此本地数据库并以最适合它的格式获取数据，而不必向其他服务发送同步请求。 在"数据库捆绑：微服务时代的提交日志"演示文稿中可以找到这种方法的一个很好的例子，该文档具有同步微服务体系结构的"重构"功能。

马丁提到的另一个好处是更好的模式演化。 传统上，如果数据格式不再符合目的，那么迁移到新格式将很痛苦。 客户端代码必须更改，有时还需要中断才能运行迁移作业。 为避免这种情况，我们可以通过重新处理Kafka日志来创建一个新的派生视图，并对该视图进行试验以查看其效果是否优于旧视图。 然后，我们可以逐步修改客户端，最后删除不再使用的旧视图。

将状态推送给客户端

当您的应用程序从服务器获取数据，显示并允许对其进行修改时，它的行为类似于数据库副本-网络连接问题会产生与数据库世界类似的问题(欢迎解决冲突)。 Martin提到的另一个新趋势是将先前的想法不仅应用于"派生"数据库，还应用于客户端应用程序。

替代让服务器进行繁重的准备工作以准备满足客户端需求的大量数据，替代方法是保持开放的通信通道并将非常基本的数据更改发送给客户端。 就像在Change Data Capture中一样，但是使用WebSocket或Server-Sent Events代替Kafka，并使用类似Redux的引擎(请参阅ngrx上的文章)，而不是包含派生数据的数据库。 优点：客户端不在系统的过时视图上工作，但是会随着服务器状态的改变而经常更新。 在Nexocode中，我们使用MongoDB的Change Streams功能将更改(添加，修改或删除的文档)发送到基于Angular的Web应用程序，它提供了出色的用户体验。

结论

我们可以假设，由于数据库已经开发了50多年，因此我们知道如何使用它们。 但是我们仍在学习中并且会犯错误。 幸运的是，学术研究似乎可以帮助改进现有产品，我们可以更好地了解不同解决方案的功能，并且可以修改旧的假设，以使系统在分布式环境中更好地工作。

对于那些将数据存储在不同种类的数据库中的人来说，诸如Apache Kafka之类的分布式日志系统是传播更改的正确方法。 同样，类似Kafka的平台可减少微服务之间的同步调用，并构建响应速度更快的系统。 关系数据库仍然是重要的组成部分。 NoSQL数据库可以采用正在进行的研究结果来提供有意义的一致性保证，而又不牺牲性能-这样，现有引擎可以被更广泛地采用，否则全新的引擎将受到欢迎。

与往常一样，没有银弹。 出现了新的工具和新功能，但是需要对数据系统原理有扎实的了解，以便选择适合于具体项目的解决方案。

最初于2020年6月17日发布在https://nexocode.com。

需要Nexocode团队更多的东西吗？ 在Medium，Twitter和LinkedIn上关注我们。 想一起做魔术吗？ 我们正在招聘！

(本文翻译自Piotr Kubowicz的文章《Future according to Designing Data-Intensive Applications》，参考：https://medium.com/nexocode/future-according-to-designing-data-intensive-applications-44bb15e3c55e)