本日私たちは InfluxDB のクエリー言語であるIFQL 初期のアルファ版をリリースします。これはInfluxDB 1.4 と共にすぐに利用できる全く新しい言語および実行エンジンです。これは個別のスタンドアロンのバイナリーとして実装されており、InfluxDB と並行して動作します。これは InfluxDB API において、バージョン 0.9 が２年以上前にリリースされて以来の最大の進歩を示しています。しかし、当時のリリースと異なり、これは最新の InfluxDB と互換性があります。
言語としては、IFQL は JavaScript とよく似ています。これは、jQuery や D3 のコードに見られるような、相互に連結された一連の関数から成ります。こちらがクエリーの例です。
select(db:"foo")
.where(exp:{"_measurement"=="cpu" AND
"_field"=="usage_system" AND
"service"=="app-server"})
.range(start:-12h)
.window(every:10m)
.max()
上記クエリーは下記の InfluxQL クエリーと同じです。
SELECT max(usage_system)
FROM "foo".."cpu"
WHERE "service" = 'app-server'
AND time > now() - 12h
GROUP BY time(10m), *
IFQL における私たちの目標は、時系列データと共により自然に利用できる言語を作ることでした。私たちはSQLよりも関数型のパラダイムの方が、あなた方がやりたい事とより密接にマッチしていると感じました。私たちは Python の Pandas や R の Tidyverse プロジェクトからインスピレーションを受けました。データフレームは関数から関数へと受け渡され、それぞれの関数はそれに対してなんらかの操作を行います。もちろん、基礎となる実装の詳細は異なりますが、ユーザーは概念的にそのように考える事ができます。
関数は名前付きパラメータを持っています。これにより関数は壊れにくくなり、コードは使いやすくなります。位置指定パラメータでは、それぞれの引数が何かを調べるために関数の定義を調べなければなりません。また、名前付きパラメータでは、既存のクライアントコードを破壊する事なく、将来的に関数のパラメータを追加できます。
Where 関数には、述部を指定するための特別な式言語があります。これは私たちが純粋な関数型アプローチを取らなかった一つの箇所でした。その代わりに、私たちはこの SQL の where 句のように見える述語言語を選択しました。クライアントライブラリの作者や開発者向けに、私たちはこの述部を JSON オブジェクトとして指定する機能を追加する予定です。この特殊言語によりタイプしたり読んだりするのが容易になります。
目標は最も簡潔な言語を作ることではありませんでした。確かに、幾つかのクエリーは InfluxQL や PromQL等より冗長になるでしょう。私たちの目標は可読性、柔軟性、拡張性のための設計をすることでした。新しい機能を、言語自体のセマンティクスを変更することなく、導入することができます。
IFQL では、クエリーエンジンはストレージレイヤーから切り離されます。私たちの目標は新たなクエリープロセッサが任意台数の InluxDB ノードからデータを取得し、オンザフライで動作可能にすることでした。これはワークロードの分離と、データベースの外部で動作可能なデータサイエンスタスクのための今後の開発をも広げるものです。
InfluxQL で実行できず、現在の IFQL で実行できるクエリーがあります。例えば、HAVING クエリーです:
select(db:"foo")
.where(exp:{"_measurement"=="foo"})
.range(start:-12h)
.window(every:10m)
.sum()
.where(exp:{$ > 100}) // this is the having
または、measurement をまたがった計算:
// math across measurements, or dbs
var a = select(db:"foo").where(exp:{"_measurement"=="foo"}).last()
var b = select(db:"foo").where(exp:{"_measurement"=="bar"}).last()
b.join(on:[“host"], exp: {$ + a})
IFQL では、全てがタグのキー/バリューペアで表されます。そのため、 measurement と field名に特別な _measurement と _field キーでアクセスできます。こうした構造は Prometheus の中でも見られるものです。
この例は、IFQL が割り当て可能な変数を持っていることも示しています。これはKapacitor で利用可能な機能に似ています。
私たちが IFQL で目指したのは、データベースや実行中のプロセスに対して対話的にクエリーを実行しているか、Kapacitor で処理や監視、アラートのタスクを実行しているかにかかわらず、それをプラットフォームをまたがって利用できる一つの言語となることです。
IFQL の設計上のもう一つの目標は、クエリー言語を実行エンジンから切り離すことでした。IFQL は解析されると、JSON で表される DAG に構造化されます。私たちはIFQL のエンジン上で動作する InfluxQL、Tickscript、そして（おそらく）PromQL のパーサーを作るつもりです。これは新しいエンジンがSQLスタイルのクエリーや新しい IFQL 言語で動作することを意味しており、IFQL がリリース可能になった時、新しい機能の大部分が搭載される場所となります。
私たちは現在プロジェクトをオープンソースプロジェクトとしており、Docker イメージ、deb、rpm のパッケージの初期ビルドを出しています。コードは Github の IFQL リポジトリにあります。それは AGPL V3 ライセンスまたは私たちの商用ライセンスの下でライセンスされています。私たちはこれを MongoDB がAGPL ライセンスを扱うのと全く同様に扱います。私たちは新しいプロジェクトやスタートアップ企業がソフトウェアを無料で利用可能にしたいと思いますが、私たち自身がそれをマネージドホスティングサービスで収益化できるようにもしています。基本的に、あなた方がユーザ向けにサービスとしてそれをホスティングしていなければ、それは無料ですが、ホスティングプロバイダーのようなサービスとしてホスティングすることを計画している場合、ホスティングプラットフォームのコードをオープンソース化しないのであれば、商用ライセンスが必要です。私たちはオープンソースインフラストラクチャの場で起こっていることを見ているため、このようにしました。つまり、デュアルライセンスモデル: 無料のオープンソースユーザのための AGPL と、それを必要とするユーザのための商用ライセンスです。
今後数ヶ月にわたり、私たちは IFQL のクエリービルダーを Chronograf に加えていきます。私たちは継続して定期的に IFQL に機能を追加し、リリースします。
私たちはコミュニティからのフィードバックを得て、APIに繰り返し適用したいと思います。私たちの目標は、来年のはじめにこれを止めて、実際のプロダクション対応のリリースに移行できるようにすることです。言語に関数するより詳細については、 IFQL の仕様 の初期の記事を読むことが出来ます。 今回のリリースは決して終わりではなく、私たちは毎日追加開発をしています。私たちはどんなクエリー機能を追加する必要があるかここで 追跡しています。
差し当たっては、IFQL のリポジトリのセットアップの進め方の説明をご覧ください。
