はじめに

Node-REDには数多くのDBノードが存在するため、DBからデータを取得したりデータ処理の結果をDBに保存したりすることが可能です。ただし、DBノードの扱い方がバラバラであるため、本記事でNode-REDで使えるデータベースと操作の違いを整理します。
※本記事は、2015年12月18日時点のNode-REDで検証をしています。日々アップデートされておりますので、情報にGAPが生じる可能性がございます。

検証環境

・MacBook Pro OS X El Capitan(ver:10.11.2)
・Bluemix Node-RED Starter

2015年12月時点で利用可能なDBノードを検索する

まずはNode-RED Libraryにアクセスし、利用可能なDBノードを確認してみましょう。
「DB」で検索をかけてみました。

なんかいっぱいありますね。

DBとは関係ないものも混ざっているのでそちらは確認対象から除外します。（RBE、LedBorg、MODBUS）

「DB」という検索キーワードから漏れたものもあるので、「SQL」でも検索をかけてやります。
これでもCloudantは引っかからなかったので手動で見つけてやります。
Node-RED Libraryも数が増えてきたので、タグを付けるなど検索キーワードを考慮した工夫をするべきですね。

ということで、下記ノードの仕様を確認していきます。思ったより数が多いですね。
　
* Cloudant（最終更新日：7ヶ月前）
* mongodb1（最終更新日：8日前）
* mongodb2（最終更新日：11日前）
* Influxdb（最終更新日：3週間前）
* LevelDB（最終更新日：7ヶ月前）
* LevelDB-TTL（最終更新日：2ヶ月前）
* DynamoDB（最終更新日：10ヶ月前）
* MySQL（最終更新日：1ヶ月前）
* SQLite（最終更新日：7ヶ月前）
* PostgreSQL（最終更新日：8ヶ月前）
* DB2/dashDB（最終更新日：1ヶ月前）
* Oracledb（最終更新日：1日前）
* ODBC（最終更新日：10ヶ月前）

※更新頻度の違いも重要な要素です。

利用可能なDBノードを全部インストール

package.jsonにインポートしたいDBノードを記述し、OSS版ならnpm install、Bluemixならcf pushもしくはgit pushしてやります。
　→OracleDBとODBCはMac X/Bluemix共にエラーになりました。
　　　→ODBCはunixODBCをサポートするドライバが必要とのこと。Bluemix版では使えそうにないですね。
　　　→OracleDBはOracle Instant Clientを事前にインストールしておけとのこと。こちらもBluemix版では使えそうにないですね。
　　　　※今回は動作確認の対象外とします。

OSS版でもBluemix版でも動作するpackage.jsonは下記の通りです。
2015年12/18時点の最新バージョンを利用しています。今後の各ノードの更新で仕様変更になる可能性がありますのでご注意ください。

package.json

{
    "dependencies": {
        "node-red-node-cf-cloudant":"0.2.14",
        "node-red-node-mongodb":"0.0.4",
        "node-red-contrib-mongodb2":"0.2.2",
        "node-red-contrib-influxdb":"0.0.4",
        "node-red-node-leveldb":"0.0.5",
        "node-red-contrib-leveldb-ttl":"0.0.3",
        "node-red-node-ddb":"0.1.0",
        "node-red-node-mysql":"0.0.7",
        "node-red-node-sqlite":"0.0.7",
        "node-red-contrib-postgres":"0.4.0",
        "node-red-nodes-cf-sqldb-dashdb":"0.2.11"
    },
    "engines": {
        "node": "0.10.x"
    }
}

Node-RED上に配置してみる

Node-REDにアクセスし、追加したDBノードを並べてみます。

ノードの種類で仕様に違いがあることが想像できるかと思います。

DBノードの仕様はバラバラで、DBノードごとに使い方を把握する必要がある
- Input専用
- Input/Output兼用 (mongodb、LevelDB、MySQL、SQLite、PostgreSQL)
- Output専用
データロード用のノードが存在せず、保存しかできないノードがある
- DynamoDB 　→DynamoDBのLibraryを見てみると開発途中であり、10か月以上更新がないことを確認できる。
  　→非常に不便であるためDynamoDBをNode-REDで利用するのは現時点ではお勧めしません。　（自身でノードをカスタムしてPull Requestしてくださるとありがたいですが…！）

各DBノードの認証方法の違い

Bluemix版はBluemixで使えるDBサービスをバインドすることで、認証を省略することができます。
OSS版やBluemixにないDBを使う場合は認証情報を手動入力する必要があります。
各DBノードの認証方法を確認してみました

DB名	Bluemix認証可否	手動認証可否	備考
Cloudant	○	○
mongodb1	○	○
mongodb2	○	○
Influxdb	×	○
LevelDB	×	○
LevelDB-TTL	×	○
DynamoDB	×	○
MySQL	×	○
SQLite	×	○
PostgreSQL	×	○
DB2	○	×	OSS版利用不可
dashDB	○	×	OSS版利用不可

DB2とdashDBは手動で認証できる設定項目が存在せず、
Bluemix側で事前にサービスをバインドさせておく必要があるようです。
そのため、OSS版でDBノードの追加はできても、DB2やdashDBを利用することはできません。
（何か対策を知っている方はご教示ください。）

クエリ発行方法の違い

クエリ選択型　【Cloudant、mongodb1、mongodb2、LevelDB】ノードの仕様で事前に使用可能なクエリが決められているタイプ。※Cloudant、mongodb2はmsg入力も可能クエリの書き方を知らなくても使うことができるため、初心者向けです。 LevelDBはinput側に繋ぐと「get」、output側と繋ぐと「save」する動きをします。

Cloudantの例：CloudantのOutput側はInsertかRemoveの2つを選択できる

　
2. クエリ記述型（ノード内から入力）【DB2、dashDB】
ノードの編集画面にクエリ用の入力フォームがあり、クエリをノードそのものに記述するタイプ
ノードを見れば発行しているクエリ内容が確認できる可読性にメリットあり。
入力フォームを空白のままにしておくと、msg.payloadをクエリ文として入力させることも可能。

　
3. クエリ記述型（msgから入力）【Cloudant、mongodb2、Influxdb、MySQL、SQLite、PostgreSQL、DB2、dashDB】
ほとんどのDBノードはmsgにクエリ文を記述し、DBノードに渡すことで処理を実行できるようになっています。
ただし、クエリ文を記述する箇所が異なるので注意が必要です。

MySQLの例：functionノードを追加し、msg.topicにクエリ文を代入しておく。
　
その他：mongodb1とmongodb2の違い mongodb1は選択可能なクエリが3つ程度なのに対して、 mongodb2は選択可能なクエリが50程度選択可能で、別ノードから直接入力も可能であるため、選択型による利便性と記述型の自由度の高さの両メリットを兼ね備えている便利なノードです。 mongoDBを扱うならmongodb2を使う方が良さそうです。
　
その他：DynamoDB
仕様の説明がほとんどなく、パッと見では扱い方がよく分かりませんでした。
現時点では少し使いにくいDBノードです。
　
クエリ発行の違いまとめ

DB名	クエリ選択型	クエリ記述型(ノード内)	クエリ記述型(msg)	msg記述先
Cloudant	○	×	○	msg.payload
mongodb1	○	×	×
mongodb2	◎	×	○	msg.operation
Influxdb	×	×	○	msg.query
LevelDB	○	×	×
LevelDB-TTL	○	×	×
DynamoDB	×	×	？
MySQL	×	×	○	msg.topic
SQLite	×	×	○	msg.topic
PostgreSQL	×	×	○	msg.payload
DB2	×	○	○	msg.payload
dashDB	×	○	○	msg.payload

まとめ

今回、Node-REDで使えるDBノードについて調べてみました。
現在もノードの開発が進んでいるものもあれば、開発が止まっているものもあり、
Libraryにノードがあるからと安易に使えるものと判断しないほうが良いケースもあります。

そんな中でも、mongodb2やMySQLなどは非常に使いやすいと感じました。
MongoDBはmongoLabやCompose-mongo、
MySQLはAmazon RDSやAurora、MariaDBなども利用可能であるため、
必要な要件に応じてDBaaSの選択の幅があるのも魅力的です。

Amazon RedshiftについてはPosgreSQL互換ではありますが、
列指向型DBであるため、Node-REDからのデータ投入の方法には工夫する必要があります。
いずれ、パフォーマンス面も考慮したDBノード活用方法についても検証してみたいですね。

LevelDBやInfluxDBは普段あまり使うことはありませんが、
データ処理の軽量性と高速性にとても魅力があるので、Node-REDと相性の良い、
IoT系のストリーミング処理系の大量通信を扱うのであれば、
他のDBよりもメリットがありそうなので、Node-REDの中に組み込んでみることを検討してみたいと思います。

Node-REDで扱えるDBノード総まとめ（MySQL / PostgreSQL / MongoDB / DB2 / Cloudant / dashDB / LevelDB / InfluxDB / DynamoDB /RedShift / Aurora / MariaDB）