約7万円のNASで始めたMariaDBを、5年間使い続けた

製品名も機械名も、最初は文字で直接保存していました。MariaDB上の工場用データベースは3代目になり、今では12台のプレス機から3分ごとの記録を受けています。

最初から正しいデータベースは作れなかった

ぼくが最初に知りたかったのは、「この仕事は本当に見積もりどおりにできているのか」でした。1時間500個の見積もりに対して、本当に500個できているのか。そのときの売上はいくらで、利益は残るのか。頭の中の計算を、実際の数字で確かめたかったのです。

2020年ごろ、会社の見積もりやパソコンのデータを集めるため、SynologyのDS218+を買いました。本体は当時約4万円、HDDは約1万5,000円を2台。RAID1で使える容量は約5TB、合計約7万円でした。

黒いSynology DS218+を正面から見た製品画像
会社のファイル集約と工場データの保存に使っているSynology DS218+

2021年7月ごろ、このNASへパッケージセンターからMariaDBを入れ、プレス機の稼働データを貯め始めました。最初は2〜5個ほどの小さなテーブルです。製品名もプレス名も従業員名も、記録へ文字で直接入れていました。リレーションという考え方も、ほとんど理解していませんでした。

同じ変更を、12台へ一台ずつ入れていた

当時は12台のプレス機すべてにRaspberry Pi 3 Model A+を付け、それぞれでNode-REDを動かしていました。例えば、時間チャージが2,000円を下回ったら、当時使っていたLINE Notifyへ知らせる。その機能を一つ付けるだけでも、12台すべてのフローを変更する必要がありました。

緑色の基板にUSB端子一つとHDMI端子を備えたRaspberry Pi 3 Model A+
当時、機械側に使っていたものと同型のRaspberry Pi 3 Model A+

一台3〜4分なので、12台なら36〜48分。作業時間より困ったのは、加工中のデプロイでした。プログラムが止まる間にショット信号を取りこぼすのが怖かったのです。実際にカウントが減ったかは未確認ですが、加工していないプレスを見つけて一台ずつ更新していました。

2024年2月、12台に分かれていたNode-REDをNASへ集めました。各機械側に残したのは、電源の入り切りとショット信号を取得して送る処理だけです。

  • 各機械のRaspberry Piが信号を取得する

  • MQTTでNASへ送る

  • NAS上のNode-REDが受け取る

  • 同じNAS上のMariaDBへ登録する

Node-REDでは共通処理をサブフローへまとめました。一か所を変えれば、各機械につないだ同じ処理へ反映できます。ただし、NAS側をデプロイしている間の取りこぼし対策は、現在もできていません。大きな変更は機械が動き始める前の早朝に行い、稼働中ならタイミングを見てデプロイしています。集約したから、すべての問題が消えたわけではありません。

機械側を替えても、後ろは作り直さなかった

その後、機械側はRaspberry PiからESP32へ交換しましたが、NASへ送るMQTT信号は同じだったため、NAS側のNode-REDは変えていません。機械側の端末と、データを処理する場所を分けていたため、入口だけを交換できました。交換した理由は、次の記事で詳しく書きます。

黒い基板に無線モジュールと端子列を備えたESP32開発ボード
後に機械側へ交換したESP32の開発ボード

現在も、MQTTを受けてMariaDBへ登録する部分はNode-REDが担当しています。一方、グラフ、製品登録、PDF出力などは、N100のUbuntu小型PCで専用Webアプリを作っています。

NASへGrafanaを入れたこともありますが、全体的に重く、使うのをやめました。Node-REDは信号とデータを直感的なフローでつなぐ。Webアプリは自由な画面や帳票を作る。NASはMariaDB、Node-RED、ファイル保存に絞る。それぞれの役割へ分けました。

数個のテーブルから、3回作り直した

データベースは3世代あります。製品名やプレス名を文字で直接保存していた最初の構造では、名称を変えたり、過去データを使って新しい機能を足したりするときに困りました。実際に困ってから、IDで保存し、製品マスターや機械マスターと紐づける意味が分かりました。

現在のデータベースは2025年8月20日に使い始めた3代目です。一部未使用を含め24テーブル、2026年8月27日時点で約32.5MiB。旧データベースやWordPressを含むMariaDB全体でも約368.8MiBでした。

稼働データは、電源が入っている機械から3分ごとに届きます。タイムスタンプ、工程ID、ロット、機械ID、従業員ID、3分間の加工数、時間当たりのショット数を記録しています。最初は1分ごとでしたが、データ量との釣り合いで3分へ変えました。5分にすると、短い停止が平均化され、棒グラフで見えにくくなる。自社では3分で十分だと判断しました。

写真、動画、図面はNASへファイルとして置き、MariaDBには保存場所だけを入れています。注意事項などの短い文章はMariaDBへ保存します。製品単価は製品マスターに置き、稼働記録と組み合わせて時間チャージを計算します。

会社のファイルを全部含めても、まだ8%だった

この仕組みを使う自社工場の規模は、プレス機12台、利用者6〜8人ほどです。2026年8月27日時点で、NAS全体の使用量は約406GB。見積もり、各パソコンの保存データ、MariaDB、写真、動画、図面、記事などをすべて含めても、使用可能な約5TBの8%でした。MariaDBやNode-REDが原因で現場の記録が取れなくなったことも、ぼくが把握している範囲では一度もありません。

一方で、UPSは付けておらず、RAID1とは別の定期バックアップもできていません。停電後にデータが壊れた経験はありませんが、障害へ十分備えた構成ではなく、ここは今後の課題です。すべて社内のローカルネットワーク内で使い、外部へは直接公開していません。

ぼくはデータベースの専門家ではありません。この構成が唯一の正解だとも思っていません。自社では、約7万円のNASと数個のテーブルから始め、必要な仕組みを作りながら5年使い続けられた。それが確認できた事実です。

今の形を最初からゴールにしたわけではありません。本を読んだだけでは分からなかったリレーションも、自分のデータで困ったから理解できました。最初から正しく作れなかった。それでも、小さく始めたことは良かったと思っています。

最初に決めるのは、データベースの構成ではなく、経営者が頭の中で何度も計算しているものを、何の記録で確かめるかです。

あなたの工場で「多分これぐらい」と判断している数字は、何を記録すれば確かめられますか。

実践・執筆M-LABO
X原文を見る →