b-Bit MinHashによる高速かつ省スペースな類似度判定 | SmartNews開発者ブログ
ゴクロの浜本です。ネットカフェでコードを書くのが好きです。 前回のエントリーでも触れられていますが、SmartNewsはホットな話題をユーザにお届けするために、常時、膨大な数のツイートおよびURLをクロールしています。こうして収集した記事に対し、様々な分析が施されますが、その中でも重要な処理の1つに、記事の類似度判定があります。内容の似通った記事をインデックスから発見し、グループ化する処理です。 毎秒、大量の新着記事が到着することから、この類似度判定は高速に実行する必要があります。また、インデックスを全てメモリに載せているので、類似度判定を実現する際の空間効率も要求されます。 今回は、SmartNewsが高速かつ省スペースな類似度判定のために使用しているb-Bit MinHashと呼ばれる手法を紹介します。2年前に、PFIの岡野原さんが非常に分かりやすい解説記事を書かれており、本エントリー
ISUCON3 予選の企画と運営をしました - 941::blog
運営担当なのですが正式名称が ISUCON3 なのか ISUCON 2013 なのか ISUCON なのか未だによく分かってません。去年 #isucon2 ってことにしたのにあまり浸透しなかったので気に入ったやつでいいです。ちなみに ISUCON は いすこん と読みます。 はい。というわけで予選の企画と運営をしました。本選も引き続きやります。 今年は出題をカヤックさんにお願いしようと思っていて、１月にあった CROSS2013 というイベントで藤原さんに最初に相談した気がする。すぐに快諾いただいて、「じゃあ具体的になる頃にまた～」というかんじで徐々にスタート。 参照 【追記】エンジニアサポートCROSS2013に参加してきたのでイベント的な視点で感想 #cross2013 基本的には問題作成まわりを藤原さんにまるっと(オンライン予選二日目まで出題内容知らないくらいにまるっと)お願いして、
MacのClangでC++11を試すには clang++ -std=c++11 -stdlib=libc++ としてみよう - minus9d's diary
MacのClangもアップデートできたので早速C++11を試す。unordered_setという機能を使ってみようと、main.cppに #include <unordered_set> ...と書き $ clang++ -std=c++11 main.cppとビルドを試みるも、以下のエラーが出てコンパイルに失敗。ヘッダファイルが見つからないらしい。 main.cpp:1:10: fatal error: 'unordered_set' file not found #include <unordered_set> ^ 1 error generated. どうやらlibc++と呼ばれる、C++11をターゲットとした標準ライブラリを使うのが正解らしい。そこでClangのオプションを以下のように変更すると、無事コンパイルが通った。 $ clang++ -std=c++11 -stdlib=l
SQLでincrementした値を表示するやつ - かみぽわーる
MacBook Air 11インチ欲しい！ @sugyanさんのSQLでincrementした値を表示する方法を考える - すぎゃーんメモを生DBIでやってみたのとベンチマークとってみた。 トランザクションなし Rate dbic teng dbi1 dbi2 dbic 578/s -- -64% -92% -92% teng 1587/s 175% -- -78% -79% dbi1 7143/s 1136% 350% -- -7% dbi2 7692/s 1231% 385% 8% --トランザクションあり Rate dbic teng dbi1 dbi2 dbic 581/s -- -59% -88% -92% teng 1429/s 146% -- -71% -81% dbi1 5000/s 760% 250% -- -35% dbi2 7692/s 1223% 438% 54%
grunt-contrib-watch が重いので grunt-este-watch を試したら幸せになった
最近、Grunt と grunt-contrib-watch を使っているのだけど、grunt-contrib-watch が CPU を消費しがちである。 watch 対象のファイルが少ないうちは grunt-contrib-watch は問題なく動くんだけども、ファイル数が増えてくると CPU の消費量が増えてくる。自分の環境では、1,000 個ぐらいのファイルを監視していると、常時 10% 程度 CPU を消費している。 この問題は既知であり、FAQ には次のように書いている。 たくさんのファイルを監視している場合、デフォルトの interval の値が小さすぎるかもしれない。options: { interval: 5007 } のようにして増やしてみてほしい。詳しくは issues #35 と #145 を参照のこと (※日本語訳は私によるもの) Another reason i
RGenGCに対応する方法 - mirichiの日記
Ruby2.1.0-preview1は出たがREADME.EXT.jaを見ても書いてないので調べたことをここに書いておく。正式なマニュアルじゃないし検証してるわけでもないから豪快に間違っているかもしれん。 ■はじめに RGenGCは今までの拡張ライブラリのコードそのままで動作するように作られていて、何も考えずにコンパイルすれば普通に動く。2.1用に拡張ライブラリをコンパイルして動かない場合、よっぽど特殊なことをしていない限りはRGenGC以外のところに原因があると考えてよい。そのぐらい互換性に気を使われている。 なので特別に対応する必要は無いのだが、対応すればGCのパフォーマンスが上がるし、Shady化の処理を省く効果もあったりしてさらに速くなるかもしれない。速度を売りにした拡張ライブラリは対応しておいて損は無いだろう。 RGenGCの対応には大きくわけて以下の2つのパターンがある。両方や
ログファイルの圧縮方法
圧縮レベル2と3では、bzip2よりずっと短い所要時間で高い圧縮率が得られています。興味深いのはレベル4で、所要時間が大きく増えたのに圧縮率が下がっています。xzはレベル4からLZ法の一致文字列を探すアルゴリズムが変わるので、これが裏目に出ているようです。 bzip2より2割以上高い圧縮率が得られるレベル7以上では、所要時間は5倍以上になります。ログファイルの圧縮方式が混ざるのは何かと面倒なので、5倍の所要時間でこの程度の圧縮率の差ではxzに変更する気にはなれないです。 圧縮率はそうでもないですが、xzの伸張速度の速さはとても魅力的です。デフォルトの圧縮率のファイルを伸張するのに、bzip2が1分22秒かかるのに対してxzは25秒しか掛かりません。ログを集計するときに伸張速度が3倍近く速いのはとても有利です。 もし圧縮方法を決め直せるならxzにするかもしれません。適宜レベルを調節してbzi
JavaScriptフロントエンド開発の昨今
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Capistrano Version 3
Deploying — the smell of coffee, the satisfaction of shipping, the excitement of lovingly crafted code going out into the world. It’s hard not to love releasing code, but when it comes to actually writing deployment scripts, it’s one part of programming that most people don’t write home about. In the Ruby world, Capistrano has been the de-facto standard for deploying applications since it’s releas
「社長が覚えられないので管理者のパスワードは４桁の数字でお願いします」 - 情報の海の漂流者
新規で立ち上げる某中小企業サイトのネットショップ機能について、タイトル通りのセリフを言われて、ここ最近気が重かった。 そういう感覚で自前のネットショップをやるのはセキュリティ上明らかにまずい。 この件のことを考えていると、顧客情報流出したらどうしようとか、管理者アカウントを乗っ取られたらどうしようとか、そもそもそんな危険なサイトを作るのはインターネット全体に対する裏切りなんじゃないのかとか、いろいろ悩んでしまい、胃が痛くて仕方がなかった。 そんなタイミングで、yahooショッピング出店料無料化のニュースが流れたのはすごいラッキーだった。 先方はどうやら、出店料や維持費が払えないため、自前でネットショップをやろうと思ったらしくて、ヤフーの変更について話したら「その条件ならばヤフーでやりたい」と即座に方向転換することが決定した。 yahooでやってくれるならば、パスワードは最低6桁必要になる。
mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
Making full table scan 10x faster in InnoDB
At MySQL Connect 2013, I talked about how we used MySQL 5.6 at Facebook, and explained some of new features we added to our Facebook MySQL 5.6 source tree. In this post, I'm going to talk about how we made full table scan faster in InnoDB. Faster full table scan in InnoDB In general, almost all queries from applications are using indexes, and reading very few rows (0..1 on primary key lookups and
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
英語コミットコメントに使えるオシャレフレーズ集