YAPC::Asia 2014にレポータとして参加してきました

今年も去年に引き続きgihyo.jpのレポータとして参加させていただきました。下記公開されていますので是非ブクマなどしていただけると嬉しいです。

レポータについて

レポータ自体は今回で3回目ですが初めて英語セッションも担当できたのは個人的にはチャレンジでした。単に同時通訳++なんですが。。。でもいざやってみるととりあえずスライドだけ写真にとって残しておけばセッション中それほどメモとれなくてもなんとかなるのは発見でした。*1

いつも人手不足で声をかけていただく形で参加させていただいているのですが人気セッションでもプレス席確保してもらえて最前列で聞けるので興味あるかたは来年もあれば是非応募してみてください*2。私もPerlは仕事で使ってはいますが文章を書くということについては素人ですし、今回はプログラミング未経験の方も参加されてPerl入学式をレポートされたりもしているので日本語が読み書きできればだれでもできると思います。

開場について

今年も昨年に引き続き慶應義塾日吉キャンパスでしたが駅近で開場もコンパクトなので移動が楽なのは良かったです。ネットワークも快適でした。同時通訳++。コーヒーも両日頂きましたし、二日目は貸し切りHUB無料ビールもいただけて最高でした。ただ多目的ホールは立ち見が多くて少し気の毒だったかなと。。。

セッションについて

印象にのこったセッション

  • 「hrhm.info」 自分も仕事中のメインBGMはDream Theaterな程度にはメタルは好きなので。HM/HRの違い「ボーカルがモテるのがHRでギターがモテるのがHM」の説明が秀逸だった。発表者の方は懇親会にもいらっしゃったようなので最近のオススメとかお尋ねすればよかったけど非コミュ力を全力で発揮してしまい声かけらなかったのが心残り。。。
  • 「wri.pe」メモとるためにHerokuで月2万払っているというのは良い意味でcrazyだなぁと。でもアプリ開発以外のところで手こずると萎えるのは確かなのでそれ以外のところをお金で解決してると思えばありなのかも。むしろこれぐらい投資した方が本気になれてよいかもしれない。
  • Perl meets Real World 〜ハードウェアと恋に落ちるPerlの使い方〜 」 Raspberry PiArduinoは興味はあったものの違いもよくわからないので試せてなかったのが違いもわかって個人的にはすごくためになりました。とりあえずRaspberry Piクックブック( http://www.oreilly.co.jp/books/9784873116907/ )を買って帰った。
  • DBIx::Class - what is it and what is it good for?」なつかしい。最近はTeng使っているけどResultSetとかJoinとかたまに欲しくなるし*3自分が使ってた頃*4よりだいぶ進化している印象をうけたので久々につかってみたくなりました。
  • 「ウェッブエンジニアのためのローレベルプログラミング」 ハードウェアつながりでこちらも興味深く聞かせていただいた。プレゼン上手い。ローレベルといっても自分はC言語ぐらいでいいやという感じだったけどカジュアルにARMアセンブラから入るのがすごい。それでWEBアプリ作ってみようとは思えないけどRasPi買って必要になったら臆せずアセンブラも試して見たいとは思う。
  • 「Dockerで遊んでみよっかー」名前はよく聞くけど全く触ったことはなかったので揮発性のあるコンテナであるという話など基礎がわかってよかった。とりあえずセッション聞きながらvagrantVirtualBoxまではインストールしたけれど、プロダクション環境でつかうにはまだ課題が多いそうなので個人的にはしばらくは遠目にウォッチという感じかな。
  • Google BigQuery で DWH 構築 」最近hiveで集計したりしているけど何がつらいってちょっとしたクエリでも数十秒とかかかって、せっかちな自分は待ってる間に他のことしてたら忘れてて戻ったら結果間違っててやりなおしで全然進んでないみたいなのがよくあるので数秒で返ってくるとなる捗りそうだし試してみたい。
  • Plack for Fun and Profit (But Mostly Profit)」MasonとかClass::DBIとかレガシーなシステムを作りなおすのではなく活かしながら複数のpsgiアプリを組み合わせて再構成した話。つくりなおしたいって思うことは多いけど、既存資産をいかしつつビジネス的に現実的な判断をしていく姿勢は見習わないといけない。
  • 「Mobile Application Development for Perl Mongers [ninjinkun x gfx] 」まさに納得しない機能は作りたくないタイプの人間なのでユーザテストに参加するというのは実践したい。あとReactive Programmingも調べてみたい。
  • 「キーノート」 受託開発が楽しいという言葉を聞いた時最初「え?」って思ったけど、技術面やビジネス面でもチャレンジングな案件を選べるようになれば楽しそうだということがわかった。ただそうなるには自分に突出した技術と世間で認められるだけの実績がないと難しいだろうからすぐに真似できる話ではない。が目指したい姿ではあるので、目標として意識しつつ日々精進していけたらと思いました。

さいごに

Perlやってるところって増えてない(というか減ってる?)と思うけどYAPC::Asiaの参加者は毎年増え続けていてすごいイベントだなぁと思う。運営の方々は本当にお疲れ様でした。

*1:トークとデモのスタイルだと多分辛かったと思われる

*2:とこんなブログに書いたところで誰が見ているというのか

*3:プラグインはあるようですが

*4:あんまり覚えてないけど

ng-mtg#4 AngularJS 勉強会

AngularJS 勉強会( http://atnd.org/event/E0021975/0 )に参加してきました。

AngularJS @naoya_ito さん

  • jsフレームワーク、最近githubのスター数1位
  • MVW (Model View Whatever)
    • MVV◯とか議論するのは時間の無駄
    • AngularJSそのものを理解するのがいいと思う。
  • AngularJSの特徴
    • HTMLそのものがテンプレート
    • 双方向データバインディング
      • HTMLを変えると$scopeの値がかわる
      • $scopeのオブジェクトの値を変えるとHTML側の値が変わる
  • 典型的な双方向バインディング。{{name}}がng-model="name"の内容を表示。inputをいじるとnameが変わる
<input type="text" ng-model="name">
<p>Hello {{name}}</p>
  • 2つの特徴によって・・・
    • アプリ側はDOMの構造を知らない
    • jQueryやBackbone.jsだとアプリ側がDOM構造を知っている。 $('#button-id button').on('click', function() {});
  • HTMLからアプリを掴みにいく
  • HTML構造の変更に強い
    • HTMLそのものがテンプレート
    • アプリ側を知らなくてもDOMの構造を変更できる
  • アプリ側から見た目を動的に変えたいときは?
    • nShowやngClassを使ってHTML/CSS側で。ロジックでDOMの構築はしない
  • ふりかえり Angular JSでの開発の流れ
  • AngularJSの「制約」
    • HTMLにロジックはかけない
    • ロジック側からDOMを操作しにいけない
    • コントローラの責務範囲は特定のHTMLブロックに限定
    • 双方向バインディングによりコードが少なくなる
  • Angular JSの機能(いくつか抜粋)
    • リモートのJSONデータもバインド(ngResouce)
    • フィルタ(ng-modelでバインとしたモデルで、ng-repeatをフィルタ)
    • Form Validation
    • Directives ng-bindやng-modelなどを自分で作れる
    • 再利用可能なモデルに(services) テスト書きやすくなる。DIによってテストがしやすい
  • Angular JS雑感
    • Angular JSのDI
      • $scope, $route, $resource, ....
      • function定義を文字列としてパースしてDIしているので、引数名は注意
  • Angular JS得意・不得意
    • 1ページアプリケーション
    • JSONサーバが後ろに控えたCRUD
  • 不得意
    • グラフィック系
    • DOMいじる系
    • ゲーム
  • Angular JSの印象
    • 軽く動かすまでは簡単
    • 本格的に使おうとすると学習コストが高い
      • GruntとかYeomanなど周辺ツール知識も必要に
    • 強い制約と少ないコード量は複数人開発に向いていると思う
  • Angular JSもやもや例
    • HTMにng-modelとか書いてるからいいっていうけど、HTMLにonclick書くなっていってたような・・・
    • ドメインモデルを記述するベストプラクティスがよくわからん
  • まとめ
    • HTML拡張と双方向データバインディング
    • HTMLの変更に強よい
    • 高いテスタビリティ

OnsenUIについて

実戦! AngularJS (@sakatamさん)

  • プロジェクトについて
    • 開発期間3ヶ月
    • ECサイトのリニューアル
    • Mobile first
  • システム構成&人員構成
    • 旧構成 - レガシーSOA (RPC)からAngularJS, Node.js(REST), LegacyAPI(RPC), DBへ
    • UX 1, Front Engineer 2, Backend Engineer 1。全部JSなので人員の流動性高かった
  • なんでAngularJS?
    • GiltのメインプロダクトはBackbone.jsベース
    • Backbone.jsは柔軟性が高い反面、コード品質がばらつく
    • モジュールベースの開発を強制
      • DI/Module, APIのmock化が可能
    • Directiveによる画面の部品化
    • コントローラが薄くなる
  • 開発フロー
    • 1-3week 開発基盤づくり
    • 4-5week チーム展開
    • 6-12week 実開発
    • 基盤づくりに時間をかけた。ファイル構成やビルドプロセスを整備
    • DI/モジュールの概念理解
    • Directiveをハンズオンで理解
  • 開発イテレーション
  • 実戦投入Tips
    • 階層化されたモデル・データの状態管理
      • viewと直結しないモデルの状態をどう管理するか?
      • Google Groupsでも議論になっているが明確な答えなし
      • モデルを浅くして問題回避
    • $routeScope.$broadcast
      • 大域ジャンプ
      • 便利だけに中毒性ある。DIの意味なくなるので注意
    • 仮引数のMinify対応
    • リクエスト数の肥大化
      • アプリ本体&ビュー
      • httpコストが高いモバイルサイトは注意
      • ビルド時にバンドルする。webmakeとか。angular-templateでviewをバンドル
      • APIの設計を工夫
    • SEO/Crawler対策
    • 杞憂だったこと
      • Two-way Bindingによるレスポンス悪化( 変数のwatchをループで監視しているが大丈夫だった )
      • 遅延ロードによるレイアウト崩れも問題なし
      • AngularJS本体のサイズ。1回ロードされれば問題なし
  • まとめ
    • ほどよい制約・モジュール化の強制
    • Frontendエンジニアの底上げも
    • チーム開発には向いている

目指せ脱初心者!あなたの知りたかったAngularJS ( @agektmr さん )

  • 最初は超簡単だけど、いろいろやり始めると難しい
  • ユーザの悩み
    • ドキュメントが英語
    • Angular Wayがあるっぽい
    • 日本語の情報が少ない( Angular Ninjaとか出てきたけど )
    • 相談相手がいない
    • ドキュメントがわかりにくい。リファレンスはそろっているがどっから追えばいいのかわからない
    • みんなで相談だ
  • angularでDOMを弄りたいときはどうしたらいいの?
    • ファイルを扱いたい
    • angular.element(this).scope().load(this) ? これはいけてない。
    • そこで登場するのがdirectiveだが、ハードル高い
  • directive
    • linkがあればDOMの操作はできる
    • angularJSはjqLiteを内蔵しているので、bindなど簡単な操作はjQueryを使わなくてもいい。
    • restrict: 'A'とすると、attribute, 'C'にするとクラス、'E'にするとタグになる
  • angularで既存ライブラリとか使うのってあんま向いてないんでしょ?
  • controller間で変数をまたぐには
    • directiveには親子関係があり、子から親の変数は見れる
    • CSS Flexbox Please ! 本家の人が修正してくれたコード ( http://demo.agektmr.com/flexbox/ )
    • valueというのを使う。必然性はなさそう。普通の変数で共有してもいいとおもう。
  • webコンポーネント

LT

AngularJS始めました ( @Tkashiro さん )
Coffee ScriptとAngularJS ( @ntaoo さん )
  • CoffeeScript
    • Less typing, Bad readability
    • Simple, 安定
    • Class based OOP
  • Angular with coffee script sample.
    • html5mode(true)にすると楽しい
PHPとAngular JS ( @yando さん )
DirecviteにngAnimateをつけよう
  • ロード angular.module("mainModule", ["ngAnimate"]);
  • ng-repeatなどとあわせてclassで指定
  • 自作のDirectiveにもアニメーション設定可能
    • $animateで設定
AngularJSでmessagepackを使ったときに残念な思いをした話 ( @__yuunyan__ )
  • 通信まわりを後回しにしたらこれが地獄
  • JSON部分の結合がかなりつよくあとから分離できない
  • json parserでデータがパースされてしまいmesssagepackでデコードできない
  • http.jsとhttpBackend.jsに手を入れた
  • coreに手をいれたけどcontributeの仕方がわからない

「mixi Engineers' Seminar #2」参加メモ

http://atnd.org/events/16917

開発者のためのiPhoneAndroidアプリ移植のポイント

赤松洋介さま(サイドフィード株式会社)

http://www.slideshare.net/yoski/iphoneandroid-8455306

  • TwitCastingやっている
  • 会場参加者:iPhone開発者1割、Android開発者3割
  • 今日の資料はiPhoneからAndroid開発の流れ
  • Androidへの不安
    • 画面作成面倒、遅い、端末依存、Java遅い
  • 移植の手段
  • 結論 コード移植
  • 準備
  • Activity - View Controller
    • Activity間の呼び出しは難しいので、iOSでController間の呼び出しをしていると苦労する
  • Inteface Builder
    • 座標固定に注意
  • ソースコード移植
  • Point
    • JavaとObj-Cで共通の物も多い
    • NSString => String
  • リソース移植
    • 変換ツールを作成
    • 表示文字列はすべてリソース化。%@ -> %1$s
  • 画像など
    • ファイル名に-が使えない
    • @2xアイコンはdrawable-hdpiに
    • 国際化対応はAndroidの方が簡単。フォルダ名を-jaとかするとよい
  • ひたすら猿作業で移植
  • よかった点
  • 良くない点
  • 気づいたこと
    • 言語化がすごい楽(XMLやフォルダ名で吸収してくれる)
    • ThreadとHandlerの扱いが楽。iOS4も^{block}でちょっと楽になった
    • ほかアプリとの連携が楽。Activity素晴らしい
  • Design
    • XMLでいろいろ定義。iOSみたいにボタン押したときの表示などが用意されていない。
  • はまったとこ
    • Memory管理
      • Out of memory !
    • バイナリ周り。unsignedがない。Big Endian
  • 共通コード
    • C言語で書いていると、Android NDKでコードを共通化できる
    • HTMLはWebViewベースの箇所はほぼそのまま利用可能
  • 端末の設計思想
    • メニューボタンと戻るボタン
  • 反省
    • メニューがあるのでツールバー隠す>たくさんクレーム来た
    • ユーザには設計思想を押し付けるな
  • テスト環境
    • iPhoneはシミュレータが高速
    • Provisioningが面倒
    • Androidはシミュレータ動かん。端末のデバッグ簡単。apk配布楽
  • 端末依存
    • コードは正しくてもアプリは動かない
    • 毎月Android端末買いたしてます
    • それでも、ドキュメント豊富。yanzm女神
  • 審査
    • Androidは審査不要
    • Appleの審査は約2週間。最高42日待った。
  • まとめ
    • 画面作成。癖はあるけど大丈夫だった
    • アニメーションはXML書けば大丈夫
    • Java速かった
    • 端末依存ひどかった。
質疑応答
  • Q. Objective-CからJavaに移植するときの正規表現って何パターンぐらい作ったのか?
  • A. 作ったのは20パターンぐらい。YES/NOをtrue/falseに変換とか、-(void)をvoidにするとか

Windows Phone 7 アプリケーション開発概要

高橋忍さま(日本マイクロソフト株式会社)

  • まだ出てないけど・・・
  • ユーザのためのスマートフォン
  • トロデザインフレームワーク
  • ライブタイル、ハブ
    • ライブタイルにプッシュ通知で情報更新できる。現在の気温とか運行情報とか。
    • パノラマインタフェース。横長の巻物のような画面
  • ハードウェア
    • WVGA800x480、4ポイントマルチタッチ、CPU世代、5つのセンサー、500万画素以上の内蔵カメラなど厳しく規定
    • これらにより、13端末ほどでているが、ほとんど機種依存は心配しなくて良い
  • Windows Phone 7 アプリケーションプラットフォーム
  • Marketplace
    • トライアルができる
    • トライアルだったらという判定がAPIでできる
    • 24000本(6/29現在)
  • APP Hub
    • アプリケーション管理
  • アプリケーションの申請プロセス
    • Appleと同様
    • だいたい2,3日で公開される
    • 開発者登録は$99/1年
      • 品質面のテストもしてくれるので、質のいいテスターを雇ったと思えば安い
    • 70%収入シェア

mixi x Android深イイ話

藤崎友樹さま (株式会社ミクシィ

  • たんぽぽグループ
  • 2010年末 Android向けアプリケーション「mixi」の提供を開始
  • 開発の経緯
    • 連絡先連携のデモが評判に
  • 2010年10月
  • 開発環境
  • Jenkins(旧Hudson)
    • テスト結果をグラフ化してくれる
    • +Android Emulator Plugin
    • +Matrix Build
    • 環境の違いによる問題を発見
  • 開発要員
    • 2010年: 2人
    • 2011年: ほぼ1人
    • mixi API SDK for Androidは別チームで開発
    • 複数人での効率的な開発手法を模索中
  • mixi for Androidの紹介
    • 2010/12/24 1.0リリース
      • 17回アップデート
    • タッチでマイミクとか
    • SoftBank 007SH - 見た目ガラケー。中身はAndroid2.3
      • ソフトキーをエミュレート
    • 横向きをサポート
    • 大事にしたこと
      • 使いやすさ。Androidらしい導線、UI, UX
      • 機能の積極的な活用。ブラウザを超えたところにある体験を追求
  • ネイテイブアプリ開発に求められること
    • スマートフォン向けWeb開発との違い
      • フロントエンド+ブラウザ自体の開発
      • ネイティブ機能の開発
    • ブラウザ自体自分で作る
      • Web上の画像をダウンロードして表示
      • 6kバイトの画像を3Gでダウンロードすると1〜6秒からかかる
  • Android: 非同期処理は大前提
    • メインスレッドを止めない
  • 非同期処理を簡単にする道具
    • AsyncTask
    • IntentService
  • キャッシュも欲しい
    • 毎回取得は困る
  • 自分で作れ!
  • java.util.concurrent.Executor !
  • 既存ライブラリあった。Droid-Fu: WebImageView
  • キャッシュがあふれる。調べると嘘 Expires
  • ネイティブ機能の活用
  • ネイティブクライアント
    • 見せ方を変えるだけではない
    • サービスの再考も必要(プッシュ)
    • Webの延長とは考えない
  • 現状の「スマートフォン開発」
  • 書ける
    • GUIプログラミング
      • イベントドリブンなコード
    • マルチスレッド
  • 念頭に置く
    • ライフサイクル
    • 空間効率
    • 時間効率(バッテリー)
  • やってみないとわからないことだらけ
    • mixi API SDK for Android
      • ユーザのログイン手続きを省略できる
      • OAuth周りをハンドリングしなくていい(トークンのリフレッシュも自動)
  • まとめ
  • スマートフォン」にできること
    • 生活をかる
    • 概念を変える
質疑応答

Q. プッシュサービスでプロフィール画像が変わった際にキャッシュをクリアするという使い方はありか?
A. 今のところは予定はない。
Q. 端末や、対応するバージョンの方針は?
A. 最初はOSのバージョンだけ。2.2以上で作っていたが、当時まだメインが2.1だったため、2.1もサポート対象とした。対応機種はそれほど意識していない。
Q. テストは何機種ぐらい実施したか?
A. マーケットで使われている機種がわかるので、上位機種をいくつか選んでテストしている

「Titanium Mobileで始めるiPhone / Androidアプリ開発」のメモ

参加したメモです。

http://atnd.org/events/12449

  • Titanium Mobileで作られているアプリ
  • Titanium Developer
    • IDEじゃない
    • Aptana IDEで対応予定(3月後半リリース)
      • debuggerなども使えるようになる
      • 現在はprintデバッグが主流
  • iPhone環境構築
    • XcodeApple Developer登録、鍵作成など通常のiOSアプリ作成と同じ
    • Xcodeは対応バージョンを使う
      • Beta版は対応しない。正式版はすぐ対応
      • Betaなどで速く欲しい人はgithubを確認
      • 複数いれている場合はxcode-selectコマンドで最新版を選ぶ
  • Android環境構築
    • Android SDKインストール
    • SDKパスをTitanuim Developerで設定
    • Android SDK Tools R8以降では、platform-tools/adbをtools/adbにコピー
  • トラブルシュート
    • build/iphone/build/*とbuild/android/*を削除
    • Titanuim Developerを再起動
  • 同じコードでもiPhoneAndroidで見た目が違う
    • Titanium Mobileではそれぞれのプラットフォームのネイティブの部品が使われる
  • KitchenSink
    • デモアプリケーション
  • Titanium Mobileのアーキテクチャ
  • FAQ
    • 実用になる?
      • iPhoneはかなり完成している
      • Android版はサポートが遅れているが、1.6以降ならおすすめ
    • 学習中にどこで詰まる?
      • ドキュメントが英語。サンプル不足。HTMLはない(それは昔のバージョン)。進化が速い。
    • 速度は?メモリ管理は?
      • Obj-C/Javaよりは遅いので、リアルタイム性が高いものは厳しい
      • メモリ管理は自動(GC)
      • メモリもネイティブより食う
    • 得意/苦手
      • ネットのフロントエンドアプリが特に得意
      • アニメーション・エフェクトも楽
      • リアルタイム性が高いモノは厳い
      • 画像処理APIがない。カメラや回転縮小はある
      • JS <-> Obj-Cの行き来が簡単にできるので、そこで苦手分野はカバーできる
    • Appleの審査は通るの? -> 問題なし
  • アプリの作り方
    • 1window == 1source
      • Window間で独立したContextにより、複数人で同時につくる時に便利
      • 共有変数はTi.App以下にぶら下げる
      • Window間の共有は苦手
    • single context
      • AJAXに近い形
      • 変数は全体で共有
  • Titanium MobileはWEB系の技術者がスムーズに移行出来るように意識して設計されている
  • Feedの取り扱い
    • JSONのパースは簡単だけど、XMLは面倒
    • YQLモジュールが標準添付
  • 見た目がだいぶ違う
  • Pull to refreshでKitchenSinkを検索
  • OSはTitanium.Platform.osnameで判定
  • ロジックだけ共通化して、iPhone/AndroidそれぞれのUIを作る。
    • 各プラットフォーム毎にチューニングが必要だが、いいかえれば各プラットフォームらしいアプリが作れる
  • 先にiPhoneでひと通り作って、Android作成時にリファクタリングするのが効率が良い
  • 経験的に7〜8割はコードを共通化できる
  • デバッグ
    • Ti.API.debug()
    • API docの様に動かない場合はKitchenSinkを検索
    • 機能が足りない場合はモジュールを書く
      • loading indicatorを単独で回す機能がないなど(通信中は自動的に回る)
  • アニメーションテクニック
    • 標準のアニメーションを組み合わせて凝ったアニメーションも作れる
    • MogSnapの「食べたい」とか
  • Modern JavaScrtip
    • Titanium MobileではJavaScript1.6をサポート
    • CommonJS, JavaScriptオブジェクト指向, 非同期処理とクロージャ, Deferred
    • Ti.IncludeよりCommonJSのrequireの方がオススメ
    • この辺のModern JS勉強会もやりたい。[twitter:@masuidrive]などウォッチしてください
  • イベント処理
    • Deferredいいよ!非同期処理を書くときに階層が深くならない
  • 資料

質疑応答

  • Q. jQueryのUtilityなどを正式に対応する予定は?
  • A. eachとかmapとかはJS1.6の機能でできる。HTTPの通信部分をサポートする予定はない。同じような方法で通信できるモジュールがあったと思う
  • Q. Androidに実機転送できなくなる
  • A. USBを挿し直す。本体を再起動する。build/以下を消してから実行すると結構な確率で入る。あるいはAndroid側のUSBデバッグを一度解除してからつなぐといい。
  • Q. JSとネイティブを交互に行き来してもパフォーマンスはでるのか?
  • A. 十分でる。実際にコミックビューアの部分では、ビューアの部分はネイティブ実装して、速度のいらない部分はJSでというのがよい

「全文検索エンジンgroongaを囲む夕べ #1」参加メモ

参加メモ:http://atnd.org/events/9234

全文検索エンジンgroongaについて

発表者: (有)未来検索ブラジル 末永 匡 a.k.a. グニャラくん

  • 全文検索エンジンSenna
    • 2チャンネル検索のために作った
  • Sennaの特徴(1)
    • 高速なインデックス更新
      • 参照ロックフリーなデータ構造を採用
      • データ更新時に検索を阻害しない
    • 2ch地震速報板をすぐに検索したい
      • 検索の速報性が重要。Twitterなど
      • TwitterLuceneを使ってしまってへこんでいる
    • Senna全文検索「ライブラリ」
      • 転置インデックスをのみを更新
      • 本文、タイトル、作成者といった文書の情報を持たない
      • 文書情報はMySQLにやらせる
    • Tritonn MySQL + Senna
      • Sennaの利用≒Tritonnの利用
      • SQLを用いて全文検索ができた。全文検索、並び替え、グループ化、これらの組み合わせ
      • SELECT * FROM table1 WHERE MATCH(body) AGAINST('クエリ') AND last_update > '2010/01/31'
    • Tritonnのよいところ
      • MySQLの資産(人的にも物的にも)が使える
      • SQLを用いた柔軟なクエリが書ける
    • Tritonnの悪いところ
    • Tritoonの仕組み
    • MyISAMとテーブルロック
      • 更新時テーブル単位でロックを行うため、更新スループットが低下。更新時の検索を阻害
      • Sennaの特徴と矛盾している
      • TritonnではSennaの設計特性を活かせなかった
  • groonga *1
    • groongaの特徴
      • MyISAMに依存しない
      • 単体で動作
    • 文書情報の保存:カラムごとに保存
      • key-valueストアを並列に並べたイメージ
    • ベクターカラム(multiValued)
      • カラムの値として配列を保存できる
    • テーブルカラム
      • カラム値として、他のテーブルの行、もしくはその配列を保存できる
    • groonga単体で全文検索可能
    • プロトコル: HTTP GET, memcachedバイナリ, 独自、MessagePack(未実装)
    • クエリ言語
    • その他の特徴
      • ドリルダウン(ファセット)
      • ジオサーチ(地理情報検索)
      • サジェスト(検索キーワード候補の提案)
    • ドリルダウン
      • 検索結果を特定のカラムでグループ化。SQLでいうところのGROUP BY
      • ベクターカラムでも可能
    • ジオサーチ
      • ある地点からの距離計算
      • 楕円体としてキチンと計算している
      • 日本測地系世界測地系両対応
      • インデックスを用いて高速に検索可能
    • サジェスト
      • ユーザの検索クエリログを収集
      • 上記ログを収集し、おすすめのクエリを提案する
      • 今収集するところは自分で作らないといけない。将来的には自動にできるかも。
      • 提案、訂正、補完
    • SQL経由で使いたい
      • groongaストレージエンジン = MySQL + groonga
      • textsearch_groonga = PostgreSQL + groonga
      • あとの発表おたのしみに
    • 複数プロセスでの利用
      • 複数スレッド・プロセスで共有可能。更新時はロックされる
      • MySQLで更新、groongaデーモン経由でHTTPで検索
    • 分散構成
      • 直接のソリューションは現在ない -> アプリケーション側で頑張る
      • Spider/VPエンジンなどと組み合わせればできるのではないかと考えている
    • 使い方 http://groonga.org/docs/
    • 導入事例
      • groongaデーモン 某Webサイトでのアイテム検索
      • groongaライブラリ(Ruby) 某番組情報サイトの検索、buzztter
    • 注意点
      • 64bit専用
      • ファイルディスクリプタMAXあげる
      • カラムごとに1ファイル
      • ネットワークサーバも兼用
      • 可変長カラムの空間効率には改善の余地がある
    • まとめ
      • Sennaの特徴である「高速な更新」を真に実現するために書かれた全文検索エンジンである
      • LGPL2.1 開発者、バグ報告募集中
  • Q&A
    • Q.分散構成について。Spiderとの連携はどういう構成になるか?
    • A.Spiderの後ろにいるInnoDBをgroongaストレージエンジンに置き換える感じ。
    • Q.インデックスの分散はどうするの?
    • A.分散はSpiderが担当。groongaは分散されていることを意識しない。Spiderがわけたようにインデックスができあがる
    • Q.groonga自体が堅牢でも、ライブラリやOSの問題で異常終了したケースが想定される。その場合、InnoDBのような復旧システムはあるか?
    • A.更新中はいつ落ちても壊れるようになっているw ロックフリーな更新のために諦めている。元データは別で持っておくのが良いと思う。
    • Q.バインディングはどの程度?
    • A.作りたいけど手が回ってない。Rubyは結構できがいい。開発者募集中。HTTP経由ならどんな言語からでも簡単に使える
    • Q.データのオンラインバックアップは
    • A.更新してなければcpという素晴らしいコマンドで!w データのダンプ機能は持っている
    • Q.Sennaでファイルサイズが問題になっているがgroongaはどうか?
    • A.Sennaに比べて文書情報を保存する分ファイルサイズは大きくなる。転置インデックスのサイズはそれほど変わらない。

Ruby/groonga (rroonga/ActiveGroonga/Racknga) について

発表者: (株)クリアコード 須藤功平 (すとうこうへい)さん

 users.select do |record|
   record.name =~ "mo"
 end
    • クエリ重み付け
 record.match(query) do |target|
   # titleにマッチしたらスコア100, descriptionにマッチしたらスコア10
   (target.title * 100) |
     (target.description * 10 ) |
     (target.content)
 end
      • block内は一回だけ評価されるようにしている
    • rroongaをインストールするとgroongaも自動で入る
  • 利用シーン
    • インデクサ。Rubyで加工しながらデータ追加
    • データベースメンテナンス。バッチ処理
    • groongaの挙動確認 irb -r groonga
    • テストデータ作成
  • 利用例
  • ChupaText: 目標
  • ChupaRuby
    • HTTPインタフェース(予定)。テキスト抽出Webサービス
    • gemでインストールできるが、ChupaTextはインストールされない(ChupaTextのインストールは大変)
  • ActiveGroonga
    • Rails3 用groongaモデル
    • 実装はrroonga + ActiveModel
    • ActiveGroonga::Base
    • rake groonga:*
    • マイグレーション、バリデーション、リレーション
  • racknga
    • いれ場所こまった便利な物をいれている
  • Q&A 聴き逃した。。。。

MySQL + groonga (groongaストレージエンジン) について

発表者: 住商情報システム(株) 池田徹郎さん

  • groongaストレージエンジンとは
    • Tritonnの後継プロダクト。まだ置き換えるまでの品質まではいってない
    • MySQL 5.1/5.5 pluggable storage engine
  • Tritonnのコンセプト
    • MySQL全文検索を使えるようにする
      • MySQLのビルドインは、半角スペースで文章が区切られる言語圏のみ。日本語、中国語などがだめ
    • MySQLユーザのためのもの
    • 簡単に・シンプルに使えるもの
    • 安定して・安心して使えるもの
    • Tritonnアーキテクチャ
    • Tritonn patchの規模
      • parser /execution layer 19ファイル、899行のパッチ
      • myisam storage engine 32ファイル、1306行のパッチ
    • MySQLの規模
      • 2393ファイル
      • 160万行 原稿用紙8万枚相当
      • これだけの規模のソースにパッチを当てるのは大変。
    • Tritonnの品質向上スキーム
    • MyISAM依存による限界
      • MySQLは1プロセス、マルチスレッドモデル
      • MyISAMではtable lock。検索に関しては共有ロック、更新は排他ロック
  • groongaストレージエンジンのコンセプト
    • MySQL5.1+で全文検索を使えるようにする
    • MySQLユーザのためのもの + 柔軟性追加
    • 簡単に・シンプルに使えるもの
    • 安定して・安心して使えるもの
    • MyISAMから離脱、+さらに高速化
  • 公開場所 http://mroonga.github.com/ など
    • groongaストレージエンジンではDB-APIをつかって、MySQLのストレージエンジンを実装している
    • MySQL5.1 ソース/バイナリパッケージ配布中。MySQL5.5はソースからのみ
  • Tandem構成
    • MySQL with groonga storage engineで作ったファイルを、rroongaや、groonga HTTP Serverから読み書きできる
  • 仮想カラム
    • _id
      • groongaにおけるレコードの識別番号。
      • MySQLにはROW_IDの概念が存在しない(内部的にあるのみ)
    • _score
      • 全文検索のヒット時のスコア値
      • インタフェースがイケてない
      • メモリ節約のため
  • 従来からのORDER BY LIMIT問題
    • 100万件のレコードから先頭の100件だけ取りたい場合
    • 検索条件とorder byで指定しているものが複合インデックスでマッチすると非常に早く動くが、そうでない場合遅い
    • インデックスでマッチしない場合、ヒットした大量レコードを全部読み込む処理が走る。これが遅い。キャッシュが足りないと他のキャッシュが追い出される
    • データを読んだ上でscore値に用いてソート
    • Row IDをもとにしたランダムアクセス。場合によってはここがほとんどを占める場合もある。
  • ORDER BY LIMITの高速化
    • ストレージエンジンからクエリの情報が取れる
    • 全文検索+スコア取得+ソート+LIMIT適用
    • LIMIT指定件数のみレコードの読み取る。ここが高速化されると大幅に早くなる
    • スコアに基づくROWIDソート
    • ROWIDしていによるレコード読み取り(LIMIT 100)
  • その他実装済の高速化機能
    • カラムの刈りこみ
    • COUNT高速化
  • 大規模分散検索対応
    • Spider Storage Engineとの連携で対応を予定している
  • Current Development Status
    • 2010/11/29 ver0.4 alpha released
    • 近々betaになるかも
    • 開発者募集
    • [twitter:ikdttr]まで

MroongaとSpiderのコンビネーション(予定)

発表者: 斯波健徳さん

  • スコアソートでの全文検索
    • Spider検索エンジンでは、最初の段階ではスコアの高いものがどこにあるかわからない
    • スコアでのソートの場合は、全パーティションに同じSQLが並列実行され、結果が返却される
    • 100件のデータが欲しい場合、例えば3箇所に分散している場合、それぞれから100件ずつとる
    • そこで得られた300件をSpider側でソートして返却する
  • レンジパーティション条件でのソート
    • order by c1なら、c1が小さいパーティションから検索して、結果が指定した件数に揃った段階で返す
  • パーティションの分割条件に沿った絞り込み
  • ここで質問。これらはまだ実装できていません。どれぐらいできて欲しいですか?
    • 会場挙手半数以上。頑張りますw
  • Q&A
    • Q.最初scoreをつくっていなくて、後からつけたい場合は?
    • A.現状alter tableをサポートしていないので、create table時に作るしかない。ゆくゆくは対応予定
    • Q.他のテーブルとJOINした場合など、取得件数がたりなくなるケースなどは?
    • A.まだjoinには対応できていない。エンジン側で高速化ロジックが使えるかどうかを判定して、データが取得できないリスクがある場合は高速化ロジックを使わないなどの対応が考えられる
    • Q.複数カラムにまたがる全文インデックスの対応予定は?
    • A.groonga自体のマルチカラムインデックス対応が行われていない。groonga本体が対応すればgroongaストレージエンジンも対応する予定。
    • Q.NULL値を入れたら0になった
    • A.groongaではサポートできていない。設計時にはNULL値いらない方針だった?MySQLから使うにはあったほうがいいので再検討
    • Q.groongaストレージエンジンで、ベクターカラムのサポート予定は?
    • A.MySQLで持っているデータとのマッピングが難しいので、今のところノーアイデア
    • Q.mroongaという名前は使わないの?
    • A.時々使っている。別名として使ってください。

PostgreSQL + groonga (textsearch_groonga) について

発表者: フォルシア(株) 板垣貴裕さん

発表者資料:http://www.slideshare.net/ItagakiTakahiro/textsearch-groonga-v01

  • textsearch_groonga
    • バージョン0.1をリリース
    • PostgreSQL 8.3, 8.4, 9.0, 9.1dev
    • groongaなるべく新しいもの
    • 基本的な検索機能をサポート
  • 組み込みのtextsearch
  • 追加インデックス・アクセス・メソッド
    • textsearch_senna -> senna
    • textsearch_groonga -> groonga
  • textsearch_ja 固有名詞やカタカナ連語の検索漏れが怖い
  • SennaPostgreSQLはもともとは相性がよかった -> PostgreSQL8.3の機能HOT更新と相性が悪いことが判明
    • Sennaは文書削除時にももとの文書が必要だったため
  • PostgreSQLの拡張インタフェース
    • インデックスを拡張可能
    • やれることは限定的だが、拡張は容易。必要なのはハンドラ関数10個程度
    • トランザクション管理は本体に任せられる
  • 使い方
    • インストール
      • ソースからビルド。PGの開発用ヘッダ、ライブラリをインストール。makeで自動的にPGXSが使われる
      • データベースへの登録が必要 psql -f ...
    • インデックス作成
      • create index idx on t bl USING groonga (doc)
    • 検索
      • doc=キーワード - 比較演算子による検索
      • 単語検索 doc %% 'キーワード' - N-gramによる検索
      • doc @@ groonga.query('キーワード', '列と重み')
      • LIMITは悩ましい問題。多めを指定するとかリトライするとか
    • スコアリング
      • 行を識別するシステム列,tableoid, ctidを使って特定の行のスコアを取得
      • 行が更新されていると結果が0になることがある
  • textsearch_senna vs textsearch_groonga
    • 利点
      • スコアリングやgrn_expr等の機能を活用できる
      • text型以外に、スカラー型(数値、日時)もサポート
      • マルチカラム・インデックスをサポート
    • 欠点
      • ディスク消費量が多い(文書をDBとgroongaの両方で持つ)
      • (将来対応予定)LIKE演算子をサポートしていない
      • (将来対応予定)インデックスをDROPした際にゴミが残る
    • 類似点
  • ToDoと今後
    • LIKE演算子のサポート
      • textsearch_sennaで意外に人気の機能。LIKE "%foo%"とかでつくってしまった遅いアプリを後から救う
      • groongaにも機能はあるみたい?
        • UNIGRAM, BIGRAM, TRIGRAMの使い分けは?
        • 英数字も文字単位でインデックスするには?
    • PostgreSQLとの相性の向上
    • 標準SQLで仕様化されたストレージ・エンジン
      • PostgreSQL9.1に向けて開発中
      • groonga DBを、表として参照可能
      • 行志向のPG表と、列志向のgroonga表の使い分け
    • 標準SQLに含まれているのは参照処理のみ
    • この辺ができたらproongaを勝ち取りたい *2
  • まとめ
    • 現在おためし版をリリース中
    • textsearch_sennaの良いところ/悪いところを踏まえて作った
    • SQL/MEDが大本命
  • Q&A
    • Q.groongaのデータモデルとRDBMSのデータモデルはあわないので、フル実装は難しい。groongaを最大限に活かすのか、RDBMSの機能を残すのかどちらの方針か?
    • A.Postgresはmulti valueに対応する配列型を持っている。型サポートに関してはPostgresはフルサポート出来る見込み。
    • A.groongaストレージエンジンはMySQLから使えるのがうれしい。MySQLで頑張れるところはできるだけ頑張る。MySQLで頑張れ無いところはTandem構成で頑張る。UDF(User-Defined Function)を使いまくる。UDF動作するタイミングがレコード1件毎なので、その範囲ではいろいろ頑張れる
    • A.なにしてもいいなら、何でもしますよw 要望があれば頑張ります
    • Q.ORDER BY LIMIT, JOINしたときの問題にたいして、groongaからの解決案は?
    • A.Sphinx - MySQLプロトコルを受け取って、自前で全文検索結果をかえすものがある。そういうことをやればいろいろ頑張れるかも。
    • A.MySQLの場合はJOINのときは各テーブルに分解されて呼ばれる。ただストレージエンジンではもとのSQLが取れるので、頑張ればできるかもしれない。今後の課題として少しずつ制限を解除していきたい
    • A.Postgresの対応は、地理情報検索でN近傍検索ができるようになる見込み。テキスト検索のスコアを、あるスコアからの距離として返すことで、LIMIT処理を一般化できるかも。
    • Q.性能限界は?
    • A.インデックスもデータ量も、容量が重要。1テーブルに30bitレコードしか保存できない

LT 三日で作るGroonga関数

[twitter:hotpepsi]さん

発表者資料:http://www.slideshare.net/firewood/groonga

  • filterで呼べる関数を作る
  • しょぼいサーバでスループットを上げたい
  • 更新中も処理をとめたくない
  • 親子関係を持つテーブルから子のテーブルを探したい
  • 具体的には商品(1), 在庫・価格(n)
  • SQLの場合、JOINしてDISTINCT ? groongaの場合素直にできない
  • 親のIDでドリルダウンすれば2度引きで可能
  • 子テーブルで検索する
  • 重複するキーをfilterで捨てる
  • filterで使える関数を自作する
  • 自作の関数
    • 引数として親のキーを取る。
    • 格納済かどうかを返す
  • 雛形
    • testになるstrlen.cを参照して書く
    • とりあえずproc.cに登録
  • 正式なやり方
    • configure.ac
    • autoreconf
    • 大変なので省略
  • 手抜き
    • Makefile.in
    • .SUFFIXESに.ccを追加
    • CCLD g++に書き換える
  • groonga関数意外と簡単につくれます

*1:Sennaとう名前はSEO的に良くなかった

*2:Pは敵が多いので早めに

第4回Solr勉強会

第2回から3回目の参加。
http://atnd.org/events/9458

1.Lucene Revolution 参加報告

Basis Technology 平賀一昭 (日本支社)さま, 黒坂輝彦(サンフランシスコ支社)さま

  • Lucene Revolutionとは
    • Lucid Imagination社主催によるLucene/Solrに関するユーザ会議
  • Lucid Imagination社
    • LuceneとSolrの商用利用促進のために設立
    • コミッタが多数参加
  • エンジニア向けトレーニン
  • BASISさん主催
    • Solrアプリケーション開発3日間コース
    • 「Solr勉強会で聞いた」で10% Off !
    • 本年度中に申し込みで20% Off!
  • Lucene & Solr User Conferenceについて
    • ハイアットハーバーサイド(ボストン空港のすぐそば)
    • ダウンタウンは遠い。カンファレンスに集中しろって?
  • 会場の様子
  • Lucene/Solrロードマップ
    • 各々のコミッタがやりたいことを主張しているだけ?
    • Solr Cloud、大規模処理、リアルタイムが大筋の方向性っぽい
  • TwitterでのLuceneの活用
    • A Billion Queries Per Day1日10億クエリー
    • MySQLからLuceneへ以降
    • Luceneの索引周りを改変している模様
    • かなりマニアックな内容
    • 1000 tps (tweets/sec) => 80M tweets/day
    • 12,000 qps => 1G queries/day
    • tweetから10秒latency( tweet後検索できるようになるまでの時間)
    • tweetから1秒いないにindexing
    • 最新のつぶやきを最初に表示したい 索引項目中のdoc listの後ろからスキャン
    • 全部検索しないで途中でうちきり
    • LUCENE-2329前 postingListはクラスオブジェクトを指していた。オブジェクトの生成が必要で効率が悪い->三つのArrayに分割して効率があがった。Lucene4.0で出てくる?
    • docIdとpositionを別々に持っていた。Twitterは文字数が少ないのでpositionは1バイトでよい。docIDを24bit、positionを8bitで表現 > ひとつのintに押しこむ
    • Lock-freeアルゴリズム(スレッド間の同期でロックを使わない)
    • volatile変数ひとつを使って、スレッド間の同期をとる話
    • Java言語規約を深読み。volatile変数の処理順?が決められている
    • 実際はJVM内でロックしている気もする
  • Solr 3.1とその後
    • LuceneとSolrサブプロジェクトの合併
    • 次期リリースはSolr 3.1 (Solr 1.5ではなく)
    • 現在trunkにあるのは、Solr 4.0になる?
  • Solr 3.1新機能
    • 拡張DisMaxパーサー。Luceneパーサの構文をサポート。例外をおこらなくするのが目的だった。それを教科。Boostは加算のみだったのが積算で出来るようになる
    • 空間・地理検索。緯度経度情報をもとに検索
    • 結果のグループ化/フィールドたたみ込み(collapsing)。グーグルの同じサイト内の検索結果をまとめるやつ。任意のフィールドでまとめることができる
    • ファセット機能改善。ピボットとして指定されたフィールドによってさらに再分割できる。数値の範囲も指定できる
    • Solr Cloud。シェーディングするときにホスト名を羅列しないでよくなる
  • 柔軟な索引(?)
  • LucidWorks Enterprise
    • Solr + GUI管理ツール + クローラ+ いろいろ
    • 有償(要サポート契約)
    • アプライアンス並の簡単設定
    • DB連携もサポート
    • 現在Early Access
    • 来年初旬GA
    • 目玉機能
      • クローラ、DB連携
      • Click Scoring 関連度フレームワーク
      • アラート
      • REST API。管理機能も
      • セキュリティ
      • スケジュール機能
      • 改良型クエリー・パーサ
    • サポート料は未定

2.SI向けパッケージ製品でのSolr利用と事例紹介

 (株)NTTデータ イントラマート 清彰宏さま [twitter:@seikun]さん

  • ちょっとだけ会社紹介
    • intra-martという開発基盤パッケージ製品を開発
    • 以上!
  • 謝辞
    • 素敵なTシャツとか配れません
    • パンフレット用意してません>社長すいません
  • Solrを利用した製品の話( IM-ContentsSearch )
    • 標準でインストールされる。Solrは別でセットアップ
    • コアAPIはcmecab-java作者の武田さんが作成されたものを使用
  • intra-martの機能
    • ユーザ管理系のマスタとAPI
    • 権限管理系のマスタとAPI
    • メニュー&ポートレット管理
    • 簡易ばっち機能
    • ワークフロー&BPMエンジン(一番の売り。日本の業務に特化している)
    • Server Side JavaScriptを約12年前から採用(エンジンは昔はiPlanet, 今はRhino)
    • グループウェアとしてIntranet Start Packもあります
  • IM-ContentsSearch
    • ワークフロー、スケジュール、ブログ、掲示板、文書管理。これらを全文検索(コンテンツ内容&添付ファイル)
    • 業務データのクローラ作成 -> 全文検索(売れそうなのに売れない・・・)
    • コアはひとつだけ
  • Solrの利用について
  • 専用スキーマを設定
    • 形態素解析フィールド
    • コンテンツタイプフィールド。ただの文字列配列フィールド。業務とかグループウェアのどの種類かを判別
    • 参照許可・不許可フィールド。ただの(ry。エンタープライズでは重要
    • 参照許可・不許可フィールドをフィルタクエリで検索(速度の観点)
    • わりと普通につかっている
  • 事例紹介
    • 社内の共有ファイル3TBを社内システム(intra-mart)から全文検索したい
    • 頑張って上司を口説いた>「やりましょう」
    • Solrでの開発は楽しかった・・・・が苦しい道のりの始まりだった
  • 基本的な設定など
    • Tomcat 6.x
    • cmecab-java-1.3
    • jcifs-1.3.14 ActiveDirectoryだったので
    • jvm : -Xmx, -Xms 12G。他はfessを参考にチューニング
  • 形態素解析
    • 定期的にipadicのユーザ辞書を更新(品番・品名・特殊な略称などへの対応)
  • ActiveDirecotyとの権限情報の連携
    • jcifsで接続して権限情報を取得
    • intra-martのグループに専用ツリーを作成
    • ADの権限をバッチで同期
    • 検索クエリに反映される
  • 独自でクローラを開発
    • 索引化対象の詳細な設定が可能
  • クロール時の苦労話
    • データセンタに共有ディスクはない>ファイルは拠点ごとにある
    • データセンタの外向き帯域は??>15Mbps
    • 対象ファイルは3TB
    • 全部クロールするのに20日の計算(帯域全部使ったとして)
    • 100M以上のファイルは文書数の2%なので対象外(データの40%を削減)
    • お客様の現地でのクローリング1.2T/1.8Tできた
    • のこり4日でクロールできる。>初期移行可能に
  • これから
    • 本番運用開始から5ヶ月経過
  • しめ(SIでの)
    • 社内用語(商品名、品番、略称)があり、辞書の拡張(形態素解析前提)が必要
    • ソリューション化しないと学習コストがたかくなりがち
    • 汎用的なスキーマ定義が必要(dynamicFieldを多用するなど)
    • スループット応答時間の要求は低い
    • 次回Solr 1.3からSolr 1.4への移行(イントラマートの場合)
  • Q&A
    • Q. 1.8Tのドキュメントでインデックスは?
    • A.200Gで済んだ
    • Q.差分更新はどうしている?
    • A.更新日付をつかってチェックしている。削除には専用のクローラを作っていて存在チェックをしてなければインデックスから消す
    • Q. JavaVMのGCは発生しない?
    • A. かなり発生している。マルチコアのCPUなので分割GCで対応。クローリング中は80〜90%くらいCPU使う。コンカレントGC使っている

3.Field Collapsing/Result Groupingについて

 (株)シーマーク 大谷純さま

  • Field Collapsing / Result Groupingの概要
    • SQLでいうdistinctやgroup byのような機能
    • SOLR-236としてJIRAに登録
    • Solr 1.4.1時点で正式にサポートされていない
  • Field Collapsing(SOLR-236)について
    • Solr1.4.1にSOLR-236-1_4_1.patchを適用
    • QueryComponentの代わりにCollapseComponentを利用
  • 動作
    • 検索にヒットするドキュメントセットを取得
    • 取得したドキュメントセットをcollapse.fieldの値をもとにHashMapを利用してグループ化
    • 残念ながらtrunkに採用されず。今後メンテナンスされない可能性大
    • Distributed Searchを利用できるのはいいところ。Result Groupingは対応していない
    • collapse.fieldにmultiValuedのフィールドは指定できない
  • Result Grouping (SOLR-1682 => trunk) について
    • trunkのSolrに利用( Solr 4.0 ) Solr 3.1からいける?
    • QueryComponentの機能として実装されているため設定不要
    • グループ化を行うために2回の検索
    • 検索にヒットするドキュメントセットの中のトップグループのドキュメントを取ってくる
    • クエリーの結果が同じもの、関数の結果が同じ物など、いろいろグループ化できる
    • troup.query=age[20 TO 39]などができる
    • Distributed Searchは未対応
    • 総グループ数が不明
    • multiValuedフィールドでのグループ化は未対応
    • SolrJも未対応
  • 結論
    • Result Groupingの実装を待てる場合は待つ
    • 今すぐ使いたければField Collapsingを利用
    • 利用しない手を考えるのが現状は妥当かも

4.全文検索エンジンgroongaについて

 (有)未来検索ブラジル 末永 匡さま [twitter:@tasukuchan]さん

  • プロローグ
    • 人に歴史あり -> groongaにも歴史あり
  • 全文検索エンジンSenna
    • 高速なインデックス更新
      • 参照ロックフリーなデータ構造を採用
      • データ更新時に検索を阻害しない
    • Twitterなどのリアルタイム検索をターゲット
    • 全文検索「ライブラリ」
    • 文書情報の保存 -> MySQLにやらせれば?
    • Tritonnのクエリ
      • SQLを用いた柔軟な問い合わせ。並び替え、グループ化など
    • Tritonnのよいところ
      • MySQLの資産が使える(人的資産、ソフトウェア資産)
      • SQLを用いた柔軟なクエリが書ける
    • Tritonnのよくないところ
      • 特にチューニングしないSolrとTritonnなら、Solrが10倍以上速かった
      • 更新が遅い!
      • 更新時に、検索スループットが悪い
      • 高速な更新をうたっていたのに??
    • Tritonnの仕組み
      • TritonnMyISAMの性能特性に引きずられた
      • MyISAMはテーブル単位でロックを行う
      • Sennaの構造と矛盾している -> Sennaの設計特性を生かせていなかった
    • めざせTritonn越え -> grroonga
  • groonga
    • 文書の情報も保存。単体で全文検索可能。MySQLにもMyISAMにも頼らない -> 高速な更新を活かせる
    • 文書情報の保存:カラムごとに保存 key-valueストアを並列に並べたイメージ
    • ベクターカラム(multi valued)
      • (例)タグ
    • テーブルカラム
      • カラム値として、他のテーブルの行、もしくは配列を保存できる。1対Nのデータを扱える
    • 単体で全文検索可能
      • ネットワークサーバとして起動。HTTP GET, memcached, 独自プロトコル、MessagePackも予定
      • HTTP経由では管理ツールが利用出来る(phpMyAdminみたいなもの)
    • クエリ言語
    • コマンドライン
    • groongaライブラリ。C言語Ruby
    • その他の特徴
      • ドリルダウン(ファセット)
      • ジオサーチ(地理情報検索)
      • サジェスト(検索キーワード候補)
    • ドリルダウン
    • ジオサーチ
      • ある地点からの距離計算
      • 矩形内
      • 楕円体としてきちんと計算しているよ!
      • 日本測地系世界測地系両方に対応(アメリカが中心じゃなくても大丈夫)
      • インデックスを用いて高速に検索可能
    • サジェスト
      • ユーザの検索クエリログを収集。変換途中も含めて全て収集
      • 上記ログを解析し、おすすめのクエリを提案
      • 提案「全文検索」-> 「grooonga」
      • 訂正「gloonga」-> 「groonga」
      • 補完「gro」-> 「groonga」
    • SQL経由で使いたい
      • groongaストレージエンジン。MyISAMそのものを置換
      • textsearch_groonga PostgreSQLのインデックス拡張
      • 現在開発中
    • 複数プロセスでの利用
      • 複数スレッド・プロセスで共有可能
      • MySQLで更新しつつ、groongaデーモン経由でHTTP検索。参照ロックフリー
    • ドキュメント
  • 導入事例
    • groongaデーモン。某Webサイトでのアイテム検索
    • groongaライブラリ(Ruby)
      • 某裏組情報サイトの検索
      • buzztter
  • groongaとSolr
    • 1つの判断規準。「ゾウの時間ネズミの時間」
    • 技術というのは次の3つの点から評価されなければならない
      • 使い手の生活を豊かにすること -> 実運用に近い環境で所定の性能がでるかどうか
      • 使い手と相性がいいこと -> 実際につかってみててになじむかどうか
      • 使い手の住んでいる環境と相性がいいこと -> Javaで運用しているならLucene/Solrがあっている
  • まとめ
  • Q&A
    • Q.KVSの場合シーケンシャルな扱いが苦手。range scanなどはうまくいく?
    • A.KVSと固定長と可変長のものをわけている。固定長のものはシーケンシャルな扱いはうまくいく。トランザクションをサポートしていないので、range検索しているときに違うものが入ってくることはある。
    • Q.大規模なデータに対するものと、拡張性はどうか
    • A. 参照が大規模な場合は、MySQLエンジンをちゃんとかけば、MySQLレプリケーションが使える。更新が多い場合はシェーディングが必要。Spiderストレージエンジンなどと組み合わせて高速な更新ができる想定
    • Q. Tokenize機能は?
    • A. bi-gramとmecabが入っている。bi-gramで1文字検索も高速にできる

LT: Solrの重複uniqueKeyの扱い

ECナビ春山さん

  • 単一のshardの場合はないが、複数shardの場合で重複する場合がある
  • QueryComponent.javaで処理されている
    • uniqueKeyの重複を検出したら、最初に見つかったものが結果に入る。以降は処理しない
  • uniqueKeyを重複させたい場合
    • 一部の文書だけ頻繁に更新したい
      • 最新情報の反映(価格、在庫など)
    • 更新は重たい
    • 更新用のデータ数の小さいshardをつくる
    • shardの名前の大小で優先順位をつける
    • timestampNoフィールドで優先順位をつける
    • 作ってみた

YAPC::Asia Tokyo 2010にgihyo.jpさんのレポータとして参加させていただいた

id:hirataraさんのお誘いにより、10/14〜10/16の間YAPC::Asia Tokyo 2010(http://yapcasia.org/2010/)に技術評論社さんの「YAPC::Asia Tokyo 2010スペシャルレポート」(http://gihyo.jp/news/report/01/yapcasia2010)レポータとして参加させていただきました。個人的な感想を書いておこうと思います*1

担当したセッション

以下のレポートを担当させていただきました*2
これらのセッションに関する文責は私にあります。誤植などありましたらコメントなりTwitter( [twitter:@usuihiro] )宛なりでご指摘いただけると助かります。出来る限り早急に修正させていただきます。

10/14 前夜祭
  • sugyanさん「Ark」
  • tokuhiromさん「Amon」
  • スペシャルゲスト対談
10/15 1日目
  • Kazutake Hiramatsuさん「Modern Perl Web Development on Amazon EC2
  • Tokuhiro Matsunoさん 「モダンな Perl5 開発環境について - Modern Perl5 Development Environment - 2010年代を生きのびる Perl5 活用術」
  • Hiroki DaichiさんInside Mixi - ソーシャルネットワークを支える技術
  • Lyo Katoさん「DataPortability and SocialWeb Protocols」
  • Jiro Nishiguchiさん「Write Good Parser in Perl
  • Seiji Haradaさん「mixi チェックインの裏側」
  • keroyonnさん「非同期タスクの通知処理 with Tatsumaki
  • 吉見 圭司(walf443)さん「Webサービスのページング処理について」
10/16 2日目
  • gfxさん「How Xslate Works - The next generation's template engine」
  • overlastさん「Perl自然言語処理
  • cho45さん「映画にでてくるハッカーになりたい」
  • kazuhoさん「perl-casual特別企画 Unix Programming with Perl
  • perl-casual特別企画 PMグループディスカッション」
  • 横山 彰子さん「perl-casual特別企画 Perlをするとこんないいことあったよスペシャル」
  • Yusuke Wadaさん「perl-casual特別企画 NoSQLで作るTwitter解析サービス」
  • sugyanさん「perl-casual特別企画 とある自社サービスの運用事例」
  • Tatsuhiko Miyagawaさん 「Keynote - The Tale of Plack
下書き

前夜祭は練習も兼ねて大体下書きしましたが、信頼のhirataraブランド*3で全て公開されているので省略します。
1日目以降はセッションがかぶってないので私担当分をさらしておきます。(結構間違ってそうなので消すかも・・・)

http://d.hatena.ne.jp/usuihiro1978/20101015/p1
http://d.hatena.ne.jp/usuihiro1978/20101016/p1

感想

  • 誘われたときにIRCにて

hiratara:「感想文がかければいいですよ」
usuihiro:「小学校の宿題の読書感想文とか提出したことありません(キリッ」
というやりとりをしたのですが、上記の通り文章く自信がないので結構疲れました。。。

  • とはいえ楽しかった。イベントに行っても寝落ちしちゃったりして勿体無いないなぁと思うことがよくあるけど、レポート書かないといけないとなると必死でメモらないといけません。そのために真剣に聞くので結果的に得るものも多くて有意義だったと思う。
  • 書く加減で悩んだ。やはりgihyo.jpの名を冠してレポートするわけなので、あまり個人的なことを書き過ぎるのも良くないだろう。草とか使うのもおかしいし言い回しに気を遣う。かといってスライドの丸写しだと発表者のものを参照したほうが正確だし、淡々と書きすぎるのも価値がない気がして結構悩んだ。内容についても細かすぎるのもあれだし、かといってはしょり過ぎるのもよくないし。エッセンスを抜き出して綺麗にまとめるのがいいんだろうけど、それがまた難しい。この辺については書き終わった今もこれでよかったのかはわからない。本当はもっと口頭で話されたこととか、会場の雰囲気とか伝えられるとよかったんだろうけど、スライドのメモで必死であまりそこまで伝えられなかった。今後の課題ですね
  • 雰囲気を伝えるのは難しい。cho45さんの発表とか相当おもしろかったけど、字面だと伝わらない。miyagawaさんの発表も相当感動的だったけど、あんなレポートで申し訳ないなぁとか。力量不足を痛感しつつ、精進するしかないですね
  • やっぱり次は発表者になりたいと思ったとか思わないとか
  • id:hirataraは偉大だった*4

最後に

感想のところでは苦労ばかり書いていますが、本当に参加してよかったと思っていますし感謝しています。最後に貴重な機会をもたらしてくれたid:hirataraさん、perlに関してなんの実績もない私をレポータとして受け入れていただいた技術評論社の高橋さん、このような素晴らしいイベントを提供してくださったYAPC関係者の皆様に感謝いたします。本当に有難うございましたm(_ _)m *5

*1:最近xxに行ってきた系しか書いてないけど・・・・

*2:見る人がみればわかったかもしれませんが清書が遅かったのはほぼ私担当です。。。

*3:http://d.hatena.ne.jp/hiratara/20101014/p1

*4:まとめ速すぎ

*5:顔文字も表現には便利だけどレポートには使えないよね。。。w