「RDBとNoSQLの一般的な違いについて(前回参照)」に記載した観点に沿って比較を行います。

2. 検索性/操作性

① 検索性

検索性の観点では、NoSQLはRDBと比較し、便利な検索機能が少ない事があげられます。
例えば、PostgreSQLでは図1に記載のような結合処理ができますが、InfluxDBでは一部制約が発生します。

　　　　　　　　　　　　　　　　　　　　　　　図1 SQLで実行可能な結合の種類

具体的なInfluxDBの結合処理の制約には、以下のようなものがあります。

制約②については少しわかりづらいので、実際にFluxを使った結合をいくつか見ていましょう。

新たに例としてその時間帯のネットワーク機器のリソース情報(CPU使用率、メモリ使用率、ストレージ使用率)を
管理する「resourcemsr」が追加されたとしましょう。
「特定の時間のパケットの遅延時間が長かった場合にその時間のネットワーク機器のリソース情報を確認する」
といった使い方が想定されます。
このような場合は2つのテーブル(measurement)に必要なデータが跨っているので結合が必要となります。
　　　　　　　　　　　　　　　　　　　図2 追加measurementとユースケース例のイメージ

まずは簡単な例として「特定の時間を指定し、それぞれ1field情報を得て結合する」ものがどのように結合されるか確認します。

結果は図3の通り、結合条件に一致したものだけが表示されます。
これはSQLで言う「内部結合」の動きとなります。

　　　　　　　　　　　　　　　　　　　　　　　図3 Fluxの実行例1

では結合対象となるレコード(ポイント)とカラムが複数ある場合はどのようになるのでしょうか。

結果は図4のようにデータが取得されます。
時間データごとにカラム(列)の組み合わせを全パターン取得しており、交差結合に近い動きとなります。

　　　　　　　　　　　　　　　　　　　　　　　図4 Fluxの実行例2

つまり、結合するレコード自体は条件に一致する内部結合のような動きをしつつ、
列に関しては交差結合のような動きになります。
このように同じ「結合」といってもRDBとは異なった動きをする為、注意が必要です。

なお図3・図4ともに結合条件となる時間と取得するfiledしか記載していない事を注意ください。
（実際の取得結果はそれ以外の情報も含んでいます。）

なお、実行例は長くなる為、記載を省きますが、細部を確認されたい方はこちらから参照ください。
実行例のFluxのコードは単ラインを例に記載しています。
また実行例はあくまで参考ですので、実際に使用する際にはユースケースに沿った確認作業を行う事を推奨します。

② 操作性

PostgreSQLと比較し、InfluxDBに制限が付くのはデータの取得(検索)だけではありません。
以下で何点かご紹介します。

制約①と③は何が困るのかわかりづらい為、以下で具体的な注意点も何点か挙げます。

一方でPostgreSQLにはなく、InfluxDB独自の機能も存在します。
例えば今回の例では「7日たったデータは削除する」という要件がありましたが、この点はInfluxDBに最適な機能があります。
それが「リテンションポリシー」と呼ばれる機能で、データ保持期間を設定し、期限が切れたものは定期的に
削除することができます。

ちなみにPostgreSQLでは上記要件をどのように実現するでしょうか。
データの削除手法としてはInfluxDBと同様に1テーブルで集中管理し、日時の範囲指定で定期的に該当レコードを
削除する、という手もあるでしょうし、メンテナンスや検索性の観点からテーブルをレンジパーティションで
日ごとに分けて日ごとテーブルごとにdropするという案もあるでしょう。

ただし、「定期的に削除」という機能はPostgreSQLには存在しない為、スケジューラ(cron等)による定期処理を
別途設定する必要があります。

その為、InfluxDBでは自身のみで完結・対応できていたものが、PostgreSQLの場合はDBMS以外の手段を
組み合わせて対応する必要があります。

3. 一貫性

RDBはACID特性を満たすため、トランザクション機能がサポートされており、PostgreSQLも例外ではありません。
InfluxDBではこのトランザクションが未サポートとなっています。

その為、例えば一部データを変えた際に別のデータも変えないといけない、という処理があった場合に
片側だけ成功し、片側は失敗となるケース（＝データ矛盾が発生する可能性）があります。

一例として複数データ投入で見てみましょう。
csvファイルからデータを投入する方法として、それぞれ以下のような手法があります。

なお、copyはPostgreSQLに実装された機能であるのに対し、ExportCsvToInfluxはサードパーティツールである点は
注意が必要ですが、InfluxDBはトランザクションがない為、途中で失敗しても巻き戻す方法がない為に
このような動きとなる、といえます。

また、InfluxDBではPostgreSQLと同様にログ先行書き込み(WAL)がある為、ACID特性のD(永続性)は満たされています。

実際にそれぞれの動きを見てみましょう。

[PostgreSQL]

上記の実行例のように、PostgreSQLにおいてはトランザクションでcopyによるデータ投入をしており、
失敗した場合は途中まで投入した状態をそのままとせずトランザクション機能を用いて
copy実行前の状態(0レコード)に戻しているとわかります。

[InfluxDB]

処理が途中で中断しているにもかかわらず、約1万程度のデータが登録されており、
中途半端な状態になっている事、また処理が失敗しても投入前に戻っていない事がわかります。

「検索性/操作性」の欄でも触れたようにタイムスタンプとタグが同じであればデータが更新されることから
csvインポートは途中で失敗した場合に再度実行する事で漏れなく登録する事はできます。

その為、この例自体はあまり問題にならないかもしれませんが、最初にも触れたような
「特定のデータを更新時に別の箇所も更新する」といった処理を実現しようとするとデータ矛盾に
つながる可能性があります。

4. 分散/拡張性

DBの性能を向上させたい場合、PostgreSQLではどのような手法がとれるでしょうか。

クエリの実行計画を確認し、パラメータチューニングを行う、CPUやメモリ数等を増加させるスケールアップを行う、
テーブル空間(table space)機能で実体ファイルの書き込み先を分ける等、様々な案が考えられます。

また、PostgreSQLの場合はレプリケーション機能で冗長化が可能、かつ
（ストリーミングレプリケーション・ロジカルレプリケーションどちらの方法でも）スタンバイ側で参照が可能な為、
レプリケーション機能を活用する事で書き込み処理と参照処理を負荷分散させるといった運用も可能となります。
　　　　　　　　　　　　　　　　　　　　図5 レプリケーションを活用した負荷分散

一方で、処理マシンの数を増やす事で性能向上を行うスケールアウトはPostgreSQL自体に機能はなく、
追加でシャーディングソフトを入れる等の対応が必要となります。
また、実現方法にもよりますが、例えば一部のクエリが実現できないといった機能的な制限が付く可能性があります。

　　　　　　　　　　　　　　　　　　　図6 シャーディングとスケールアウトのイメージ例

InfluxDBの場合はスケールアウト(クラスタリング機能)をサポートしており、追加ソフト等が不要で、
基本的にはスケールアウト後の機能的な制限を気にすることなく、スケールアウトを実現する事ができます。

ただし、クラスタリング機能は商用版のみサポートしており、OSS版では使用できません。
同様にレプリケーション機能もクラスタリング機能を使う為、商用版のみとなります。

商用版を使用すれば追加ソフト等不要でスケールアウトが可能になる為、InfluxDBは分散/柔軟性が高いといえます。

さて、これまで一般的にRDBとNoSQLの違いとして挙げられている事を観点に、PostgreSQLとInfluxDBの比較を行ってきました。
まとめると以下のようになるかと思います。

上記結果はPostgreSQLとInfluxDBの比較結果でした。
次はこの結果をもとにもう一段、視野を上げてRDBとNoSQLの関係で言えそうな事を以下にまとめます。

参考までに弊社で例に近しいシステムを開発した際には検討の結果、RDBを使用しました。
理由は様々ですが、主な理由として高度な検索が必要であった事があげられます。
また、NoSQLの活用事例でいえば応答速度の求められる加入者DBの構築に用いた例等があります。

満たしたい要件や重視するポイントによって使用する製品を選択する事が重要です。

「RDBとNoSQLの一般的な違いについて」の欄(前編参照)にて「RDBとNoSQLは完全に代替されるものではない」と記載しました。
最後に組み合わせて使うケースの例をご紹介します。

「比較結果からいえる事」で、NoSQLは書き込み速度がRDBより早いという点を上げました。
例えば「高度な検索を行いたいが、書き込みが多く、処理が追いつかない」という場合には
以下のような構成が取りうると考えます。

　　　　　　　　　　　　　　　　　　　　　　図7 NoSQLとRDBの組み合わせ構成例

このようにお互いの長所を組み合わせて、短所を補う形で構成する、という視点も重要です。