ColumnStore性能模块
性能模块执行I/O操作以支持读取和写入处理。它不会看到查询本身，而只会看到由用户模块给出的一组指令。
有三个关键任务对于扩展数据库行为至关重要：
- 分布式扫描
- 分布式哈希连接
- 分布式聚合
这些的组合使得在查询密集型环境下实现了大规模并行处理（MPP）。
进程
性能模块由许多进程组成
管理和监控进程
进程管理器（ProcMgr）是负责启动、监控和重新启动性能模块上所有MariaDB ColumnStore进程的进程。
为了实现这一点，ProcMgr在每个性能模块上使用进程监视器（ProcMon）来跟踪MariaDB ColumnStore进程。
处理查询
主要进程（PrimProc）处理查询执行。用户模块将应用程序中的查询处理为指令，然后将这些指令发送到性能模块。PrimProc将这些指令作为面向块的I/O操作执行，以执行谓词过滤、连接处理和数据的初始聚合，之后PrimProc将数据发送回用户模块。
执行加载和写入
性能模块处理对底层持久存储的加载和写入。它使用两个进程来处理：WriteEngineServer和cpimport。
WriteEngineServer协调每个性能模块上的DML、DDL和导入。DDL更改在系统目录中持久化，该目录跟踪所有ColumnStore元数据。
用户和性能模块都使用cpimport。在性能模块上，它在加载大量数据时更新数据库文件。这使得ColumnStore能够支持完全并行加载。
共享无数据缓存
性能模块使用共享无数据缓存。当它首次访问数据时，它按照用户模块的指示对数据进行操作，并将其缓存在基于LRU的缓冲区中以供后续访问。
当性能模块在专用服务器上运行时，您可以将大部分可用空间专用于此数据缓存。由于性能模块缓存是共享无设计：
- 参与的性能模块节点之间没有数据块来回传递（如其他多实例/共享磁盘数据库系统中有时发生的情况）。
- 添加到系统中的更多性能模块节点，数据库的整体缓存大小就越大。
故障转移
当使用多个性能模块节点部署MariaDB ColumnStore时，心跳机制确保所有节点在线，并在特定节点失败时进行透明故障转移。如果节点异常终止，则正在处理的查询会返回错误。由于性能模块引起错误的用户可以重新提交查询。然后ColumnStore使用剩余的性能模块进行工作。
在故障转移的情况下，底层存储数据是外部挂载的（例如EC2 EBS或SAN），数据块到性能模块的映射会在工作性能模块之间重新组织，并且用户模块上的Extent Maps会重新评估，以便将查询发送到适当的节点。也就是说，附加到失败性能模块的DB Roots会附加到工作性能模块上。这个过程对用户来说是透明的，不需要手动干预。
当失败的性能模块重新上线时，ColumnStore会自动将其重新加入配置，并开始使用它进行工作。
