去年から公開されてる「JR東日本アプリ」ですが、機能の一つに「山手線トレインネット」というものがあります。 これは山手線の各車両の現在位置、混雑状況、室内温が見えるというもので、 座りやすい車両を探すのに便利だったりします。 山手線トレインネットから取得した車両位置と混雑率 電車の運行情報がここまで時間粒度細かく公開されているのは世界的にも珍しいので、特に目的も無しにデータをクローリングして遊んでみました。 データをクローリングする まずは山手線トレインネットの車両位置・混雑情報をクローリングします。 JR東日本アプリの山手線トレインネット。 今の車両内の混雑や室内温が見える。すごい! 「山手線トレインネット」はブラウザから見えるページが存在しない、iPhone/Androidアプリ専用の画面です。 なので普段の「FirebugでAJAXの通信を見てAPIをリバースエンジニアリング」ほど簡
(環境変数GODEBUGは、 ランタイム パッケージで提供されています) この環境変数を指定してプログラムを起動すると、標準出力に以下の追加出力が出力されます(少し簡略化されています)。 % env GODEBUG=gctrace=1 godoc -http=:6060 ... gc76(1): 2+1+1390+1 us, 1 -> 3 MB, 16397 (1015746-999349) objects, 1436/1/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields gc77(1): 2+0+1582+1 us, 2 -> 4 MB, 14623 (1016248-1001625) objects, 1436/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields scvg0: inuse:
先日、有志で集まって「BigQuery Analytics」という書籍の読書会をやった。その名の通り Google BigQuery について書かれた洋書。 BigQuery を最近仕事で使い始めたのだが、BigQuery が開発された背景とかアーキテクチャーとかあまり調べもせずに使い始めたので今更ながらその辺のインプットを増やして以降と思った次第。 それで、読書会の第1回目は書籍の中でも Overview に相当するところを中心に読み合わせていった。それだけでもなかなかに面白かったので少しブログにでも書いてみようかなと思う。 BigQuery の話そのものも面白いが、個人的には Google のインフラが書籍『Google を支える技術』で解説されたものが "Big Data Stack 1.0" だとして、BigQuery は Big Data Stack 2.0 の上に構築されており
Schema-less Stream Processing with SQL Norikra is a open source server software provides "Stream Processing" with SQL, written in JRuby, runs on JVM, licensed under GPLv2. Schema-less event streams (called as 'target') Input/Output event streams as JSON objects, which can contain any fields with a target name. SQL processing Norikra's query is SQL with window specifier support (It's actually Esper
2010/09/07 KVS(キー・バリュー・ストア)に分類されるオープンソースのRedisの新バージョン、「Redis 2.0.0」が2010年9月5日にリリースされた。Redisはmemcachedと同様にキーと値のペアをメモリ上に保持するKVSの一種だが、3つの際立った特徴がある。1つはハッシュ以外のデータ構造もサポートしていることで、リスト型、集合型、順序付き集合型などのデータ構造が扱え、サーバ側でコレクションに対するpush/pop、コレクション同士のunion/intersection、数値のincr、decrなどの操作がアトミックに行える。バージョン2.0では複数の操作を1つにまとめてアトミックに操作するコマンドも増えている。 もう1つのRedisの特徴は、マスター・スレーブによるレプリケーション設定ができ、リード側のスケールアウトが容易にできること。 そして3つ目の特徴は、
『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』『MarkeZine Academy』『MarkeZine プレミアムセミナー』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day
Redis でのデータの永続化方法について調べたので、忘れないうちにまとめておきます。 調べた時の Redis のバージョンは 2.6.13 です。 スナップショット(RDB) Redis のデフォルトの永続化の仕組み この設定が有効な場合、Redis は定期的にデータベースの内容をディスクに出力する Redis を再起動するとこのファイルからデータが読み込まれ復元される 一定回数の更新 + 一定間隔でディスクにファイル出力 ファイル出力タイミングは設定ファイル、CONFIG コマンドで変更可能 無効にもできる 出力は非同期で行われるため、プロセスがクラッシュした場合には前回のスナップショット以降のデータが失われる可能性あり 多少のデータロスを許容できるようなデータならスナップショットのみでもイケそう 手動で実行するには SAVE コマンドまたは BGSAVE コマンドを実行 SAVE は
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の3つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から: なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
huin Job : Software Engineer(iOS, Android) Use : Objective-C, Swift, Java Like : Gadget, Apple, Photography, Art, Design, UI, UX More posts by huin. 今年もやって来ましたApple WWDC 2014。 昨年は幸運にもチケットが手に入ったので現地で生で観れたのだけど、 今年はハズれてしまったので大人しく家から中継みてました。 今回は、過去最大レベルで開発者向けのアナウンスが多かったように感じます。 正直、ぜんぜん把握しきれてませんが、ひとまず発表内容をまとめてみます。 ※写真はThe Vergeへのリンクになっています。 WWDCについてのアナウンス 25回目の開催 69カ国からの参加、70%は初参加. 世界には900万人の開発者が登録.過去1
From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluentd Meetupのデモでは9億件を7秒程度で検索していたが、BigQueryの真の実力はこれより1〜2ケタ上だからだ。ちょっと手元で少し大きめのテーブルで試してみたら、120億行の正規表現マッチ付き集計が5秒で完了した。論より証拠で、デモビデオ(1分16秒)を作ってみた: From The Speed of Google BigQuery これは速すぎる。何かのインチキである(最初にデモを見た時そう思った)。正規表現をいろいろ変えてみてもスピードは変わらない。つまり、インデックスを事前構築できないクエリに対してこのスピードなのである。 価格も安い。さすがに120億行のクエリは1回で200円もかかって気軽に実行できなさそうであるが、1.2億
mysqldumpのオンラインバックアップ mysqldumpのオプション mysqldump時にロックをかけないオプションは「--single-transaction」です。 --single-transaction このオプションはサーバからデータをダンプする前にBEGIN SQLステートメントを発行します。InnoDBといったトランザクションテーブルに対してのみ便利です。なぜなら、アプリケーションをブロックせずに、BEGINが発行された当時のデータベースの状態をダンプするからです。 このオプションを使用しているときは、一定の状態でダンプされるのはInnoDBテーブルのみだということを留意してください。例えば、このオプションを使用中にダンプされたMyISAMやMEMORYテーブルは状態が変化する可能性があります。 mysqldump — データベースバックアッププログラム リファレンス
特定の更新があって、世界中のコンピュータが同時に同じ更新ファイルをダウンロードした時の瞬間最大風速的トラフィックは恐らく凄いです。 Microsoft社がWindows Updateで新ファイルを公開した次の瞬間に世界中で国際間にある光ファイバがパンクしないのはアカマイ社があるからとも言えそうです。 4秒ルール? 表示に4秒以上かかると75%の顧客は購買意欲がなくなるという調査結果もあるようです。 「BBC NEWS : Websites face four-second cut-off」 Shoppers are likely to abandon a website if it takes longer than four seconds to load, a survey suggests. The research by Akamai revealed users' dwindli
2013年03月21日18:11 MySQL 今さらだけどMySQLのパーティショニング機能を試してみた 最近は花粉が飛んでて辛い季節ですがみなさまいかがお過ごしでしょうか。でももうちょっと我慢すればサクラの季節ですよ〜。花見良いですよね、飲みたいだけですが。 ・・さて、今回はちょっと必要になったので、MySQLのパーティショニング機能なるものを試してみました。存在は知ってたけど、実際に試してみたことは無かった…。 パーティショニングとは? これはどういうものかと言うと、MySQL5.1から使えるようになった機能で、ひとつのテーブルのデータを条件によって複数の領域(パーティション)に振り分けて管理することができる、というものです。例えば日別にデータを別々のパーティションに振り分けたり。 パーティショニングするとデータの削除が高速だったり(通常は削除ってものすっごい遅いけど、特定のパーティシ
39. 実際の使用イメージ 試行数 アーム1期待値 アーム2期待値 アーム3期待値 活用or探索 0(0/0) 0(0/0) 1 1(1/1) 0(0/0) 2 1(1/1) 0(0/1) 3 1(1/1) 0(0/1) 4 1(2/2) 0(0/1) 5 1(2/2) 0.5(1/2) 6 1(2/2) 0.5(1/2) 7 8 0.66(2/3) 0.5(1/2) 9 0.5(2/4) 0.5(1/2) 10 0.4(2/5) 0.5(1/2) 0(0/0) 0(0/0) 0(0/0) 0(0/1) 0(0/0) 0(0/0) 0(0/2) 0(0/2) 0(0/2) 0(0/2) ・・・最も期待値の高いアーム 39 探索 探索 探索 探索 探索 探索 活用 活用 活用 活用 ランダム選択 引くアーム 結果 1 2 3 1 2 3 - アーム1 アーム2 アーム3 アーム1 アーム2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く