1つのデータベースですべてに対応するアプローチの時代は過ぎ去りました。
速度、パフォーマンス、敏捷性に対する要件が高まるにつれ、1つの特定の問題を解決することを目的とした多数のデータストアが登場しました。リレーショナルデータベース、ドキュメントストア、時系列データベース、列データベース、全文検索エンジンがあります。
複数のデータストアが同じ環境で連携するのはよくあることです。
では、MariaDB AXはどのように画像に適合しますか？ MariaDB TXとどのように比較し、どのような問題を解決しますか？
このブログ投稿では、MariaDB AXを見て、なぜそれを使用したいかを確認します。
MariaDB AXとは何ですか？
まず最初に、MariaDB AXとは何ですか？
これは列ストアであり、データを... column！で格納します。 MariaDB10.3データベースに個別のエンジンとして実装されています。
ご存知かもしれませんが、MySQLとMariaDBは、プラグ可能なストレージエンジンを使用するように設計されています。 InnoDB、Aria、MyRocks、Spider、その他のエンジンを問わず、すべてのストレージエンジンはプラグインです。
同様に、MariaDB AXはColumnStoreエンジンを使用します：
MariaDB [(none)]> SHOW ENGINES\G
*************************** 1. row ***************************
Engine: Columnstore
Support: YES
Comment: Columnstore storage engine
Transactions: YES
XA: NO
Savepoints: NOこれにより、興味深い組み合わせが得られます。 SQLの解析はMariaDBによって行われるため、MariaDBで慣れているものと非常によく似たクエリ構文を使用することが期待できます。これにより、同じアプリケーションでMariaDBAXとMariaDBTXの両方へのアクセスを簡単に組み合わせることができます。 2つのデータストアに接続するために特定のコネクタやライブラリは必要ありません。すべては、MySQLまたはMariaDBクライアントライブラリを使用して実行できます。両方のデータストアにMaxScaleを利用することもできます。これは、MariaDBAXの高可用性を構築するのに役立ちます。
柱状データストアを使用する必要があるのはなぜですか？
柱状データストアの背後にある考え方を簡単に紹介しましょう。
MariaDBAXとMariaDBTXの違いは何ですか？
主な違いは、データの構造です。通常のデータベースでは、データは行として保存されます。
Id, Product, Price, Code, Warehouse
1, Door, 10, 12334, EU1
2, Window, 9, 9523, EU1
3, Glass, 12, 97643, EU2ご覧のとおり、3つの行があり、それぞれに製品エントリに関するすべてのデータが含まれています。
問題は、このデータのサブセットだけを取得したい場合、データを保存するこの方法は実際には効率的ではないということです。 「Product」列と「Price」列だけを取得したいとします。そのためには、行全体とすべてのデータを読み取り、不要な列を破棄する必要があります。データを並べ替えるのも難しいです。データセットを最も高価な製品から最も安価な製品に並べ替える場合は、すべてを読んでから並べ替えを行う必要があります。
データベースがインデックスを利用してアクセスを高速化することは誰もが知っています。インデックスは、インデックス付きの列のコンテンツと、行全体へのポインター（InnoDBでは主キー）を含むように構造化されています。たとえば、「Id」が主キーであると仮定した場合の「Product」列のインデックスは、次のようになります。
Product, Id
Door, 1
Window, 2
Glass, 3これにより、「Product」列の値を見つけるためだけに行全体を読み取る必要がなくなるため、データへのアクセスが高速化されます。データベースがそれを見つけると、ポインタをたどることで（必要に応じて）残りの行を読み取ることができます。
列ストアでは、状況が異なります。データは行ではなく列として構造化されています。ある程度、これはインデックスに似ています。列データストアのテーブルは次のようになります。
Id: 1, 2, 3
Product: Door, Window, Glass
Price: 10, 9, 12
Code: 12334, 9523, 97643
Warehouse: EU1, EU1, EU2MariaDB AXでは、列は別々のファイルに保存され、特定の「行」の各エントリは同じオフセットで始まります。
ここでの主な利点は、データのサブセットのみを処理するクエリを実行する場合、クエリに関連する列からデータを読み取るだけでよいことです。
前の例では、データセット全体を読み取る代わりに、「Product」列と「Price」列のデータを読み込むことができます。ディスク上でアクセスする必要のあるデータを減らし、プロセスをスピードアップします。
また重要なのは、データを列に保存すると、列の区別が少なくなり、圧縮率が向上することです。たとえば、「倉庫」列には2種類のエントリしかありません。実際のシナリオでも、製品の数に比べて倉庫の数が少なくなる可能性が非常に高くなります。これにより、「Warehouse」列は圧縮の非常に適切なターゲットになります。
これらすべての結果として、列型データストアは大規模なデータセットをより適切に処理し、「標準的な」OLTPに焦点を合わせたデータベースよりも効率的な方法でクエリを実行できます。
MariaDB AXを使用する必要があるのはなぜですか？
ディスクアクセスは、データベースの主要なボトルネックです。柱状データストアは、ディスクから読み取る必要のあるデータの量を減らすことにより、パフォーマンスを向上させます。クエリに回答するために必要なデータのみを読み取ります。
もちろん、MariaDBAXだけが列型データストアではありません。 ClickhouseやApacheHBaseなど、他にもたくさんあります。
真実は、他のどのオプションもMySQLがサポートする完全なSQL構文をサポートしていないということです。異なるコネクタ、データをクエリするための異なるアプローチが必要ですが、MariaDB AXは、「通常の」MariaDBをクエリするのと同じようにクエリできます。
また重要なことは、MariaDB AXがColumnStoreエンジンを利用していることを考えると、他のエンジンと混合することはまったく問題ありません。 InnoDBテーブルとColumnStoreテーブルを同じクエリで問題なく混合して結合できます。
さらに、MaxScaleなどのMariaDB TXに付属するツールは、MariaDB AXで問題なく動作するため、統合された使いやすい環境を簡単に構築できます。そのため、MariaDB 10.3とMaxScaleでClusterControlを実行している場合、MariaDB AXをミックスに簡単に追加でき、セットアップの他の部分で機能します。
MariaDB AXには、他のソースからのデータ転送を支援することを目的としたツールが付属しています。 KafkaまたはSparkを使用している場合は、それらのソースからMariaDBAXにデータをインポートするときに使用するコネクタがあります。
さらに、MariaDB TX（InnoDB）とMariaDB AX（ColumnStore）の間の通常のレプリケーションは、ColumnStoreの制限のためにうまく機能していません（レプリケーションで行われるため、単一の挿入よりも列データストアでバッチ挿入を行う方が常に優れています）。 binlogサーバーとして構成されたMaxScaleとAvroCDCルーター、MaxScaleCDCデータアダプターとMariaDBAXで構成されるパイプラインを構築できます。これらは、アダプターからほぼリアルタイムでデータを受信します。
このブログ投稿が、MariaDB AXとは何か、およびClusterControlによってデプロイおよび管理されるMariaDB TX環境と一緒にどのように利用できるかについての洞察を提供することを願っています（無料でダウンロードしてください）。