はてなブックマーク

ElasticSearch でインデックス時と全文検索時で異なる analyzer を設定する 前回は ElasticSearch が全文検索クエリを処理する際の分かち書きのしくみについてふれました。ElasticSearch ではさまざまな種類の tokenizer を中心に analyzer を設計することができ、この analyzer が実際に文字列の単語分割を行ってくれます。 ElasticSearch ではインデックスに格納するドキュメントの内容（フィールドの値）と、全文検索クエリの検索キーワードに対して分かち書きが行われますが、この 2 つに対して異なる analyzer を適用することができます。今回は、インデックスにドキュメントを格納する際の転値インデックス作成時と、検索キーワードを渡した全文検索クエリでの検索時とで、異なる analyzer を利用してみたいと思います。

ElasticSearch で文書を検索をしてみる ElasticSearch で提供されている代表的な文書の検索機能には、全文検索クエリと Term ベースクエリがあります。全文検索クエリは、検索時のキーワードが含まれているるドキュメントを探し出すための検索クエリです。一方 Term ベースクエリは、検索時のキーワードが完全に一致するドキュメントを探し出すための検索クエリになります。 よくある検索エンジンのようにキーワードが含まれている WEB ページを探すというような用途では全文検索クエリが適していますが、ユニークなキー値のようなものをキーワードにして、そのキー値が割り当てられている文書を探すような用途では Term ベースクエリが適しています。全文検索クエリではあらかじめ文書が単語に分割されて、その単語に対して検索が行われますが、Term ベースクエリでは文書が単語に分割されず、キー

python の pip でインストールできる自作モジュールを作ってみる Java にはライブラリの依存性を管理するためのつーるとして Maven や Gradle がありますが、Python の世界にもパッケージ管理ツールとして pip があります。コードの規模が大きくなってくるとモジュール化は避けては通れない課題なので、今回は pip を使って、Python での自作モジュールの作成と呼び出しをしてみようと思います。 自作モジュールを用意するまずは作業をするための自作モジュールのディレクトリを作り、その中に移動します。ディレクトリはなんでもいいですが、わかりやすいようモジュール名と同じにしておきます。$ mkdir libhollow $ cd libhollow このディレクトリ内に、自作モジュールのためのファイルを用意します。 ディレクトリ内に、さらにモジュール名と同じディレクトリ

Hive を構築して Hadoop とつなげてみた 引き続き Hadoop でいろいろ試してみるシリーズです。 前回は Hadoop 本体を構築し、HDFS に配置したファイルを使って簡単なデータ分析をしてみました。取り扱ったデータが小さい上に、実際には単体構成な Pseudo-Distributed Mode だったのでアレですが、Hadoop の概要のようなものが少しずつ見えてきました。 Hadoop ではやはり HDFS という独自のファイルシステムを扱うことが特徴的で、実際に HDFS 上にファイルを配置し、処理を行うというのは、自動化を考えるとなかなか大変そうでした。この HDFS を使ったデータ処理をより手軽に行うための周辺技術として、古くから Hive というコンポーネントが使われてきました。Hive を利用することで、HDFS へのファイル配置や参照・集計といった処理を、H

svn リポジトリをローカルにコピーしてから git リポジトリに変換する 今年になって、個人的なコードを書き溜めていた svn リポジトリを徐々に git に移行しています。 私はフリープランでもプライベートリポジトリを無制限に作れることから、数年前から assembla を使っていました。しかし最近（？？）になってフリープランで作れるリポジトリ数に上限が設定されたようで、新しいリポジトリが作れなくなっていました。有料プランへ乗り換えられればよかったのですが、リポジトリ数をふまえて開発予算（お小遣い）と相談した結果、やむなくお世話になった assembla から bitbucket に移住することにしました。念のため強調しておきますが、これまでながらく愛用していたことからもわかるとおり、assembla 自体に不満があるわけではありません。あくまでやんごとなき事情（お小遣い）のため、泣く

Python nose でユニットテストを書いてみた chocolablog は Python で書かれていますが、これまであまりユニットテストの整備に時間を割いてこれませんでした。しかし初期バージョンの開発から 2 年以上が経ち、その間に何度か sqlite3 をとりまく DB アクセス部分を中心に、処理を書き換えています。他のロジックはともかく、コアとなるコードはしっかり動作を担保しておくべきだなと感じ、ユニットテストの整備に着手することにしました。 Python では 2.1 移行、ユニットテストフレームワークとして unittest が組み込まれています。これは個人的に大好きな JUnit をベースに作られているそうです。ただネット上で目にした Python 系のオープンソースプロジェクトでは、この uniittest モジュールではなく nose というモジュールを使ってテストコ

svn リポジトリをローカルにコピーしてから git リポジトリに変換する 今年になって、個人的なコードを書き溜めていた svn リポジトリを徐々に git に移行しています。 私はフリープランでもプライベートリポジトリを無制限に作れることから、数年前から assembla を使っていました。しかし最近（？？）になってフリープランで作れるリポジトリ数に上限が設定されたようで、新しいリポジトリが作れなくなっていました。有料プランへ乗り換えられればよかったのですが、リポジトリ数をふまえて開発予算（お小遣い）と相談した結果、やむなくお世話になった assembla から bitbucket に移住することにしました。念のため強調しておきますが、これまでながらく愛用していたことからもわかるとおり、assembla 自体に不満があるわけではありません。あくまでやんごとなき事情（お小遣い）のため、泣く

Linux 環境でマルチコア CPU を利用した python プログラムを書く マルチコア CPU を利用した python プログラム、と言っても、Linux 環境ではプロセス単位で CPU が割り当てられるので、つまりはマルチプロセスを意識したプログラミングになります。 java でマルチコア CPU を利用しようとするとマルチスレッドで実現することになりますが、python の場合はわかりやすく別プロセスで実現されているため、ps や top コマンドで見えて面白いです。 python ではマルチプロセス用に multiprocessing モジュールが用意されていますが、今回はひとまず古典的な fork() 関数を使い、実際に複数のプロセスがマルチコア CPU によって処理されている様子を見てみたいと思います。 どちらかというと新人さん向けのプロセスのお話になってしまいましたが、

Linux でマザーボードの情報を調べる うちの開発用マシンは、今はなきクレバリーのショップブランド PC です。 買ったのは 2008 年 11 月。当時にしてはそれなりのスペックだったはずなのですが、4 年も経てばさすがに時代に取り残された感が拭い切れず、この度増強をすることにしました。 が、メモリを増やそうにも肝心の最大認識量がわからず。 納品書にはマザーボードのチップセットしか書かれていなかったのです。 Windows ではマザーボードを調べるフリーソフトがありますが、 Linux ではどうなんだろうと調べてみると、dmidecode コマンドを使うと表示することができるそうです。 ということで Fedora さんにて yum してみました。 実行結果はこちら。# dmidecode # dmidecode 2.11 SMBIOS 2.4 present. 38 structure