数据密集型应用--0625--单机应用-数据基础

本书将是一趙关于数据系统原理、实践与应用的旅程，并讲述了设计数据密集型应用的方法。我们将探索不同工具之间的共性与特性，以及各自的实现原理。

 

1：可靠、可扩展、可维护的数据系统

应用同步数据到全文搜索引擎和缓存：

 

可靠性（Reliability)

系统在困境（adversity)（硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）。

 

如果所有这些在一起意味着“正确工作“，那么可以把可靠性粗略理解为即使岀现冋题，也能继续正确工作

硬件故障：冗余、硬盘 cpu 机房、双电源、云平台、

软件故障：

错误输入：充分测试

资源共享竞争：进程隔离

服务变慢：允许进程崩溃重启

级联故障：测量、监控系统，并且不停的自检

人为故障：

精心设计的抽象、更容易理解

沙箱隔离

彻底的测试

快速恢复

监控

 

 

可扩展性（Scalability)

有合理的办法应对系统的增长（数据量、流量、复杂性）

推特：推文推送的应对系统增长的扩展考虑：

 

应对负载的方法：

负载：垂直扩展：增加更强的机器，水平负载，将负载分摊到小机器上

弹性：增加计算资源（自动或者手动）

 

 

可维护性（Maintainability)

许多不同的人（工程师、运维）在不同的生命周期，都能在高效地在系统上工作（使系统保持现有行为，并适应新的应用场景）。

三个设计原则：

可操作性

便便于运维团队保持系统平稳运⾏行行。

良好的监控

自动化运维支持

避免单机依赖

良好的文档

管理权限放大

自我修复+人工干预

 

简单性

从系统中消除尽可能多的复杂度(complexity)，使新⼯工程师也能轻松理理解系统。(注意这和⽤用户接 ⼝口的简单性不不⼀一样。)

消除复杂最简单的手段是--抽象。屏蔽细节

 

 

 

可演化性：

使⼯工程师在未来能轻松地对系统进⾏行行更更改，当需求变化时为新应⽤用场景做适配。也称为可扩展性

(extensibility)，可修改性(modifiability)或可塑性(plasticity)。

 

 

 

 

数据模型与查询语言

关系型数据库：1970提出，已经流行几十年

Nosql相比关系型数据库的优点：

更好的扩展性，非常大的吞吐和数据集

开源、免费

一些特殊的查询操作

具有动态&表现力

 

模型分类：

关系模型：演进成关系型数据库，sql，

文档模型：擅长处理1对多的关系，无法表示多对多的关系，多用nosql进行持久化。

层次模型：擅长处理1对多的关系，数据结构式：树，嵌套结构，类似json

网络模型（CODASYL 模型、图）：是层次模型的推广，数据结构是：图，可以表示多对多、多对1的关系。每条记录只记录一个父节点。缺点：需要知道查询路径。

 

 

查询语言：

SQL:申明式。

IMS/CODASYL :命令式，命令式语⾔言告诉计算机以特定顺序执⾏行行某些操作可以想象⼀一下，逐⾏行行地遍历代码，评估条件，更更新变量量，并决定是否再循环⼀一遍。

web上声明式查询

以点击元素，改变背景颜色为例，css就是申明式、js就是命令式

 

MapReduce查询

既不是纯粹的声明式查询也不是命令查询

 

 

图数据模型

在顶点中描述连接的头、尾顶点，由顶点和边组成，

典型例子：社交图谱，网络图谱，公路和铁路网络，

 

存储与检索

 

哈希索引:

哈希索引方式区间查询效率低

SSTables:

我们还要求每个键只在每 个合并的段⽂文件中出现⼀一次(压缩过程已经保证)

实现方式：平衡数据结构如红黑树，当数据量大于几M的时候写入磁盘。

LSM：

基于这种合并和压缩排序⽂文件原理理的存储引擎通常被称 为LSM存储引擎。

LSM树的基本思想 —— 保存⼀一系列列在后台合并的SSTables —— 简单⽽而有效。 即使数据集⽐比可⽤用内存⼤大得多，它仍能继续正常⼯工作。由于数据按排序顺序存储，因此可以⾼高效地执⾏行行 范围查询(扫描所有⾼高于某些最⼩小值和最⾼高值的所有键)，并且因为磁盘写⼊入是连续的，所以LSM树可 以⽀支持⾮非常⾼高的写⼊入吞吐量量。

B树：

通过日志来实现高可用（预写式⽇日志(WAL, write-ahead-log)(也称为重做⽇日志(redo log) ），

通过锁存器器 实现并发控制

 

 

 

对比：

通常LSM树 的写⼊入速度更更快，⽽而B树的读取速度更更快

原因：

1：LSM树上的读取通常⽐比较慢，因为它们必须在压缩的 不不同阶段检查⼏几个不不同的数据结构和SSTables。

2：B树索引必须⾄至少两次写⼊入每⼀一段数据:⼀一次写⼊入预先写⼊入⽇日志，⼀一次写⼊入树⻚页⾯面本身(也许再次分 ⻚页) 即使在该⻚页⾯面中只有⼏几个字节发⽣生了了变化，也需要⼀一次编写整个⻚页⾯面的开销。有些存储引擎甚⾄至 会覆盖同⼀一个⻚页⾯面两次，以免在电源故障的情况下导致⻚页⾯面部分更更新

 

其他索引：

聚簇索引：数据存在索引中，写入慢，读取快，额外的事务保证

非聚簇索引：索引中只保持实际数据的引用，写入快，读取慢

全文索引：

模糊索引：

 

多维索引：是⼀一种查询多个列列的更更⼀一般的⽅方法，这对于地理理空间数据尤为 重要。例例如，餐厅搜索⽹网站可能有⼀一个数据库，其中包含每个餐厅的经度和纬度。当⽤用户在地图上查看 餐馆时，⽹网站需要搜索⽤用户正在查看的矩形地图区域内的所有餐馆。这需要⼀一个⼆二维范围查询，如下所 示:

SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079
                           AND longitude > -0.1162 AND longitude < -0.1004

 

多列索引（链接索引）：它通过将⼀一列列的值追加到另⼀一列列后⾯面， 简单地将多个字段组合成⼀一个键 (索引定义中指定了了字段的连接顺序)

 

 

事务处理还是分析（OLTP?OLAP?）

列存储，为什么需要？

1：⾯面向⾏行行的存储引擎仍然 需要将所有这些⾏行行(每个包含超过100个属性)从磁盘加载到内存中，解析它们，并过滤掉那些不不符合 要求的条件。这可能需要很⻓长时间。

2：面向列的存储背后的想法很简单:不不要将所有来⾃自⼀一⾏行行的值存储在⼀一起，⽽而是将来⾃自每⼀一列列的所有值存 储在⼀一起。如果每个列列存储在⼀一个单独的⽂文件中，查询只需要读取和解析查询中使⽤用的那些列列，这可以 节省⼤大量量的⼯工作

 

 

 

列存储压缩：

当您的查询需要在⼤量⾏中顺序扫描时，索引的相关性就会降低很多。相反，⾮非 常紧凑地编码数据变得⾮非常重要，以最⼤大限度地减少查询需要从磁盘读取的数据量量。我们讨论了了列列式存 储如何帮助实现这⼀目标。

 

因为同一列数据结构相同，数据类似，可压缩空间很大

常用压缩位图方法：

 

优势：位图索引，查询高效，按位与或即可

 

优化事务处理理(OLTP)和优化分析(OLAP)的区别：

OLTP：读少写多

OLAP：读多写少，而且不面向用户，主要由业务分析人员使用，对查询难度要求高。

 

日志结构学派

只允许附加到⽂文件和删除过时的⽂文件，但不不会更更新已经写⼊入的⽂文件。 Bitcask，SSTables，LSM树， LevelDB，Cassandra，HBase，Lucene等都属于这个组。

 

就地更新学派

将磁盘视为⼀一组可以覆盖的固定⼤大⼩小的⻚面。 B树是这种哲学的最大的例子，被⽤在所有主要的关系数 据库中，还有许多⾮系数据库。