Wikitable
Wikitables - Convert Wikipedia tables to CSV file
URLを入力すると、Wikipediaのページにあるテーブルの内容をCSVファイルに変換する。
- 1つのarticleに1テーブルが存在する場合は綺麗にデータが取れる。e.g. Parsed tables from https://simple.wikipedia.org/wiki/List_of_countries_by_population
- しかし1つのarticleに複数のテーブルがある場合、そのデータが何を指すのか機械的に判断出来ない。e.g. Parsed tables from https://simple.wikipedia.org/wiki/Crime_in_Russia
Parsed tables from https://ja.wikipedia.org/wiki/%E5%AE%AE%E5%9F%8E%E7%9C%8C
Wikipediaですらこの状態。世に多数存在する雑なウェブページからテーブルを抽出したところで、そのデータが何なのか判断できない。なんとかしてテーブルに適切なタイトルをつけることが出来ないだろうか?
道は遠い。
クローラの不具合が直る
本当に長い間調査をし続けて、ようやくhappyouのクローラの不具合が治ったことを記念し、久しぶりにブログを書く。
今後、happyouをスケールアウトさせることを考えたとき、今のボトルネックは明らかにDB.細かな最適化をおこなったところで多寡が知れている。
(1)次はDBの垂直分割を行いたい。教科書的には、更新系と参照系にわけるのだろうがそれは参照の比率の高いWebシステムの場合。happyouのクローラは約1:1なわけだからあまり効果はないと思う。
(2) または適当なKVS。で、Valueがサイト丸ごと(おぉ)。その評価を行わなければならない。パフォーマンスは高くなくてもよいので、できるだけ少ないメモリで動かしたい。
目的は何で、妥協できる点はどこなのか?そこを明確にしなければならない。
自らを制約するものは何もない。 どんどんやらかそう。
サーバを増強しAPIの検索機能が軽くなりました。
happyou.infoは現在、クロールの規模を拡大するための諸々の作業を行っています。
そのためにまずAPIの検索を担当するサーバの増強を行いました。かなり軽くなりました(まぁ、これまでなぜここまで負荷をかけていたのかという問題があったのですが…)。 ずっと懸案であったので一つ荷が降りた気持ちです。
NASDAQ全銘柄のウェブサイトをスクレイピングする計画
FinalScraperの現状と今後
FinalScraperを発表してから1ヶ月位たったのでまとめておこうと思う。
- 動作はかなり安定していると思う。
- サービスを公開した本来の目的であるところの、「正しく検出できないパターンについてユーザさんにクレームを付けてもらう」が全く達成できていない。皆黙って使うだけ。うまく動かなければ黙って立ち去るだけ。どうにかならないか。
- 日本語URLがうまく処理できないようだ。直そう。例) http://www.fsight.jp/subcategory/無料 エンコードされていないURLが投げられた場合の処理。%E7%84%A1%E6%96%99
- そのサイトが元々RSSフィードを出力している場合、「元々そのサイトはこのRSSを出力していますよ」と結果表示に含めるべき。
- サーバの負荷が増えてきたらログイン必須にして上限を設ければ良い。