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会自动将其重新加入配置,并开始使用它进行工作。

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.