Designing Data

Stella981
• 阅读 386

Designing Data

下面是这本书序言中的大部分内容****,本人的英文水平有限,有理解不到位的地方还请大家指教,这算是自己对这本书的读书笔记和总结。

数据是当今系统设计中许多挑战的中心,一些难以解决的问题如系统的可扩展性,一致性,可靠性,有效性和可维护性等需要弄清楚。 另外,面对这些琳琅满目的工具包括关系型数据库,NoSQL数据库,流处理或批处理以及消息队列等,我们该如何做出正确的选择? 我们又该如何正确理解这些流行术语?

在这本实用且全面的指南中,作者Martin Kleppmann通过分析处理和存储数据的各种技术的优缺点,能够帮你快速了解这个多样化的领域。在软件开发中世界是变化的,但其基本原则保持不变。软件工程师和架构师更应该学习如何在实践中应用这些想法,以及在现代应用中如何充分利用这些数据。

概括起来,本书有以下五个方面的特色:

  • 探究你目前正在使用的系统幕后的技术细节,学习如何更有效地使用和操作它们
  • 通过鉴别不同工具的优缺点做出最明智的决策
  • 在一致性,可扩展性,容错性和复杂性之间进行权衡
  • 明白分布式系统技术的研究和实践取决于你所使用的数据库
  • 探究大部分在线服务背后的技术细节,学习他们的架构

作者在开篇就告诉了读者写此书的目的:

技术是推动社会发展的强大力量。 数据,软件和信息可以用来做坏事:巩固不公平的权力结构,破坏人权,保护既得利益。 但是,它们也可以用来做好事:让外界听到底层民众的声音,为每个人创造机会,避免灾难。 这本书正是致力于指引人们人朝着正确的方向前进。

如果你近年来从事软件工程领域的技术开发工作,尤其从事于服务端/后端的开发工作,你的耳朵可能会被大量的有关数据处理和存储的热门术语所充斥:NoSQL! 大数据! 全网域(Web-scale)!分片(Sharding)! 最终一致性(Eventual consistency)! ACID(原子性、一致性、隔离性、持久性)! CAP(一致性、可用性、分区容错性) 理论! 云计算服务(Cloud services)! MapReduce!Real-time!

在过去的十年中我们看到了很多数据库,分布式系统以及在其上构建的应用程序的有趣的发展趋势。这些发展背后有着有不同的推动力:

  • 诸如谷歌,雅虎,亚马逊,Facebook,LinkedIn,微软和Twitter等互联网公司正在处理大量的数据和流量,这样的需求迫使他们创造新的工具使他们能够高效地处理这种大规模的数据

  • 企业的敏捷性,低成本开发,通过缩短开发周期和构建灵活的数据模型能够对不断变化的市场需求做出快速反应

  • 在许多业务中成功的免费开源软件已成为商业或定制的内部软件的首选

  • CPU时钟频率的增长在近年已趋于饱和,但是多核CPU已经成为服务器标配,网络性能不断提升,意味着并行计算能力得到大幅度提升

  • 即使你在一个小规模团队工作,你依然可以借助AWS(Amazon Web Services)这样的基础设施服务(Iaas)在多台计算机甚至多个地理区域上构建分布式系统

  • 现在很多服务都预想是高可靠的,因停电或维修造成的长时间停机越来越不可接受

数据密集型应用正在利用这些技术拓展着无限可能。现在很多应用都是数据密集型的,而不是计算密集型的。因为对这些应用来说,CPU的计算能力不再是瓶颈,更大的挑战来自于数据的数量、复杂度和更新的速度。

帮助数据密集型应用存储和处理数据的工具和技术已经迅速适应这些变化。在新的数据库系统(“NoSQL”)引起业界广泛关注的同时,消息队列,缓存,搜索索引,批处理和流处理框架以及相关技术也同等重要,很多应用综合使用很多种技术。

随处可见的流行语意味着我们热衷于尝试新鲜事物,这是一件好事。 但是,作为软件工程师和架构师,如果我们想要构建出色的应用程序,我们就需要对这些新鲜技术有更加深入精确的理解以及能权衡这些技术的优劣, 为此,我们必须深入挖掘这些新鲜技术背后的细节。

幸运的是,万变不离其宗,在技术快速变化的背后依然存在始终保持正确的持久不朽的原则,无论您使用哪个版本的某种特定工具。 如果你了解这些原则,您就能知道每个工具适用的地方,以及如何充分利用它还有如何避免错误。这也是本书的目的。

本书的目标是帮助您了解数据处理和存储的日新月异的多样化技术。这不是某个特定工具的专属教程,也不是一本充满干枯理​​论的教科书。相反,我们将会介绍许多数据系统的成功案例:那些运行在生产环境中的支撑起很多流行应用的且每天能够满足伸缩性,性能和可靠性需求的技术。

我们将深入到这些系统的内部,梳理他们的关键算法,讨论他们的原则以及他们面临不同目标时作出的权衡取舍。在这个过程中,我们将尝试寻找探索数据系统的有效方法 - 不仅仅局限于知道它们是如何工作的,还有它们为什么用这种方式工作,以及我们需要问些什么问题。

阅读本书后,您将能够恰当地按需选择合适的技术,并了解如何综合使用多种技术去构建一个健壮的应用程序体系架构。幸运的是很少需要你从头开始构建自己的数据库存储引擎,其实也没有这个必要。然而,你必须能直观的明白你的系统内部正在做什么,这样你就可以推断他们的行为,做出合理有效的设计决策,并且能追踪到可能出现的问题。

谁该阅读这本书?

如果你开发的应用有着存储或处理数据的服务端/后端,并且你的应用使用互联网(例如,Web应用程序,手机app或连接到互联网的传感器),那么这本书适合你。

本书适用于喜欢编程的软件工程师,软件架构师和技术经理。如果您需要对你所开发的系统架构做出决策,例如,如果你需要选择哪些能工具解决给定问题并弄清楚如何最好地应用他们,这也是相当适用的。但即使没有这样的需求,这本书也能帮助你更好地了解他们的优劣。

您应该具有一些开发过Web应用或网络服务的相关经验,并且您应该熟悉关系型数据库和SQL。最好熟悉一些非关系型数据库和其他与数据相关的工具,但不是必须。大致了解常见的网络协议如TCP和HTTP对于本书也是有帮助的。本书与你使用的编程语言或平台无关。

如果你符合下面列出的任何一种情况,这就是一本很有价值的书:

  • 您想了解如何使数据系统可扩展,例如,为数百万用户支持Web或移动应用。
  • 您需要提高应用的可用性(最大限度地减少停机时间)和运行稳定性。
  • 您正在寻找使系统长期易于维护的方法,即使随着系统不断发展即使需求和技术的不断变化。
  • 您对事物的运行机制有着天然的好奇心,并且希望知道大部分网站和在线服务背后的原理。本书分析了各种数据库和数据处理系统的内部结构,探索这些系统设计中的亮点是非常有趣的事情。

有时,我们在讨论可扩展的数据系统时,有些人会作出“你不是谷歌或亚马逊”这样的评论。"停止担心规模,只使用关系型数据库“这个陈述中有这样的道理:为不需要的规模构建系统是浪费精力,这也有可能会把你锁在僵化的设计中。 实际上,这是一种过早优化的形式「过早优化是万恶之源」。但是选择合适的工具也很重要,每个技术都有各自不同的优点和缺点。 我们将会看到关系型数据库固然很重要但他不是对数据处理技术的盖棺定论。

本书范围

本书没有打算给出关于如何安装或如何使用专用软件包或API的详细说明,因为这些内容已经有很多文档了。 相反,我们会讨论对数据系统至关重要的各种原则和权衡,我们也会探索不同的产品所做出的不同的设计决策。

在本书的电子版中,我们包含了在线资源的全文链接。所有链接都在出版时都进行了验证,但不幸的是,由于网络自身的性质,有些链接存在频繁中断的现象,如果您遇到这种情况或者您阅读的是本书的印刷本,你可以借助搜索引擎查找这些参考资料。对于学术论文,您可以在Google学术搜索中搜索相关标题以查找开放取阅(open-access)式的PDF文件。 或者,您可以在https://github.com/ept/ddia-references找到所有的参考资料,我们会在这里维护最新的链接。

我们主要关注数据系统的架构以及它们被集成到数据密集型应用中的方式。由于篇幅的原因这本书不涉及部署,操作,安全,管理等领域 - 这些都是复杂而重要的话题以致于在本书中用一些片面的粗略的注解都不足以给与他们正确的评价,他们中的任一个亦能单独出一本书。

本书中描述的许多技术属于大数据领域。 然而,“大数据”这个术语被过度使用且定义很模糊。 本书使用更为明确的术语,如单节点VS分布式系统,在线/交互式VS离线/批处理系统。

本书偏向于自由和开源软件(FOSS),因为阅读,修改和执行源代码是一种理解事情是如何工作的有效方式。使用开放平台还可以降低供应商锁定的风险。 然而,在适当的情况下,我们也讨论所有权软件(闭源软件,软件即服务,或仅在文献中描述但不公开发布的公司内部软件)。

本书纲要

本书分为三部分:

  1. 在第一部分中,我们会讨论数据密集型应用设计的基本思想。我们将从第1章开始讨论我们要努力实现的功能:可靠性,可扩展性和可维护性;我们该如何考虑这些功能以及如何实现它们。在第2章中,我们将比较几种不同的数据模型和查询语言,看看它们是如何适应不同情况的。在第3章中,我们将讨论存储引擎:数据库如何在磁盘上存储数据以便我们可以再次快速地找到它。第四章将转向介绍数据编码(序列化)的格式和架构演变的历程。
  2. 在第二部分中,我们将单节点数据存储转移到分布式数据存储。这通常对于实现可扩展性的应用来说是必需的,但同时也会带来各种各样的挑战。我们将先讨论复制(第5章),分区/分片(第6章)和事务(第7章)。然后,我们再更详细地讨论分布式系统中存在的问题(第8章),以及在分布式系统中实现consistency和consensus意味着什么(第9章)。
  3. 在第三部分中,我们将讨论数据抽取、转换、装载的过程。源数据通常存储在异构系统中:当没有一个数据库可以把所有事情都能处理好的时候,应用程序就该需要集成几个不同的数据库,缓存,索引等等。在第10章中,我们将用批处理的方法进行数据转换,而在第11章中我们将用流处理的方法来进行数据转换。最后,在第12章中,我们将所有内容放在一起,讨论在未来构建可靠的,可扩展的、可维护的应用程序的方法。

参考文献及延伸阅读

我们在本书中讨论的大部分内容已经在其他地方以某种形式被提及了----会议报告,研究论文,博客文章,代码,bug追踪器,邮件列表。 这本书总结了来自许多不同来源的最重要的想法,其中包括了这本书所有的原始文献的出处。如果你想更深入地探索每一个知识细节,那么每章末尾的参考资料都是很好的资源,他们中的大多数可以在线免费获取。

作者:鱼果
本文地址:http://www.cnblogs.com/fingerling/p/8297696.html
欢迎转载,请在明显位置给出出处及链接。

点赞
收藏
评论区
推荐文章
blmius blmius
2年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
Wesley13 Wesley13
2年前
java将前端的json数组字符串转换为列表
记录下在前端通过ajax提交了一个json数组的字符串,在后端如何转换为列表。前端数据转化与请求varcontracts{id:'1',name:'yanggb合同1'},{id:'2',name:'yanggb合同2'},{id:'3',name:'yang
Jacquelyn38 Jacquelyn38
2年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
Souleigh ✨ Souleigh ✨
2年前
前端性能优化 - 雅虎军规
无论是在工作中,还是在面试中,web前端性能的优化都是很重要的,那么我们进行优化需要从哪些方面入手呢?可以遵循雅虎的前端优化35条军规,这样对于优化有一个比较清晰的方向.35条军规1.尽量减少HTTP请求个数——须权衡2.使用CDN(内容分发网络)3.为文件头指定Expires或CacheControl,使内容具有缓存性。4.避免空的
Stella981 Stella981
2年前
Android So动态加载 优雅实现与原理分析
背景:漫品Android客户端集成适配转换功能(基于目标识别(So库35M)和人脸识别库(5M)),导致apk体积50M左右,为优化客户端体验,决定实现So文件动态加载.!(https://oscimg.oschina.net/oscnet/00d1ff90e4b34869664fef59e3ec3fdd20b.png)点击上方“蓝字”关注我
Easter79 Easter79
2年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
2年前
35岁,真的是程序员的一道坎吗?
“程序员35岁是道坎”,“程序员35岁被裁”……这些话咱们可能都听腻了,但每当触及还是会感到丝丝焦虑,毕竟每个人都会到35岁。而国内互联网环境确实对35岁以上的程序员不太友好:薪资要得高,却不如年轻人加班猛;虽说经验丰富,但大部分公司并不需要太资深的程序员。但35岁危机并不是不可避免的,比如你可以不断精进技术,将来做技术管理或者
Wesley13 Wesley13
2年前
35岁是技术人的天花板吗?
35岁是技术人的天花板吗?我非常不认同“35岁现象”,人类没有那么脆弱,人类的智力不会说是35岁之后就停止发展,更不是说35岁之后就没有机会了。马云35岁还在教书,任正非35岁还在工厂上班。为什么技术人员到35岁就应该退役了呢?所以35岁根本就不是一个问题,我今年已经37岁了,我发现我才刚刚找到自己的节奏,刚刚上路。
Python进阶者 Python进阶者
3个月前
Excel中这日期老是出来00:00:00,怎么用Pandas把这个去除
大家好,我是皮皮。一、前言前几天在Python白银交流群【上海新年人】问了一个Pandas数据筛选的问题。问题如下:这日期老是出来00:00:00,怎么把这个去除。二、实现过程后来【论草莓如何成为冻干莓】给了一个思路和代码如下:pd.toexcel之前把这