ColumnStoreユーザーモジュール

You are viewing an old version of this article. View the current version here.

ユーザーモジュールはエンドユーザーからのクエリ操作を管理します。各クエリの状態を管理し、クエリ処理を行うためにパフォーマンスモジュールへ処理を委譲します。全てのパフォーマンスモジュールからの処理結果をマージし、最終的にはエンドユーザーへ結果を返します。

ユーザーモジュールはいくつかのプロセスで構成されます。

  • MariaDB Serverプロセス:mysqld
    • mysqldはMariaDB ColumnStore用に特別に改修されたMariaDB Serverのバイナリです。
    • 通常のMariaDB Serverのサーバーバイナリと同様の処理(接続、SQLのパース、SQLプランの生成、最終的か結果セットの組み立て)を行います。
    • さらに、MariaDB Serverのクエリ実行計画を、MariaDB ColumnStore形式に変換します。MariaDB ColumnStore実行計画は、基本的には解析木ですが、実行におけるヒントがオプティマイザーより付加され、ユーザーモジュールが解析木をジョブリストに変換するのを助けます。
  • 実行マネージャー:ExeMgr
    • ExeMgr listens on a TCP/IP port for query parse trees from mysqld. ExeMgr is responsible for converting the query parse tree into a job list, which is a construct in MariaDB ColumnStore that represents the sequence of instructions necessary to answer the query. ExeMgr walks the query parse tree and iteratively generates job steps, optimizing and re-optimizing the job list as it goes. The major categories of job steps are application of a column filter, processing a table join, and projection of returned columns. Each operation in a query plan is executed in parallel by the job list itself and has the capability of running entirely on the User Module, entirely on the Performance Module or in some combination. Each node uses the Extent Map to determine which Performance Modules to send work orders to (see ColumnStore Storage Architecture for details on the Extent).
  • DML, DDL and import distribution managers (DMLProc, DDLProc and cpimport).
    • DMLProc and DDLProc distribute DML and DDL to the appropriate Performance Module. Cpimport, when run on the User Module, distributes source files to the Performance Modules.

The User Module performs these core functions for MariaDB ColumnStore:

  • Transforms MariaDB plan into a ColumnStore Job List.
  • Performs InfiniDB OID (object ID) lookups from the MariaDB ColumnStore system catalog.
  • Inspects the Extent Map (described in ColumnStore Storage Architecture) to reduce I/O, which is accomplished via the elimination of unnecessary extents.
  • Issues instructions (sometimes referred to as ‘primitive operations’) to the Performance Modules.
  • Executes hash joins as needed (depending on size of smaller tables in the join). Helps manage distributed hash joins by sending any hash maps needing processing to Performance Modules.
  • Executes cross-table-scope functions and expressions that happen after a hash join.
  • Receives data from the Performance Modules and re-transmits back to them if needed.
  • Executes follow-up steps for all aggregation and distinct processing.
  • Returns data back to the MariaDB interface. The primary job of the User Module is to handle concurrency scaling. It never directly touches database files and does not require visibility to them. It uses a machine’s RAM in a transitory manner to assemble partial query results into a complete answer that is ultimately returned to a user.

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.