实验室这一周真的忙爆(虽然都是各种打杂的活)所以拖了很久终于在周末(摸鱼)把实验3做完了。同时准备把和查询这一块有关的博客补一下。然后就进入最后一个project并行和锁那里。不过下周华为的比赛就开了。争取四月份之前把这些东西全都搞定。等到四月份的时候开一个新坑(leveldb源码阅读笔记??)
如今数据库分布在多种资源中,以提高DBMS的不同方面
并行DBMS
分布式DBMS
每一个worker就是一个独立的进程。worker可以理解为打工人。执行任务
整个流程大致如下
fork
一个子进程(也就是产生一个worker)来执行这个任务这个模型的好处是。如果一个进程出现了bug整个系统不会出现问题。只需要通知调度器在fork一个进程就好了
进程之间仍然共享内存。并且依赖于操作系统的调度。每个worker可以使用在进程池中任意的一个进程
一个进程可以有许多worker线程
整个流程大致如下
应用程序直接和worker的线程进行交互
优点
注意这并不意味着dbms里的所有任务一定要多线程来执行
DBMS永远知道的比操作系统更多
通过允许多条查询同时进行来提高整体的性能。
如果多条查询语句只是读数据库的话,那我们在不同的查询之间几乎不需要加任何限制条件
但是如果写操作比较多的话就很麻烦了
这个就是流水线操作。csapp第四章讲的非常清楚
通过并行执行单条查询语句来提高单个查询的性能。可以从生产者消费者的角度来理解
下面来看一个例子 -> PARALLEL GRACE HASH JOIN
这个非常简单我们让一个worker去执行一行的join操作然后输出结果就好
将整个查询操作分解为几个独立的片段,这些片段对不同的数据集执行相同的功能
例如下面的例子(截图警告)
其中A1承担一小部分任务
每个不同的worker承担不同的任务
最上面的Exchange操作基本可以分为三个类型
case1 Gather
将来自多个worker的结果合并到一个输出流中。最上层的Exchange操作必须始终是Gather
case2 Repartion
将多个输入流重新打乱成多个输出流
case3 Distribute
将单个输入流拆分为多个输出流
对于上面这个比较复杂的例子
这也叫做pipelined parallelism.
这种方法非常好理解就是位于下层的worker把得到的结果向上传递给上层的worker
方法1和2的结合版本
SELECT*FROM A JOIN B JOIN C JOIN D
在这个方法里一个woker1和worker同时执行整条语句的两个部分。并且会将执行之后得到的结果往上传递给worker3和worker4
因为磁盘的限制。所以使用额外的进程/线程可能并不会产生很好的效果。接下来介绍I/O的并行
拓展阅读RAID
RAID0形式
不同的page存储在不同的存储设备中
RAID1形式
不同的存储设备中存储着相同的数据。
逻辑上的一张表。我们可以把它分成几个独立的部分放在不同的物理资源中。并且理想情况下分区程序应该对用户是透明的
下面来看两种不同的划分方法
顾名思义就是按照列来划分。我们可以把不同的列放在不同的物理资源中
水平划分就是把不同的tuple(元组)放在不同的物理资源中
原文:https://www.cnblogs.com/JayL-zxl/p/14497016.html