astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

PostgreSQL の バグ修正状況を調べてみた。

はじめに

初めてこちらのblogに登場いたします。データエンジニアのt-sugai です。
今年の1月頃からアスタミューゼにJOINしています。
前職はJavaをメインとしたアプリケーションエンジニア……だったと思うのですが、エンジニアはエンジニアでいっしょくたの組織でした。そして最近は運用やDBAのような仕事を任されることが多かったこともあり、アスタミューゼではデータエンジニアとして働いています。

今日はデータエンジニアらしくデータベースのお話をしようと思います。

アスタミューゼで利用されているPostgreSQL

f:id:astamuse:20190724095444j:plain

国内外の特許の情報をはじめ、様々な技術情報を持っているアスタミューゼですが、RDBMSとしては主としてPostgreSQLを利用しています。 (もちろん、RDB以外のDBMSもデータの量や特性、利用目的に応じていろいろ使っているのですが、今回はRDBのお話です)
私が入社する以前の話ですが、PostgreSQLを9.6にUpgradeした話も書かれています。

そう、世界にイノベーションを起こすための原石たり得るアスタミューゼの技術情報を保管しているDBなので、世の中の流れに追随して適切にバージョンアップしていかなければなりません。
論理レプリケーションが使えれば、バックアップの考え方はもちろん、準リアルタイムでのデータ加工についても利用方法が広がるでしょうし、大規模データに対してのSELECTではパラレルクエリーの効果だって期待できます。
さあ、早くPostgreSQL12にしましょう!
おっといけない、12はまだbetaだった。でも11なら正式リリースから半年以上経ったし、そろそろアップグレードしましょう!!

冷静な視点

新しもの好き、なによりも便利な機能とPostgreSQLが大好きな私はともかくとして、インフラ・事業に責任を持つ部長の namikawa からは

「ちょっと落ち着け。当たり前だが客観的にみて安定したといえるバージョンを使うようにしたい。バグ曲線みたいなものを参考にしながら、今後も使えるアップグレード方針を検討してほしい」

という、至極まっとうなリクエストが出たのでした。

PostgreSQL の 開発プロセス

PostgreSQLはオープンソースのDBMSです。そして、近年のOSSプロジェクトにしては珍しい(と思う)のですが、基本的に本体の開発に関する議論はすべてMailing List(ML)で行っており、Issue Trackerに類するものがありません。
そうなるといわゆるバグ曲線的なものはすぐには得られませんね。
ないものは仕方がないのですが、「たぶん大丈夫だとおもうからUpgradeしようぜ」とはさすがに私もいえません。
このリクエストをいただくときに、「アスタミューゼでの話ではないが、某DBMSをうかつにUpgradeしてひどいバグを踏んでデータが壊れた経験がある」などという話をされていたのでなおさらです。

代替手段はないか?

要は新規リリース直後の、多くの人に使っていただいたからこそ出てきた不具合修正が収束してきていることがわかれば良いのです。
修正の情報が一番わかりやすそうなのはリリースノートじゃないでしょうか。
ということで、PostgreSQLのリリースノートを眺めてみましょう。
コミットメッセージなどでもよく使われる表現ですが、不具合の修正に類することは、ほぼ必ず「FIX 〜」という記述になっているように見受けられます。
これを数え上げたら、割とそれっぽい情報として代替できないでしょうか?

ところで Jupyter Notebook というやつがあるよね。

と、いうことで、スクレイピングというのもおこがましいレベルの話ではありますが、リリースノートのページをいくつか巡回して、内容を抽出して数え上げて、なんなら最後にグラフにでもできるとうれしいですね。

ここまで考えたとき、こういうのは「PythonとJupyterNotebookを使うといいぜ」と心のどこかで囁く声が聞こえた気がしました。 勝手知ったる curlgrepsedawk 、あとはスプレッドシートでもあればどうにかなってしまいそうな気もしましたが、その場合次回アップグレード時などにもう一度やるのが面倒くさそうだったし、なによりも私はデータエンジニアに転向したのです。Pythonとももっと仲良くなりたい。そんな気持ちでJupyter手習いをやってみようと思ったのでした。

最近はDockerという便利なものがあるので、ちょっと使ってみたいくらいの用途だったら

$ docker pull jupyter/datascience-notebook
$ docker run --name notebook -p 8888:8888 jupyter/datascience-notebook

こんな感じでサクッと環境が作れてしまいます。簡単ですね。

プログラミングしてみる。

PythonやJupyter NotebookのTIPSについては、ほかに詳細なドキュメント・記事が豊富にありますし、ここですべてを解説することはしませんが、やってみたことをいくつかご紹介してみようと思います。

今回書いたソースコードは github.com/t-suga/postgresql_release_checkに置いておきます。

後半でデータをソートしたり分割したりするところで試行錯誤が多くなりすぎて力尽きました。
もう少しきれいにできたような気もするのですが……精進いたします。

Webページの取得とデータ抽出

HTTPリクエストは、 requests 、 DOMのパースには BeautifulSoup というライブラリがよく使われているようなので、これを使ってみました。 正規表現には re 、 集計には pandas グラフには matplotlib という定番ライブラリです。

これらを使えば、リリースノートのページから Fix〜 の 記述を抽出して、数え上げることは簡単です。 累積のFix数にするためには cumsum というメソッドを使いました。

PostgreSQLは初版からリリースノートがありますが、EOLになっているものまでスクレイピングすることはないでしょう。今回は9.3以降を対象とするようにしました。

初回の失敗。

当たり前ですが、素朴にやるとプロットはリリースごとになります。
そして、もちろんですが日々のアップデートには既存バグの改修というのもあり、そういったバックポートされるようなFixがあるため、このグラフはいつまでたっても収束しているようには見えなくなってしまいます。

リリースの間隔を考慮し、グラフを調整する。

リリースごとにリリース日を収集するようにして、リリース日の差分を取ることにします。
今回は、間隔の比が保存できていればいいと割り切って大分横着をしてしまいましたが、どうにかマイナーバージョン1を0として、リリースまでの期間が横軸になるようにデータを成形することができました。
このあたりもう少しきれいな方法があれば是非教えていただきたいです。

最後に、古いメジャーバージョンのものはそれだけ累積バグ数が大きくなりますが、ある一定のところまできたらあまり意味がないはずです。ということで、縦軸は対数にしてしまいます。

そんな感じで得られたグラフがこちらです。

f:id:astamuse:20190724095114p:plain
得られたグラフ

グラフを読み解く。

といっても、一目瞭然で、きれいにほぼ同型のグラフになっています。
一番新しい11のラインすらもほぼ安定のカーブに半ば程度到達しており、10に関しては峠は越えたなという感じでしょう。
バージョン全体を概観すると、PostgreSQLはリリースから大体半年も経てば安定し始めており、1年経てばほぼ十分に安定すると考えてよさそうです。

まとめ

これらのことから、現状では(まだ)最新の11を利用するというのもある程度安心できるんじゃないでしょうか。と進言することができそうです。
また、スクリプト化したので次に更新を検討する際にも、リリースノートの公開方法が大きく変わっていなければ少ない手直しで再実行できることでしょう。

最後に、毎度のお願いで恐縮ではございますが、アスタミューゼではエンジニア・デザイナーを募集中です。 興味のある方は是非下記のバナーからご応募をお願いいたします。

プロジェクトにBIツール「metabase」を導入したらいい感じになった話。

f:id:astamuse:20190719202102j:plain

こんにちは、アスタミューゼでデザイナーをしている@YojiShirakiです。

最近、新規プロジェクトでBIツール(metabase)導入していい感じに機能しつつあるので、どのように導入したかその変化をご紹介したいと思います。

BI導入の背景

BIの導入は次のような理由で早い段階で導入しようと考えていました。

  1. プロジェクトが横断的で共通認識とコンセンサスの土台が必要であること
  2. Webサービスではあるがキャッシュポイントが契約(オフライン)にあること
  3. 初期の機能実装が最低限で、リリースした後の機能実装ニーズが継続的に相当量見込めること

2番目の「キャッシュポイントがオフラインにある」点は特に注意が必要です。というのも、キャッシュポイントが近いところの意見はどうしても強くなりがちで、「お客様の声」事案は優先順位が高めに設定されやすくなるためです。

「お客様の声」はとても重要です。しかし、現状クリアすべき事業課題・サービス課題 とお客様の声は必ずしも同次元ではありませんから、そこを無自覚に「お客様の声」を優先し続けてしまうと、本質的な事業課題への対処が遅れ、プロジェクトが遅延するリスクが高まります。

そうならないように、プロジェクトの初期段階で基本的な数値基盤を構築し、ユーザーシナリオやそれに付帯するKPIと照らし合わせながら課題解決をしていく目線醸成が重要になるわけですね。

「お客様の声」で明らかに改善すべき箇所は継続的に改善しつつ、一方で、数値によって明らかにされるマクロなサービス課題への対応をロスを少なく実行していく、そのための数値整備というイメージです。

なお、余談ですが優先順位判断のメソッドについては様々なものがあるので調べてみてください。

例)プロダクト開発における意思決定のための「ユーザーストーリーの優先順位付け手法」まとめ

機能は計測可能に設計しておくこと

BIは数字を可視化するツールですから、数字が取れることが前提です。そのために比較的早い段階から計測を意識した機能実装の意識醸成に配慮します。

具体的には、企画時にその成果をどのように計測するのかを議論できるように企画書のフォーマット作りを行います。企画書の骨子として以下のようなフォーマットを定義し行動を強制するようにします。

  1. 企画意図・目的
  2. 期待する効果
  3. その計測方法
  4. 具体的な実装内容

計測方法が定義されていない企画書はフォーマット違反なので、別途議論するというふうになります。

計測方法はGAでも良いですし、ログでもいいと思います。ただログデータの収集機構を構築するのはそれなりにコストがかかるので、手っ取り早く履歴テーブルなどを新たに整備してしまうのも良いかと思います。何れにせよ行動が記録に残るように企画段階で方針を固めておきます。

試験導入(とツールの選定ミス)

ある程度状況が整ってきたら試験導入です。今回は以下の5つを検討しました。無料ツールではメジャーな選択肢だと思います。

上記のうち re:dash, superset, PowerBI は既に触ったことがあり感触はわかっていたので、今回は(あまり時間も割けなかったということもあり)インストール不要で、且つ、アカウント管理が容易な Google Data Studio を選択しました。

なお最初に作ったダッシュボードはこんな感じです。

f:id:astamuse:20190719201143j:plain

ぼかしが多くて解りにくいですが営業活動向けダッシュボードを作りました。まず最初に営業に役立つものを作ることで、営業・企画メンバーに対して数値化メリットを感じてもらいたいと考えたためです。思った以上に好評だったのでこの意図は奏功したと思っています。

metabase への乗り換え

ただ一方で以下のような誤算もありました。

  1. 思った以上にもっと数値を見たいという要望が挙がってきた
  2. Google Data Studio の画面レイアウト思ったよりもが使いにくい・面倒
  3. Google Data Studio のDBとのコネクション設定動作が安定しない
  4. Google Data Studio のグラフ表現力が弱い・設定が難しい

1 はともかく、2,3,4 についてはかなり辛いものがありまして、早々に Google Data Studio に見切りをつけ別のツールの検討を始めます。

結果的には、この時、たまたまプライベートで試していて頗る感触の良かった metabase への乗り換えを決めます。

圧倒的な metabase の使いやすさ

metabase の選定は良かったと思います。インストールが簡単で DB の設定も容易です。他にも

  1. Googleの oauth が使えるためアカウント制御が容易(Gsuiteとの相性が良い)
  2. GAとの連携が可能で他のデータと重ね合わせて見せることができる
  3. データの抽出が超簡単
  4. ダッシュボードレイアウトがしやすい
  5. デザインがきれい

など。特に、3, 4, 5 は日々の利用が楽しくなるレベルで洗練されています(なお、1, 2 は re:dash でも可能です)。

デザインとUI/UX が優れているのが最もポイント高かったです。

とは言え、なかなか伝わらないと思うので YouTube にあがっている Demo が参考になるので貼っておきます。

作ったダッシュボード

さて、ではその metabase でどんなダッシュボードを作ったかと言うと下記のようなものです(数字はいじってあります)。デイリーで追うべき数字とその推移をメインに置いたもので、一つのダッシュボードの情報量は少なくして、見るべき数字に集中できるように心がけて作っています(そのかわりダッシュボードの数はやや多め)。

f:id:astamuse:20190719193838j:plain
※数字はダミーです

f:id:astamuse:20190719194435p:plain
※数字はダミーです

最近ではもっと込み入った情報などの可視化も行っていて、あるデータ母集団と別のデータ母集団のマッチング判定データなども可視化しています。

だがしかし…メンバーからのフィードバックが思ったより薄かった

ただ意外なことに作ったダッシュボードについては、あまり大きなフィードバックを得られませんでした。 Google Data Studio でダッシュボードを作っていたからか、「あ、こういう数字見れるのね、ふーん」くらいです。悲熊・・。

そこでもっとアピールするために企画の MTG の時に metabase を映し出して必要な数字やグラフを即時に出すことを何度か行いました。

これが結構刺さりまして「おお、凄い」とか「あ、これいいですね」など言われるようになり「数字が即座に見られる」「色々な数字が手軽に見られる」という感覚が広まりました。ライブ感って大事ですね、いい勉強になりました。

加えてやはり metabase が気軽に数字を引っ張ってこれる様になっているので、人によっては「あ、それ自分も使いたい」となったと思います。

議論と企画の質の変化

こんなゲリラをしばらく繰り返していった結果徐々にチーム内で以下のような変化が生まれました。

  1. 課題がどこにあるのか数字も交えて議論するようになった
  2. 何かをやる時に事前に軽く調べてみるという理解が進んだ

1 については、例えば「●●機能は面白いけど、今はその手前の数値が悪くてボトルネックだから、まずはそこを改善するのが先じゃない?」とか「そこって数値どうなってんだっけ?効果でる?」などの発言が増えていくような変化でした。

2 については、「面白そうな機能を考えてみたものの今のデータ数だと有効にワークしないので一旦置いておこう」や、逆に「数値見たら●●に課題はあるけど、そこを改善すればワークする可能性が高いからやってみよう」とういケースも出てきました。

何れにせよ、数値をもって一定の客観性と共通認識を確立したことで「思いついたら実装する」から脱却し徐々に良い方向に向かようになりました。

とは言えデータドリブンの限界は認識しておくべき

とは言え私たちのチームメンバーはデータが全てとは思っていません。データと同じくらい発想・インスピレーションも大事に考えています(そもそもこの2つは相反するものではなく補完関係です)し、またデータによって明らかにできない課題(というよりも付加価値の可能性)があることも承知しています。

大事なことは、そういったマインドも持ちつつも定量的アプローチでシャープに課題認識と優先順位判断を行い、より良いサービスを作っていく姿勢を全員が持つことだと思っています。

まとめ

ということで、今回は BIツール導入の流れと、どのように変化したかをメモがてらまとめてみました。

長々書きましたが、こういう取り組みは、プロダクトマネジメントがしっかりしている企業から見ると、至極普通なことだと思っています。ですので、私たちももっとレベルアップしていかないとなぁ、と日々日々感じる次第です。

もし本稿について何かご質問等あれば@YojiShirakiにDM頂ければと思います。本文では触れませんでしたが metabase のインストール方法などはそれなりにしっかり検証したのでお役に立てると思います。

では、本日も最後までお読みいただきありがとうございました。

例によって当社では一緒にサービス開発してくれるエンジニア・デザイナー・ディレクターを超絶賛募集しております。

カジュアル面談も随時行っておりますので、「ちょっと話聞きたい」という方は、このブログのサイドバー下にあるアドレスか@YojiShirakiにDMいただければと思います。いつでもウェルカムです。採用サイトもありますので下の水色のバナーから是非どうぞ!ではまた:- )

@YojiShirakiの過去記事)

SPTAGを触ってみた

ご挨拶

どうもお久しぶりです、gucciです。
入社して1年半経ちまして、なんともう3回目のブログのターンが回ってきました。

パソコンを一日ずっと同じような姿勢で叩いていると、肩甲骨周りの筋肉が凝り固まってきて、しまいには肩こりからくる吐き気やストレスに襲われて日常生活に支障をきたしてしまいます。
そうなってしまっては生産性も上がらず、作業時間は伸びてしまいさらに肩が凝ってしまいます。
なんという悪循環でしょう。

そんな時にオススメなのが、ストレッチポールです。
ストレッチポールに乗ることで肩甲骨周りの筋肉をほぐすことができ、また背骨のS字を正しくもどしてあげることで腰痛も軽減されるという良いこと尽くし。
みなさんも是非ストレッチポールをお試しあれ。

最近やっていること

さて、
私がこの会社に入社してからここまで、様々なことに挑戦する機会をいただいてきました。
入社前のプログラミングスクールではRubyを3ヶ月ほど学んでいたのですが、入社後はJavaを半年ほど学び、
その後はアプリケーション開発で半年ほどScalaに触れ、その後データチームに移ってからはSparkを用いた大規模データ処理などを学び、
ここ最近はPythonを使ってバッチやアプリケーションを組んでおります。
使うライブラリやミドルウェアに合わせて選択したり、好きなものや興味があることを自ら選択することができるのでとてもやりがいを感じております。

f:id:astamuse:20190710024218j:plain
space
ここ最近は、
高次元ベクトルデータ検索を行うべくNGTというライブラリを用いてあれこれやっております。
まさか私がベクトルデータを扱うだなんて。いや、むしろベクトルデータって何それ?!と少し前の私ならなっておりました。
(いや、今でも正直あまりわかっておりませんが)

NGTって何?ベクトルデータって何?というのは、我がぶちょー・弊社並河の個人ブログにとてもわかりやすいエントリーがありますので、是非そちらを参考にしてみてください。
NGTがYahoo!の公開しているOSSに対して、
Microsoftが公開している近傍検索を行えるライブラリであるSPTAG (Space Partition Tree And Graph)という存在を同僚のaranが教えてくれたので、
このブログではそちらのSPTAGを実際にお試しで触ってみた内容をご紹介しようと思います。

SPTAGをインストールしてみよう

github.com

NGTのGithubには日本語の説明があるのに対して、SPTAGは英語オンリーの模様ですね。
この時点で難易度の高さが伺えます。
必要項目を見てみると、

swig >= 3.0
cmake >= 3.12.0
boost >= 1.67.0
tbb >= 4.2

とありますので、順々にインストールしていきましょう。
当方の環境は Ubuntu 18.04.2 LTSを使っております。
それでは必要ライブラリのインストールからレッツゴー。

Swigのインストール

必要ver : swig >= 3.0

swingはパッケージがあるのであっという間に入れられます。

$ apt list swig
Listing... Done
swig/bionic,now 3.0.12-1 amd64 [installed]

よしよし。

$ sudo apt install swig

これでばっちりです。

cmakeのインストール

必要ver : cmake >= 3.12.0

cmakeなんてもちろんすぐ入れられるよ、むしろ入ってるんじゃないかな、
と思ったらなんと残念。

$ cmake --version
cmake version 3.10.2

versionが古いではないか・・・

$ apt list cmake
Listing... Done
cmake/bionic 3.10.2-1ubuntu2 amd64

なるほど。パッケージにあるのがそれなのですね。
自分の手で最新版にしてあげましょう。

$ wget https://github.com/Kitware/CMake/releases/download/v3.14.5/cmake-3.14.5-Linux-x86_64.sh  
$ chmod +x cmake-3.14.5-Linux-x86_64.sh
$ sudo ./cmake-3.14.5-Linux-x86_64.sh
$ sudo mv cmake-3.14.5-Linux-x86_64 /opt
$ sudo ln -s /opt/cmake-3.14.5-Linux-x86_64/bin/* /usr/bin
$ cmake --version
cmake version 3.14.5

成功です。

boostのインストール

必要ver : boost >= 1.67.0

続いてboost。
恐る恐るパッケージを見てみると・・・

$ apt list libboost-dev
Listing... Done
libboost-dev/bionic 1.65.1.0ubuntu1 amd64

ブーストよ、お前もか。
これも経験、レッツトライ。

$ wget https://dl.bintray.com/boostorg/release/1.68.0/source/boost_1_68_0.tar.bz2
$ tar --bzip2 -xf boost_1_68_0.tar.bz2
$ cd boost_1_68_0/
$ ./bootstrap.sh
$ sudo ./b2 install
〜少し時間がかかります〜

無事に終わりましたね。お疲れ様です。

tbbのインストール

必要ver : tbb >= 4.2

最後にtbbのインストールです。

$ apt list libtbb-dev
Listing... Done
libtbb-dev/bionic 2017~U7-8 amd64

お、ありますね。

$ sudo apt install libtbb-dev

さあ準備は整いました。いよいよSPTAGをインストールしてみましょう。

SPTAGをインストール

$ git clone https://github.com/microsoft/SPTAG.git

クローンしてあげたら、後はREADMEにあるとおりに実行すれば・・・

$ cd SPTAG
$ mkdir build
$ cd build && cmake .. && make

最後にインストールです!

$ sudo make install
・・・
CMake Error at Wrappers/cmake_install.cmake:87 (file):
  file INSTALL cannot find "/home/develop/SPTAG/Wrappers/src/SPTAG.py".
Call Stack (most recent call first):
  cmake_install.cmake:43 (include)

こけました!!
なんということでしょう。
ログをみるとふむふむ、SPTAG.pyというファイルが見つからないと、って怒っていますね。
探して見ましょう。

$ cd ..
$ find . -name SPTAG.py
./Wrappers/inc/SPTAG.py
./Release/SPTAG.py

いたぁあああああああああ!
どちらが正しいのか・・・
diffをとってみると同じでした。

$ cp ./Wrappers/inc/SPTAG.py ./Wrappers/src/

コピーしてきて、再実行!お願い!

$ cd build/
$ sudo make install

エラー起きず!やりました! READMEには「テストやってみてね」と書いてあるのでやりましょう。

$ cd ../Release/
$ ./test
Load Data From delindices/vectors.bin
Load Data (97, 10) Finish!
Load BKT From delindices/tree.bin
Load BKT (1,98) Finish!
Load Graph From delindices/graph.bin
Load Graph (97,32) Finish!
10@(1,1) 90@(3,3) 250@(5,5) 

*** No errors detected

やりました。我々はついにたどり着いたのです。

GettingStartに詳しい使い方があるので、さっそく試してみましょう。
上記ページには大文字で記載されていますが、indexbuilderの小文字でパスが通っていて、Usageが出るのでそれを見てみましょう。

$ indexbuilder
Required option not set:
  -d, --dimension <value>       Dimension of vector.
Required option not set:
  -v, --vectortype <value>      Input vector data type. Default is float.
Required option not set:
  -i, --input <value>           Input raw data.
Required option not set:
  -o, --outputfolder <value>    Output folder.
Required option not set:
  -a, --algo <value>            Index Algorithm type.

Usage: 
  -t, --thread <value>          Thread Number.
  --delimiter <value>           Vector delimiter.
  -d, --dimension <value>       Dimension of vector.
  -v, --vectortype <value>      Input vector data type. Default is float.
  -i, --input <value>           Input raw data.
  -o, --outputfolder <value>    Output folder.
  -a, --algo <value>            Index Algorithm type.
  -c, --config <value>          Config file for builder.

ふむふむ。なるほど。上の5つは必要なオプションなのですね。

そしてInputのformatは、

<metadata1>\t<v11>|<v12>|<v13>|
<metadata2>\t<v21>|<v22>|<v23>|

であると。なるほど。 手元に実況パワフルプロ野球2018年の開幕版データがたまたまあるので、それを使ってやってみましょう。
少しデータが古いのはご了承ください。
こんなデータがインプットになっております。

山田哲人        50|73|81|65|77|62|
大引啓次        36|53|67|60|58|73|
西浦直亨        25|51|60|51|50|48|
川端慎吾        56|51|65|58|56|50|
武内晋一        30|46|48|46|71|65|
荒木貴裕        33|54|60|62|51|53|
畠山和洋        32|61|29|54|65|61|
・
・
・

6次元のベクトルで、

<選手名>        ミート力 |パワー|走力|肩力|守備|捕球|

といったステータスになっております。
本来パワプロはこれらのデータに加えて特殊能力があり、それによるプラスマイナスが大きいのですが、今回はお試しということでご了承くださいませ。
それでは作って見ましょう。

インデックスの作成

$ indexbuilder -d 6 -i ./input_yasyu_list_sptag.tsv -o ./powerpro2018_SPTAG -v Int8 -a KDT
Setting NumberOfThreads with value 32
・
・
・
Start to build KDTree 1
1 KDTree built, 394 396
build RNG graph!
Refine 1 0%Refine RNG, graph acc:0.992813
Refine 2 0%Refine RNG, graph acc:0.997813
Build RNG Graph end!
Save Data To ./powerpro2018_SPTAG/vectors.bin
Save Data (396, 6) Finish!
Save KDT to ./powerpro2018_SPTAG/tree.bin
Save KDT (1,396) Finish!
Save Graph To ./powerpro2018_SPTAG/graph.bin
Save Graph (396,32) Finish!

やりました。成功です!

インデックスの検索

続いて検索を行ってみましょう!

適当に検索クエリ用のファイルを作成します。

パワー100       0|100|0|0|0|0|

これを使って検索を投げてみます。

$ indexsearcher ./powerpro2018_SPTAG Index.QueryFile=./testSPTAG_Query.tsv Index.ResultFile=./testSPTAG_Result.tsv Index.K=10
・
・
・
Load Data From ./powerpro2018_SPTAG/vectors.bin
Load Data (396, 6) Finish!
Load KDT From ./powerpro2018_SPTAG/tree.bin
Load KDT (1,396) Finish!
Load Graph From ./powerpro2018_SPTAG/graph.bin
Load Graph (396,32) Finish!
Set []/powerpro2018_SPTAG = ./powerpro2018_SPTAG
Set [Index]QueryFile = ./testSPTAG_Query.tsv
Set [Index]ResultFile = ./testSPTAG_Result2.tsv
Set [Index]K = 10
Load data: (1, 6)
        [avg]       [99%]   [95%]   [recall]    [mem]
Setting MaxCheck with value 2048
2048    0.000129    0.0001  0.0001  0.0000      0GB
Output results finish!

やりました。成功です! 結果のファイルを見てみると・・・

パワー100:0.307@アマダー|0.362@G後藤武敏|0.370@マレーロ|0.370@山川穂高|0.378@阿部慎之助|0.386@黒瀬健太|0.394@園部聡|0.394@デスパイネ|0.402@バティスタ|0.402@メヒア|

実データで並べてみると・・・

アマダー 37|80|18|52|30|38|
G後藤武敏 25|61|31|39|35|30|
マレーロ    57|85|42|56|37|36|
山川穂高    51|86|41|53|46|40|
阿部慎之助 46|69|15|51|27|41|
黒瀬健太    19|51|21|51|24|15|
園部聡   18|60|42|56|21|19|
デスパイネ 45|84|52|66|36|40|
バティスタ 46|81|53|69|35|29|
メヒア   42|80|42|60|44|47|

おぉぉ、力自慢の男たちがずらりとでてきましたね。
ふむ。なるほどなるほど。

NGTでやってみる

同じ元データで作ったインデックスに対して、同様のクエリを投げる作業をNGTでもやってみました。

Query No.1
Rank    ID  Distance
1   316 81.2711
2   84  82.1766
3   280 84.5044
4   217 87.327
5   42  91.1757
6   375 91.4549
7   385 91.4549
8   286 95.3625
9   31  96.566
10  186 98.3972
Query Time= 0.000167582 (sec), 0.167582 (msec)
Average Query Time= 0.000167582 (sec), 0.167582 (msec), (0.000167582/1)

こちらを実データで並べてみると・・・

19   51  21  51  24  15  黒瀬健太    316
25  61  31  39  35  30  G後藤武敏 84
37  80  18  52  30  38  アマダー    280
18  60  42  56  21  19  園部聡   217
46  69  15  51  27  41  阿部慎之助 42
41  62  45  33  30  35  清宮幸太郎 375
41  62  45  33  30  35  今井順之助 385
27  60  56  42  29  32  岩見雅紀    286
26  60  46  46  39  36  鵜久森淳志 31
24  51  44  63  20  20  青木陸   186

ほほお・・・SPTAGとは異なる結果になりました。
実に興味深いですね。 このあたりは実際のアルゴリズムを理解していかないと真相に辿りつけなさそうですね。
オプションの付け方などでもインデックスの作成や検索は微妙に変わりそうなので、
精度や速度比較など、まだまだ調べられることはたくさんありそうです。
インストールのしやすさや、Outputの見やすさはNGTの方に分がありそうですね。

おわりに

いかがだったでしょうか。
SPTAGとNGTの比較検証をもっとやろうかと思っていたのですが、SPTAGのインストール自体で思いの外知見がたまったので、そちらをメインにアウトプットさせて頂きました。
文書や画像などをベクトル化し、そのベクトルの距離が近いものでサーチする近傍検索。実に面白いですね。
いつの日か、人間の遺伝子をベクトル化することで、その人間がどんな特徴を持つのかなどがわかってしまう日が来るのかもしれないし、来ないのかもしれない・・・。

ということで! アスタミューゼは常に新しいものや面白いものに挑戦しています!
エンジニア・デザイナーを絶賛募集中です! 是非一緒に面白いことをやっていきましょう!ご応募お待ちしております!

Copyright © astamuse company, ltd. all rights reserved.