増え続ける産業ビッグデータを管理する新しい方法：マウント機能の活用
はじめに
スマートファクトリーなど、いわゆる「スマートX」の分野では、センサーデータや時系列データと呼ばれる産業ビッグデータが増え続けています。企業はさまざまな技術やソフトウェアを使って保存・管理していますが、近年はAIの学習に利用するため、以前のようにすぐに廃棄したり、一定期間後に削除したりできない場合も増えています。こうしたデータをどう管理するかが、重要な課題となっています。
データベースやプレーンテキストに保存されたデータを、もっと効果的に管理する方法はないでしょうか。今回は、Machbaseが提案する新しい方法と、その効果を見ていきます。
膨大に蓄積するIIoTデータの管理が難しい理由
従来のデータベースバックアップの限界
ここでは、データの保存先をMySQL、MariaDB、MongoDB、InfluxDBなどのデータベースに限定して考えます。
通常、データベースを稼働させる機器の保存容量には限りがあります。今後あまりアクセスしないと考えられる古いデータ、つまりコールドデータは、バックアップ後に稼働中のデータベースから削除するのが一般的です。
ただし、データベースに備わるバックアップ機能で大量のデータを管理しようとすると、次のような現実的な問題があります。
第一に、バックアップ対象の範囲を柔軟に管理しにくいことです。
従来のデータベースのバックアップは、全データを保存するフルバックアップと、変更部分だけを保存する増分バックアップに大別されます。毎回全体をバックアップすると、時間やリソースを無駄にするためです。しかし、IIoTデータでは、特定の時間範囲や特定のテーブルだけをバックアップする必要もあります。
第二に、バックアップからデータを取り出すための復元（Restore）に時間がかかることです。復元せずにバックアップのデータへアクセスすることはできません。
データベースの復元は、インスタンスをバックアップ時点の状態に戻す処理です。そのためには、バックアップ内容をデータベースに再反映する必要があり、環境によっては数時間から数日かかります。この長い処理が完了して初めて、過去のデータへのアクセス、分析、探索が可能になります。
バックアップ機能の代わりに、特定のテーブルやデータベース全体をEXPORT／IMPORTする方法もあります。ただし、テキスト形式では保存容量が大きくなり、読み込み後のインデックス作成が完了するまで検索できません。復元という観点では、やはり多くの時間とリソースを要する方法です。
第三に、バックアップから復元すると、元のデータベースの状態が変わることです。
復元はインスタンスを過去の時点に戻す操作なので、現在の状態が変更され、最新データをそのまま維持できません。そのため通常は、障害などで元のデータベースに問題が生じた場合に行います。
バックアップとデータ提供の課題
このように、データベースの復元は、元のデータベースを利用できなくなるような障害への対応を主な目的とした技術です。
では、バックアップした過去のデータを頻繁に提供・抽出する必要がある場合は、どうすればよいでしょうか。
保存容量やバックアップの方針に従い、月末にフルバックアップを取得した後、すべてのデータを削除する組織を考えてみましょう。
3か月前のある日に生産した製品の不良が見つかり、当時の状況を示すデータを提出することになった場合、毎回数時間かけて復元してから抽出する必要があります。非効率で時間がかかりますが、他に有効な方法がないことが問題です。
AI分析チームが、時間、センサー、データ範囲などの条件を変えて定期的にデータを要求する場合も同様です。月ごとに保存した数十個のバックアップを、その都度長い時間をかけて復元していては、迅速な提供は困難です。
つまり、大量のデータを一度バックアップすると、従来の技術では、そのデータを素早く提供・抽出することが難しくなります。
新しいデータ管理の方法を考える
保存容量は無限ではないため、バックアップを繰り返すことは避けられません。そこで、少し違う視点から考えてみましょう。
バックアップ時に、データベース全体か個別のテーブルかを選べたらどうでしょう。
対象範囲を選べれば、バックアップ時間を短縮し、データ管理を簡単にできます。
不要なデータを、バックアップ対象から除外する自由も生まれます。
バックアップする時間範囲も指定できたらどうでしょう。
時間範囲の指定は、時系列という性質を持つIoT・IIoTのセンサーデータに適しています。
全体ではなく、時間軸に沿って必要な部分だけをバックアップできます。
バックアップしたデータを即座に復元できたらどうでしょう。
それは大きな技術的進歩です。
6か月分のデータを2TBの領域にバックアップしたとして、復元にどれほど時間がかかるかを見積もるのは簡単ではありません。
途中でエラーが発生した場合のことは、想像したくもありません。
復元するのではなく、ファイルシステムのようにマウントして参照できたらどうでしょう。
ゲームに例えるなら、まさに究極の機能ではないでしょうか。
先ほどの2TBのバックアップを、別のデータベースとしてマウントし、確認・検索・活用・提供できるとします。不要になったらアンマウントするだけです。これが可能なら、データ管理のあり方は大きく変わります。
Machbase Neoによる新しいIIoTデータ管理
次の図は、先ほど考えたデータ管理の方法を、Machbase Neoがどのように実現するかを示しています。
テーブルAとBがオンライン状態で、TIME-0から現在までリアルタイムにデータを保存しているとします。稼働中のテーブルには、SELECT * FROM AまたはBのようなSQLでアクセスできます。
バックアップの手順
1. データベース全体を対象に、TIME-0からTIME-1までのデータをバックアップします。
2. 保存領域を節約するため、テーブルBの同じ時間範囲のデータ（B1）を削除します。
図のクエリでバックアップを実行すると、指定したディレクトリにバックアップファイル一式が作成されます。
BACKUP DATABASE FROM time-0 TO time-1 INTO DISK = '/tmp/MYBKUP';DELETE FROM B BEFORE time-1;
完了するとバックアップが作成され、対象のB1データがテーブルBから削除されます。ここでは、バックアップを低コストの保存領域である/backup-storeへ移したものとします。
マウントの手順
その後、何らかの理由で、削除したテーブルBのB1データにアクセスして抽出する必要が生じたとします。
このとき、バックアップをすぐに参照できるよう、図の操作を行います。
MOUNT DATABASE '/backup-store/MYBKUP' to newdb;
バックアップをnewdbという新しいデータベースとしてマウントすると、インデックスも整った状態でアクセス可能になります。この処理は数秒以内に完了します。
データを活用する
マウントしたデータベースでは、データだけでなくインデックスも完全な状態で利用できるため、時系列クエリを高速に実行できます。
テーブルを指定するときは、「データベース名.ユーザー名.テーブル名」をすべて記述する必要があります。
SELECT * from newdb.sys.B WHERE 여러조건들
newdb、管理者ユーザーsys、テーブルBを指定すればアクセスできます。マウントした領域は常に読み取り専用である点に注意してください。
データ管理の操作を大きく変えるインターフェースです。
データベースの一部をバックアップし、復元せずにマウントして即座に参照できる。この考え方は、データベースにおける非常に革新的なアプローチの一つだと考えています。
アンマウントの手順
データの利用が終わったら、図のアンマウントコマンドで接続を解除できます。
UNMOUNT DATABASE newdb;
マウントしたデータベースの利点と注意点
データの抽出という点では、マウントしたデータベースはオンラインのテーブルとほぼ同じですが、いくつかの注意点があります。
非常に短い復旧時間
数TBのバックアップでも、マウントすれば長くても数秒で追加のデータベースとしてアクセス可能になります。MySQLやOracleのバックアップを復元してから特定のデータを抽出する手順と比べると、その違いがよく分かります。
高速アクセス用のインデックスを維持
マウントしたデータベースには、高速な検索に必要な時系列インデックスがそのまま備わっています。内部のデータ構造は、バックアップ時点の状態を維持しています。
ロールアップの構造もそのまま維持
Machbaseの大きな特徴の一つが、任意の時間範囲の統計結果をリアルタイムに取得できることです。ロールアップテーブルを作成していれば、そのデータ構造もバックアップに保持されます。マウント後も同じ環境で、長期間の統計データを取得できます。
読み取り専用
マウントしたテーブルは、読み取り専用です。Unixのファイルシステムは書き込み可能な状態でマウントできるため、混同しないようにしてください。
利用できるのはSELECTクエリです。バックアップを参照・提供するための仕組みなので、これは自然な制約です。バックアップを読み書き可能なデータベースとして使うには、データベース全体を上書きするRestore処理が必要です。
Machbase Neoでは、次のように復元できます。Classic版についてはマニュアルをご参照ください。
machbase-neo restore --data <Machbaseホームディレクトリ> <バックアップディレクトリ>
ex) machbase-neo restore --data /data/machbase_home /tmp/backup
マウントしたテーブルのV$テーブル名_STATは利用不可
タグごとの統計をリアルタイムに更新するV$XX_STATは、マウントしたデータベースでは利用できません。今後の改善課題ですが、タグのデータを抽出することが主目的であれば、大きな問題にならない場合が多いでしょう。
バックアップのデータ量が非常に多い場合は、事前に各テーブルのV$テーブル名_STATを別途ダウンロードしておき、参照する方法もあります。
バックアップとマウントを試す
ここからは、実際にマウント機能を試してみましょう。
1. Neoのインストールとneo-appsの入手
インストール手順は以前の記事と同じです。リンク先の手順1（Neoのインストール）と手順2（neo-appsのダウンロード）を参照し、可能であれば8.0.18-rc3a以降のMachbase Neoを入手してください。その後、本記事に戻り、下記の手順2から進めます。
可能であれば、Machbase Neo 8.0.18-rc4以降を使用してください。
2. backup-mountディレクトリの確認
neo-appsを入手すると、backup-mountディレクトリが見つかります。番号の順番にテストを進めます。
3. スキーマの作成とデータの取り込み
このデモでは2つのテーブルを作成し、それぞれに1つのタグを用意します。各タグに、2023年1月1日から3月31日まで、1分ごとに1件のデータを投入します。
「0-Schema Data.wrk」を開き、順番にスキーマを作成してデータを取り込みます。TQLであらかじめデータを投入できるように準備してあります。
赤いボタンを順に押すと、スキーマが作成され、各テーブルに129,600件のデータが入ります。1番は2つのテーブルを作成するため、それぞれの行にカーソルを置いて実行してください。
次のように取り込み件数を確認できます。この表示は8.0.18-rc4以降で利用できます。
「1-Chart online.dsh」を開くと、3か月分のデータを表示するダッシュボードを確認できます。ロールアップを使わず全データの平均を計算するため、表示に少し時間がかかる場合があります。
4. 全体バックアップとマウントを試す
データの準備ができたので、データベース全体をバックアップし、マウントしてみましょう。
「2-Full Backup and Mount.wrk」を開き、順番に実行すると、ここまで説明した操作を試せます。
データベース全体のバックアップ
BACKUP DATABASE INTO DISK='/tmp/mybkup2';このコマンドは、現在のデータベース全体を指定したディレクトリにバックアップします。オンラインバックアップのため、他の処理を継続したまま実行できます。
ディレクトリを確認すると、次のように複数のファイルで構成されていることが分かります。
jkim@gamestar:~$ ls /tmp/mybkup2 -l
total 348
drwxrwxr-x 8 sjkim sjkim 4096 May 25 11:16 TAG_TABLESPACE
-rw-rw-r-- 1 sjkim sjkim 1148 May 25 11:16 backup.dat
-rw-rw-rw- 1 sjkim sjkim 2722 May 25 11:16 backup.trc
drwxrwxr-x 103 sjkim sjkim 4096 May 25 11:16 machbase_backup_19700101090000_20240525111644_27
-rw-r--r-- 1 sjkim sjkim 139264 May 25 11:16 meta.dbs-0
-rw-r--r-- 1 sjkim sjkim 143360 May 25 11:16 meta.dbs-1
-rw-r--r-- 1 sjkim sjkim 8192 May 25 11:16 meta.dbs-2
-rw-r--r-- 1 sjkim sjkim 36864 May 25 11:16 meta.dbs-3
-rw-r--r-- 1 sjkim sjkim 0 May 25 11:16 meta.dbs-4
-rw-r--r-- 1 sjkim sjkim 12288 May 25 11:16 meta.dbs-5マウントしてデータを確認する
バックアップファイルを、内部の新しいデータベースインスタンスとしてマウントできるか試します。次のコマンドを使い、データベース名をmountdbとします。
MOUNT DATABASE '/tmp/mybkup2' to mountdb;この例では、1秒もかからずコマンドが成功します。
NeoのメニューにはMOUNTDBが表示されます。これでマウントが完了しました。
SHELLからクエリを実行すると、データが正しく入っていることを確認できます。
テーブル名が単なるmytab_Aではなく、mountdb.sys.mytab_Aになっている点に注目してください。
アンマウント
確認が終わって不要になったら、次のコマンドで簡単に接続を解除できます。
UMOUNT DATABASE mountdb;実行画面
アンマウント済みのテーブルにアクセスすると、エラーになることを確認できます。
これで、バックアップ・マウント・アンマウントを利用した、便利なIIoTデータ管理の基本が分かりました。
5. 時間範囲を指定したデータベースのバックアップとマウント
手順4ではデータベース全体をバックアップしました。次は、すべてのテーブルについて、特定の時間範囲だけをバックアップします。独自の管理方針に合わせてデータを分類・配置するうえで有効な機能です。「3-Time Range DB Backup and Mount.wrk」を使います。
時間範囲を指定したデータベースのバックアップ
構文は次のとおりです。
BACKUP DATABASE FROM <開始時刻> TO <終了時刻> INTO DISK=<保存先フォルダー>;次の例では、1月分のデータをmybkup3フォルダーにバックアップします。
BACKUP DATABASE FROM TO_DATE('2023-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS')
TO TO_DATE('2023-01-31 23:59:59','YYYY-MM-DD HH24:MI:SS')
INTO DISK='/tmp/mybkup3';
DELETE FROM mytab_B before TO_DATE('2023-01-31 23:59:59','YYYY-MM-DD HH24:MI:SS');バックアップ後、テストのためテーブルBの1月分を削除します。オンライン側では、テーブルAに1〜3月、テーブルBに2〜3月のデータが残ります。バックアップには、対象期間である1月のデータが保持されています。
マウントしてデータを確認する
オンライン側のmytab_Bからは1月のデータが削除されています。一方、マウントしたmytab_Bには、1月分のデータだけがそのまま保存されていることを確認できます。
アンマウント
先ほどと同様、次のコマンドで接続を解除します。
UMOUNT DATABASE mountdb;特定の時間範囲をバックアップしておき、必要なときにマウントして確認し、不要になったらすぐに解除できます。これなら過去のデータを扱う作業が大幅に簡単になります。
6. 特定のテーブルのバックアップとマウント
次は、データベース全体ではなく、特定のタグテーブルの特定期間だけをバックアップしてマウントします。「4-Time Range Table Backup and Mount.wrk」に例を用意しています。
時間範囲を指定したテーブルのバックアップ
構文は次のとおりです。時間範囲を指定しないバックアップも可能です。
BACKUP TABLE <テーブル名> FROM <開始時刻> TO <終了時刻> INTO DISK=<保存先フォルダー>;次の例では、mytab_Aの3月分のデータをmybkup4フォルダーにバックアップします。
BACKUP TABLE mytab_A FROM TO_DATE('2023-03-01 00:00:00','YYYY-MM-DD HH24:MI:SS')
TO TO_DATE('2023-03-31 23:59:59','YYYY-MM-DD HH24:MI:SS')
INTO DISK = '/tmp/mybkup4';マウントしてテーブルのデータを確認する
マウントの方法はこれまでと同じです。バックアップ側のmytab_Aには3月分だけが入り、オンライン側のmytab_Aには3か月分のデータが残っていることを確認できます。
アンマウント
同様に、次のコマンドで接続を解除します。
UMOUNT DATABASE mountdb;データベース全体や特定期間だけでなく、個別テーブルの特定期間もバックアップできます。そして、必要なときに任意のデータベース名でマウントし、いつでも確認できます。
7. 複数のバックアップを同時にマウントする
最後に、複数のバックアップを同時にマウントして可視化します。「5-Mount All.wrk」「6-Chart All.dsh」「7-Umount All.wrk」を順番に実行してください。
複数をマウントする
図のSQLで、これまでに作成した3つのバックアップをまとめてマウントします。
複数のバックアップを同時にマウントできました。8.0.18-rc4以降では、図のようにテーブルの構成も確認できます。
データの分布を可視化する
全体の分布を確認するため、6番のチャートを開きます。全データを表示するため、少し時間がかかります。
最初のバックアップ（MOUNT-2 Tables）には両テーブルの1〜3月分、2番目（MOUNT-3 Tables）には1月分だけが入っています。3番目（MOUNT-4 Tables）には、テーブルAの3月分だけが入っていることを確認できます。
Machbase Neoのバックアップ・マウント機能を使うと、さまざまな条件で保存したバックアップを、必要なときに高速でマウントし、すぐに検索・抽出・変換できます。
アンマウント
これまでと同様、次のコマンドを実行します。
umount database mountdb2;
umount database mountdb3;
umount database mountdb4;
企業のデータ管理方針を決める際の検討事項
意思決定のポイント
企業全体のデータ管理方針を定めるには、各社の環境に合わせて選択肢を検討する必要があります。主な論点は次のとおりです。
何をバックアップするか。
データベース全体
特定のテーブル
どの頻度でバックアップするか。
月に1回
四半期に1回
半年に1回
バックアップデータにどうアクセスするか。
稼働中のデータベースにマウントする（サービス負荷が集中）
マウント専用のデータベースを構築する（サービス負荷を分散）
バックアップの保存先をどう構成するか。
稼働中のサーバーのストレージを利用する
低コストのストレージ（HDD、S3）へ移す
マウントの運用方針をどうするか。
誰が必要なバックアップをマウントするか。
自動マウント機能を実装・提供するか。
いつアンマウントし、誰が管理するか。
これらの選択肢は、バックアップしたデータに誰もが必要なときにアクセスできるマウント機能を前提としています。この機能がなければ、データ利用者への提供方法そのものを別の形で設計する必要があります。
データ提供の運用シナリオ
以下は、ある企業の運用を想定した架空のシナリオです。参考例として紹介します。
ある企業では、XX製造工程から発生する大量のデータをリアルタイムに保存しています。製造品質を改善する分析チームが、さまざまな条件でデータを利用します。そのため、便利で迅速な社内データ提供の仕組みを、次のように構築しました。
タグ数
合計10万個
データ収集速度
毎秒5万〜9万件
データ管理環境
Windows 10を稼働させたサーバー
Machbase Neoの最新版
バックアップ対象
データベース全体（ロールアップを含む）
バックアップ頻度
月に1回
バックアップの保存先
まずSSDにバックアップし、処理性能を確保
二次ストレージ（HDD）へ移し、一次保存先から削除
マウントしたデータへのアクセス方法
オンライン処理サーバーへの影響を避ける構成を検討
別のWindowsサーバーを用意し、二次ストレージを接続
必要に応じて対象のバックアップフォルダーをマウントし、準備完了を通知
アクセスURLとマウントしたデータベース名を分析チームに通知
マウントの運用方針
分析チームがデータを要求
現場の担当者がマウント・アンマウントを実施
データを利用する組織
社内のデータ分析チーム
REST APIやSQLで、必要な時点のデータを取得
自社の分析ソフトウェアで品質を分析
分析完了を現場の担当者に通知し、アンマウント
おわりに
Machbase Neoのマウント機能は、大量データの管理と提供を大きく改善します。オンラインのデータを1か所に無制限に保存できず、バックアップが必要で、さらに過去のデータへ不定期にアクセスするような場面では、特に便利な方法です。
企業ごとに条件は異なりますが、この機能が社内のデータ活用とサービス品質の向上に役立つことを願っています。
