1億PV/日のデータ分析をTableauで効率化！ドワンゴ流アクセス解析の裏側とは。 | SELECK
今回のソリューション：【Tableau/タブロー】 〜Hadoop、R、Apache Pigを組み合わせた分析基盤に、BIツール「Tableau」を導入した事例〜 「ニコニコ動画」や「ニコニコ生放送」からなる「niconico」は、1日のPV数が1億を超える国内最大級の動画サービスだ。それだけのアクセス数を持つWebサービスの場合、そのアクセスログなどのデータ分析をどのように効率化するかは大きな課題になる。 運営元である株式会社ドワンゴでは、以前、Hadoopなどのデータソースから各担当者が欲しいデータを都度取得し、エクセルなどで加工し直してレポートを作成する、というフローをとっていた。各サービスごとに分析に使うツールも異なっていたため、KPIなどの数値も横断的に可視化できていなかったのだという。 そこで導入したのが、ビッグデータを簡単にグラフなどにビジュアライズするBIツール「Table
Google Chromeが採用した、擬似乱数生成アルゴリズム「xorshift」の数理
2015年12月17日、Google Chrome の JavaScript エンジン（処理系）である V8 の公式ブログにて、 JavaScript の標準的な乱数生成APIである Math.random() の背後で使われているアルゴリズムの変更がアナウンスされました。 Math.random() 関数は JavaScript を利用する際には比較的よく使われる関数ですので、親しみのある方も多いのではないかと思います。 新たなバグの発見や、従来より優秀なアルゴリズムの発見によってアルゴリズムが変更されること自体はそれほど珍しくはないものの、 技術的には枯れていると思われる Math.random() のような基本的な処理の背後のアルゴリズムが変更されたことに驚きを感じる方も少なくないかと思いますが、 それ以上に注目すべきはその変更後のアルゴリズムです。 実際に採用されたアルゴリズムの原
apigeeのWeb API Designよんだ
なるほど URLには複数形の名詞で具体的な名前をつけましょうね 大抵の人がおそらく使うであろうRESTful APIはGETメソッドだろうとのことでURLの名称は複数形の名詞にしておくのが自然。 ただし、複数のリソースを含んでしまうような名前は避けないとダメ。 それから、/itemsとか/assetsみたいな抽象的な名称も避けないといけない。/itemsというリソースにはおそらくブログや動画が含まれうるから。 関連性はシンプルに リソースはほとんどの場合が別のリソースと関連している。では、そういう時どうやってシンプルさを保つか。 犬には飼い主がいるだろう。なので次のようにできる。 GET /owners/5678/dogs POST /owners/5678/dogs こんな風にしていくといくらでもリソースの階層が深くできてしまう。 そこで知っておきたいのは主キーが決まってしまえば情報は特
MySQLでクエリチューニングことはじめ
最近、寒暖の差が激しいですがみなさん体調は崩されていないでしょうか？ こんにちわ。モニプラ for Facebookを担当しています高橋です。 サービス開始当初は問題なかったものの稼働が高くなりデータ量が多くなって クエリのパフォーマンスが悪化すること…よくありますよね？ 今回はクエリチューニングの基本的な手順とケース別に解決方法を解説したいと思います。 クエリチューニングの手順 1.スロークエリログで問題のクエリをあぶり出す まずはどのクエリが問題なのか特定する必要があります。 アプリケーション側でクエリの実行時間を測定し自前でログを出力しておくというのも手ですが、 お手軽にMySQLの設定で一定時間以上掛かったクエリをログに出力しておくことができます。 スロー クエリ ログ(MySQL 5.1 リファレンスマニュアル) mysqldを–log-slow-queriesオプションつきで起
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
