top of page

MachbaseのバックアップをAmazon S3に保存し、マウントして手軽にデータへアクセス

2 時間前
読了時間: 7分

背景


Machbaseのお客様から、よく寄せられる質問があります。

「MachbaseのバックアップファイルをAmazon S3に保存した場合、そのデータに直接アクセスできないだろうか?」というものです。

Machbaseのバックアップ・マウント技術は、米国と韓国で特許登録されている、独自性の高い優れたデータ管理機能の一つです。ただし、製品を設計した当初は、Amazonのようなクラウドにバックアップを保存することを想定していませんでした。そのため、S3のような低コストのストレージに保存したバックアップからデータを取り出すには、ダウンロードまたはコピーを行い、復元する必要がありました。


そこで本記事では、クラウドが普及し、多くのバックアップが低コストのS3互換ストレージに保存される2025年の環境で、Machbaseのマウント機能を利用できるか検証します。


Machbaseのバックアップ・マウント機能について詳しくは、こちらの記事をご覧ください。

検証環境


実際のAmazonの環境でテストするには、時間と費用がかかります。今回はローカルにS3互換の環境を構築し、S3上のバックアップをマウントできるか、手早く検証します。


オペレーティングシステム


手軽に利用でき、テストにも適したUbuntu 24.04を使用しました。実際にはWindows上のWSLで検証しています。Windows環境でもLinuxを簡単に使えるようになりました。


S3ストレージ

複数のオープンソース製品の中から、Dockerですぐに試せるMinIOを選びました。


MinIOはAmazon S3と完全互換の環境をローカルで提供するため、今回の検証では同等の動作をするものとして扱いました。


S3用のファイルシステム — s3fs


Linux上のMachbaseデータベースエンジンから、クラウドまたはローカルにあるS3ファイルの一部へアクセスするには、何らかの形でファイルシステムとしてマウントする必要があります。

実際のファイルは仮想的なストレージ内にありますが、Googleドライブをファイルシステムとして利用するのと同じように、ローカルの特定ディレクトリを、大きなS3ストレージの一部へアクセスする窓口にできます。

この役割を果たすパッケージとして、s3fsを使用します。


これで必要な構成要素がそろいました。


MinIOの起動


Dockerを使えば、次の1行で簡単に起動できます。

sudo docker run -d --name minio   -p 9000:9000 -p 9001:9001   -e "MINIO_ROOT_USER=admin"   -e "MINIO_ROOT_PASSWORD=password123"   quay.io/minio/minio server /data --console-address ":9001"

このコマンドにより、MinIOコンソールは http://localhost:9001 に、Access Keyはadmin、Secret Keyはpassword123に設定されます。以下のように、ブラウザーからログインしてシステムを監視できます。



まだデータは入っていませんが、上の画面右上にあるUploadボタンから、Machbaseのバックアップフォルダーの内容をアップロードできます。


MinIOクライアントのダウンロード

MinIOのS3環境でストレージを作成するため、次の手順でMinIOクライアントをダウンロードします。

wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc
sudo mv mc /usr/local/bin/mc3

これでmc3を使ってバケットを管理できます。mcからmc3へ名前を変えたのは、Midnight Commanderのコマンド名と重複するためです。


テスト用バケットの作成

Machbaseのバックアップファイルを保存するバケットを、次のコマンドで作成します。

mc3 alias set local http://127.0.0.1:9000 admin password123
mc3 mb local/mybucket

以下のように、mybucketというテスト用バケットが作成されました。



バックアップデータのアップロード


Uploadボタンを使い、Machbaseでバックアップしたフォルダーをアップロードします。

本記事では、sjkimという名前のバックアップを、以下のようにS3ストレージへアップロードしました。


s3fsのインストール

Ubuntuでは、次のようにs3fsをインストールできます。

sudo apt update
sudo apt install s3fs

s3fsの認証設定

s3fsからS3サーバーへ接続するため、先ほど設定したユーザー名とパスワードを記載したファイルを作成します。

コマンドは次のとおりです。

echo "admin:password123" > ~/.passwd-s3fs
chmod 600 ~/.passwd-s3fs

s3fsでLinuxのローカルファイルシステムにマウント

これで準備が整いました。

s3fsを使い、sjkimのバックアップを保存したS3ストレージへ、Linuxのローカルファイルシステムからアクセスできるようにします。

次のコマンドを実行します。

マウント先のディレクトリは /home/sjkim2/work/s3 です。

sjkim2@PC:~/work$ s3fs mybucket ./s3    -o passwd_file=~/.passwd-s3fs   -o url=http://127.0.0.1:9000   -o use_path_request_style   -o dbglevel=info -f -o curldbg
2025-11-19T06:10:59.323Z [INF] s3fs version 1.93(unknown) : s3fs -o passwd_file=/home/sjkim2/.passwd-s3fs -o url=http://127.0.0.1:9000 -o use_path_request_style -o dbglevel=info -f -o curldbg mybucket ./s3
2025-11-19T06:10:59.323Z [CRT] s3fs_logger.cpp:LowSetLogLevel(239): change debug level from [CRT] to [INF]
....
2025-11-19T06:13:30.283Z [INF]       curl.cpp:RequestPerform(2520): HTTP response code 200
2025-11-19T06:13:30.283Z [INF] threadpoolman.cpp:StopThreads(195): Any threads are running now, then nothing to do.
2025-11-19T06:13:30.283Z [INF]       threadpoolman.cpp:Worker(76): Start worker thread in ThreadPoolMan.

このようなメッセージが出れば、S3は正常にマウントされています。ディレクトリを確認してみましょう。

sjkim2@PC:~$ cd work/
sjkim2@PC:~/work$ ls -al s3
합계 4
drwx------  1 sjkim2 sjkim2    0  1월  1  1970 .
drwxrwxr-x 11 sjkim2 sjkim2 4096 11월 19 14:10 ..
drwxr-x---  1 sjkim2 sjkim2    0  1월  1  1970 sjkim
sjkim2@CEO-PC:~/work$ ls -al s3/sjkim
합계 24464
drwxr-x--- 1 sjkim2 sjkim2        0  1월  1  1970 .
drwx------ 1 sjkim2 sjkim2        0  1월  1  1970 ..
drwxr-x--- 1 sjkim2 sjkim2        0  1월  1  1970 TAG_TABLESPACE
-rw-r----- 1 sjkim2 sjkim2     1148 11월 19 14:54 backup.dat
-rw-r----- 1 sjkim2 sjkim2     6073 11월 19 14:54 backup.trc
drwxr-x--- 1 sjkim2 sjkim2        0  1월  1  1970 
Machbase_backup_19700101090000_20251113184807_130
-rw-r----- 1 sjkim2 sjkim2   159744 11월 19 14:54 meta.dbs-0
-rw-r----- 1 sjkim2 sjkim2   155648 11월 19 14:54 meta.dbs-1
-rw-r----- 1 sjkim2 sjkim2     8192 11월 19 14:54 meta.dbs-2
-rw-r----- 1 sjkim2 sjkim2 24707072 11월 19 14:54 meta.dbs-3
-rw-r----- 1 sjkim2 sjkim2        0 11월 19 14:54 meta.dbs-4
-rw-r----- 1 sjkim2 sjkim2    12288 11월 19 14:54 meta.dbs-5

S3にアップロードしたファイルが、すべて表示されています。


Machbaseでバックアップをマウント

S3のディレクトリに圧縮したまま保存されているバックアップを、マウントして参照できるでしょうか。次のコマンドで確かめます。

MOUNT DATABASE '/home/sjkim2/work/s3/sjkim' to s3_backup;

/home/sjkim2/work/s3/sjkim にあるバックアップファイルをマウントし、どのテーブルがあるか確認しました。

約5秒でマウントが完了し、DB_NAMEがS3_BACKUPとなっている数十のテーブルを確認できました。


次に、tagテーブルの情報を確認しましょう。

マウントしたデータベースのtagテーブルには1,000万件のレコードがあり、10個のタグそれぞれに100万件ずつデータがあることが分かります。


最後に、特定の時間範囲を指定してクエリを実行します。全1,000万件のデータから、10秒間のデータを抽出するクエリを試しました。


正常に動作しました!うれしい結果です。

S3に保存したMachbaseの圧縮バックアップをマウントするだけで、中のデータを直接取り出せることが分かりました。


実行には約1秒かかりました。対象データを含むバックアップのチャンクを読み込む時間と考えられます。通常のファイルシステムでは0.1秒未満で実行されます。


実際のs3fsログは次のとおりです。

赤枠で示した読み込みサイズを見ると、約39MBのデータベースチャンクを読み込んでいることが分かります。

S3へのアクセスでは大きなファイルを読み込むため、コストと性能を改善するヒントをご紹介します。


性能の改善とコスト削減のヒント


S3のファイルはHTTP経由でアクセスするため、ファイルへのアクセスが多すぎると、コストが増えたり性能が低下したりします。

一方、バックアップファイルには次の特徴があります。

  • ファイル単位のチャンクで構成されている

  • 圧縮した形式で保存されている

  • 読み取り専用である

これらの特徴を生かし、s3fsでキャッシュして各ファイルを一度だけ読み込めれば、大幅なコスト削減が期待できます。読み取り専用のため、内容が変わらないからです。ChatGPTの助けを借り、必要なファイルを読み込んで再利用するための選択肢を、以下のように整理しました。

キャッシュの種類

既定値

説明

ファイル内容のキャッシュ(--enable_noobj_cache)

❌ 無効

存在しないファイルの情報をキャッシュ

ディレクトリキャッシュ(--stat_cache_*)

small

statキャッシュ

メタデータキャッシュ(--enable_content_md5)

❌

性能への影響

メモリーキャッシュ(-o use_cache)

❌

ファイル単位のローカルキャッシュ

既定値からこれらの設定を有効にすることで、コスト削減や性能向上を期待できそうです。


おわりに

当初は、S3に保存したバックアップデータを直接マウントして利用できるとは想像していませんでした。しかし、さまざまな方法を試すことで、S3のような低コストのストレージにあるMachbaseのバックアップファイルを、個別に変更・コピーすることなくマウントし、中のデータへSQLでアクセスできることを確認しました。


この記事が、Machbaseデータベースの管理、バックアップ、データの再利用を検討している方の参考になれば幸いです。


ご質問や改善のご提案がありましたら、公式サポート窓口 support@machbase.com へお気軽にお問い合わせください。


ありがとうございました。


 
 
電話
英語
bottom of page