検索エンジンを作る（予定）その3 〜 HBaseを分散モードに移行

過去の記事

• 第1回: Nutch + HBaseを動かすまで
• 第2回: Nutchの動作を解説

背景・前提

HBaseじゃなくてMySQLを使えば？

Nutch + HBaseのクローラーが動作するようになったが、正直1台で動かすならMySQLを使ったほうが色々楽だし、データの抽出も楽。

HBaseを使ったほうがいい場合というのは、データが非常に多い場合ってのが共通認識らしい。1台で扱えなくなる位の大規模なデータ。その場合、当然HBaseも複数台で動かすことになる。

今は、データが100GBに満たない程度だし1台なんだけど、そもそも今回は勉強も兼ねているし、今後データが増えてくるとも限らないので、引き続きHBaseを使っていく。

HBaseの動作モード

HBaseには以下の3種類の動作モードがある。詳しくはこのへん。

• スタンドアローン
• 擬似分散モード
• 分散モード

Nutch + HBaseのチュートリアルに従うと、スタンドアローンモードでHBaseが動く。それを今回分散モードにしてみる。

第1回初心者向け分散処理勉強会

第1回初心者向け分散処理勉強会は無事終わりました

11人が集まりました。飲み物無料の懇親会も！

2/4（月）に分散処理勉強会を開催しました。当初は内輪2名で話をしていて、その後Twitterで声をかけたところ何人からか返信を頂いたので、まぁ4〜5人でやろうかなと思っていたのですが、Partakeにイベントを立てた所思ったより参加登録が多く、最終的には11人が集まりました。

Partakeはこちら。
進め方はこんな感じでどうでしょう？って皆さんに聞いた所、進め方に関しては特に異論がなかったので、そんな感じでやる予定。

太っ腹なVOYAGE GROUP様には勉強会の会場、懇親会の会場、そして飲み物を無料で提供していただき。ありがとうございます。1人1000円でピザを宅配して、無料の飲み物とともに軽く懇親会をしました。

月1で開催決定。ハッシュタグは #bunsan

今後の開催はとりあえず月1回で、次回は3/4に同じくVOYAGE GROUP様会議室にて実施予定です。

公式ハッシュタグは多数決で #bunsan に決まりました。

毎回、有志の方々が発表＆質疑応答というスタイルで。発表内容は分散処理に関係すれば何でも。3分程度のLTでも1時間の発表でもOKです。

Magnet Patternを使って、type erasureで同じ型になるオーバーロードの問題を解決する

久しぶりにプログラミングネタ。

背景

List[Int]もList[String]もバイトコードでは同じ

type erasureについて知ってる人は飛ばしてOK。

知らない人向けに簡単に説明すると、Scalaでは（Javaでも同じだけど）以下の様なメソッドのオーバーロードは定義出来ない。理由はList[String]とList[Int]がバイトコードレベルでは同じなので、2つのfooメソッドが同一のシグネチャになるため。詳しくは「type erasure」や「型消去」でググって欲しい。

// won't compile
class C {
  def foo(list: List[Int]): SomeResult = {
    // ...
  }
  def foo(list: List[String]): SomeResult = {
    // ...
  }
}

解決方法

一応、解決方法はいくつか思いついた。

• fooの中で要素の型をチェックして処理を分岐
• Manifestの型によって分岐

で、とりあえず後者で実装してたんだけど（※1）、もっといい方法はない？ってScala勉強会で質問した所、りりろじるんるんさんから以下の2つを教えてもらった。

• implicitパラメータを使う方法（※2）
• Magnet Patternを使う方法

※1 Manifestを使った方法は、勉強会のスライドの後半部分を参照。
※2 異なるimplicit parameterを渡すことによってシグネチャを変える、らしい。詳細は省略。

検索エンジンを作る（予定）その2 〜 Nutchについて少し解説

その3はこちら。

概要

前回はNutch + HBaseでクローラーを動かすところまでを書いた。

今回はNutchの動作の仕組み、起動オプション、設定項目をちょっと解説。

（理解が浅い or 間違っている箇所も多いと思うので、何かあれば指摘して頂けると助かります）

Nutchの動作の仕組み

このブログ記事を見てもらえば大体分かると思う、などと言っちゃうと身も蓋もないし、英語が苦手な方もいるかもしれないので若干補足。

検索エンジンを作る（予定）その1 〜 Nutch + HBaseのクローラーを動かす

その2はこちら。

目的

個人的に興味があって、ある領域に特化した検索エンジンみたいなのを作ろうとしている。

当面の目的としては、以下のような事をやる。

• 対象のサイト（ある領域に関連するサイト）をクロールして保存
• クロールしたページから必要なデータを抜き出して、DB（必ずしもRDBMSとは限らない）を作成し、以下のような検索が出来るようにする
  • カテゴリ等をドリルダウンして、対象ページを絞る
  • キーワード検索

今回はNutchとHBaseのインストール、実行くらいまで書く予定。

Warning when ssh'ing from OS X Terminal

Connecting to a Linux server from OS X Terminal gave me the following error:

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8)

To fix this, comment out the following line in /etc/ssh_config

   SendEnv LANG LC_*

This blog post explains about this issue in detail.

この方法だとエラーは出なくなるけど、漢字の入力とか出来なくなる？

Index "PRIMARY_KEY_B" belongs to a constraint

エラーの概要

H2で、あるテーブルのプライマリーキーを削除しようとした時に以下のようなエラーメッセージが発生（"PRIMARY_KEY_A5"の部分はそのテーブルのプライマリーキーの名前で、通常は自動採番）。

Index "PRIMARY_KEY_A5" belongs to a constraint; SQL statement:
alter table t2 drop primary key [90085-169] 90085/90085

削除しようとしているプライマリーキーの対象カラムが、別のテーブルの外部キーになっている場合に発生。

再現方法

create table t1 (
  id integer,
  primary key (id)
);
create table t2 (
  id integer,
  primary key (id)
);
create table t3 (
  t1_id integer,
  t2_id integer,
  constraint t3_pkey primary key (t1_id, t2_id),
  constraint t3_t1_id_fkey foreign key (t1_id) references t1(id),
  constraint t3_t2_id_fkey foreign key (t2_id) references t2(id)
);

この後、以下のSQLを発行するとエラー

alter table t3 drop primary key;

t3のプライマリーキーを削除しても、別に外部キーの整合性を壊すことにはならないから、エラーにしなくてもいい気がするけど。

解決方法

先に外部キーを削除してからプライマリーキーを削除。その後、外部キーは付け直し。

alter table t3 drop constraint t3_t1_id_fkey;
alter table t3 drop constraint t3_t2_id_fkey;
alter table t3 drop primary key;
alter table t3 add constraint t3_t1_id_fkey foreign key (t1_id) references t1(id);
alter table t3 add constraint t3_t2_id_fkey foreign key (t2_id) references t2(id);

参考URL