Ameba Piggの裏側
The document describes the architecture of AmebaPigg, a social networking application. It shows that AmebaPigg uses a hadoop cluster for file storage, MySQL for user data storage, and memcached for caching. It also uses various socket servers to handle chat, games, and other functions, with a web app server presenting the interface, all built using Flash (ActionScript 3).Read less
Evernoteのアーキテクチャ概要 - nokunoの日記
みなさん、Evernoteは使っていますか？ Evernoteは「全てを記憶する」が合言葉のメモアプリで、クラウド上にデータを保存してWin/Mac/iPhone/Webから共通のデータにアクセスしたり同期したりできるのが特徴の便利なサービスです。開発元はシリコンバレーの会社ですが、日本人のユーザも非常に多いそうで、Evernoteの使い方についての記事は日本語でも星の数ほどありますのでここでは触れません。 今回は、そのEvernoteの裏側のシステム概要を解説する記事が今月開設されたばかりの技術ブログに公開されていましたので、翻訳してみました。Architectural Digest | Evernote Tech Blog はじめにこのブログの手始めとして、Evernoteの構築について大雑把な概要を述べる。ここではそれぞれのコンポーネントの詳細に踏み込むことはしない。それらについての
いきあたりばったりのアーキテクチャと教訓
スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです（訳は前述の記事「データベースの間違った使い方10項目」から）。 Dynamic table creation（動的なテーブルの作成） Table as cache（テーブルをキャッシュとして使う） Table as queue（テーブルをキューとして使う） Table as log file（テーブルをログとして使う） Distributed Global Locking（分散したグローバルなロック）
NoSQLを上回る性能のVoltDB、そのアーキテクチャとは
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
内部WebAPIの呼び出しコスト - MVCモデルの”次” - Tous Les Jours 攻防記
デブサミ２００９でid:secondlife氏が発表されたという資料を見てみました。 http://www.slideshare.net/hotchpotch/deb2009-1023281 はてぶをフルスクラッチでリニューアルした際に、従来のMVCモデルからさらに一歩進んで抽象化を進めたとのことで。 資料中、MVCの発展系として、MVACなる概念が提唱されているのですが、Aは「Applicaiont」？？「アプリケーションレイヤの作成」という記述もあるし、たぶんApplicationのtypoですねきっと。 資料からは「データソース層」「サービス層」「アプリケーション層」の３層が「Model」「View」「Application」「Controller」にどう対応するのかよくわからなかったけど、おそらく「サービス層」を担当するのが「Application」なのでありましょう。 そして、「
スキーマ不定のデータをRDBに永続化する方法の比較 — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
「クックパッド」の裏側にいってきた | Carpe Diem
Web デベロッパーの祭典に行ってきた。今回は、通路沸きに用意された比較的狭いスペースで開催された。 以下、メモと自分の勝手な感想をまとめておく。 クックパッドについて 毎日の料理を楽しみにすることで心からの笑顔を増やす 1998年にオープン 去年のリニューアルのときに Rails で作り直した 使い方 レシピをのせる レシピをさがす 月間ユーザ数 547万人 Rails サイト中世界7位 (from rails 100 wiki)、まさか1位がscribd.comとは 月間 2.8億 PV(PVでは、Rais サイト中世界3位) 登録レシピ数: 47万品 トラフィックは、16-18時くらいがピーク(夕飯を作る前に調べるユーザが多いとのこと) 秋からバレンタインにかけてトラフィックが伸びる(来週はピークだということで、最近はパフォーマンス向上に中心にやっていた) ユーザ数: 547万人(す
分散プロジェクトの誤謬 - steps to phantasien t(2008-02-26)
タネン本を始めとする分散システムの教科書で必ずとりあげられる話題に "分散コンピューティングの誤謬" がある. 以下 Wikipedia から引用. ネットワークは信頼できる. レイテンシはゼロである. 帯域幅は無限である. ネットワークはセキュアである. ネットワーク構成は変化せず一定である. 管理者は一人である. トランスポートコストはゼロである. ネットワークは均質である. ネットワークプログラミングをしたことがあれば, いずれも該当のバグに思いあたる節があると思う. これらはみな複数台の計算機が関わる際の問題であり, いわばコミュニケーションの問題. 同じ問題は計算機同士に限らず, 人と人の間, 組織の間でもおこる. 順番に例を並べてみる. <伝言や連絡は信頼できる> : できない(よね?) ミーティングには欠席者がいる. 後輩は話を聞いてない. メモもとらない. メールはスパムに
Google の大規模データ処理: Days on the Moon
Google の鵜飼文敏さんによる講演会「大規模データ処理を可能にする Google の技術」に行ってきました。内容的には筑波大学で開かれたものと同じではないかと思います (「新ビジネスモデル」がそのままだったことなどから)。以下、上記記事に載っていないことを中心にメモから抜書きを。 此頃 Google にはやる物 現在 Google では Google の使命 (Google's mission is to organize the world's information and make it universally accessible and useful...) の早打ちが流行中。鵜飼さんは 50 秒程度、一番速い人は 30 秒程度。 Google の扱う情報 Google のいう「情報」はインターネット上のものだけに限らない (例: Google ブック検索)。 データセンター
livedoor Techブログ : nowaのサーバ構成
こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://japan.internet.com/developer/20080226/26.html