mppdbLibra

1：三种数据库架构、特征、应用

数据库架构中shared-nothing等三个之间的优缺点）
1.shared-everything
一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表是SMP技术
2.Shared-Disk：
各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。典型的代表Oracle RAC，它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能?。
3.Shared-Nothing：
各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP（大规模并行处理）模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。典型代表Greenplum、Vertica，各节点相互独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转。

2：数据库锁机制：

表级锁模式

ACCESS SHARE只与“ACCESS EXCLUSIVE” 锁模式冲突;查询命令（Select command）将会在它查询的表上获取”Access Shared” 锁,一般地，任何一个对表上的只读查询操作都将获取这种类型的锁。

ROW SHARE与”Exclusive’和”Access Exclusive”锁模式冲突;”Select for update”和”Select for share”命令将获得这种类型锁，并且所有被引用但没有 FOR UPDATE 的表上会加上”Access shared locks”锁。

ROW EXCLUSIVE
与 “Share,Shared roexclusive,Exclusive,Access exclusive”模式冲突;“Update,Delete,Insert”命令会在目标表上获得这种类型的锁，并且在其它被引用的表上加上”Access shared”锁,一般地，更改表数据的命令都将在这张表上获得”Row exclusive”锁。

SHARE UPDATE EXCLUSIVE
”Share update exclusive,Share,Share row ,exclusive,exclusive,Access exclusive”模式冲突，这种模式保护一张表不被并发的模式更改和VACUUM;
“Vacuum(without full), Analyze ”和 “Create index concurrently”命令会获得这种类型锁。

SHARE
与“Row exclusive,Shared update exclusive,Share row exclusive ,Exclusive,Access exclusive”锁模式冲突,这种模式保护一张表数据不被并发的更改;
“Create index”命令会获得这种锁模式。

SHARE ROW EXCLUSIVE与“Row exclusive,Share update exclusive,Shared,Shared row exclusive,Exclusive,Access Exclusive”锁模式冲突;任何Postgresql 命令不会自动获得这种锁。

EXCLUSIVE
与” ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE”模式冲突,这种索模式仅能与Access Share 模式并发,换句话说，只有读操作可以和持有”EXCLUSIVE”锁的事务并行；任何Postgresql 命令不会自动获得这种类型的锁；

ACCESS EXCLUSIVE

与所有模式锁冲突(ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE),这种模式保证了当前只有一个事务访问这张表;“ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, VACUUM FULL” 命令会获得这种类型锁，在Lock table 命令中，如果没有申明其它模式，它也是缺省模式。

3：ACID事物隔离级别

事务：数据库中访问并可能更新数据库中数据项的程序执行单元。
Acid：原子性、一致性、隔离性、持久性
二阶段提交：预提交+最终提交
有一个节点提交则事务提交，有一个取消则回滚。

支持的隔离级别是读已提交和读未提交。可重复读和可串行化没从语法上静止，但是和读已提交一样的隔离效果。

脏读：一个事务读取了另一个未提交事务写入的数据
不可重复读：一个事务重新读取之前读取过的数据，结果发现该数据已经修改
幻读：多查几次，结果变了，因为数据变了。
隔离级别：

默认：读已提交。
怎么解决幻读？可串行化？

4：Libra如何保证数据库安全

1：添加白名单（pg_hba.conf）,指定用户名，ip，数据库
2：角色和用户
3：基于角色的权限管理模型
4：对象权限：表，数据库，模式，表空间，函数
5：审计日志

a) 网络隔离
双平面
b) 主机安全
操作系统内核安全加固
更新操作系统最新补丁
操作系统权限控制
操作系统端口管理
操作系统协议与端口防攻击
c) 应用安全
d) 安全认证
基于用户和角色的认证统一体系
单点登录
审计
统一证书管理功能

5：LibrA的逻辑架构，各个部分的作用

在这里插入图片描述
名称描述
MPPDBServer(CM) 负责管理和监控分布式系统中各个功能单元和物理资源的运行情况。CM分为主CM和备CM。
CM服务由CMServer、CMAgent、Monitor组成。
CMServer是整个LibrA集群的大脑，它会根据CMAgent上报上来的各MPPDBServer状态信息来决定是否需要状态变更。CMServer只部署在主备CM上。
CMAgent是MPPDBServer上面部署的实例代理线程，负责接收CMServer下发的命令和上报MPPDBServer的Coordinator、Datanode、GTM的状态给CMServer。每个MPPDBServer均会部署一个CMAgent，也包括主备CM和主备GTM。
Monitor是watchdog定时任务，其唯一的任务是在CMAgent停止的情况下将CMAgent重启。每个MPPDBServer均会部署一个Monitor，也包括主备CM和主备GTM。
MPPDBServer(GTM) 全局事务管理模块GTM（Global Transaction Manager），负责生成和维护全局事务ID、事务快照、时间戳等需要全局唯一的信息。GTM分为主GTM和备GTM。
MPPDBServer 业务模块，由Coordinator及多个Datanode组成，负责执行CM、GTM下发的任务。
Coordinator 负责提供外部应用接口、优化全局执行计划、向Datanode分发执行计划，以及汇总、处理执行结果。
Datanode 负责存储业务数据、执行数据查询任务以及向Coordinator返回执行结果。
Datanode实例分为主Datanode实例、备Datanode实例和从备Datanode实例，它们之间的工作原理如下：
主、备实例间可以正常同步数据时，主实例不会同步数据到从备实例。
主、备实例间无法正常同步数据时，主实例会将数据同步到从备实例。
主、备实例间数据同步恢复正常后，主实例会将异常期间的数据同步到备实例上，并在完成后知会从备实例清空之前同步的这部分数据。备实例同步主实例数据期间，如果主实例发生故障不可用，备实例将升为主实例，并在升为主实例成功后从备实例上同步之前异常期间的数据。
备需要同步主的数据，且主备failover，从备与备failover。
Storage 服务器的本地存储资源，持久化存储数据（支持行存、列存、混合存储）。
WLM 负载管理

6：LibrA是怎样实现数据分布的？

1.列存储和行存储
a.LibrA 可以指定两种表数据存储方式，即行存或者列存，其值为
COLUME，则表的数据将于列存储，其值为 ROW，则表的数据将于
行式存储。若不指定，则其默认值为 ROW。
b.行形式存储适合于 OLTP 业务，此类型的表上交互式事务比较多，
一次交互会涉及表中的多个列，总行存储查询率较高。
c.列存储适合于数据仓库业务，此类型的表上会做大量的汇聚计算，
且涉及的列操作较少

2.数据分布式存储:散列、hash
3.数据分区