Ctlab.org© 2008-2015 by Register.com™, Disclaimer and DMCA Notice. Trademark Free Notice
LinkedIn Data Infrastructure (QCon London 2012)
LinkedIn uses DataBus to replicate data changes from Oracle in real-time. DataBus consists of relay and bootstrap services that capture changes from Oracle and distribute them to various services like search indexes, graphs, and read replicas to keep them updated in real-time. This allows users to immediately see profile updates or new connections in search results and feeds.Read less
LINE Storage: Storing billions of rows in Sharded-Redis and HBase per Month « NAVER Engineers' Blog
Hi, I’m Shunsuke Nakamura (@sunsuk7tp). Just half a year ago, I completed the Computer Science Master’s program in Tokyo Tech and joined to NHN Japan as a member of LINE server team. My ambition is to hack distributed processing and storage systems and develop the next generation’s architecture. In the LINE server team, I’m in charge of development and operation of the advanced storage system whi
Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
AWS-CloudDesignPattern CDP2.0候補
AWSクラウドデザインパターンとは？ AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収
Evernoteのアーキテクチャ概要 - nokunoの日記
みなさん、Evernoteは使っていますか？ Evernoteは「全てを記憶する」が合言葉のメモアプリで、クラウド上にデータを保存してWin/Mac/iPhone/Webから共通のデータにアクセスしたり同期したりできるのが特徴の便利なサービスです。開発元はシリコンバレーの会社ですが、日本人のユーザも非常に多いそうで、Evernoteの使い方についての記事は日本語でも星の数ほどありますのでここでは触れません。 今回は、そのEvernoteの裏側のシステム概要を解説する記事が今月開設されたばかりの技術ブログに公開されていましたので、翻訳してみました。Architectural Digest | Evernote Tech Blog はじめにこのブログの手始めとして、Evernoteの構築について大雑把な概要を述べる。ここではそれぞれのコンポーネントの詳細に踏み込むことはしない。それらについての
Shop and Discover Books, Journals, Articles and more | Elsevier Shop
Discover Books & Journals by subjectLife sciencesAgricultural & Biological SciencesDrug DiscoveryImmunologyLife SciencesMicrobiology & VirologyNeurosciencePharmaceutical SciencesPharmacologyToxicologyPhysical sciences & EngineeringAstronomy, Astrophysics, Space ScienceBuilt EnvironmentChemical EngineeringChemistryComputer ScienceEarth & Planetary SciencesEnergy & PowerEngineering & TechnologyEnvir
Quoraを支える技術 - nokunoの日記
勉強になる記事を見つけたので気になったところを翻訳してみました。Quora’s Technology Examined | Phil Whelan's Blog はじめにQuoraはハイテク起業家の世界を体現しており、問題を見つけるのが難しいほどなめらかなシステムを提供している。この巧妙なシステムは回答者と質問者だけに支えられているわけではなく、よく練られたバックエンドシステムによっても支えられている。それは共同創業者がFacebookで磨きをかけた技術でもある。さほど驚くべきことでもなく、賢い人々は良く考えられたたくさんの賢い道具を使う。NoSQL信者たちはこう言って頭をかかえる：「なぜQuoraはCassandraやMongoDBやCouchDBのようなNoSQLではなく、MySQLをデータストアとして使うのか？」このエントリではQuoraについての技術的な情報をまとめ、考察を行う。彼
Morgan & Claypool Publishers - Synthesis Lectures on Computer Architecture - 4(1):1 - Abstract
is a totally awesome idea still being worked on. Check back later.
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
非同期プロトコルのクライアント - sdyuki-devel
非同期プロトコルとは、サーバーから返ってくる応答が、必ずしも要求した順番通りに返ってこないプロトコル（ソース無し。オレオレ定義）。 順不同で返ってくる応答と要求を対応づけるのはクライアントの仕事で、典型的には要求の中にシーケンス番号を入れておき、サーバーは要求と同じシーケンス番号を応答の中にも含める。 例：MessagePack-RPC 非同期プロトコルの特徴： イベント駆動型のサーバーの場合、サーバーの実装が簡単になる 同期プロトコルだと順番を揃えてから返さないといけない。サーバーの実装が（要求１つに対してスレッドを割り当てて処理するのではなく）ソケット１つに対してスレッドを割り当てて処理する方式だとあまり関係なくて、特に実装は簡単にならない。 処理が重い要求と軽い要求を続けて送っても、重い要求に詰まって後の応答が返ってこなくなることが無い 同期プロトコルだと、応答を送り返すにはその前の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
arch/tile: new multi-core architecture for Linux [LWN.net]
http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html