MariaDB ColumnStoreからS3を使用する

MariaDB
この記事は最終更新から4年以上経過しています。内容が古くなっている可能性があります。

MariaDB ColumnStoreからS3を使用する

先日MariaDB Server 10.5.4(GA)がリリースされ、それに含まれる形でMariaDB ColumnStore 1.5.2(Beta)がリリースされました。

MariaDB Enterprise Server 10.4では、先行してMariaDB ColumnStore 1.4がリリースされておりますが、コミュニティでは同梱されるMariaDB Serverのバージョンに合わせて1.5となったようです。

MariaDB ColumnStore 1.4 から導入されたStorege Manager(SM)という機能により、AWS S3及びその互換ストレージをDBRootとして利用可能となっています。

ストレージの故障はデータベースの運用において悩みの種ですが、パブリッククラウドのオブジェクトストレージは非常に可用性も高く、高コストな初期投資無しに利用可能ということでMariaDB ColumnStoreで利用できることは非常に喜ばしいものと思います。

今回はMariaDB ColumnStoreのStorage Manager(SM)からS3互換ストレージを使用する方法についてご紹介致します。

目次

リファレンス

https://mariadb.com/docs/features/mariadb-columnstore/#s3-storage-manager
https://mariadb.com/docs/deploy/enterprise-multi-columnstore/#storage-manager
https://mariadb.com/docs/deploy/enterprise-multi-columnstore-es104-centos8/#storage-manager

環境について

  • 今回はCentOS 8.2/MariaDB Server 10.5.4を使用します。
  • 同梱されているMariaDB ColumnStore 1.5.2はまだBetaですので、将来的には動作が大きく変更される可能性がございます。
  • AWS S3とS3互換ストレージであるGCPのCloud Storageを使用します。

また、S3の準備については以下をご確認ください。

AWS S3

https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html

GCP Cloud Storage

https://cloud.google.com/storage/docs/creating-buckets#storage-create-bucket-gsutil

Storage Managerとは

MariaDB ColumnStoreではPerformance Moduleが利用するマウントポイントであるDBRootとして、以下がもともと利用可能でした。

  • ローカルストレージ
  • SANなどのハードウェアレベルの共有ストレージ
  • GlusterFSなどのソフトウェアレベルの共有ストレージ

これまでは大部分を外部の仕組みに依存していましたが、Storage Managerでは共有ストレージの利用を一括で管理し、さらにS3互換ストレージを共有ディスクとして利用可能となっています。

  • AWS S3, Google Cloud Storage, IBM Cloud Storage, Ceph, etc

アーキテクチャ

Storage Manager S3は、ローカルに配置するジャーナルファイルと、リモートのS3互換ストレージで構成されます。

一定量の更新データはローカルのジャーナルファイルに保持されます。

何らかのクエリを実行した場合は、ジャーナルファイルとリモートのS3互換ストレージのデータをマージして、クライアントに結果を返します。

ジャーナルファイルは起動・停止時、及びジャーナルファイルの上限を超過した場合にS3にマージされます。

MariaDB Server 10.5でのColumnStoreの起動

MariaDB Server 10.4からはMariaDB ColumnStore Engineがマージされており、より簡単にインストールが可能となっています。

Storage Managerの設定

起動前に /etc/columnstore/storagemanager.cnf に設定を行います。
オリジナルの設定ファイルには様々なコメントが記載されていますが、ここではコメントを削除した内容を記載します。
また今回はLocalStorageを使用していないため該当セクションは除外しています。

セクション パラメータ名 説明
ObjectStorage service S3互換ストレージを利用するならS3, それ以外ではLocalStorageを指定します
ObjectStorage object_size S3に保存される1オブジェクトのサイズ。Storage Managerによってデータはこの単位に分割されます
ObjectStorage metadata_path S3上のオブジェクトが列挙された管理用ファイル(JSON)を保持するディレクトリ
ObjectStorage journal_path 更新ログを保持するディレクトリ
ObjectStorage max_concurrent_downloads S3からの最大ダウンロードスレッド数
ObjectStorage max_concurrent_uploads S3への最大アップロードスレッド数
ObjectStorage common_prefix_depth DBRootが存在するディレクトリの深さ
S3 region 利用するS3のリージョン名
S3 bucket S3バケット名
S3 endpoint S3のエンドポイント。AWS S3の場合は必要ありませんがその他のS3互換ストレージの場合に指定します(eg. storage.googleapis.com)
S3 aws_access_key_id S3 APIを利用する際のアクセスキー。AWSに限らず指定する必要があります。
S3 aws_secret_access_key S3 APIを利用する際のシークレットアクセスキー。AWSに限らず指定する必要があります。
Cache cache_size ジャーナルファイルの最大サイズ。このサイズを超えるとS3へのアップロードが行われます。
Cache path 一時オブジェクトが配置されるディレクトリ

今回はus-east-1リージョンにmcs-s3バケットを作成しました。

準備ができましたら起動します。

起動した時点で、オブジェクトストレージに必要なファイルが配置されます。

AWS S3の確認

S3上で、object_sizeでのデータファイルが大量に作成されていることが判ります。

GCP Cloud Storage

今度は一旦データをクリーンアップし、GCPのバケットを使用します。
AWS以外のS3互換ストレージでは明示的にendpointの指定が必要です。

同様にDBT-3のデータをロードし、内容を確認しました。

正常に格納されており、S3 互換ストレージであれば利用可能な事が確認できました。

DBT-3の実行

今回はDBT-3の最も大きいテーブル(725M)をColumnstoreにインポートしてみました。

また、DBT-3のQuery-1を実行し、速度差異について確認しました。

パフォーマンス結果

今回の検証環境はMemory 2GB/CPU 2 coreというスペックですので、性能自体は参考程度とお考えください。

cpimport DBT-QUERY-1
S3 96s 11s
GCP CS 75s 11s
Local 28s 11s

ネットワーク通信の影響により、データローディングは顕著に遅い状況となりました。
一方でcache_sizeに収まる程度のデータが対象であればSELECTの速度はあまり落ちないようです。

所感

ネットワーク越しのストレージを使用する場合、どうしてもI/O性能が下がってしまうという点がデメリットとしてありますが、その代わりにマネージドサービスによる恩恵が受けられ管理運用の手間がなくなるという点は魅力的だと思います。

今回、オンプレの検証環境からS3を利用したため速度差が顕著でしたので、実稼働時には同じパブリッククラウド内にMariaDB Columnstoreを構築する等のNWに関する工夫が必要なようです。

また、すでにRados Gatewayを含むCeph Clusterをストレージサーバとして運用されている場合は、オンプレで完結することも可能です。

ご興味がありましたらぜひお試しください。

MariaDB

 

 

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがMariaDBに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次