nashibao blog @nashibao-blog - Tumblr Blog

oplog tailingを使ったリアクティブウェブ

リアクティブウェブはウェブアプリケーション開発者の桃源郷だ、と考えるのは僕だけではないと思う．参考: Trigger と Stream ベースの Reactive スタイルについて考える

Meteor 0.7.1: oplog support for complex queries, Meteor developer accounts

リリースされた0.7.1で、実践環境のMongoDBでよく使われるクエリのほとんどをoplog driverが対応した．

The 0.7.1 release extends the set of MongoDB queries supported by the oplog driver to cover most of the common queries needed in production apps.

以前のMeteorでは、複雑なクエリに関してはポーリングすることでサーバーサイドの変更をクライアントサイドに通知していた．今回の変更で、登録されたクエリに関連する変更差分のみがサーバーサイドからプッシュすることが出来るようになった．ポーリングはリアルタイム性の観点でプッシュに劣り、さらに無駄な負荷を生む事になるためスケーリングの障害になりうるため、これは非常に大きい前進だ．Meteorではこの機構を、 1. MongoDBのoplog をtailing(監視) 2. 変更差分を独自のセレクタ(minimongoの一部）を使ってオンメモリでクエリ 3. 該当変更差分のみをプッシュというやり方で実装している．（ソースを流し読みしただけなので間違っている部分があるかもしれません．その場合はご指摘お願い致します:)）

また、同じくリアクティブウェブを指向したデータ同期を目指すプロジェクトにcloudup/mydbがある．

参考: Introducing MyDB MyDB の紹介

MyDBでは、まだ複雑なクエリに対して変更差分を送るのではなくネームスペース単位でoplogをクライアントサイドに通知している．(ただしオンメモリでのクエリライブラリcloudup/mongo-queryがすでにあるので、これを今後組み込むことはあり得る．)

補足

プロジェクトを長期的に考えると一つ一つの機能はなるべく薄くあって欲しい．その点フルスタックのmeteor.jsよりもcloudupのやり方がデベロッパーフレンドリーだと思う．好みのテンプレートバインディングに加えて、監視(cloudup/oplog)と軽量のクエリシステム(cloudup/mongo-query、logicalparadox/filtr、nedb)などを組み合わせて自前のリアクティブウェブを実現出来る．

とはいえ上記のようなやり方(oplog tailing+query)はまだまだ洗練されていない．より原始的に、プロキシのようなものを介して変更を検知し、ネームスペース(または権限)ごとに変更が起きたことをクライアントサイドに伝えて再クエリする、というのが現状の現実路線だろう．

InfluxDB - 分散時系列DBについて

InfluxDBはY Combinatorがバックについていることもあってか海外、国内問わず特別注目度が高いように感じる．また開発者が反応しやすいログ解析のインフラとして使える時系列DBということもあるかもしれない．

My Impressions of InfluxDBより抜粋

It already supports filtering using where clauses, in addition to aggregates using group by, merge and join. There are a handful of mathematical functions (min, max, mean, mode, median, and percentile), making it suitable for routine analytics tasks.

InfluxDBはすでにwhereに加えてgroup byやmerge、joinといった処理をサポートしている．またmin、max、mean、mode、median、percentileといった一部の数学的計算が使えることで、日常的な解析タスクに使いやすいものとなっている．

さらにSlideShareを見るとderivative、stddevなどもサポートしているようだ．

They plan to add a feature called continuous queries, which will allow users to "precompute expensive queries into another time series in real-time".

continuous queriesといって、コストのかかるクエリをリアルタイムに事前に計算しておく機能を計画中だ．

この機能についてはすでにcloseされている．

There remain some questions around its potential to scale, as well as general benchmarks.

スケーリングやベンチマークについては聞きたいことが残っている．

初期のclusteringについてはcloseされた模様．

このエントリに対してErrplaneのCEOから直接コメントが乗っていた．

...Of particular concern are large range deletions and compaction delays...We structured the code in a way so that we'll be able to trade out storage engines later,...

(..LevelDBでテストしなければいけない..)特に大きなレンジの削除や圧縮による遅延が問題だ．... ただ、私たちはコードを構造化してあるので、あとでストレージエンジンを変えることが出来る．...

Very soon after that we'll target custom user defined functions. I think those paired with continuous queries will make Influx super useful for all sorts of real-time computing/analytics/metrics tasks.

この(スケーリングなどの実装)のすぐ後に、custom user defined function(continuous queriesの組み合わせで出来る)を作る予定だ．どんな種類のリアルタイム(コンピューティング|解析|メトリクス)においても、この機能によってInfluxDBは便利に使える．

計算部分がある程度柔軟に書けてプラグインのように使い回せるイメージだろうか．うまく使えばよりコンテキストに特化した解析インフラを個別にカスタムすることが出来るかもしれない．Errplaneはここに強くフォーカスしているように感じた．

さっそくFluentdのプラグインを書いた人がいる．クラスタリングや事前処理は前面に置いてしまうというのは一つの手だろう．

coを補助するco-gateモジュールを公開しました．

co(koa.js)は中で何をしているのか．の続き．

co用のゲートモジュールco-gateを公開しました． visionmedia/coを使うと、非同期APIを同期的に使うことが出来るのは、今までのエントリに書いた通りです．ただ、ThunkやPromiseにAPIを書き換えなければいけません．

そこでco-gateでは、非同期APIのコールバックをゲートに入れて（gate.in()）、同期的にゲートから出す（gate.out()）ことで、従来型のAPIをそのままで使うことが出来るようにしています．

このモジュールはGo風のチャンネルモジュールであるchanに発想を得ています．興味のある人はchanと見比べてみると面白いと思います．

#javascript #node.js #coroutine #yield #koa.js

今のターゲット広告は間違っている．

クッキーはオーディエンスについて教えてくれるが、ほとんどが間違っている．Cookies tell you a lot about your audience, but most of it is wrong

純粋な行動ログベースのパーソナライゼーションの世界では、あなたはすでに見た物を何度も見ることになる．

If your personalised Web experience is based purely on your past behaviour, you are going to get more of what you’ve seen before.

serendipitous 発見性のあるアルゴリズムが求められているというのは、ターゲット広告を見た事がある人ほぼ全てが同意する事だろう．確かに単純な広告よりはCTRは上がるかもしれないが、「今知りたかった情報だから」クリックしたわけではない．

コンテキスト(ある物の意味や価値が時間によって変化すること)を捉えられるかどうかが、発見性の鍵だ．

A large part of this is the ability to understand and interpret context, what something means to you at one moment may well be different at another moment in time.

時々刻々と変化するユーザーの興味（コンテキスト）を捉えることが、発見性のあるパーソナライゼーションにとって確かに重要だろう．例えば、Amazonの「この商品を．．」や、Netflixのジャンル単位での推薦、Googleの「もしかして..」などはコンテキストを捉えるように設計された巧い例である．これらは、ユーザーベースではなくアイテムベースのレコメンデーションであり、パーソナライゼーションとは言えないかもしれない．だが、ターゲット広告に対して示唆は与えてくれるだろう．

ソーシャルデータ解析

上記のarticleは、IntentHQというソーシャルデータ解析の会社からのTheNextWebへの寄稿なので、”クッキーを使った行動ログデータだと発見性もコンテキストも捉えられない”→”ソーシャルデータ”という話の流れになっている．これは議論の残る所だと思うが、面白い目の付けどころだとは思った． IntentHQの考え方については、SlideShareに上がっているスライドを見るといいと思う．

co(koa.js)は中で何をしているのか．

node.jsはasyncの夢を見るか？の続き．

coのようなモジュール（他にもこことかこことか）がどのような形で実装されているのか知りたいのは僕だけでは無いと思う．理解のために出来る限り単純化してみた．

このコードではco()のスコープ内で呼ばれたdone(val)の引数をgen.next(val)でyieldの返り値として渡している．そのため、done(val)が呼ばれるまで待つ挙動を実現出来る．

このままでは、doneを常に引数で渡さなくてはいけないし、ジェネレータのネストや並列実行に対応出来ない．これらを実装した最終コードは co.jsに置いておいた．こちらもco関数自体は50行ほどで書いてあるので、理解しやすいと思う．（visionmedia/coとはココロは同じだけれど、実装はかなり違うのでご了承下さい．あくまで勉強用です．特に並列実行は返り値の順番が適当だったりします．）

補足

僕はC++やObj-C出身のエンジニアなので、こういう非同期周りは泥臭いイメージしか無かった．Win8のシンポジウムでC#のasyncについて聞いた時は、激しく興奮した覚えがあったけれど、それがnode.jsのシンプルなジェネレータで簡単に実装できるというのは素晴らしいな、と思う．またこれでnode.jsがひとつ好きになった．

yieldシリーズ、次はchanについて書いてみる．

node.jsはasyncの夢を見るか？

Experiments with Koa and JavaScript Generators 日本語訳

*がC#でのasyncと同じ役目を果たしていて、yieldがC#でのawaitに相当（少なくともkoa.jsや類似のフレームワーク内では）している．

The * in function *() { } plays a similar role to C#’s async keyword, and JavaScript’s yield (at least when used inside Koa or a similar framework) plays a similar role to C#’s await.

Koa.jsが出てきたことで、ほとんどC#の非同期構文と同じ形式に見えるようになった．実質これはNodeの新しいgenerator（Node.js 0.12 では yield が使えるのでコールバック地獄にサヨナラできる話 Google Chromeに入ったジェネレータとPromiseで非同期処理に革命が起きた）とcoモジュールのおかげだが、直接coのようなモジュールを使う形よりもフレームワーク側で吸収した方が綺麗に、そしてシンプルに書ける．

ちなみにC#でもasync実装前はgeneratorで代用していたらしい．

気になるのは既存のコールバックを引数の最後に渡すJavascriptの標準的な非同期APIの対応だが、thunkifyのようなライブラリを使えば、比較的簡単にこの形式に対応する事が出来る．またchanモジュール（GolangのChannel風のモジュール）を使う方法もある．

次はcoやchanの内部動作について書く予定．

モジュラーなアプリをNode.jsとExpressで書く方法．

Node.js界の重鎮でExpress作者のTJさんが、モジュラーなアプリをExpressで書く方法を公開してる．僕はこの方法が非常に気に入ってて、仕事の方にもがっつり取り入れているのでご紹介．

https://vimeo.com/56166857

This short screencast describes how you can use Express' app mounting feature to create modular self-contained applications to construct your product.

モジュール化された自己完結型のアプリ郡によってプロダクトを構成する方法を、短いスクリーンキャストで説明します．

ExpressはデフォルトのScaffoldingでは、小さいアプリを書くためか、モジュラライズされた形式では吐き出さない．これは全体像を把握するためには良いけれど、規模をでかくしようとするとたちまち問題になる．そこで、上のようなやり方が必要になってくると思う．僕はクライアントサイドのモジュール化にはまたもやTJさん謹製のcomponentを使っている．こちらもオススメ．

#programming #node.js #express.js

lastfmのデータを解析してみる（続３）

前回のデータが10Kで少し小さかったので300Kにしてみた．

300mbくらいの疎行列で、解析時間は100iterationで70sくらい.

jpopとkpopが１クラスタを占めてるってのが面白い結果っすね．

1 indie alternative ele british hardcore post-punk

(6343 artists) the smiths 47 morrissey 133 the cranberries 219 hooverphonic 470 kraftwerk 474 suede 884 ceremony 1170 lifetime 1591 modern life is war 1785 gang of four 1798

2 jazz piano instrumental

(1387 artists) frank sinatra 176 dean martin 1014 keiko matsui 2242 acoustic alchemy 2509 benny goodman 3284 count basie 3376 fourplay 3768 bing crosby 4083 lionel richie 4129 tony bennett 4266

3 punk ska

(3515 artists) nofx 77 rancid 183 flogging molly 257 against me! 274 millencolin 275 anti-flag 317 less than jake 337 reel big fish 352 ska-p 512 pennywise 543

4 classic-rock folk

(65108 artists) the beatles 1 pink floyd 4 bob dylan 17 led zeppelin 22 u2 25 queen 26 david bowie 29 tom waits 36 johnny cash 45 the rolling stones 48

5 pop female dance

(12654 artists) britney spears 33 paramore 66 avril lavigne 92 kylie minogue 131 rihanna 137 lady gaga 184 christina aguilera 189 beyoncé 190 lily allen 201 mariah carey 207

6 alternative rock

(68988 artists) radiohead 2 coldplay 3 muse 6 death cab for cutie 12 placebo 13 the killers 15 arctic monkeys 23 sigur rós 24 the smashing pumpkins 34 björk 35

7 pop female dance electronic

(8241 artists) madonna 31 michael jackson 102 goldfrapp 202 kate bush 320 pet shop boys 346 sarah mclachlan 497 céline dion 559 janet jackson 639 scissor sisters 647 róisín murphy 707

8 industrial rock funk metal

(45585 artists) nine inch nails 7 red hot chili peppers 8 linkin park 9 system of a down 10 nirvana 18 depeche mode 19 the cure 21 blink-182 27 tool 28 green day 30

9 jrock jpop kpop

(3298 artists) in flames 11 dir en grey 180 동방신기 549 gackt 573 ムック 628 kotoko 843 l'arc~en~ciel 864 ガゼット 889 epik high 1047 larc~en~ciel 1050

10 metal gothic hard-rock

(41162 artists) metallica 5 nightwish 14 iron maiden 16 rammstein 20 ac/dc 56 dream theater 60 evanescence 67 opeth 73 disturbed 76 children of bodom 83

NMF on Amazon EC2

NMFをそれなりの規模のデータで利用したかったので、Amazon EC2上のHadoopを使って実装してみた。

ec2+hadoopの手順はhadoopのwikiに書いてあったのを真似した。あと「階層クラスタリングをEC2上で動かしてみる」も参考にした。

今回はHadoop Comunityのhadoop-ec2というのを利用したけど、ClouderaのCDH Cloud Scriptというのも使えると思う。誰か使ってみておくれ。

データはいつも通り30万^2なlastfmのデータで、これまたいつも通りハードクラスタリングしてみた。

ハードクラスタリングの結果は以下。

コードも一応挙げときます。[zip]

inputやoutputはstream?とか。sequencialFileとか。

スケーラビリティはこんな感じ。

15台で10倍程度だからwww2010よりはいいっすね。

Mahoutに関する考察その１-pLSI

https://issues.apache.org/jira/browse/MAHOUT-31

google patent

ちょっとHadoop上の機械学習実装であるApache Mahoutに興味があるので、数回にわたって考察してみる．第一回はpLSIについて．

MahoutはまだpLSIを実装していないようだけれど、もうちょっと先のバージョンには載ってるらしい．LDAは載ってるのにｗ

https://issues.apache.org/jira/browse/MAHOUT-106

ここでちょっと議論されているが、

2) I’ve been looking at the complexity of the algorithm. The computation of Q* produces as many records as number of users * number of stories * number of values of z which get quickly to a pretty big number. The article states it’s been run on a dataset of 61265*1623*30 ~ 3E9 records for Q* I’m looking at the record count as opposed to operations because this is something that will cause IO and a bottleneck in the processing.

と書かれてる．要はMapReduce中の途中データがむちゃくちゃでかいということだけれど、これはちょっと勘違いも入っているけれど*、これは元々の論文のやり方が悪いからだ．(どーもこのスレッドではTOIS04の論文を使ってる風に書いてるけど、たぶんWWW07の方のことだと思う．)

実際には疎行列ということで、ユーザ数xアイテム数(MxN)じゃなくてエントリ数(RxMxNただしR:sparsity)で、またz(K個)はkeyじゃなくてvalueの方でずっとまとめて計算するから、Q*のレコード数はエントリ数(RxMxN)そのもの．ただレコードサイズのオーダーはO(RxMxNxK)になる．これはそれなりに大きいから邪魔になる．

[1] A.S. Das, M. Datar, A. Garg, and S. Rajaram, “Google news personalization: scalable online collaborative filtering,” Proceedings of the 16th international conference on World Wide Web, ACM, 2007, p. 271–280.

これは実際にGoogle NewsのRecommendationに使われてるらしい(もう3年前だから今は知らない)けど、書かれてないことが多すぎる．

NMF on MapReduce

もろ大学でやってる研究の話題．

ここのところ二つほどdistributed nmfについて論文が出てる．

[1] C. Liu, H.-chih Yang, J. Fan, L.-W. He, and Y.-M. Wang, “Distributed nonnegative matrix factorization for web-scale dyadic data analysis on mapreduce” Proceedings of the 19th international conference on World wide web - WWW ’10, 2010, p. 681. [google scholar]

[2] Z. Sun, T. Li, and N. Rishe, “Large-Scale Matrix Factorization Using MapReduce” 2010 IEEE International Conference on Data Mining Workshops, Dec. 2010, pp. 1242-1248. [google scholar]

[1]がMicrosoftの人でWWW2010の論文．[2]はちょっと後に出たやつで、Orthogonal NMFとtri-NMFっていう亜種NMFにも対応してる．基本的にはやり方はおんなじ．

このorthogonal NMFとtri-NMFもだいぶ面白いから、他のエントリで書く．

ところで、Apache Mahoutを見てもまだNMFが実装されてない．教師無しのバッチ学習だとクラスタリングにもフィルタリングにもただの次元圧縮にも使えるNMFがシンプルな中ではけっこーいい方と思うので、NMFのHadoop実装はあると便利だろう．というかあるべきだろう．

ところで、この実装は出たばっかりだからかだいぶパフォーマンスが悪い．ちょっとそこら辺を直してみる．

lastfmのデータを解析してみる（続２）

さらに飽き足らずデータをNMFでハードにクラスタリングしてみることにした。

Poisson NMFではなくGaussian NMFの方を使った。Gaussianの方が往々にしていい結果になっちまうという話と計算時間がだいぶ少なく済むので僕は常にGaussian NMF派です。

NMFのいいところは行列演算ライブラリを使えば、基本二行で済むところ。しかも計算量もだいぶいい方（lastfmのデータで0.1s/iterくらいで済む)。とてもお手軽でお勧めです。

結果は以下。10クラスタに切ってみた。artistの横の数字は順位/10'000を表してる。

jazz,pop,rb,punk,classicrock,j-pop,female vocalist,metal,altenativeなどが出てきた。lastfmって日本のユーザがけっこー多い？のかな。

1 (Jazz)

(28 artists) frank sinatra 193 dean martin 908 keiko matsui 2365 acoustic alchemy 2693 benny goodman 3616 fourplay 3686 wonder girls 3694 count basie 4117 bing crosby 4452 tony bennett 4539

2 (Pop)

(188 artists) madonna 30 michael jackson 119 kate bush 314 pet shop boys 368 céline dion 563 jonas brothers 577 janet jackson 586 the corrs 806 róisín murphy 819 mylène farmer 879

3 (R&B)

(74 artists) mary j. blige 626 brandy 837 sade 974 aaliyah 1246 r. kelly 1609 jill scott 1651 lauryn hill 1707 india.arie 1978 ashanti 2051 keyshia cole 2391

4 (Punk)

(193 artists) nofx 64 rancid 153 millencolin 216 anti-flag 281 less than jake 291 reel big fish 316 pennywise 484 ska-p 514 descendents 527 streetlight manifesto 569

5 (Classic Rock)

(2123 artists) the beatles 1 pink floyd 3 bob dylan 18 led zeppelin 21 queen 28 u2 29 david bowie 33 tom waits 43 johnny cash 47 oasis 49

6 (?)

(134 artists) the smiths 44 morrissey 130 hooverphonic 502 kraftwerk 534 suede 846 ceremony 1077 lifetime 1399 坂本龍一 1893 trash talk 1934 gang of four 1950

7 (J-pop)

(154 artists) in flames 10 dir en grey 140 동방신기 459 gackt 505 ムック 548 big bang 684 kotoko 759 l'arc~en~ciel 763 ガゼット 771 larc~en~ciel 952

8 (Female Vocalist)

(362 artists) britney spears 34 avril lavigne 93 kylie minogue 125 rihanna 168 christina aguilera 180 mariah carey 192 lady gaga 217 beyoncé 218 kelly clarkson 227 nelly furtado 253

9 (Metal, Punk)

(2958 artists) metallica 4 linkin park 9 system of a down 11 nightwish 13 iron maiden 14 rammstein 16 blink-182 24 green day 27 koЯn 35 rise against 41

10 (Alternative)

(3756 artists) radiohead 2 muse 5 nine inch nails 6 coldplay 7 red hot chili peppers 8 death cab for cutie 12 placebo 15 nirvana 17 depeche mode 19 the killers 20

続き書いた．

lastfmのデータを解析してみる（続）

lastfmのデータがすぐに行列で扱えるようになっていないので、とりあえずartist_id,user_id,countのタプルのテキストファイルに変更した[zip]。ライセンスとかはこっちにしたがってくらさい。手軽なようにartist1万、ユーザ10万、エントリ440万で4'400'000/(10'000*100'000)の0.44%程度の充填率になってる。平均44artist/userでまぁまぁ良さげなデータですな.

こないだ言及したlastfmのデータを色々見てみた。一個目はplaying countのmean（artistは全体のplaying countで順位づけして１００位まで見てる）.

バカみたいに上位10位くらいまでが聞かれてる。１００位までだからlong tailっぽさは表示してないけど、たぶんそーなってるんだろう。

次に聞いているユーザー数。こっちは意外とばらつきが大きい。コアなファンがつきやすいのと、広くファンを集めやすいアーティストとかいるからかな。

最後に一番そのartistを聞いているユーザのplaying count.これはごっちゃごっちゃ。これ何分布してるんだろう。

なかなかやるな。numpy+cuda

なぜかpublishするのを忘れていたエントリを見つけた。teslaは電力食うから今はちゃんと落としてありますよ。。

cudaにはblasのgpu実装であるcublasというのが標準でついてるから、そいつの評価をしてみた。あとcublasをpythonからよぶpycublas*1というのも使ってみた。

比較相手はnumpy,octave,matlab,cpplapack。

まず1000x1000行列同士の積の場合。ハードはcorei7 vs tesla S1070*2。時間計測は繰り替えしてないし、tic,tocとか使って適当なのでご了承ください。だいたいです。

*1 pycublasはpystreamというGPULibの元となったプロジェクトから持ってきてる。ほとんど同じなので、こっちから引っ張ってきてもかわんない。これらはpythonのctypesを利用したラッパーで、元をたどればpython-cudaっていうプロジェクトが元になってるっぽい。ソースをみた感じだと。

あと、別の流れでcudamatというプロジェクトもあった。こっちはcuファイルとか込みになっちゃっていてせっかくのcublasのおいしいところを生かせてない感じ。neuralnetの学習とかも入ってはいる。

*2 ただしpycublasは、teslaの乗っているcentos5がまさかのpython2.4で、ctypesとかが使えないため断念。代わりにubuntuからgeforce gts250を使った。

cpplapackがどう考えても何か失敗している点を除けば*、まぁまぁ予想どおりな結果。＋というのはpycublasでデータのgpuのメモリ確保とデータ転送を含めた結果になっている。numpyの健闘が光る。

*　なぜにcpplapackがこんなに遅くなってしまったのかが不思議。久しぶりだったのでatlasのインストールを失敗した気がする。でもそーしたらnumpyも遅くなりそうな気がするから、、むにゃむにゃ。

追記＞ 2013/2/28 cpplapackの開発者の方からご指摘．MKLでコンパイルした場合、matlabとほぼ同じになるだろうとのこと．atlasを使った場合でもこうはなんないはずだから、僕は設定を何かしらミスったんだと思う．ちゃんと実験せずにデータだけ出してすみません．

次に5000x5000の積の場合。もはやlapackは外した。

cublas+pycublasが速いけれど4コアを全開に使うmatlab君もなかなか健闘。MKLがいいのかもしれない。pycublasはnumpyのarray型からの変換あたりに無駄なオーバーヘッドを食っているようだ。numpyもだいぶ健闘している。matlab/cublasが8倍程度、numpy/matlabが2.5倍、numpy/pycublasも8倍くらい。*

* pycublasはshared memoryのbunk conflictを気にして行列を内部で32bitにalignしているのがけっこー効いてる。それを外すと二倍かかったりする。

しかしこの程度の速度差ならgpuわざわざ使わなくて良さげ。もう少しでかい行列とか繰り返し演算とかの場合なら、もっと効いてくるはずだと思うんだけど。

追記＞2011/4/12 今回はだいたい168GFLOPS程度だったけど、"PGI Fortran と CUDA CUBLASを使用した行列積の計算とGPU性能"を見てみると、もう倍は出てる。fermiだからかな.

lastfmのデータを解析してみる

http://mtg.upf.edu/node/1671 にlastfmのクローリングデータがダンプされて置いてあって、こいつがだいたい1.5GBで1700万行くらい。

これをpythonで約30万のアーティストをソート（ユーザー数）してファイルに書き出してみると、だいたい40秒ってところだった。このくらいのデータ規模だとちょっと解析して数十秒程度という感覚か。一番時間食う処理が意外やstringからintへのキャスト処理だった。しかし置き換え辛いなこれ。

ちなみに上位50件くらいはこんな感じ

radiohead 77348 the beatles 76339 coldplay 66738 red hot chili peppers 48989 muse 47015 metallica 45301 pink floyd 44506 the killers 41280 linkin park 39833 nirvana 39534 system of a down 37324 queen 34215 u2 33247 daft punk 33040 the cure 32673 led zeppelin 32341 placebo 32111 depeche mode 31966 david bowie 31907 bob dylan 31840 death cab for cutie 31515 arctic monkeys 30387 foo fighters 30177 air 29837 the rolling stones 29801 nine inch nails 28982 sigur rós 28944 green day 28768 massive attack 28734 moby 28269 amy winehouse 28252 portishead 28121 rammstein 27199 björk 27110 kanye west 27052 bloc party 26838 johnny cash 26680 kings of leon 26369 the white stripes 26273 beck 26264 the doors 25773 oasis 25768 ac/dc 25714 the prodigy 25674 madonna 25497 the smashing pumpkins 25370 iron maiden 25147 jack johnson 24937 franz ferdinand 24549 michael jackson 24311

だいぶロックよりな感じがするね。

ちなみにlastfmでのデータはhttp://www.lastfm.jp/chartsにある。こっちのデータだと、古いデータは切ってるみたいでlady gagaとかが上位に来てる。クローリングデータの方だとbeatlesは3000万回再生とかでlady gagaは121位になってる。最近のだけに絞った方がいいね、ほんとは。

pythonでテキスト1000万行舐めるのにかかる時間は？

ふと気になったので測ってみた。手元にあった1.5GBの1700万行のテキストファイルでうまいこと約1.７秒だったので1000万行あたり1秒程度ってとこですな。そこに x+=1のような1処理加えるごとに0.6秒ほど加算される感じ。体感として持っとくと便利かもしれない。

dropbox apiにlock制御を加える

dropbox apiはSDK含めてすごく使いやすいんだけど、ファイルロックがない．（たぶん．あるかもしんない．）なので、まだまだ微妙なんだけど、どーしても欲しかったら隠しフォルダを使って自前で実装してしまおう．

つまり、

1. ".lock"フォルダを作成

error.code=404が返って来たらすでにある（=ロックされてる)キャンセル

2. 書き換えたいファイルをごにょごにょする．

3. ".lock"フォルダを削除

という手順を踏めばよろし．lock制御用に別サーバー立てるのもあほらしい．

Trending Blogs

Recently Viewed Blogs

nashibao blog