典型的なMySQLDBAは、日常業務の一部としてOLTP（オンライントランザクション処理）データベースの操作と管理に精通している場合があります。あなたはそれがどのように機能するか、そして複雑な操作を管理する方法に精通しているかもしれません。 MySQLに付属しているデフォルトのストレージエンジンはOLAP（Online Analytical Processing）には十分ですが、特に人工知能を学びたい人や、予測、データマイニング、データ分析を扱う人にとっては、かなり単純です。
このブログでは、MariaDBColumnStoreについて説明します。コンテンツは、ColumnStoreについてあまり理解していない可能性のあるMySQL DBAの利益と、OLAP（オンライン分析処理）アプリケーションにどのように適用できるかを考慮して調整されます。
OLTPとOLAP
OLTP
関連リソースMariaDBAXを使用したアナリティクス-オープンソースの列型データストア時系列データベースの概要非同期スレーブを使用したGaleraクラスターのハイブリッドOLTP/アナリティクスデータベースワークロードこのタイプのデータを処理するための一般的なMySQLDBAアクティビティは、OLTP（オンライントランザクション処理）を使用することです。 OLTPは、挿入、更新、または削除を行う大規模なデータベーストランザクションを特徴としています。 OLTPタイプのデータベースは、複数の環境でアクセスされている間、高速クエリ処理とデータ整合性の維持に特化しています。その有効性は、1秒あたりのトランザクション数（tps）によって測定されます。親子関係テーブル（正規化フォームの実装後）がテーブル内の冗長データを減らすことはかなり一般的です。
テーブル内のレコードは通常、行指向の方法で順番に処理および保存され、データの取得または書き込みを最適化するために一意のキーで高度にインデックス付けされます。これはMySQLでも一般的であり、特に大きな挿入、高い同時書き込み、または一括挿入を処理する場合によく見られます。 MariaDBがサポートするストレージエンジンのほとんどは、OLTPアプリケーションに適用できます。InnoDB（10.2以降のデフォルトのストレージエンジン）、XtraDB、TokuDB、MyRocks、またはMyISAM/Ariaです。
CMS、FinTech、Web Appsなどのアプリケーションは、多くの場合、大量の書き込みと読み取りを処理し、多くの場合、高いスループットを必要とします。これらのアプリケーションを機能させるには、多くの場合、高可用性、冗長性、復元力、およびリカバリに関する深い専門知識が必要です。
OLAP
OLAPはOLTPと同じ課題を処理しますが、異なるアプローチを使用します（特にデータ取得を処理する場合）。OLAPはより大きなデータセットを処理し、データウェアハウジングで一般的であり、ビジネスインテリジェンスタイプのアプリケーションでよく使用されます。これは通常、業績管理、計画、予算編成、予測、財務報告、分析、シミュレーションモデル、知識発見、およびデータウェアハウス報告に使用されます。
通常、OLAPに保存されるデータは、OLTPに保存されるデータほど重要ではありません。これは、ほとんどのデータがOLTPから取得してシミュレートでき、OLAPデータベースにフィードできるためです。このデータは通常、一括読み込みに使用され、最終的に視覚的なグラフにレンダリングされるビジネス分析に必要になることがよくあります。 OLAPは、ビジネスデータの多次元分析も実行し、複雑な計算、傾向分析、または高度なデータモデリングに使用できる結果を提供します。
OLAPは通常、列形式を使用してデータを永続的に格納します。ただし、MariaDB ColumnStoreでは、レコードはその列に基づいて分割され、ファイルに個別に保存されます。このように、SELECTステートメントクエリで参照されている関連する列のみをスキャンするため、データの取得は非常に効率的です。
このように考えると、OLTP処理は、ビジネスアプリケーションを実行する日常の重要なデータトランザクションを処理し、OLAPは、ビジネスアプリケーションを持つための構成要素である製品の管理、予測、分析、およびより良いマーケティングを支援します。
MariaDB ColumnStoreとは何ですか？
MariaDB ColumnStoreは、MariaDBサーバー上で実行されるプラグ可能な列型ストレージエンジンです。これは、MariaDBサーバーポートフォリオ全体で使用されているのと同じANSI SQLインターフェイスを維持しながら、並列分散データアーキテクチャを利用します。このストレージエンジンは、元々InfiniDB（githubでまだ利用可能な現在は機能していないコード）から移植されたため、しばらく前から存在しています。ビッグデータのスケーリング（ペタバイトのデータを処理するため）、線形スケーラビリティ、および実際の-分析クエリへの時間応答。列型ストレージのI/Oの利点を活用します。圧縮、ジャストインタイムプロジェクション、水平および垂直分割により、大規模なデータセットを分析する際に驚異的なパフォーマンスを実現します。
最後に、MariaDB ColumnStoreは、このテクノロジーで使用されるメインストレージエンジンとしてのMariaDBAX製品のバックボーンです。
MariaDB ColumnStoreはInnoDBとどのように異なりますか？
InnoDBは、アプリケーションが可能な限り最速の方法で応答する必要があるOLTP処理に適用できます。アプリケーションがその性質を処理している場合に役立ちます。一方、MariaDB ColumnStoreは、複雑な結合、さまざまなレベルのディメンション階層での集計、広範囲にわたる年間の財務合計の予測、または同等性と範囲の選択を使用するビッグデータトランザクションまたは大規模なデータセットの管理に適しています。 。 ColumnStoreを使用するこれらのアプローチでは、十分に高速に実行できるため、これらのフィールドにインデックスを付ける必要はありません。 InnoDBは、このタイプのパフォーマンスを実際に処理することはできませんが、InnoDBで実行できるようにそれを試すことを妨げることはありませんが、コストがかかります。これには、インデックスを追加する必要があります。これにより、ディスクストレージに大量のデータが追加されます。つまり、クエリの完了にはさらに時間がかかる可能性があり、タイムループに閉じ込められていると、クエリがまったく終了しない可能性があります。
MariaDBColumnStoreアーキテクチャ
以下のMariaDBColumStoreアーキテクチャを見てみましょう：
画像提供：MariaDBColumnStoreプレゼンテーション InnoDBアーキテクチャとは対照的に、ColumnStoreには2つのモジュールが含まれており、分散アーキテクチャ環境で効率的に動作することを目的としています。 InnoDBはサーバー上で拡張することを目的としていますが、クラスターのセットアップに応じて、相互接続された複数のノードにまたがっています。したがって、ColumnStoreには、MariaDBサーバーに要求されたプロセスを処理する複数レベルのコンポーネントがあります。以下のこのコンポーネントを掘り下げてみましょう：
- ユーザーモジュール（UM）：UMは、SQL要求を、1つ以上のPMサーバーによって実行される最適化された一連のプリミティブジョブステップに解析する役割を果たします。したがって、UMは、PMサーバーによるクエリの最適化とクエリ実行のオーケストレーションを担当します。複数のUMインスタンスをマルチサーバー展開で展開できますが、単一のUMが個々のクエリを担当します。 MariaDB MaxScaleなどのデータベースロードバランサーをデプロイして、外部リクエストと個々のUMサーバーのバランスを適切にとることができます。
- パフォーマンスモジュール（PM）：PMは、UMから受信したきめ細かいジョブステップをマルチスレッド方式で実行します。 ColumnStoreを使用すると、多くのパフォーマンスモジュール間で作業を分散できます。 UMは、MariaDBmysqldプロセスとExeMgrプロセスで構成されています。
- エクステントマップ：ColumnStoreは、エクステントマップと呼ばれる共有分散オブジェクトの各列に関するメタデータを維持します。UMサーバーはエクステントマップを参照して、正しいプリミティブジョブステップの生成を支援します。 PMサーバーは、エクステントマップを参照して、読み取る正しいディスクブロックを識別します。各列は1つ以上のファイルで構成されており、各ファイルには複数のエクステントを含めることができます。可能な限り、システムは連続した物理ストレージを割り当てて、読み取りパフォーマンスを向上させようとします。
- ストレージ：ColumnStoreは、ローカルストレージまたは共有ストレージ（SANやEBSなど）のいずれかを使用してデータを保存できます。共有ストレージを使用すると、PMサーバーに障害が発生した場合に、データ処理を別のノードに自動的にフェイルオーバーできます。
以下は、MariaDBColumnStoreがクエリを処理する方法です
- クライアントは、ユーザーモジュールで実行されているMariaDBサーバーにクエリを発行します。サーバーは、要求を満たすために必要なすべてのテーブルに対してテーブル操作を実行し、最初のクエリ実行プランを取得します。
- MariaDBストレージエンジンインターフェイスを使用して、ColumnStoreはサーバーテーブルオブジェクトをColumnStoreオブジェクトに変換します。これらのオブジェクトは、ユーザーモジュールプロセスに送信されます。
- ユーザーモジュールはMariaDB実行プランを変換し、指定されたオブジェクトをColumnStore実行プランに最適化します。次に、クエリを実行するために必要な手順と、それらを実行する必要がある順序を決定します。
- 次に、ユーザーモジュールはエクステントマップを参照して、必要なデータについて参照するパフォーマンスモジュールを決定し、エクステントエリミネーションを実行して、クエリが必要とする範囲外のデータのみを含むパフォーマンスモジュールをリストから削除します。
- 次に、ユーザーモジュールは1つ以上のパフォーマンスモジュールにコマンドを送信して、ブロックI/O操作を実行します。
- 1つまたは複数のパフォーマンスモジュールは、述語フィルタリング、結合処理、ローカルまたは外部ストレージからのデータの初期集約を実行してから、データをユーザーモジュールに送り返します。
- ユーザーモジュールは、最終的な結果セットの集計を実行し、クエリの結果セットを作成します。
- ユーザーモジュール/ExeMgrは、ウィンドウ関数の計算と、結果セットに対する必要な並べ替えを実装します。次に、結果セットをサーバーに返します。
- MariaDBサーバーは、結果セットに対して任意の選択リスト機能、ORDERBYおよびLIMIT操作を実行します。
- MariaDBサーバーは結果セットをクライアントに返します。
クエリ実行パラダイム
ColumnStoreがクエリを実行する方法と、クエリが影響を与えるタイミングについてもう少し詳しく見ていきましょう。
ColumnStoreは、InnoDBなどの標準のMySQL / MariaDBストレージエンジンとは異なります。ColumnStoreは、必要な列をスキャンし、システムで維持されるパーティション分割を利用し、複数のスレッドとサーバーを利用してクエリの応答時間をスケーリングすることでパフォーマンスを向上させるためです。データの取得に必要な列のみを含めると、パフォーマンスが向上します。これは、選択クエリの貪欲なアスタリスク（*）が、 SELECT
InnoDBや他のストレージエンジンと同様に、データ型も使用したもののパフォーマンスに重要です。 0から100までの値しか持てない列がある場合、これはtinyintとして宣言します。これは、intの場合は4バイトではなく1バイトで表されるためです。これにより、I/Oコストが4分の1に削減されます。文字列タイプの場合、重要なしきい値はchar（9）およびvarchar（8）以上です。各列ストレージファイルは、値ごとに固定数のバイトを使用します。これにより、他の列の位置をすばやく検索して行を形成できます。現在、列データストレージの上限は8バイトです。したがって、これより長い文字列の場合、システムは値が格納される追加の「ディクショナリ」エクステントを維持します。次に、列エクステントファイルはポインタをディクショナリに格納します。したがって、たとえば、char（8）列よりもvarchar（8）列を読み取って処理する方がコストがかかります。したがって、可能であれば、特に辞書検索を回避する場合に、より短い文字列を利用できると、パフォーマンスが向上します。 1.1以降のすべてのTEXT/BLOBデータ型はディクショナリを利用し、必要に応じて複数ブロックの8KBルックアップを実行してそのデータを取得します。データが長くなるほど、取得されるブロックが多くなり、パフォーマンスに大きな影響を与える可能性があります。
行ベースのシステムでは、冗長な列を追加すると全体的なクエリコストが増加しますが、列システムでは、列が参照されている場合にのみコストが発生します。したがって、さまざまなアクセスパスをサポートするために、追加の列を作成する必要があります。たとえば、フィールドの先頭部分を1つの列に格納して検索を高速化しますが、さらに長い形式の値を別の列として格納します。短いコードまたは先頭部分の列でのスキャンは高速になります。
クエリ結合は最適化されており、大規模な結合に対応しており、インデックスの必要性やネストされたループ処理のオーバーヘッドを回避できます。 ColumnStoreは、最適な結合順序を決定するためにテーブル統計を維持します。結合がUMメモリに対して大きすぎる場合、ディスクベースの結合を使用してクエリを完了するなど、同様のアプローチがInnoDBと共有されます。
集計の場合、ColumnStoreは可能な限り集計評価を配布します。これは、UMとPMで共有して、特に集計列のクエリまたは非常に多数の値を処理することを意味します。 Select count（*）は、テーブル内のストレージの最小バイト数を選択するように内部的に最適化されています。これは、4バイトを使用するINT列よりもCHAR（1）列（1バイトを使用）を選択することを意味します。実装は、カウント内のnullを除外する明示的なselect（COL-N）とは対照的に、select count（*）が合計カウントにnullを含めるという点でANSIセマンティクスを引き続き尊重します。
順序と制限は現在、一時的な結果セットテーブルのmariadbサーバープロセスによって最後に実装されています。これは、ColumnStoreがクエリを処理する方法に関するステップ＃9で説明されています。したがって、技術的には、結果はデータを並べ替えるためにMariaDBサーバーに渡されます。
サブクエリを使用する複雑なクエリの場合、ウィンドウ関数がUMによって処理されるのと同じように、順番に実行されてUMによって管理されるのと基本的に同じアプローチですが、専用のより高速な並べ替えプロセスを使用するため、基本的に高速です。
データのパーティション化は、列データの最小値/最大値を維持し、パーティション化の論理範囲を提供し、インデックス作成の必要性を排除するエクステントマップを使用するColumnStoreによって提供されます。 Extent Mapsは、手動のテーブルパーティショニング、マテリアライズドビュー、サマリーテーブル、および行ベースのデータベースがクエリのパフォーマンスのために実装する必要のあるその他の構造とオブジェクトも提供します。列の値が順序または半順序である場合、これにより非常に効果的なデータ分割が可能になるため、特定の利点があります。最小値と最大値を使用すると、フィルターと除外の後のエクステントマップ全体が削除されます。エクステントエリミネーションについては、マニュアルのこのページを参照してください。これは通常、時系列データまたは時間の経過とともに増加する同様の値に対して特に効果的です。
MariaDBColumnStoreのインストール
MariaDB ColumnStoreのインストールは、簡単で簡単です。 MariaDBには、参照できる一連のメモがあります。このブログのインストール対象環境はCentOS7です。このリンクhttps://downloads.mariadb.com/ColumnStore/1.2.4/にアクセスして、OS環境に基づいたパッケージを確認できます。スピードアップに役立つ以下の詳細な手順をご覧ください：
### Note: The installation details is ideal for root user installation
cd /root/
wget https://downloads.mariadb.com/ColumnStore/1.2.4/centos/x86_64/7/mariadb-columnstore-1.2.4-1-centos7.x86_64.rpm.tar.gz
tar xzf mariadb-columnstore-1.0.7-1-centos7.x86_64.rpm.tar.gz
sudo yum -y install boost expect perl perl-DBI openssl zlib snappy libaio perl-DBD-MySQL net-tools wget jemalloc
sudo rpm -ivh mariadb-columnstore*.rpm
完了したら、 postConfigureを実行する必要があります 最後にMariaDBColumnStoreをインストールしてセットアップするコマンド。このサンプルインストールでは、vagrantマシンで実行しているセットアップが2つあります。
csnode1：192.168.2.10
csnode2：192.168.2.20
これらのノードは両方ともそれぞれの/etc/ hostsで定義されており、両方のノードが対象となり、ユーザーモジュールとパフォーマンスモジュールが両方のホストで組み合わされるように設定されています。インストールは最初は少し簡単です。したがって、基礎を築くことができるように構成する方法を共有します。インストールプロセスの例については、以下の詳細をご覧ください。
[[email protected] ~]# /usr/local/mariadb/columnstore/bin/postConfigure -d
This is the MariaDB ColumnStore System Configuration and Installation tool.
It will Configure the MariaDB ColumnStore System and will perform a Package
Installation of all of the Servers within the System that is being configured.
IMPORTANT: This tool requires to run on the Performance Module #1
Prompting instructions:
Press 'enter' to accept a value in (), if available or
Enter one of the options within [], if available, or
Enter a new value
===== Setup System Server Type Configuration =====
There are 2 options when configuring the System Server Type: single and multi
'single' - Single-Server install is used when there will only be 1 server configured
on the system. It can also be used for production systems, if the plan is
to stay single-server.
'multi' - Multi-Server install is used when you want to configure multiple servers now or
in the future. With Multi-Server install, you can still configure just 1 server
now and add on addition servers/modules in the future.
Select the type of System Server install [1=single, 2=multi] (2) >
===== Setup System Module Type Configuration =====
There are 2 options when configuring the System Module Type: separate and combined
'separate' - User and Performance functionality on separate servers.
'combined' - User and Performance functionality on the same server
Select the type of System Module Install [1=separate, 2=combined] (1) > 2
Combined Server Installation will be performed.
The Server will be configured as a Performance Module.
All MariaDB ColumnStore Processes will run on the Performance Modules.
NOTE: The MariaDB ColumnStore Schema Sync feature will replicate all of the
schemas and InnoDB tables across the User Module nodes. This feature can be enabled
or disabled, for example, if you wish to configure your own replication post installation.
MariaDB ColumnStore Schema Sync feature, do you want to enable? [y,n] (y) >
NOTE: MariaDB ColumnStore Replication Feature is enabled
Enter System Name (columnstore-1) >
===== Setup Storage Configuration =====
----- Setup Performance Module DBRoot Data Storage Mount Configuration -----
There are 2 options when configuring the storage: internal or external
'internal' - This is specified when a local disk is used for the DBRoot storage.
High Availability Server Failover is not Supported in this mode
'external' - This is specified when the DBRoot directories are mounted.
High Availability Server Failover is Supported in this mode.
Select the type of Data Storage [1=internal, 2=external] (1) >
===== Setup Memory Configuration =====
NOTE: Setting 'NumBlocksPct' to 50%
Setting 'TotalUmMemory' to 25%
===== Setup the Module Configuration =====
----- Performance Module Configuration -----
Enter number of Performance Modules [1,1024] (1) > 2
*** Parent OAM Module Performance Module #1 Configuration ***
Enter Nic Interface #1 Host Name (csnode1) >
Enter Nic Interface #1 IP Address or hostname of csnode1 (unassigned) > 192.168.2.10
Enter Nic Interface #2 Host Name (unassigned) >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm1' (1) >
*** Performance Module #2 Configuration ***
Enter Nic Interface #1 Host Name (unassigned) > csnode2
Enter Nic Interface #1 IP Address or hostname of csnode2 (192.168.2.20) >
Enter Nic Interface #2 Host Name (unassigned) >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm2' () >
Enter the list (Nx,Ny,Nz) or range (Nx-Nz) of DBRoot IDs assigned to module 'pm2' () > 2
===== Running the MariaDB ColumnStore MariaDB Server setup scripts =====
post-mysqld-install Successfully Completed
post-mysql-install Successfully Completed
Next step is to enter the password to access the other Servers.
This is either user password or you can default to using a ssh key
If using a user password, the password needs to be the same on all Servers.
Enter password, hit 'enter' to default to using a ssh key, or 'exit' >
===== System Installation =====
System Configuration is complete.
Performing System Installation.
Performing a MariaDB ColumnStore System install using RPM packages
located in the /root directory.
----- Performing Install on 'pm2 / csnode2' -----
Install log file is located here: /tmp/columnstore_tmp_files/pm2_rpm_install.log
MariaDB ColumnStore Package being installed, please wait ... DONE
===== Checking MariaDB ColumnStore System Logging Functionality =====
The MariaDB ColumnStore system logging is setup and working on local server
===== MariaDB ColumnStore System Startup =====
System Configuration is complete.
Performing System Installation.
----- Starting MariaDB ColumnStore on local server -----
MariaDB ColumnStore successfully started
MariaDB ColumnStore Database Platform Starting, please wait .......... DONE
System Catalog Successfully Created
Run MariaDB ColumnStore Replication Setup.. DONE
MariaDB ColumnStore Install Successfully Completed, System is Active
Enter the following command to define MariaDB ColumnStore Alias Commands
. /etc/profile.d/columnstoreAlias.sh
Enter 'mcsmysql' to access the MariaDB ColumnStore SQL console
Enter 'mcsadmin' to access the MariaDB ColumnStore Admin console
NOTE: The MariaDB ColumnStore Alias Commands are in /etc/profile.d/columnstoreAlias.sh
[[email protected] ~]# . /etc/profile.d/columnstoreAlias.sh
[[email protected] ~]#インストールとセットアップが完了すると、MariaDBはこのためのマスター/スレーブセットアップを作成するため、csnode1からロードしたものはすべて、csnode2に複製されます。
ビッグデータのダンプ
インストール後、試すサンプルデータがない場合があります。 IMDBは、サイトhttps://www.imdb.com/interfaces/でダウンロードできるサンプルデータを共有しています。このブログのために、私はあなたのためにすべてを行うスクリプトを作成しました。 https://github.com/paulnamuag/columnstore-imdb-data-loadで確認してください。実行可能にしてから、スクリプトを実行するだけです。ファイルをダウンロードし、スキーマを作成してから、データベースにデータをロードすることで、すべてを実行します。とても簡単です。
サンプルクエリの実行
それでは、いくつかのサンプルクエリを実行してみましょう。
MariaDB [imdb]> select count(1), 'title_akas' table_name from title_akas union all select count(1), 'name_basics' as table_name from name_basics union all select count(1), 'title_crew' as table_name from title_crew union all select count(1), 'title_episode' as table_name from title_episode union all select count(1), 'title_ratings' as table_name from title_ratings order by 1 asc;
+----------+---------------+
| count(1) | table_name |
+----------+---------------+
| 945057 | title_ratings |
| 3797618 | title_akas |
| 4136880 | title_episode |
| 5953930 | title_crew |
| 9403540 | name_basics |
+----------+---------------+
5 rows in set (0.162 sec)MariaDB [imdb]> select count(*), 'title_akas' table_name from title_akas union all select count(*), 'name_basics' as table_name from name_basics union all select count(*), 'title_crew' as table_name from title_crew union all select count(*), 'title_episode' as table_name from title_episode union all select count(*), 'title_ratings' as table_name from title_ratings order by 2;
+----------+---------------+
| count(*) | table_name |
+----------+---------------+
| 9405192 | name_basics |
| 3797618 | title_akas |
| 5953930 | title_crew |
| 4136880 | title_episode |
| 945057 | title_ratings |
+----------+---------------+
5 rows in set (0.371 sec)基本的に、それはより速くそして速いです。 InnoDBなどの他のストレージエンジンで実行するのと同じように処理できないクエリがあります。たとえば、私は遊んで、いくつかの愚かなクエリを実行して、それがどのように反応し、結果が次のようになるかを確認しようとしました：
MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select a.titleId from title_akas) limit 25;
ERROR 1815 (HY000): Internal error: IDB-1000: 'a' and 'title_akas' are not joined.したがって、MCOL-1620とMCOL-131を見つけました。これは、infinidb_vtable_mode変数の設定を示しています。以下を参照してください：
MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select c.titleId from title_akas c) limit 2;
ERROR 1815 (HY000): Internal error: IDB-1000: 'a' and 'b, sub-query' are not joined.ただし、 infinidb_vtable_mode =0を設定します 、 これは、クエリを一般的で互換性の高い行ごとの処理モードとして扱うことを意味します。一部のWHERE句コンポーネントはColumnStoreで処理できますが、結合はネストされたループの結合メカニズムを使用してmysqldによって完全に処理されます。以下を参照してください：
MariaDB [imdb]> set infinidb_vtable_mode=0;
Query OK, 0 rows affected (0.000 sec)MariaDB [imdb]> select a.titleId, a.title, a.region, b.id, b.primaryName, b.profession from title_akas a join name_basics b where b.knownForTitles in (select c.titleId from title_akas c) limit 2;
+-----------+---------------+--------+-----------+-------------+---------------+
| titleId | title | region | id | primaryName | profession |
+-----------+---------------+--------+-----------+-------------+---------------+
| tt0082880 | Vaticano Show | ES | nm0594213 | Velda Mitzi | miscellaneous |
| tt0082880 | Il pap'occhio | IT | nm0594213 | Velda Mitzi | miscellaneous |
+-----------+---------------+--------+-----------+-------------+---------------+
2 rows in set (13.789 sec)mysqldによって完全に処理されたと説明されているため、時間がかかりました。それでも、優れたクエリを最適化して作成することは依然として最善のアプローチであり、すべてをColumnStoreに委任するわけではありません。
さらに、 SELECT calSetTrace（1）; などのコマンドを実行して、クエリを分析するのに役立ちます。 またはSELECT calGetStats（）; 。これらのコマンドセットを使用して、たとえば、低クエリと不良クエリを最適化したり、クエリプランを表示したりできます。クエリの分析の詳細については、こちらをご覧ください。
ColumnStoreの管理
MariaDB ColumnStoreを完全にセットアップすると、mcsadminという名前のツールが付属します。このツールを使用して、いくつかの管理タスクを実行できます。このツールを使用して、別のモジュールを追加したり、PMからPMへのDBrootsへの割り当てや移動などを行うこともできます。このツールに関するマニュアルを確認してください。
基本的には、システム情報の確認など、次のことができます。
mcsadmin> getSystemi
getsysteminfo Mon Jun 24 12:55:25 2019
System columnstore-1
System and Module statuses
Component Status Last Status Change
------------ -------------------------- ------------------------
System ACTIVE Fri Jun 21 21:40:56 2019
Module pm1 ACTIVE Fri Jun 21 21:40:54 2019
Module pm2 ACTIVE Fri Jun 21 21:40:50 2019
Active Parent OAM Performance Module is 'pm1'
Primary Front-End MariaDB ColumnStore Module is 'pm1'
MariaDB ColumnStore Replication Feature is enabled
MariaDB ColumnStore set for Distributed Install
MariaDB ColumnStore Process statuses
Process Module Status Last Status Change Process ID
------------------ ------ --------------- ------------------------ ----------
ProcessMonitor pm1 ACTIVE Thu Jun 20 17:36:27 2019 6026
ProcessManager pm1 ACTIVE Thu Jun 20 17:36:33 2019 6165
DBRMControllerNode pm1 ACTIVE Fri Jun 21 21:40:31 2019 19890
ServerMonitor pm1 ACTIVE Fri Jun 21 21:40:33 2019 19955
DBRMWorkerNode pm1 ACTIVE Fri Jun 21 21:40:33 2019 20003
PrimProc pm1 ACTIVE Fri Jun 21 21:40:37 2019 20137
ExeMgr pm1 ACTIVE Fri Jun 21 21:40:42 2019 20541
WriteEngineServer pm1 ACTIVE Fri Jun 21 21:40:47 2019 20660
DDLProc pm1 ACTIVE Fri Jun 21 21:40:51 2019 20810
DMLProc pm1 ACTIVE Fri Jun 21 21:40:55 2019 20956
mysqld pm1 ACTIVE Fri Jun 21 21:40:41 2019 19778
ProcessMonitor pm2 ACTIVE Thu Jun 20 17:37:16 2019 9728
ProcessManager pm2 HOT_STANDBY Fri Jun 21 21:40:26 2019 25211
DBRMControllerNode pm2 COLD_STANDBY Fri Jun 21 21:40:32 2019
ServerMonitor pm2 ACTIVE Fri Jun 21 21:40:35 2019 25560
DBRMWorkerNode pm2 ACTIVE Fri Jun 21 21:40:36 2019 25593
PrimProc pm2 ACTIVE Fri Jun 21 21:40:40 2019 25642
ExeMgr pm2 ACTIVE Fri Jun 21 21:40:44 2019 25715
WriteEngineServer pm2 ACTIVE Fri Jun 21 21:40:48 2019 25768
DDLProc pm2 COLD_STANDBY Fri Jun 21 21:40:50 2019
DMLProc pm2 COLD_STANDBY Fri Jun 21 21:40:50 2019
mysqld pm2 ACTIVE Fri Jun 21 21:40:32 2019 25467
Active Alarm Counts: Critical = 1, Major = 0, Minor = 0, Warning = 0, Info = 0結論
MariaDB ColumnStoreは、OLAPおよびビッグデータ処理用の非常に強力なストレージエンジンです。これは完全にオープンソースであり、市場で入手可能な独自の高価なOLAPデータベースを使用するよりも使用するのに非常に有利です。それでも、ClickHouse、Apache HBase、Citus Dataのcstore_fdwなど、他にも試すことができます。ただし、どちらもMySQL / MariaDBを使用していないため、MySQL / MariaDBのバリアントに固執することを選択した場合、実行可能なオプションではない可能性があります。