LinuxMintでInfluxDBのネット情報を調べてPostgreSQLと比較しました

1.概要

時系列のdatabaseであるInfluxDBに関して少し調べてみました。時系列データの処理性能に優れたdatabaseとのことです。まず、ネット上の評価から調べてみることにしました。更に実機確認も行いました。その内容を記述します。

2.詳細

(1)ネット上の評価

参考資料によるとRDBがTableとRowとColumnを利用するのに対して、InfluxDBはmeasurementとpointとTimeとTagとFieldを利用します。少し複雑な感じです。pointに含まれる要素がTime以外は必須でない点が特徴のようです。

RDBはCRUD(Create,Read,Update,Delete)の操作ができますが、InfluxDBはCR(Create,Read)でUD(Update,Delete)は制限された機能しか利用できません。

RDBの操作はSQLですが、InfluxDBの操作はInfluxQLとFluxがあり、InfluxQLはSQLに似ています。私が調べた範囲ではInfluxDB v1はInfluxQL、InfluxDB v2はFluxを利用するのが基本のようです。

DockerHubのInfluxDBを調べるとv1系の方が利用されている気がします。v2系もリビジョンは上がっていますが、主流化になっていな気がします。v3はenterpriseと記述されているので有償かもしれません。拡張性のあるクラスタ構成は有償版でサポートされるとの記載もありました。

気になった点はInfluxDBには上限が設定されており、系列の総数がデフォルトで100万に制限されているようです。 この上限を増やすことはできますが、系列数がこの上限を超えるとのパフォーマンスが低下するとのことです。時系列データは秒単位で24時間処理すると3600*24=86400件、100万件に達するには1000000/86400=11.57日となり、余りにも短い気がします。

InfluxDBとPostgreSQLの性能評価の参考資料を参照した範囲では、InfluxDBが汎用的な処理に優れている気はしません。時系列データを活かした処理に利用すると性能を発揮する気がしました。

(2) influxDBとPostgreSQLのcsvからのinsert性能試験をしました

前回influxdbの概要をネットで調べたので、実際にpostgresqlと性能評価をしました。特に気になった点は100万件の壁があるか否かです。私が評価した範囲では最良の条件であるdate time以外のtag(２次キー)項目がない場合でもpostgresqlに及びません。また、100万件の壁はあるようですが、postgresqlとの性能差はもっと基本的な問題のような気がします。その内容を記述します。

試験環境はi3-7100, Memory 16GB, SSD 500GB, ubuntu-22.04です。
influxdb(v2),postgresql(v15)をdockerコンテナで動作して試験をしました。
データは下記５項目です。
データの例
date       unixtime   number  real      real   
2025-10-12,1762253561,2000000,0.0239312,0.956495
データ量は10,50,100,200万件のデータで処理をしました。
データのinsert試験のみ実施、方式はcsvからのimportです。

(a) influxdbでunixtimeだけがキーでtag項目なし
10万件　　　　　2秒
50万件　　　　　14秒
100万件　　　　18秒
200万件　　　　25秒

(b) influxdbとして一番厳しいnumber項目をtagに指定
10万件　　　　　6秒
50万件　　　　　25秒
100万件　　　　50秒
200万件　　　　120秒

(c) 比較としてpostgresqlでprimary keyをunixtime、numberをindexに指定
この条件は上記(2)と同じです。
10万件　　　　　0秒(1秒以下)
200万件　　　　7秒

個人的な主観ですが、時間を積み重ねたVersion差が性能差になっている気がします。
insert性能では、influxdb v2ではpostgresql v15に歯が立ちません。

(3) influxDBの全件読込の性能試験をしました

前回、influxdbとpostgresqlのcsvからのinsert性能比較をしたので、今回はselectで全件を読む性能比較をしてみました。select * from tableの実行時間を比較すると良いと考えたのですが、influxdbで実行するのが案外難しい。その内容を記述します。

influxdb v2を利用しています。csvからのinsertはinfluxコマンドを利用しました。そこで同じようにinfluxコマンドを利用した登録データ全件の参照処理が案外難しい。登録したcsvと同じ出力を得ることが難しいとは思っていなかったのでショックでした。select count(*) from tableのようにデータ件数をカウントすることも難しい。GoogleAIに尋ねて色々試したのですが、Postgresqlと比較する良い手段が見つからなかったので、influx v1 shellを利用することにしました。（※ GoogleAIの参考回答例参照）

influxdb v2でinflux v1 shellを利用するとselect * from tableが利用できます。しかし、対話モードでしか動作しないために、shell化して実行時間計測に課題がありました。仕方なく、時間計測処理を別途作成して、手作業で起動停止をすることにしました。この辺もGoogleAIに尋ねたのですが、Docker Containerを利用していることで制限があり、解決できませんでした。

データは前回と同じ形式で新しく作成しました。
データ項目は下記５項目で、データ件数は200万件です。
データの例
date       unixtime   number  real      real   
2025-10-12,1762253561,2000000,0.0239312,0.956495

(a) influxdb Tagなし
Insert処理　　35秒
Select処理　　25秒

(b) influxdb Tagあり(条件は前回と同じ)
Insert処理　　100秒
Select処理　　34秒

実行したマシンは同じi3-7100環境です。処理時間に前回と差異があります。実行時のメモリ利用状態が影響しそうですが、複数回実行していません。今回は誤差と考えて傾向のみ見ます。結果から100万件の壁はinsertの時に影響が大きく出るようです。

(c) postgresql ２次キーあり　上記(2)と同一条件
Insert処理　　7秒
Select処理　　7秒

入力したデータから希望する出力結果を得られないのでは、databaseと言えない気もしますが、RDBでは超えられない規模の限界を超える手段を提供しているのだと思います。大量のデータ処理が必要な場所はあり、RDBで実現できないのであれば、他の手段を探すしかなく、そのために犠牲となる部分があっても仕方ない気もします。

Docker Containerを利用してPC１台で試験する範囲ではPostgreSQLの圧勝です。InfluxDBはクラスタ機能を利用して、列単位に実行マシンを分けることができるようですが、PostgreSQLにそのような機能は標準的手段では見当たりません。クラスタに分割しないと処理できないデータ規模に達するとinfluxdbの価値が発揮されるような気はします。

3.所見

次の世代の時系列データベースををネットで検索して調べました。良くわかっていませんが、新しいものなので何かと比較しながら実態を掴む必要があると考えて、PostgreSQLと比較してみました。個人的な感触ですが、単体PC上の性能ではPostgreSQLが上だと思います。

参考

[本ブログ内参照]
・Ubuntu/LinuxMintのDocker環境でKey Value Databaseを調べました
・ARM64のubuntu-arm64をKVMで動作にチャレンジ

コメント

コメントを投稿

過去30日間に良く読まれた記事

miniPCのBMAXでWindows11のsecure boot設定漏れでトラブル発生

miniPC（BMAX）でWindows 11を再導入する際の注意点 今回のトラブルから得られた、miniPC初期化・再導入時に失敗しないための重要なポイントを整理しました。 1. 発生した問題とエラーの原因 自分で作成した「Windows 11のUSBブートメディア」から新規導入を試みた際、ライセンス認証やセットアップの段階でエラーが発生しました。このトラブルの原因は、以下の仕様ミスマッチによるものです。 インストールメディアの不適合： Windows 11の要求仕様を満たさない環境で作成されたメディアだった可能性 secure boot（セキュアブート）の設定漏れ： BIOS側でセキュアブートが「無効（disable）」のまま新規導入を進めてしまったことによる、BitLocker暗号化の不整合 2. トラブルを未然に防ぐ「失敗しない再導入の3ステップ」 miniPCのクリーンインストールを確実に成功させるためには、以下の手順を順番に確認しながら進める必要があります。 ステップ1：インストールUSBは正規の要件を満たすPCで作成する Microsoftの公式サイトから、必ずWindows 11の動作要件を完全に満たしているPC上でインストールメディア（USB）を再作成します。 ステップ2：導入前にBIOSで「secure boot」を「enable」に設定する OSをインストールする前に必ずBIOS（UEFI）画面を開き、Security項目にある「secure boot」が「enable（有効）」になっていることをmsinfo32等で確認してからインストールを開始します。 ステップ3：BitLockerの「48桁の回復キー」を事前に必ずバックアップする secure bootを設定すると、Windows 11では自動的にドライブが暗号化されます。万が一の障害復旧やWindows Update時のエラーに備え、Microsoftアカウント等に紐付いた「48桁の回復キー」を必ず紙に控えるか、別デバイスに保存してください。 1.概要 始まりは、参考資料の「6月からパソコンが動かなくなる？」です。miniPCのsecure boot設定をmsinfo32で確...
続きを読む

LinuxMint/ubuntuにWine 11導入を試しました ( LinuxMint 21.3 / 22.3 ubuntu 22.04 / 26.04 Wine 11.0 / 11.6 / 11.8 / 11.13 )

Wine環境でWindowsアプリが動作しない場合の考察と対策 最新のWine 11を利用しても、一部のWindowsアプリケーション（Acrobat Reader等）のインストールや起動が失敗するケースがあります。技術的な背景と、現場で役立つ代替アプローチを整理しました。 1. 起動・インストールが失敗する主な技術的理由 厳格なレジストリ要求： 大手メーカー製のインストーラーは、Windows固有の複雑なレジストリ構成を要求するため、Wineの標準レジストリでは処理が途中で強制終了します。 .NET Frameworkや各種ランタイムの未導入： アプリが依存している特定のランタイムがWine環境側に不足しているケースです。 セキュリティ認証・暗号化： 最新のアプリに組み込まれているデジタル著作権管理（DRM）や通信暗号化機能が、WineのAPI互換性を超えている場合があります。 2. トラブルを解決するための3つのアプローチ Wine上でWindowsアプリを安定して動かす、または目的を達成するためには、以下の対策が有効です。 対策1：winetricks を活用して必要なコンポーネントを補う 今回の日本語化（cjkfonts）と同様に、 winetricks dotnet48 や winetricks vcrun2015 などのコマンドを用いて、アプリが必要とするランタイムを個別にWine環境へ追加導入します。 対策2：単体で動作する「ポータブル版（.exe）」を選ぶ インストーラー形式（.msi や setup.exe）ではなく、フォルダを展開するだけで単体動作するポータブル版（HDBENCHなど）は、レジストリ依存度が極めて低いためWine環境と非常に相性が良く、高確率で動作します。 対策3：Linuxネイティブの代替アプリを検討する Wineに依存せず、Linux標準のリポジトリから導入できる互換アプリ（例：Acrobatの代わりに「Okular」や「Evince」、MS Officeの代わりに「LibreOffice」）を利用する方が、システムの安定性と処理速度の面で圧倒的に有利です。  1.概要 Wine 11.0がリリースされました。...
続きを読む

Windows95/98のPCゲームをUbuntu/LinuxMintの最新PCで楽しむ方法 ( KVM / Wine / dosbox-x / midi )

1.概要 Ubuntults 24.04のリポジトリを利用するLinuxMint 22.3で、32bitのアプリケーションを楽しむことができるのか整理をしました。今回、仮想環境のKVMでの試験を実施して、KVM,Wine,Dosbox-xの３種類を実施した範囲で、遜色なく利用できるのはDosbox-xだけでした。KVMやWineではサウンド処理関連の互換性がなくなったような気がします。この内容に関して記述します。 注意事項 Windowsの利用にあたっては、Microsoftが定める使用許諾契約（EULA）を遵守する必要があります。ライセンス違反（不正なプロダクトキーの利用、規約外の商用利用など）は違法行為となるため、必ず正規のライセンスを取得・確認した上で操作を行ってください。 2.詳細 (1)KVM環境 KVM環境はRegacyBIOS互換のCSMで試しました。KVM上でWindows98SEは起動します。デバイスマネージャを参照した範囲ではエラーはありませんが、サウンドが想定通りに再生されない点、ディスプレイ表示設定が思うようにならない点がありました。どちらもドライバの問題と思います。構築した環境はUbuntu 22.04まで試験をしていた環境です。仮想ソフト（KVM, VMware, Virtualboxなど）は新しい環境への対応を進める中で古い環境の互換性は保たれなくなっていると感じています。 (a) KVMにWindows98seを導入 Windows98の仮想マシンを作成（サポート期間が切れたOSを選択） Memory=128MB、CPU=1、Disk=0.5GBを選択 インストールの前に設定をカスタマイズするを選択 ブートオプション：IDE CD-ROMにチェック CD-ROM bootのため、IDE ディスクとIDE CR-ROMの順番を入替える サウンド ich6：sb16を上書設定 ビデオ QXL：cirrusを上書設定 CD-ROM boot後、CD-ROMサポート付きmsdosを利用して、fdiskでCドライブを作成 再度、上記構成で再起動をして、d:\win98にてformat c:を実行してfat16で初期化 d:\win98のsetupを実行して導入 (2)Wine環境 Wine 11.8で試験をしました。 ディスプレイ表示は普通に使...
続きを読む