简介

openGauss是关系型数据库，架构是单进程多线程，可用是单机和一主多备。

openGauss是华为在芯片被禁后的一次尝试，他的很重要的特征就是多核架构，而多核又是arm芯片的特征。

为了适配这种特征，在内核关键数据结构上采用了Numa-Aware的数据结构。

同时，在运维方面，openGauss提供了OM（Operation Manager，运维管理）模块，可以通过AI进行智能参数调优和索引推荐。

我的关注

1. 事务处理机制：

   ①并发控制：64位事务ID，缓解事务ID用完的情况；Numa-Aware引擎优化改造解决“五把大锁”

   这里的“五把大锁”含义并不清晰，在此总结一下数据库中的锁。

   1. 悲观锁和乐观锁

      悲观锁可以理解是二阶段加锁，其直接就对所有可能产生冲突的操作放弃或等待。

      乐观锁：可串行化的快照隔离技术，在对同一对象的不同对象进行操作时，可能会产生冲突（如医生同时申请休假，各自维护的快照显示都有医生正在值班）

   2. 读锁（共享锁）和写锁（写锁）

      主要在读-提交隔离中，读的时候必须加上读锁，加上读锁之后，事务不能修改对象；当事务读-修改-写回或修改对象时，事务必须获得写锁（直接获得或由读锁升级），获得写锁之后，其他任何锁都不能加上，阻塞其他所有读写。

   3. 表锁和行锁（谓词锁）

      谓词锁是作用于行上的，甚至可以保护数据库中不存在的，但可能马上被插入的对象，但是其性能很差，在实际引擎中，一般采用近似的索引区间锁，它将锁进行了一定程度的扩大化，将查询 条件的近似值都附加到某个索引上了。

2. 多引擎：

   行存、列存、内存引擎

   1. 列式存储：

   想法：不要将一行中所有值存储在一起，而是将每列中所有值存储在一起。如果每列存储咋我一个单独的文件中，查询只需要读取和解析在该查询中使用的那些列。注意：面向列的存储布局依赖一组列文件，每个文件以相同顺序保存着数据行。

   优势：对于列式存储，由于每一列中数据类型相同，其压缩率可以很高（位图）

   劣势：写入变得非常困难

   2. 内存引擎：

   想法：目前企业中内存越来越大，可以充分利用内存的快速随机读写性质，可以实现更高的吞吐量和更低的延迟。

3. openGauss server是一个instance，而真正存在文件系统上面的的文件才是DataBase

   

4. 多线程

   连接池 ： 是在客户端设置的，用于客户端与服务器的连接，主要是为了连接复用，避免频繁的创建和销毁

   线程池 ： 是在数据库服务器上配置，用于控制数据库服务器活动线程数目，避免雪崩。

   雪崩：主业务不依赖的某些辅助类服务器变得不可靠进而导致主业务所调用的核心服务受牵连直至各个上游依赖者连同崩溃的现象。

   主线程监听连接请求，分配会话，把会发分配给一个线程组；每个线程池组有一个监听线程负责监听epoll列表的所有客户端，避免“惊群”效应；每个线程组又和一个NUMA节点绑定。（可以理解为一个核心）

   epoll是一种IO复用的技术（在一个操作里同时监听多个输入输出源，在其中一个或多个输入输出源可用的时候返回，然后对其进行读写操作），目的是为了降低因为IO带来的CPU空转的问题。

   epoll采用了时间通知机制，当文件描述符的内核缓冲区非空的时候，发出可读信号进行通知，当写缓冲区不满时，发出可写信号通知。

   惊群效应：当多个进程共享一个端口，并且都是用epoll进行多路复用监听，epoll就会把这些进程挂到一个等待队列下，当事件产生时，所有进程都会被唤醒，去检查事件就绪列表，但是最后只有一个进程能够真正accept。