文字通り「ネットワークがコンピューター」な金融HFTでのFPGAの使われ方 - スティルハウスの書庫の書庫
ここのところ重度のFPGA中二病にかかってしまい、冬休み中もDE0ざんまいな日々。気になっていた金融のHFT（high frequency trading：大手投資銀行等がμ秒単位の超高速で株式等を売り買いしてる恐ろしい市場）におけるFPGA利用状況について、HFT Reviewにこってりしたレポート（HFT業界のベンダー各社にインタビューしたもの）が載っていたので、勢い余って面白かった部分を超訳してしまった。 元ネタはこちら： FPGA & Hardware Accelerated Trading, Part One - Who, What, Where and Why? FPGA & Hardware Accelerated Trading, Part Two - Alternative Approaches FPGA & Hardware Accelerated Trading, P
Paxosお勉強メモ - スティルハウスの書庫
Paxosのお勉強メモです（以下、分散システムとか無知なのですごく勘違いしてる可能性ありますので要注意） Wikipedia: Paxos algorithm Paxos is a family of protocols for solving consensus in a network of unreliable processors. Consensus is the process of agreeing on one result among a group of participants. This problem becomes difficult when the participants or their communication medium may experience failures. Paxosは、信頼性の低い複数の処理ノードによるネットワークで「コンセンサス
#hadoopModeling のust録画です - スティルハウスの書庫の書庫
ust係なのに1時間も遅刻して済みませんでしたっ！ @shot6さんの取りそびれてしまった。。ごめんなさい。佐藤先生の途中から配信＆録画できました： 佐藤先生 http://www.ustream.tv/recorded/8525140 あらかわ先生 http://www.ustream.tv/recorded/8525234 討論会 http://www.ustream.tv/recorded/8525436 皆さんそれぞれにユニークな観点からHadoopの設計手法について語られていて、とってもむずおもしろい会でした。
appengine ja night #6やりました！ - スティルハウスの書庫の書庫
先週金曜はappengine ja night #6でした。今回はSlim3 1.0.0をリリースされたばかりのひがやすをさんに、前回からひきつづきSlim3のグローバルトランザクション（gtx）についてソースを見ながらの解説をいただきました。またその前に、予備知識としてのgtxの仕組みについて荒川さんから30分ほど解説いただきました。 ＜セッション1＞ 発表者：荒川さん（@ashigeru） テーマ：「図解Global Transaction」 資料：appengine ja night #6 図解Global Transaction ＜セッション2＞ 発表者：ひがやすをさん（@higayasuo） テーマ：「Global Transaction・第2部」 参考ページ：Slim3 1.0.0 Released しげる先生は相変わらず図版（Visioで書いてるそうです）の豊富なわかりやすい
Google I/O 2010のApp Engine関連セッションの予定テーマまとめ - スティルハウスの書庫の書庫
Google I/O 2010のセッション一覧が発表されてました（thx! > @shot6）さっそくApp Engine関連のセッションを抜き出してみましょう。 Building high-throughput data pipelines with Google App Engine / Brett Slatkin This session will cover how to build, test, and maintain large-scale data pipelines on Google App Engine. It will cover maximizing efficiency, productionization, and how to deal with changing requirements.App Engine上で大規模なデータパイプラインを構築、テスト、運
Building Scalable, Complex Apps on App Engineを見たメモ - スティルハウスの書庫の書庫
Building Scalable, Complex Apps on App Engine List properties 01:40 List propertyとは何か？ 複数の値を持てるプロパティ 順序付きリスト LPのメリット one-to-many関係にあるデータをコンパクトに扱える tupleやlistのようなデータを簡単に保存できる 子entityを扱う必要がない。entityより軽い。 ただしcomposite indexで使う場合はindex explosionに注意 サイズが1000のLPを2つ使ってcomposite indexを作ると100万件のindexエントリができあがる Microbloggingの例 たくさんのエントリを多数のユーザーに配布する必要があり、スケーラビリティが要求される データ自体はコピーせず、fan-outさせる方が効率的 RDB的実装：Use
Task QueueはMapReduceの夢を見るか - スティルハウスの書庫の書庫
いまコーディング中の案件で、Task Queueにぴったりハマる要件があったので、飛びついてみました。 課題：Datasource上の大量のデータをクライアントにダウンロードしたい。30秒内では終わらないので複数のリクエスト／レスポンスに分割してダウンロードする実装にした。しかしデータ量によっては何10分もかかってしまう。 原因：データ量の多さもあるが、それを取得するためのDatastoreのクエリ、および関連エンティティの取得にもっとも時間がかかっている 書こうとしているソリューション：クエリと関連エンティティ取得をTask Queueのタスクに分割して並列処理（map）し、取得したデータを集約（reduce）してクライアントに渡す …んん、これってMapReduceではないですか。1つのリクエストでは重い処理は、たくさんのタスクに細切れにして、キューにどんどん入れる。App Engin
Task Queue戦記 - スティルハウスの書庫の書庫
とても遅かった以前の実装をTask Queueを使って書き換えることができました。感想をまとめると、 Task Queueはすばらしい。30分かかってた処理が3分で終わるようになった（前の実装がヘボいのではという疑惑はさておき） 処理を複数のタスクに分割して並列処理する（map）は簡単だけど、memcacheを使ってその結果をまとめる（reduce）のは面倒 reduce不要な用途（一括削除とか）や、reduceが簡単な場合（数の集計とか）、あとmemcache使わずにDatastoreに集約する使い方なら、そんなに苦労しないだろう memcacheを介してデータの配布や収集をするとき、とくに収集時の排他を書く必要あり（こういうバグりそうな／バグを再現できなさそうなコードは書きたくない） MemcacheService#incrementを使ってスピンロックを実装した memcacheはい
Memcacheでスピンロックを実装してTask Queue処理結果を集約してみるテスト - スティルハウスの書庫の書庫
TaskQueueで分散処理した結果をまとめるときは、排他を考慮する必要があります。Datastoreを使う場合なら、単に結果を新規エンティティとして追加したり、エンティティグループの楽観排他を使ったりすればOKです。一方、やっぱりMemcacheでスピーディーに集約したいよ、という場合は、Memcache上で排他を実装する必要があります。以前のエントリにちょろっと書いたMemcacheService#incrementでスピンロックという方法について説明してほしいというコメントをid:miztakaさんよりいただいたので、ここに改めて書きたいと思います。 Memcacheでは排他制御が必要 ご存じのとおり、App Engineはデフォルトで複数のApp Serverによるクラスタが構成されており、またMemcacheサービスはクラスタ全体で共有されるグローバルなキャッシュとして機能します
GAEのサーバー構成とリクエストの流れ - スティルハウスの書庫の書庫
＜Google App Engine Stackの構成（引用元）＞ GAE Stackの特徴 現在の利用状況 8万以上のアプリを収容 140M PV/day 20万人以上の開発者が利用 統合環境を提供 サーバーの構築や管理が不要。デプロイが容易 ログ管理、管理コンソールや各種ツールを提供 スケーラブルなWebアプリ構築のためのベストプラクティス利用を促す環境 個々のリクエストの処理時間やリソース消費を制限 ステートレス設計と内蔵APIの利用 Datastoreによるパーティション化されたデータモデルの利用 非常に高いスケーラビリティと可用性を備えるGoogleのクラスタ環境を簡単に利用できる 自動クラスタリングによる負荷分散と高可用性を提供 アプリの負荷状況に応じてApp Serverを動的に増減 アプリ間の隔離性を維持、個々のアプリの安全性とパフォーマンスを確保 既存のGoogleテクノ
Google App Engineのtips集 - スティルハウスの書庫の書庫
（随時更新中です。間違いなどありましたらコメントをお願いします！） このページのtinyurl: http://tinyurl.com/gaetips Datastoreのtips Bigtableの内部構造 BigtableによるDatastoreの実装 Datastoreによるクエリの実装 トランザクションとエンティティグループ Datastoreのtips List Proprtyとmerge joinの使い方 GAE一般のtips GAEのサーバー構成とリクエストの流れ Task Queue APIの使い方 開発環境とプロダクション環境の違い Flex/AIR＋GAEのtips GAE/JにBlazeDSを組み込む BlazeDSの本番環境へのデプロイでハマる Datastore APIの取り扱いでハマる App Engine開発の便利な参考ページ TOPGATEさんのGoogle
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
