リアルタイムセンサーデータをどう保存する？仕様書から見たInfluxDB vs MySQL

Posted at 2025-07-11

1. はじめに

どうも、趣味でデータ分析している猫背なエンジニアです。

たまには組み込みエンジニアらしい観点でデータを切っていきたいな〜と思っていたところ、ちょうどQiitaの祭典で関連テーマが開催されていたので、乗っかってみました。

IoTの世界に足を踏み入れたとき、「センサーデータをどこに保存するか？」は意外と悩むポイントのひとつだと思っています。かつての私は、「データなんて確認用だ！ログ用だ！」なんて破門級のセリフを口にしていました。
いまでは絶対に言いませんし、不必要なデータなど存在しないとさえ思っています。

この記事では、後日投稿予定の「（仮称）百葉箱IoT開発日記」に向けて、センサーデータをどのように蓄積するか、InfluxDBとMySQLの2つを仕様ベースで比較・検討した内容をまとめます。

項目	内容
ハードウェア	Raspberry Pi 4 (Model B) + USB SSD（SDカードはブート専用）
OS	Raspberry Pi OS
センサー	温度、湿度、気圧、CO2濃度、風速計
データ送信経路	ESP32 → Wi-Fi or Bluetooth → Raspberry Pi
書き込み頻度	60秒ごと × 5種 ≒ 約7,200 pts / 日
可視化要件	リアルタイム表示＋1年分の時系列分析が可能なこと
拡張性	将来的にセンサー追加・外部連携を視野に設計
電源制約	室内常設／モバイルバッテリー／発電機併用を想定

まだ構成段階なので、InfluxDBとMySQL（MariaDB互換）を中心に、仕様書やベンチマーク、ユーザーコミュニティの情報に基づいて比較を行いました。

データ処理能力が高い（高い書き込みスループット）
公式ドキュメントでは、WAL (Write Ahead Log)+TSM storage engineにより、少量の追記処理でもミリ秒単位／ポイントの高速書き込みが可能とされている。
まとまった書き込みの最適化が得意
一括投入（batch writes）が書き込み最適化の公式推奨手法とされており、1万ポイントをまとめて送っても高速処理が可能。
工夫により書き込みパフォーマンス5倍向上
Compression（gzip）を併用することで、書き込みパフォーマンスが最大5倍改善された。
時系列に特化した操作性
タイムスタンプを軸にしたクエリ構造やリテンションポリシー(保持&削除ルール)による自動集計・管理など、時系列データに特化した設計。

種類の多さ(Cardinality)にはメモリ負荷大
InfluxDBでは、Tagの組み合わせの数を「Cardinality」と呼びます。この数が多くなればなるほどメモリを消費し、パフォーマンスが低下します。
Cardinalityの例
```
temperature,location=tokyo device=sensor1 value=24.0
temperature,location=osaka device=sensor1 value=22.0
temperature,location=tokyo device=sensor2 value=25.0
```
読み込みパフォーマンスは“High Frequency Read”には弱い ?
ユーザーコミュニティでは「書き込みは速いが読み込み（クエリ多発）は遅くなる傾向あり」との報告。

大量の情報とサポート歴があるRDBMS(リレーショナルデータベース)
フルバックアップや、経験則・ノウハウが豊富に存在。
リレーショナルな JOIN や複合クエリに強い
センサーデータ × ユーザーマスタ × 設備マスタを1文で結合できるなど、リレーショナル処理に最適との評価がある。
時系列用途でも使えるが専用DBほど最適化されていない
MariaDB は汎用DBのため時系列特化ではないが、「中小規模の時系列なら問題ない」、ColumnStore エンジン併用の記述も見られる。

短時間に大量のデータを書き込む処理では書き込みパフォーマンスが課題
「1秒で100行以上 INSERT が続くとレスポンスが悪化する」「バルク LOAD 検討が必要」とするコミュニティ意見あり。
時系列データでは大きなテーブルを条件に応じて分割して管理する手法やインデックス設計が必須
正しく設計しないと全件検索になってしまうとの注意が多く、手間がかかる構成要素であるとの指摘あり。

比較項目	InfluxDB（仕様・コミュニティ）	MariaDB（仕様・コミュニティ）
書き込み速度	gzip圧縮併用で高スループット（batch write推奨）	トランザクションあり、高頻度INSERTはレイテンシ増加
バルク対応	標準的に最適化（10k pts/リクエストなど）	LOAD DATA INFILEなど外部ツール必要
メモリ負荷	高カードゥァリティで急増リスクあり	一般的な負荷なら安定運用可能
可視化準備	時系列と統合された retention policy & クエリ構造	汎用SQL、可視化ツールとの連携は工夫が必要

InfluxDBにしようかな～と思っています。理由としては、

ただし、以下のようなケースではMySQLが適していると感じます。