カテゴリー: テクノロジー

[Solr] Lucene8.1に同梱されるようになったLukeを使う

はじめに

LukeはLucene用のインデックスブラウザです。SolrはLuceneのインデックスを利用しているので、SolrのインデックスをLukeでブラウズすることができます。
Lukeは従来Luceneから見るとサードパーティのソフトウェアであったので、その時々のLuceneのバージョンに合わせてコンパイルが必要で、さらに近年ではLukeのメンテナンスが追いついていない部分もあり、実際に使うにはいろいろ手間が必要な状態になっていました。

そのLukeがLucene 8.1(Solr 8.1)でLuceneのモジュールとして取り込まれました。 この長い長いチケットを見れば分かるように、様々な方の尽力の賜物です。

Luke の特徴

  • インデックスされている文書の閲覧
  • インデックスされているタームを、頻度順で表示
  • 検索の実行と結果の分析
  • 特定の文書の削除
  • ドキュメントのフィールド構成の変更と再インデックス
  • インデックスの最適化

起動

Luke の起動に必要な lucene-luke.jar は Solr の配布物には含まれていないので Lucene をダウンロードします。 ダウンロードしたら展開して luke/luke.sh を実行します。これだけで良くなったので、以前に比べると断然使いやすくなりました。

tar zxf lucene-8.1.0.tgz
cd lucene-8.1.0
luke/luke.sh

起動直後に開くダイアログで、Solrのインデックスが格納されているディレクトリ指定します。

インデックスブラウザ

Overviewのタブでは、インデックスのフィールド毎に頻度の高い順にタームを表示することができます。

wikipedia-ja を Kuromoji の normal モードで形態素解析した場合
wikipedia-ja を Kuromoji の extended モードで形態素解析した場合

たとえば同じ Wikipedia-ja をインデックスした場合でも、Kuromoji の normal モードを使うか extended モードを使うかでインデックスの内容が大きく異なることが分かります。

extended モードでは未知語が uni-gram に分割されるという特性を反映して、上位の多くを “e”, “t”, “r” などのアルファベット1文字のタームが占めています。normal モードでは “年”, “月”, “日” や数字など1文字のタームに加えて”category”,”リンク”,”外部”,”脚注”などWikipediaで頻出の用語も上位に来ています。

おわりに

上に挙げたような、インデックスの内容を直接参照するような使い方の他にも

  • 特定の文章が期待通りのタームに分割されているか調べる
  • 期待通りの検索結果を得るためのクエリを試行錯誤する
  • Analyzerを切り替えたときの形態素解析結果の違いを調べる

など、開発に役立つ機能が満載です。

使いやすい形で配布されるようになった Luke を活用していきたいと思います。

巨大なJSONをSolrに投入する

今回は小ネタです。

先日、1GB近くある巨大なJSONファイルをSolrに投入する機会がありました。とあるシステムからダンプしたデータで、以下のような形になっています。

[{"id":"10001","name":"名前1","description":"説明文1","timestamp":"2018-01-01 12:00:00"},{"id":"10002","name":"名前2","description":"説明文2","timestamp":"2018-01-02 12:00:00"},{"id":"10003","name":"名前3","description":"説明文3","timestamp":"2018-01-03 12:00:00"},{"id":"10004","name":"名前4","description":"説明文4","timestamp":"2018-01-04 12:00:00"},{"id":"10005","name":"名前5","description":"説明文5","timestamp":"2018-01-05 12:00:00"},...]

要するに、改行のない巨大な1行のテキストファイルです。
SolrにJSONファイルをPOSTしてインデックスを作成させることはできますが、1GBはちょっと大きすぎるので、分割することを考えました。

1行1レコードになっていれば話は簡単で、適当な行数で分割してからJSONの配列になるように加工すればいいだけのことですが、全部が1行になっているのでそういう訳にはいきません。

スクリプト言語でJSONを読み込んで分割することも考えましたが、JSON全体を一括で読み込んで処理するタイプのJSONパーサーでは1GBを扱うのは辛いものがあります。SAXタイプのJSONパーサーを探さないといけないかなあと考えているうちに、jq コマンドを使うのがいいんじゃないかと思い当たりました。

$ jq '.[]' sample.json
{
  "id": "10001",
  "name": "名前1",
  "description": "説明文1",
  "timestamp": "2018-01-01 12:00:00"
}
{
  "id": "10002",
  "name": "名前2",
  "description": "説明文2",
  "timestamp": "2018-01-02 12:00:00"
}
{
  "id": "10003",
  "name": "名前3",
  "description": "説明文3",
  "timestamp": "2018-01-03 12:00:00"
}
{
  "id": "10004",
  "name": "名前4",
  "description": "説明文4",
  "timestamp": "2018-01-04 12:00:00"
}
{
  "id": "10005",
  "name": "名前5",
  "description": "説明文5",
  "timestamp": "2018-01-05 12:00:00"
}

一番外の配列を外して各レコードを取り出すことはできました。1レコード1行になっていると加工しやすいので-cオプションを指定します。

$ jq -c '.[]' sample.json
{"id":"10001","name":"名前1","description":"説明文1","timestamp":"2018-01-01 12:00:00"}
{"id":"10002","name":"名前2","description":"説明文2","timestamp":"2018-01-02 12:00:00"}
{"id":"10003","name":"名前3","description":"説明文3","timestamp":"2018-01-03 12:00:00"}
{"id":"10004","name":"名前4","description":"説明文4","timestamp":"2018-01-04 12:00:00"}
{"id":"10005","name":"名前5","description":"説明文5","timestamp":"2018-01-05 12:00:00"}

ここまでくれば後は簡単で、1000行程度ずつ読み込んでまとめてPOSTするスクリプトを作成して無事に投入することができました。

SolrのSQLインタフェースでdistinct

はじめに

前回の記事で、SQLで言うdistinctをSolrで実現する方法を採り上げましたが、実はSolrでは部分的にではありますがSQLをサポートしており、もっと直接的にdistinctを実現することができます。

SolrのSQLサポート

Solrでは/sqlハンドラでSQLによるリクエストを受け付けます。/sqlハンドラは暗黙の内に設定されているもので、利用者が特に設定をすることなく利用できます。

サポートしているのは SELECT のみです。以下の機能が使えます。

  • WHERE 句で Solr の検索式が書ける
  • ORDER BY句によるソート
  • LIMIT句による件数の指定
  • SELECT DISTINCT句
  • GROUP BY句による集約
  • HAVING句

SELECT DISTINCT

前回の記事の、スポーツ施設で対応できるスポーツの一覧を取得する例は以下のように書けます。

$ curl -s --data-urlencode 'stmt=SELECT sports, count(*) AS cnt FROM sportare GROUP BY sports LIMIT 10' http://localhost:8983/solr/sportare/sql
{
  "result-set":{
    "docs":[{
        "sports":"",
        "cnt":1}
      ,{
        "sports":"BMX",
        "cnt":5}
      ,{
        "sports":"アイスホッケー",
        "cnt":48}
      ,{
        "sports":"アメリカンフットボール",
        "cnt":32}
      ,{
        "sports":"アルペンスキー",
        "cnt":1}
      ,{
        "sports":"アーチェリー",
        "cnt":113}
      ,{
        "sports":"インディアカ",
        "cnt":16}
      ,{
        "sports":"インラインスケート",
        "cnt":10}
      ,{
        "sports":"ウィンドサーフィン",
        "cnt":1}
      ,{
        "sports":"エアロビクス",
        "cnt":262}
      ,{
        "EOF":true,
        "RESPONSE_TIME":155}]}}

試行錯誤中に、以下の問題を見付けました。

  • テーブル名(Solrではコレクション名)に’-‘が含まれているとSQLの文法エラーになる。これはコレクション名のエイリアスを設定すればなんとかなる。
  • LIMITで取得件数は指定できるが、OFFSETが指定できない。OFFSETを指定しても文法エラーにはならないものの、機能はしていないようです。
$ curl -s --data-urlencode 'stmt=SELECT sports, count(*) AS cnt FROM sportare GROUP BY sports LIMIT 10 OFFSET 5' http://localhost:8983/solr/sportare/sql
{
  "result-set":{
    "docs":[{
        "sports":"",
        "cnt":1}
      ,{
        "sports":"BMX",
        "cnt":5}
      ,{
        "sports":"アイスホッケー",
        "cnt":48}
      ,{
        "sports":"アメリカンフットボール",
        "cnt":32}
      ,{
        "sports":"アルペンスキー",
        "cnt":1}
      ,{
        "sports":"アーチェリー",
        "cnt":113}
      ,{
        "sports":"インディアカ",
        "cnt":16}
      ,{
        "sports":"インラインスケート",
        "cnt":10}
      ,{
        "sports":"ウィンドサーフィン",
        "cnt":1}
      ,{
        "sports":"エアロビクス",
        "cnt":262}
      ,{
        "EOF":true,
        "RESPONSE_TIME":168}]}}

おわりに

distinctつながりで、SolrのSQLサポートを調べてみました。distinctに限らず、制限事項がいろいろと存在するので使いどころが案外難しいという印象です。通常の検索処理でというよりもインデックスに対する統計処理などで使うのが良さそうです

オンライン決済stripeを触ってみた

ナイトプールでウェイウェイしてる夢を見ました。私の心は夏模様。
マエダです。

 

Webサービス開発しているとオンライン決済のニーズがでてきますよね。
そんな開発者の悩みを解決してくれるのがオンライン決済サービスstripe。

https://stripe.com/

“デベロッパー・ファースト”と謳っている通りで非常にかんたんなステップでシステムに決済機能を導入できます。

 

Ruby on Railsの場合

vi Gemfile

gem 'stripe'

bundle install –path vendor/bundle

あとはよしなに。

PHP Laravelの場合(定期決済)

composer update
composer require laravel/cashier

あとはよしなに。
https://readouble.com/laravel/5.5/ja/billing.html

 

全然その先説明してないじゃん!って思われたかと思いますがQiitaとかで日本語での情報も十分ありますので単発決済でもサブスクでも必要に応じて活用してみてください!

<参考>
公式ドキュメント:https://stripe.com/docs

サービス設計: Depth vs Width

こんにちは。開発担当のマットです。

開発はとても楽しい仕事で、人が考えたアイディアに命を吹き込むような仕事だと思っています。

開発者として作っているサービスを成功させたいという気持ちがあるので、サービス設計に問題があるかどうかを判断できるよう、そのサービスの設計を多くの観点から見ることがとても大事です。

そこで、サービス設計の新しい見方を紹介したいと思います。
それは、サービスの「Depth」(深さ)と「Width」(幅)。

それって一体何でしょうか?

何かのサービス(ウェブサイト、アプリ、ゲームなど)を設計する時、1番に考えなければならないことは利用いただくユーザーのことだと思います。
作ったサービスがユーザーのニーズに満たさない場合、サービスは目的を果たしません。

開発者としてそれはとても悲しいことなので、どうしても避けなければなりません。

そうならないように設計者がサービスにできるだけ多くの機能を入れようとすることがありますが、それは果たして正解なのでしょうか?

Widthとは?

ユーザーが何かの行動を取ることを「アクション」と呼びましょう。

検索バーにキワードを入れて、サイトを検索することが「アクション」。
ソーシャルメディアに写真を投稿することも「アクション」。
Bボタンを押したら、マ○オがジャンプすることも「アクション」です。

ユーザーがたくさんのことを体験できるように、設計者がユーザーに多くのアクションを与えることがよくあります。

「アクションを与える」=「自由を与える」=「良い」

と思いきや、100種類のアクションがあると、ユーザーがそれらを覚えないと使えないことが発生してしまいます。
Width = 「ユーザーが取れる行動」ですが
Width = 「複雑さ」とも言えます。

起こせるアクション数が極めて多い、複雑さある、3Dモデレリングソフトの例

せっかくたくさんの機能を作っても、複雑すぎるとユーザーがサービスを使わなくなってしまいます。

では、Depthは何でしょう?

Widthが「ユーザーが取れる行動」だとしたら、Depthは「ユーザーが取った行動によって生み出せる結果の多様性」です。

少し、わかりにくいので、実際の例をあげたいと思います。
それは、どこの国の子供でも好きな「積み木」です。

Widthが極めて低い、Depthが極めてあるオモチャ、積み木

「積み木」がサービスだとしたら、アクションは極めて少ない(積み木を拾う、積み木を置く)ですが、その簡単なルールで生み出せるものは無限に近いです。

デジタルのゲームでいうと、やっぱりMinecraftが思い浮かびますが、多くのMMOで自分のキャラクターを自分なりに成長させることができますし、多くのシミュレーションゲームでは自分の思う通りの街や国を作ることができます。

ユーザーの選択によって、遊び方が変わる

ウェブサイトとアプリでいうと、ソーシャルメディアが一番の例だと思います。
インターネットにテキストや画像ファイルを上げることがずっと昔からありましたが、「プロフィール作成」、「人をフォローする」、「友達に共有する」だけで、世界がぐっと変わりました。

実際の世界に影響を及ぼしているソーシャルメディアの力

行動の組み合わせで、ユーザーに面白いものを作りあげる力を与えることがDepthの特徴です。

では、どうしたらいい?

上記で、「Depth」=「良い」に対して「Width」= 「悪い」、だと解釈しやすいですが、必ずしもそうとは言えないと思います。

例えば、将棋と囲碁を比較すると、将棋のルールの方が複雑で「Width」はありますが・・・だから囲碁がより良いとは言えません。

Widthも適切に設計することが大事だと思います。

機能が少なすぎてWidthが足りない場合、ユーザーはすぐに飽きてしまいます。
逆に、機能がありすぎて複雑になると、ユーザーがすぐに諦めてしまいます。
Depthが足りなければ使っても面白いものではないので、すぐに使われなくなるでしょう。

つまり、サービスに機能をたくさんつけて複雑さを増やしすぎてしまうことがないよう、サービス設計者と開発者がもっと考えるべきではないかと思います。

なお、たくさんの機能をつけても、それがユーザーにとって楽しいまたは便利な結果に繋ぐことができない場合も考え直すべきではないかと思います。

今後、サービスを設計する際、上記の「Depth」と「Width」のレンズを通して、サービスの強弱を洗い出して、より良いサービスを作れるよう考えてみていきたいと思います。