2017年 12月の投稿を表示しています

「出現頻度と連接頻度に基づく専門用語抽出」という論文に出てくる MC-value について理解した(つもり)

FLR の件と同じ論文で出ていた MC-value について。「単名詞バイグラムによらない用語スコア付け」として挙げられている

「出現頻度と連接頻度に基づく専門用語抽出」という論文に出てくる FLR について読んだ | ごみばこいん Blog

元の論文

FLR と同様に「出現頻度と連接頻度に基づく専門用語抽出」という論文で語られているのでスキップ。
そして MC-value を語る前に、その元になる C-value を語らないと行けない。

C-value のものすごいざっくりした理解

  • コンテンツにおける専門用語って名詞が連続すること多いよね
  • 連続する名詞って入れ子になることあるよね
  • 形態素解析の結果って名詞かどうかわかるよね
  • → できるじゃん!!

C-value の仕組み

例として以下の連続する名詞が上がっているとして…。

トライグラム 統計、トライグラム、単語 トライグラム、クラス トライグラム、単語 トライグラム、トライグラム、トライグラム 抽出、単語 トライグラム 統計、トライグラム、文字 トライグラム

  1. CN = 複合名詞
    1. 例) トライグラム 統計
  2. length(CN) = CNの長さ(構成する単名詞の数)
    1. 例) length(トライグラム 統計) = 2
  3. n(CN) = コーパスにおけるCNの出現回数
    1. 例) n(トライグラム 統計) = 2
  4. t(CN) = CN を含むより長い複合名詞の出現回数
    1. 例) t(トライグラム 統計) = 1
  5. c(CN) = CN を含むより長い複合名詞の種類数
    1. 例) n(トライグラム 統計) = 1
  6. C-value(CN) = (length(CN) - 1) * (n(CN) - (t(CN) / c(CN)))
    1. 例) C-value(トライグラム 統計) = (2 - 1) * (2 - (1 / 1)) = 1

このとき length(CN) = 1 、つまり単名詞のときに数値が 0 になってしまうという問題がある。専門用語は単名詞になることもあるだろう。

MC-value のものすごいざっくりした理解

  • C-value で連続する名詞のスコア計算が出来たけど単名詞…
  • -1 してたものをなくせばいいじゃん!

MC-value の仕組み

例として以下の連続する名詞が上がっているとして…。

トライグラム 統計、トライグラム、単語 トライグラム、クラス トライグラム、単語 トライグラム、トライグラム、トライグラム 抽出、単語 トライグラム 統計、トライグラム、文字 トライグラム

  1. CN = 名詞
    1. 例) トライグラム
  2. length(CN) = CNの長さ(構成する単名詞の数)
    1. 例) length(トライグラム) = 1
  3. n(CN) = コーパスにおけるCNの出現回数
    1. 例) n(トライグラム) = 10
  4. t(CN) = CN を含むより長い複合名詞の出現回数
    1. 例) t(トライグラム) = 7
  5. c(CN) = CN を含むより長い複合名詞の種類数
    1. 例) n(トライグラム) = 5
  6. MC-value(CN) = length(CN) * (n(CN) - (t(CN) / c(CN)))
    1. 例) MC-value(トライグラム) = 1 * (10 - (7 / 5)) = 8.6

論文上では 5.6 と書かれているけどこの数字がどうやって出てきたかわからんかった…。
n(CN) の計算がもしかしたら違うかも。

例1(図2)の場合,MC-value(トライグラム)=(7−7/5) = 5.6である

まとめと感想

そもそも C-value が TF-IDF や FLR と異なり、全ての文字列に対して下準備をする必要がないのと、数えることがメインなので計算量すくなく、データ量をどんどん増やすようなことをしてもお手軽に使えそうな気がする。

論文中でもいい感じに取れるぜ!的なことが書いてあるので、もうちょっと実践的に?入れて様子を見ようかなあと思いましたとさ。

「出現頻度と連接頻度に基づく専門用語抽出」という論文に出てくる FLR について読んだ

以前 TF-IDF について調べた。

TF-IDF ってのを使うと単語の重要度がわかるよって聞いたので調べた | ごみばこいん Blog

まったく違うアプローチをしている重要語を抽出するようなものがないかなーと調べてたら FLR というものに行き着いた。

元の論文

「出現頻度と連接頻度に基づく専門用語抽出」という論文で語られている。

機関リポジトリ内のページ
UTokyo Repository - 東京大学学術機関リポジトリ

関連サイト
専門用語(キーワード)自動抽出システム”のページ

ここで実際どうなるのよ、が試せるっぽいのと、ライブラリが配布されているので組み込むのもまあまあ容易に行けそう。

FLR のものすごいざっくりした理解

  • コンテンツにおける専門用語って名詞が連続すること多いよね
  • 形態素解析の結果って名詞かどうかわかるよね
  • → できるじゃん!!

FLR の仕組み

  1. 単名詞バイグラム、LNnとRNnのリストを作る
    1. [LNn N](#Ln)
    2. [N RNn](#Rn)
    3. 例)トライグラム 統計、トライグラム、単語 トライグラム、クラス トライグラム、単語 トライグラム、トライグラム、トライグラム 抽出、単語 トライグラム 統計、トライグラム、文字 トライグラム
      1. LNn
        1. [単語 トライグラム](3)
        2. [クラス トライグラム](1)
        3. [文字 トライグラム](1)
      2. RNn
        1. [トライグラム 統計](2)
        2. [トライグラム 抽出](1)
  2. 単名詞スコア1 として、連接種類数 LDN(N)とRDN(N) を作る
    1. 種類の数なので、単語の出現頻度にはさほど影響されない
    2. 例)
      1. LDN(トライグラム) = 3
      2. RDN(トライグラム) = 2
  3. 単名詞スコア2 として、連接頻度 LN(N)とRN(N)を作る
    1. 単名詞バイグラムを特徴付けるものとして、全ての出現回数の合計を取る
    2. 例)
      1. LN(トライグラム) = 3 + 1 + 1 = 5
      2. RN(トライグラム) = 2 + 1 = 3
  4. 複合名詞スコア LR(CN) を作る
    1. 専門用語は複合名詞が多いが、その複合名詞の長さによって重要度はかわらない
    2. 単名詞Nに対し、左側スコアFL(N)、右側スコアFR(N)
      1. 単名詞スコア1 か 2 を利用する
      2. 複合名詞 CN = N1, N2, ... NL
      3. 複合名詞に含まれる各単名詞について FL, FR を計算し、相乗平均を取り、CNの長さLの逆数のべき乗を取ったものが LR(CN)
      4. LR(CN) = pow( GeometricMean( (FL(Ni) + 1) * (FR(Ni) + i) ) , 1/2L)
      5. 例)連接頻度をスコアとすると
      6. LR(トライグラム) = pow( (5+1) * (3+1), 1/2 ) = sqrt(6 * 4) ~= 4.90
  5. 出現回数を複合名詞スコアに加える FLR(CN)
    1. f(CN) = CNが単独で出現した頻度、他の複合名詞に含まれていないこと
    2. FLR(CN) = f(CN) * LR(CN)
    3. 例)連接頻度をスコアとすると
      1. FLR(トライグラム) = 3 * 4.90 = 14.70

まとめと感想

名詞に対して、よくでる連続した名詞がスコア高くなるような仕組みでスコアを付けて、それをピックアップできるものだった。
何かに特化した専門的なものを説明するようなコンテンツだとその節があると感じる。(例えばこの記事だと "名詞" は上位にピックアップされるんじゃないかな)

というか、最初に重要語が~みたいな話を書いたけど、「重要とは何か?」という考え方、指標、スコアを設ければそれで重要ってキメになるんだろうな。

  • 出現回数「よく出る単語は重要だ!」
  • TF-IDF「このドキュメントだけよく出るから重要だ!」
  • FLR「この名詞はよくくっついて出るから重要だ!」

ちなみにこの論文では MC-value というものも提案されており、それはまた書く。

PHP で本文抽出したいよね、という

前回の記事: ExtractContent を PHP で書き換えた | ごみばこいん Blog

「今回 PHP に書き換えてみた ExtractContent も含めて、これらの比較は次の記事でやりたい」といいつつ、他のネタが挟まり、ようやくにして比較しました。

比較した結論

お試しにはこちらのリポジトリをどうぞ。
sters/compare-article-extractors: Compare web article extractors.

日本語環境下で難しい話

php-goose 、または php-web-article-extractor では、どちらも内部にストップワード辞書を持っていて、プログラム上で言語を指定、あるいは lang 属性や meta タグから読み取った言語名から、適切なストップワード辞書を選択しています。そうして決まったストップワードの一覧が、文字列にどれくらいあるかを確認して、本文かどうか?といった判断を進めているようです。

ストップワードとはよく使われがちな単語のことで、自然言語処理の前処理として行なうことでデータ量を減らしたり、精度を上げたり出来ます。

自然言語処理における前処理の種類とその威力 - Qiita

例えば英語では「This is a pen.」といったようにスペースで区切られているので「ストップワードの is と a の 2 文字がある!こいつはコンテンツだ!」と簡単に出来るのですが、日本語の場合はそう簡単な話ではありません。日本語はスペース区切りではありませんし、前後にある文字によって、まったく異なる意味合いになったりもしますので、一概に辞書でドバーッと指定することは適切な処理でない可能性が高いです。

じゃあどうするかというと分かち書きの出番なのですが、分かち書きも簡単なものではありません。 Chasen や Mecab といった既存の技術を利用すればお手軽にもできますが php-goose や php-web-article-extractor がそれを利用して日本語対応するかというとちょっと違いそうだなあ、という気持ちです。

php-goose に出したプルリクは諦めてドバーッと処理する形ではありますが、日本語だけ特殊化せざるを得ないので、そうやってみて出してみたものの、なんだかなあと。いやそもそも 元になってる Goose はそういう実装になっていないだろうし…。

そのほかのアプローチ方法

DOM構造や、画面上の位置情報も利用するのはめっちゃ有効的だと思います。
PuppeteerでWebページからメインコンテンツっぽいところを抽出してみる - Qiita

上記の記事の「まとめ」でも出てはいますが、機械学習して取るようにするのもよさそうです。
seomoz/dragnet: Just the facts -- web page content extraction

WordPress と Twitter を連携するテスト

テストだよーん。

====

追記してみるよ。

今まで Simple Tweet を利用していたのですが、Twitter アプリの見直しをして、うっかり全部消してしまい、再度アプリを作成しても使えなくなっていました。
PIN コードの入力…、PIN どこ… と、いうような状況です。

Simple Tweet — WordPress Plugins

調べたところ WP to Twitter がよさそうだったので、これを入れました。

WP to Twitter — WordPress プラグイン

設定画面が日本語化されていますし、流れで設定していけるので簡単に利用できます。

弁当戦略

この記事は 愛俺弁当 Advent Calendar 2017 - Adventar の 20日目の記事です。

ある日のお弁当の様子。

お弁当戦略

いまのお弁当の戦略は以下の通り。

  • 週3-4日お弁当にすることが目標
  • ご飯+おかず+あったかいものコンテンツ
  • おかず
    • おかずは土曜日、あるいは日曜日に大量生産し、冷凍しておく
    • ひとりでやるときもあれば、妻と作る時もある
    • 作り置きお弁当!な本を見て食べたいやつを作る
    • またはビビッときたものを作る(例:鶏胸豆腐のエコハンバーグ)
    • 定番はほうれん草か小松菜のおひたし。ゆでで醤油とだしでぐるぐる。冷凍するとダメそうだけど行ける
    • あとはハンバーグ、肉団子系。ケチャップソース醤油砂糖あたりでタレを作るのがお気に入り
    • 卵焼きはマヨネーズと片栗粉を入れることで冷凍してもおいしいのが出来ることを身に着けた
    • レンチンかぼちゃ煮物というスキルも身につけたのでこれもいい
  • あったかいものコンテンツ
    • 同様に土曜日あるいは日曜日に生産する
    • カレーやシチュー、煮物の類がここに当てはまる
    • シャトルシェフが最高に相性がいい。煮物なんかは入れてふつふつ、しまって放置の簡単
    • 鳥手羽元と大根を適当にぶっこんだ煮物がすき
  • ごはん
    • おおむね白ご飯
    • たまにふりかけつき
    • たまに炊き込みご飯。舞茸ごはん、さつまいもごはんが適当にやっても仕上がるのでめちゃお手軽

いろいろレシピはそのうちまとめたい気持ち。

(追記)
まとめました!今後も増えます!
https://gomiba.co.in/blog/archives/1832

2017年にあったことをドバーッと振り返る(惚気コンテンツ)

この記事は 妻・夫を #愛してる ITエンジニア Advent Calendar 2017 - Adventar の12月18日の記事です!完全に遅刻です!すみません!!!
この1年どんなことあったかなーって、Googleフォトにある写真を主に思い出しながら書き出しました。

まえおき

簡単に妻のことを紹介しておきます。

  • ぼくの 3 つ年上
  • 新卒時代にちょっとwebエンジニアやってた
  • 今はwebサービスの運用担当者。ユーザさんや提携会社さんとのやりとりするようなおしごと(とぼくは思っている)
  • 元気、パワフルなタイプ
  • 雑貨とかアクセサリーとかハンドメイドしちゃう系
  • 工作とか手芸とか好き
  • ゲーム好き(電子も物理も)
  • 酒飲み(最近めっちゃ弱くなった)
  • 料理おいしい
  • かっこいい
  • かわいい

ぼくとの共通項としてはゲームとかものづくりとか。あと最近になって思うところはテンポが合うとかそういう感じですかね。

ここまでの流れはざっくりと、2014年11月から付き合い始め、2015年12月にプロポーズし、2016年4月に入籍、という流れです。いったんお金溜めるか~というのと、義姉が子供を出産したばかりなので、が被ったことによって、一年後結婚式しよう!というのが2016年の総まとめです。

かっこかわいいの、めっちゃいいですよね、わかる~。

1月

元日にごみばこ氏実家へ。毎年恒例っちゃ恒例の晩御飯会。おじいちゃんめっちゃ飲む人で無限に酒が出てくる。2日、3日は妻の実家へ、猫と戯れる。

そして今年はお弁当を頑張ろうの気持ちが出て、買ったお弁当本のレシピをメモがてら写真撮ってた。

そういえば近所にインドカレーのお店があって、チーズナンがドチャクソ美味しいので積極的にチーズナンをおすすめしていきたい。

確かこれくらいにハネムーンどうしよっかーとかいってHISのハネムーンプラン的なものを申し込んだ。オプションつけてきて高くやってきそうだったので大丈夫でーすって回避した。コンテンツ盛りだくさんというよりは、青い海!白い砂浜!うまいビール!をやりたい。

2月

結婚式の準備を進める、ウェディングドレス試着した。着たら気持ちアガってきたそうで。

今年のバレンタインデーはヤンヤンつけボーのパロ。おもしろコンテンツで!とオーダーしたらこれだった。入っていた器はしろくまプラ皿、かわいい。

このころは近所に肉のハナマサがあったので、ブロック肉を買い込んで分割冷凍したりしている。めちゃ便利ちゃん。

3月

誕生日だった。チョコクッキーもらった。プレゼントはおよそ毎回お互いにオーダーするように、今回は全身コーディネートをお願いして、夏頃に実施された。優秀なパーカーを手に入れた

引っ越しに向けて気合を入れる、いくつか内覧した。めっちゃ掃除中だったのが面白かった。

ニャンフェスというイベントに出店するので工作していた。ぼくも工作してたんだけど試作品つくっただけでそれ以上時間とれなくて量産は断念。。

4月

気分転換にメダルゲームなどする。というのはあれで、結婚式準備の帰り道とか、そういうところ。
結婚式の準備は、料理の試食、というなの割引されたコース料理を食べたり、髪型のプレビューしたり、タイムスケジュール詰めたり、ドレス決定したり、そんなところ。
このふわふわ気味の髪型かわいいよね、すき。

それと引越しが実施された。箱詰め祭り。あと引越しお祝い的なのもらったりした。

ニャンフェスも開催された。様子としてはこんな感じ。

5月

結婚式準備おおづめ。当日コンテンツの練習、お泊まり会したり。昔の写真集めたり、装備品探したり、発注したり、席札作ったり、指輪磨いてもらったり。

ちなみに私のちびっこ時代はこんな感じだったらしい。

準備中にもカメラ向けるとポーズ決めてくれたりしてかわいい妻である。

このころにちょうど知人が結婚式挙げてて、二次会に出席した。優先度順で並べたときに披露宴枠に入らなかったそうで、残念。二次会とはいえ空気感は理解したので、ある意味では自分たちの予行演習的な気持ちだった。

で、結婚式を迎えた。個別記事にしたのでそっち参照されたし。

いまさらになるけど”結婚式したよ”というご報告 | ごみばこいん Blog

結婚式やったこと、便利だったことTipsみたいなの書いてなかったので追記したので、以前みたぞ!って人ももっかい見てみてね。

 

披露宴おわったわー!の翌日からいわゆるハネムーン。フィリピンはマクタン島に飛び立った。
着いてそうそうに貧困の差を感じてなんとも言えない気持ちだった。

ホテルにあるクラブラウンジとやらが利用できるプランだったみたいで、このラウンジ、フリーに利用できるのに、ミネラルウォーターやコーラ、ジンジャエール、そしてアルコールの類(ビール、ワイン、各種リキュール)におつまみお菓子、さらには激ウマ朝食が提供されていて最高だった。ショッピングしたりで多少は英語喋ったけど、カタコトの英語でも伝わって意外と英語圏でも生きていけるのでは…?なんて思った。ただし聞き取りはかなり怪しくてyeah!とか行ってたらちょっと危なかった。それとパリピ感高めのシュラスコを体験したのだけど、日本人いてギャーギャー騒いでいたのにはちょっとワロタ。

あと印象的だったのは、ジンベイザメツアーに参加したんだけど完全に飼い慣らされているジンベイザメだったところですね、期待しすぎ?

それにしても青い空!白い砂浜!うまいビール!ってノリは国内海外問わず激推しコンテンツです。

アイスを食べる妻、きーんとしてる顔しててかわいい。

6月

妻と知人2人とモンハンの脱出ゲームに行ったりした。脱出ゲームって最後の「終わりですよ^^」みたいなところにトラップがあるのやめてほしいって毎回思っている。数回ほど行ったことあるのだがクリアしたことが未だにない。

ちょっと早いがスイカが届いてスイカパーティー。知人も呼んで人生ゲームむっちゃやった。

このあたりから二人でぼちぼちマイクラ工業をリスタートした。そういえばその辺の記事書いてないなあ。。
構成的には BuildCraft + IndustrialCraft2ex + EnderIO + MineFactoryReloaded2 + Tohu な感じ。細かいのは他にもいくつか入ってるけど、およそこれ。LogisticPipes はうまく動かなかったので断念。

7月

二次会しようぜ!って話を詰める。入ったカフェで注文したデザート、むにゅむにゅしたのがココナッツミルクに入っててよくわからんかった。衣装レンタルも確定させた、どちらも披露宴で着なかった白タキシードとカラードレス(水色)にした。

そんなこんなでやることが済んだので、夏休みを取って、妻の第二の地元、北海道へ旅行いってきた。
羽田→新千歳→札幌→すすきの→富良野→旭川→層雲峡→旭川→羽田というルート。
北大ひろすぎ、寿司うますぎ、右も左も緑一面なのすごい、しろくまかわいい。そんな感想。

ここの寿司がうまいんだぞとドヤ顔を決める妻、かわいい。

こちらはレンタカーでドヤ顔を決めるぼくです。

教訓としてバイキングは無限に食べるから気をつけようと思った。

そういえばレンジを刷新した。パン焼きのスキルが身についた。お互いにめっちゃ好きなチーズケーキも作ったりした。

そしてドラクエ11がやってきた。妻は勇者に転職しました。

8月

時間差の結婚式二次会を実施した。結婚式、披露宴はクレイジーウェディングのクオリティ高く、二次会同じ日ってちょっとなあ。。その世界観、気持ちのままお持ち帰りしてほしいみたいなところを思って同日にしなかった。なお二次会は至って普通の二次会。

二回目の夏休み、もといただの有給を使って妻の実家へ。お盆ということで義姉の一家も来ていてわいのわいのしてた。そういえば豊橋総合動植物公園がけものフレンズとコラボしてた。すっごーい!
ぼくはカメラマンしつつ、ルービックキューブという趣味が増えた。2分くらいで揃えられるようになった。それ以上はあまり望んでいない。

そして妻のちょっとしたつながりのつながりでアイドルライブに行った。妻と共にコールと振りをちょっと覚えて、スタンディングだったのでわりかし最前線でわいのわいのした。ドルヲタのつもりはないが、アイドルという存在に心惹かれる人の気持ちがちょっとわかった。応援したくなる気持ちわかる。

9月

お猫さまがごみばこ家にやってきた。元々は野良猫で、保護した人から譲り受けたってワケ。来てから数日は「飯?いらんわー」って続いたが、いつの間にかめっちゃ食べるようになった。2週間くらいはケージにこもってたが、3週目にして秘密基地を見つけてしまったらしい。
そういえばこの頃はめっちゃ威嚇された。近づくとふしゃーーーー!って。


たまにはいいじゃん!と仕事終わりに妻と餃子ビールにいくなどしてる。

10月

キャットタワーが搬入され更にフリーになっていくお猫さまであった。

ついに大型家電の大本命、冷蔵庫を新しくした。180Lくらいだったものから400Lくらいのものになった。氷が自動で作られる、すごい。フリーズドライ的なのがある、すごい。野菜がめっちゃはいる、すごい。こりゃお弁当作りが捗る捗る。しばらくの間は野菜を買いすぎて一部ダメにして全部鍋にいれるなどしたりもした。ものには限度があるやろ、みたいな。

ちなみに冷蔵庫の上はお猫さまに次なる秘密基地と化した。どうやら暖かいっぽい。

11月

岩盤浴デートした。身体むっちゃ温まるのと、汗かいたわーーー!という感覚がすごい好き。で、帰りに美味しいご飯を食べるなどした。

結婚式のプロデュース会社を使った人で集まってパーティやるよ!ってやつに参加した。どの夫妻も色強くて負けてられないなと思った(何) ドレスコードに結婚式のときのものに関連した何か~って言われたので赤めの服装をしていった。おそろや!

こそこそ溜めていて5000枚くらいあったゲーセンのメダルがうっかりしていて期限が過ぎてしまった。。まあ引っ越してこのゲーセン行きにくくなったし、多少は、ね。

なんだかんだ二人では始めてのディズニーデートをした。お互いに初めてのディズニーシーへ。朝一からいったけど、平日だけあってか激混みというほどではなく人気アトラクションはほとんど乗れた。一通り乗った感じではインディージョーンズとセンターオブジアースが激オススメ。ニモのシーライダーはディズニーすげえってなるのでこれも行ったほうがいい。あとはまあまあ。例のねずみはショーで爆発しまくってた。ハハッ!

寒くなってきたのでこたつを出したら完全にお猫さまの住処。暗くてぼやぼやな写真しかとれない。

マイクラについては一通り工業開発しきった感があって、ぼちぼちにして、配布ワールドも遊んでみている。

12月

ズーラシアに行った。動物目当てというよりは散歩気分で。おやつタイムがあっていろいろ説明してくれる。説明が聞いてると楽しいのでかなりうれしいコンテンツ。

世間からだいぶ遅れているがスイッチがやってきた。妻とのマリオカートがアツい。そして妻はスプラトゥーンに浸かりはじめる。

お猫さまはちょっとお高いおやつカリカリを出すとすぐ寄ってくるようになったのでチョロい。とはいえ警戒はしているみたいなので手からは食べたくないマン。焼き魚したりするとめっちゃ鼻聞かせて時折寄ってくるのでこれもまたチョロい。そういえば威嚇はほぼしなくなった。

最近は知人とおうちでボドゲしたりもした。カタン、枯山水、パンデミック完全治療、ラブレター、インカの黄金、およそそのあたり。カタンと枯山水めっちゃ面白かったので別の人ともやっていきたい気持ち。

おわりに

2017年に起きたことを思い出せる範囲、写真の残っているようなところを主にだだだーっと挙げました。たまにはこういう人生的なコンテンツもいいよね。来年もまたいろいろ動きそうなので、ごみばこさんのこれからにも注目です。

DynamoDBを調べたメモ

DynamoDB 使ったほうがいいんじゃない!?!?という話になったので、調べたメモ。まじでメモ。

+ 金額感
    + ストレージ利用料 + キャパシティユニットと呼ばれる処理単位 + リクエスト数
    + キャパシティユニット
        + 書き込みの制約
            + 1つの書き込みキャパシティユニットで秒間1回書き込める
            + 1つのキャパシティユニットで1KBまで
        + 読み込みの制約
            + 1つの読み込みキャパシティユニットで秒間2回読み込める
            + 1つのキャパシティユニットで4KBまで
        + これを消費する量をスループットと呼んでいる
            + Dynamoを使っている上でスループットが上がらない、はキャパシティユニットを上げればいい
        + 読み書きそれぞれ別の値を設定できる
        + オートスケールも可能。70%をしきい値に増やしたり減らしたりできる
        + この制約があるので一括でドッバー!みたいなことができない
    + キャパシティユニットの課金が厳しいのでがっつりDBストアというよりは、無限にスケールできるKVSのイメージ
+ ストレージ
    + 縦にも横にも自動でめっちゃ伸びる
    + 実態はSSD。ソフトウェア的なものはAWS独自?まあ気にしなくて良い領域
+ インデックスの設定が必要
    + なぜ必要?
        + 無限にスケールが出来る、一方でどうやってデータを検索するの?
        + 高速に検索するために、データに対して、一意に絞りこめるようなキーを設定してあげる必要がある
    + どんなインデックスがある?
        + プライマリ
            + HashKey or HashKey + RangeKey
            + 一意に絞りこめるキーと値の幅のインデックスが設定できる
        + LSI
            + ローカルなセカンダリインデックス
            + HashKey + RangeKey のときだけ使える
            + 別のRangeKeyを増やすイメージ
        + GSI
            + グローバルなセカンダリインデックス
            + プライマリキーはそれとして、別のインデックスを設定できる
        + セカンダリインデックスを設定するときのオプションで金額が変わる
            + 「射影しなかった属性データはインデックスでのクエリ結果に含まれない」っぽい
                + もし射影してない属性データが欲しい場合は改めてテーブル側から取得する必要があり
                + その分余計なユニットを消費してしまうので逆にコストが高くなることも
    + HasKeyは分散させないとスループットが出ない
        + ストレージがいい感じに分散されるため
        + 単に日付をべべっとしたデータを入れると分散されない
+ 整合性
    + 2つある
    + つよい
        + つよい。ちゃんと整合性を見てくれる
        + スループットを倍消費する
    + ふつう
        + ふつう。書き込みは同期じゃなくてちょい遅延がある
        + スループットは通常(1キャパシティユニットで秒間2回読み込める)
+ データバックアップ
    + 勝手に分散保存されるので不要(S3といっしょ)
    + バックアップしようとするとキャパシティユニットがつらい
+ RDS, Dynamo, S3 を比べてみる
    + RDS
        + スケール
            + スケールアップ、縦横分割は自分でやる
        + スピード
            + インデックスが効けば早い
            + データ量が増えるとつらい
                + 日ごとにめちゃめちゃ増えるデータに対しては難しい
            + Auroraで多少改善できるかも?
        + 検索
            + わりかし柔軟に検索できる
        + 一貫性
            + ◎トランザクション
        + その他
            + 要するにMySQLなので理解が容易
    + Dynamo
        + スケール
            + 無限にスケール出来る、縦横分割を考えなくていい
        + スピード
            + 強制的にインデックスが効くので早い
            + DAXというオプションで加速できる
        + 検索
            + インデックスに基づく簡単な検索は出来る
            + テーブルをくっつけるような複雑目なものは無理
                + ElasticSearchと連携して最高の検索ソリューションを提供できる
        + 一貫性
            + トランザクションはない
        + その他
            + キャパシティユニットを超えるとエラーになるのでスパイク対応が難しい?
                + オートスケール+ライブラリがリトライ対応してると最高
    + S3
        + スケール
            + 無限にスケール
        + スピード
            + 他と比べると遅め
            + おそすぎてやばい!というほどではなく、耐えられるくらいの遅さ
        + 検索
            + 検索することはできない、一意に絞りこめるキーを決める必要がある
            + ElasticSearchにまるっと放り込んで検索することもできるっちゃ出来る
        + 一貫性
            + トランザクションはない
        + その他
            + 要するにファイルストレージ
            + 保存コストは一番安いが、取り出しコストは大きめ?
+ 余談
    + GoogleAnalyticsはBigTableがバックエンド

勉強した色々な記事

仕事スクレイピングを楽にした

この記事は Webスクレイピング Advent Calendar 2017 - Adventar の 5 日目の記事です。

お仕事都合による発生するスクレイピングについてと、それつらたん~~~なことになってきたので解消するようにブチアゲした話を書きます。

お仕事都合による発生するスクレイピング

お仕事都合、例えば営業や企画といった人達から「こういうこと出来ないかなあ…?」とかって話が来るとおよそ7,8割の確立でスクレイピングできないっすかというお願いです。それが 1 回だけならいいんですが、異なる人から、異なることを、ちょこちょことお願いが来たりします。
さらに厄介なのが「XX さんに先月お願いしたやつ、今月もよろしく」みたいなやつ。ぼくは XX さんじゃないし、その事があったことを知らないぞ??

そしてその "お願い" の中身としては、例えばこういう感じ。

  • 指定する URL 群から XXX と YYY の情報を集めたい
    • (これがいちばんおおい)
  • 電車案内のサイトから駅名一覧を集めたい
  • 求人系のサイトから職種一覧、募集企業の情報を集めたい
  • IRまとめ系サイトから業種や会社名、連絡先を集めたい
  • 特定のメディアサイトに入っている画像を集めたい
  • 〇〇のメーカーの商品、型番の一覧を集めたい
  • ムフフなコンテンツ集めたい
  • etc...

そしてこういったお願いはかなりの速度感を求められることがあります。

とはいえ、どばーーーーってスクレイピングしたら、対象のサイトに対して、迷惑を掛けることにつながりますし、訴訟リスクも存在します。前提として 1 日目の vaaaaanquish さんが書かれているようなこと( PythonでWebスクレイピングする際の規約回りの読み込み - Stimulator ) を
確認しつつ、良心的な範囲でやらなければいけないので、その点については説明し納得をしてもらっています。

そんなこんなで、これまではまあいっかーという気持ちで、毎回 0 からコードを書いて、ぐるぐるしたりしてやっているのですが、いやいやちょっとそろそろ面倒になってきましたよ、ということでもうちょっとやることにしました。

「コレ使えばおおよそいいよ」セットを作る

毎回コードを書くのはまあいいとして、でも毎回 0 スタートはかなり面倒です。ボイラープレートというか、フレームワークというか、何かそういう「コレ使えばおおよそいいよ」セットを作ります。
このセットがあることによって、コードがざっくりと統一されるので、引き継ぎだったり、並行開発だったり(するか?)、そのあたりの勝手が良くなります(なりました)。

Guzzel 使えばいいじゃん、とかそういう話でもあるんですが、スクレイピングしたときってデータの入出力はもちろん、スクレイピングのやり方によってはキューイングしたり、一時データをもったりするじゃないですか。そういうところ全部扱いたいんですよ。で、後述するんですけど、速度感よくやっていこうとすると、あーだこーだ composer require するってよりは、ファイル 1 個読めばいいじゃん、という環境にしたいのです。

制約とか

お仕事の都合によって、言語の制約は PHP になります。他の言語でもいいのですが、周りの人の取り回しを考えるとこれがベストマッチです。

また composer や PEAR は利用できません。お願いを解決するにあたって速度感よくやるために「コレ使えばおおよそいいよ」セットは、何も考えずにとにかくサクッと使えることが必要です。なんなら PHP の設定も気にせずに使えるように、どこかのサーバにファイルを設置して eval(file_get_contents()) みたいに使えると最高です。

そうして出来たものがこちらです

easy scraping kit
※ CSS セレクタを扱う箇所がざっくり過ぎて正しくないです

コレを使って、例えば「Mapion を利用して、指定する都道府県・市区町村の駅名を集める」ものを書くとこんな用になります。

// プログラム本体
eval(file_get_contents('https://.../scraping_kit.txt'));

HTMLDoc::$waitMin = 5000;
HTMLDoc::$waitMax = 15000;

$baseUrl = 'https://www.mapion.co.jp';

foreach(Console::getListFile('list.csv') as $zip) {
	Console::out("start {$zip[0]}");

	// search pref
	$topDoc = HTMLDoc::loadURL($baseUrl . '/station/');
	$prefLinks = $topDoc->findCSSPath('.section.type-a a');
	foreach($prefLinks as $prefLink) {
		if ($prefLink->textContent !== $zip[0]) {
			continue;
		}
		Console::out("found {$zip[0]}");
		Console::out("start {$zip[1]}");

		// search city
		$prefDoc = HTMLDoc::loadURL($baseUrl . $prefLink->attributes['href']->value);
		$cityLinks = $prefDoc->findCSSPath('.section.type-a a');
		foreach($cityLinks as $cityLink) {
			if (mb_strpos($cityLink->textContent, $zip[1]) === false) {
				continue;
			}

			Console::out("found {$zip[1]}");

			// search station
			$cityDoc = HTMLDoc::loadURL($baseUrl . $cityLink->attributes['href']->value);
			$h1 = $cityDoc->findCSSPath('h1.type-a-ttl');
			$h1 = explode('の', $h1[0]->textContent);
			$h1 = $h1[0];

			$trainLinks = $cityDoc->findCSSPath('table.list-table tr');
			foreach($trainLinks as $train) {
				$item = [
					$h1,
				];
				$tds = $cityDoc->findCSSPath('td', $train);
				foreach($tds as $td) {
					$item[] = str_replace('[MAP]', '', trim($td->textContent));
				}
				Console::outputResult($item);
			}
		}

		Console::out("done {$zip[0]}{$zip[1]}");
	}
}
// list.csv の例
神奈川県,川崎市
神奈川県,横浜市

今ままで 0 から書いて、1,2 時間かかってコードを書いていたのがサクッと終わるようになりました。
また、簡単にではありますが、キューやキャッシュも持てるようになるので、 cron などを使って定期的に回したり、 web サイト A の情報を元に web サイト B の情報を取得するといった複数のステップがあるようなスクレイピングもわりかし簡単にできるようになりました。

ごく簡単なスクレイピングはコードを書かずに済ませたい

「コレ使えばおおよそいいよ」が出来ましたが、そもそもとして、よく発生するお願いは「指定する URL から XXX と YYY の情報を集めたい」です。これってコードを書く必要はほとんどないはずで、入力として URL と CSS セレクタ( もしくは XPath セレクタ)さえあれば、あとはよろしく処理するような仕組みがあれば十分なはずです。

というわけで一旦雑に作って様子を見ています

11 月くらいに作って様子を見ようと思っていたのですが、特に何かあったわけでもないんですが、急にお願いが減っちゃって作らなくていいかなあと思ってきました。とはいえ怠けているとあとが大変になりそうな予感がするので、近いうちにやりたい気持ち。

おわりに

「コレ使えばおおよそいいよ」を作ってお仕事都合のスクレイピングを簡単にしたり、別の開発者が入るときも問題の起きにくい状況になりました。
しかし、もはやこの件についてコードを書くことをなるべくやめたいので、そういう「スクレイピングいい感じにできるツール」みたいなのあったら教えてください。

(Google スプレッドシートで出来ることは知っていますが、時間系のあたりをもうちょっと自由度が効く感じで…)


6 日目は _kjou さんで「何か書きたい」です。こちらもお楽しみに!

Webスクレイピング Advent Calendar 2017 - Adventar