Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

Elastic{ON} 2017 2日目 | Elasticsearch SQLの中身を解剖 #elasticon

Elastic{ON}2017 レポートのまとめはこちら!!

こんにちは、nakaです!

Elastic{ON}も二日目!
さて、今日私から紹介するのは、
「Elasticsearch SQL」のセッション。
f:id:acro-engineer:20170309200348p:plain

昨日のOpening Keynoteで話題となった
Elasticsearch SQLがどうやって作られているのか、
どのような機能をサポートするつもりなのかを紹介してくれました。

現在サポートする機能について

以下がElasticsearch SQLでサポートする機能です。

  • SQL実行はReadのみサポート
  • 単一のIndexおよびTypeへの実行が可能

f:id:acro-engineer:20170309174241p:plain:w500

最初のリリースにより、データ取得に関して、
基本的な機能が入ることになりますね。

後は特徴として

  • 50%はElasticsearchの機能を使って、実現
  • クエリ実行はElasticsearch内部で実施。
  • 直接Elasticsearchクエリを実行するのでフットプリントがない

ということなので、SQL実行をするとしても、
強みである分散処理は最大限生かした構成となりますね。

SQLが実行可能な分散DBとなると、
かなり強力な機能と感じます。

Elasticsearch SQLの中身は?

今日のセッションでは、Costin氏より、
Elasticsearch SQLの中身がどのような作りになっていて、
どのような順番に、どのような処理が行われるかを、
最初から最後まで丁寧に説明してもらいました。

Elasticsearch SQLの中身の透明性を担保するため、
全てを隠さず紹介してくれたと感じました。
まさにOSS文化ですね。

SQL実行の流れ

以下はSQL実行時の大まかな流れです。
f:id:acro-engineer:20170309173248p:plain:w500

パース、アナリシス、プランニング、実行と
DBと同じ流れでElasticsearch SQLも実行されることがわかります。

パースの実行

パーサーでは、以下のようにクエリを分解し、
何が書かれているのかをプログラム側で理解しています。
f:id:acro-engineer:20170309173723p:plain:w500

アナリシスの実行

構文を理解した後は、クエリのチェックおよび、
テーブル名や列名など各種構文の値の解決を行います。
f:id:acro-engineer:20170309175204p:plain:w500

クエリの最適化によるプランニング

クエリの各種値が解決できた後は、プランニングで最適化を行います。
無駄な処理はまとめられます。
f:id:acro-engineer:20170309175538p:plain:w500

クエリの生成

最適化された構文をもとに、Elasticsearchクエリに変換します。
ここから先はElasticsearchにお任せですね。
f:id:acro-engineer:20170309175820p:plain:w500

クエリの実行

Elasticsearchのクエリとして実行します。
Streamで結果の取得が可能だったりと、必要な機能はサポートしています。
f:id:acro-engineer:20170309180213p:plain:w500

JOINについて

現在のところ、JOIN機能も入れる予定とのことでしたが、
JOINはElasticsearchの特性上、
単一インデックスへの対応です。
f:id:acro-engineer:20170309183843p:plain:w500

単一のインデックスでJOIN?
と思うかもしれませんが、ネストしたドキュメントに使うという発想ですね。

例えば、DBから値を移植する場合に、
データを格納したテーブルと、マスタ情報を格納したデータを紐づけ、
紐づいたまま一つのインデックスに入れれば、
JOIN相当の検索を実施することができます。


とはいえ、業務で使うことを考えると、
やはり、複数インデックスに対し、
JOINで結合したいという声が多いです。

この点、Costin氏としては将来、
どうする方針で考えているかが気になります。
明日AMAでもう一度聞こうと思います。

その他

また以下考えるべきポイントや、特徴を説明してもらいました。

analyzedとnot analyzedフィールドの違い

Elasticsearchには文字列フォーマットとして、
analyzed(text型)フィールドと、not analyzed(keyword型)フィールドがあります。

どちらのフォーマットかによって、
内部的に実行されるElasticsearchクエリが変わります。

例えば以下は、SQLで取得するカラムを絞った場合ですが、
analyzedフィールドは、_sourceフィールドに列名を入れ、絞ります。

not analyzedフィールドでは、必要な列名を列挙することで、列を絞ります。
f:id:acro-engineer:20170309180901p:plain:w500

DBにはnot analyzedという考え方がないため、
Elasticsearch SQLを使い場合は、注意ですね。

Elasticsearch SQL特有の構文をサポート

Elasticsearchで強力なAggregationと、スクリプト埋め込みは、
Elasticsearch SQLでも使えるようになります。
f:id:acro-engineer:20170309181526p:plain:w400f:id:acro-engineer:20170309181530p:plain:w400

このようにSQL構文内に埋め込むことができます。

その他サポート機能

Elasticsearch SQL用のCLIが提供となります。
Openning keynoteのデモで紹介していた
コマンドラインツールですね。


またJDBCも使えるようになります。
JDBCは使いたい人が多くいるのではないでしょうか。
これで対応可能なユースケースが増えそうです。


ということで、かなりSQL機能はかっちりと
SQLの作法に従い開発しており、
しっかりと動きそうだと感じました。

どのような構造にしたのかをすべて話すのは、
OSSならではと思います。
このOpenさが信頼につながるのではないでしょうか?

セッション後はパーティ

今日はセッションが終わった後、
Elastic{ON}のダンスパーティ!

会場はなんと、博物館を貸し切っていました。
このような会場は初めてです。
こんな感じでダンスしてました。

Post from RICOH THETA. - Spherical Image - RICOH THETA

最後に

明日はついにElastic{ON}最終日
最後まで走り切りたいと思います。

Elastic{ON}2017 レポートのまとめはこちら!!

Acroquest Technologyでは、キャリア採用を行っています。

  • ビッグデータHadoop/Spark、NoSQL)、データ分析(Elasticsearch、Python関連)、Web開発(SpringCloud/SpringBoot、AngularJS)といった最新のOSSを利用する開発プロジェクトに関わりたい。
  • マイクロサービスDevOpsなどの技術を使ったり、データ分析機械学習などのスキルを活かしたい。
  • 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

Elasticsearchを仕事で使いこみたいデータ分析エンジニア募集中! - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com