タグ

分散に関するkoroharoのブックマーク (14)

  • STF分散オブジェクトストレージ - Articles Advent Calendar 2011 Hacker

    lestrratです。日めでたく正式にSTFがオープンソースとしてlivedoor ラボ EDGE上でリリースされました! プレスリリースはこちら。 いままでちょこちょこと先出し先出しで情報をだしていましたが、これで当に当の正式公開です。一応上記のサイト以外に「公式」サイト的なものも用意しました。ソースコードはgithub上に公開されています。ということで使って欲しいので紹介記事です。 STFは分散オブジェクトストレージです。Perlメインの似たようなシステムとしてはMogileFSが有名ですが、STFは後発のメリットを生かしてPSGI互換にしたり、使用するプロトコルを基的にHTTPというオープンで枯れた技術を採用したりとメンテナンス・運用の利便性があがっていると考えています。 歴史 STFは元々ApacheモジュールといくつかのPerlワーカーで書かれていましたが、ひょんなことか

    STF分散オブジェクトストレージ - Articles Advent Calendar 2011 Hacker
    koroharo
    koroharo 2011/12/22
    『枯れた技術とオープンなプロトコルばかりを使っているのでメンテナンスやトラブルシューティングもかなり楽です。パフォーマンスも申し分ないです。』
  • 楽天、性能向上を分散オブジェクトキャッシュで実現。将来のデータ構造変革のプラットフォームとしても期待

    楽天は、同社ECサイトのバックエンドで稼働している受注データベース、在庫データベースへのアクセスの増大によって、システム全体の性能が低下することに対する解決策を求めていました。 その結果導入したのが、分散オブジェクトキャッシュです。これにより性能面での改善以外に、画面とロジックの分離に成功し、さらにデータベースの運用についての自由度も拡大してます。 7月12日、13日にガートナージャパン主催で行われたイベント「ガートナー アプリケーション&アーキテクチャサミット2010」のセッション「楽天株式会社にみる変化に柔軟なシステム構造構築の取り組み ~SOAとDCPの組み合わせ」で説明された楽天の取り組みを紹介しましょう。 ロジックの分散による複雑化とスケーラビリティが課題 解説されたのは、楽天株式会社 開発部 アーキテクチャ&コアテクノロジー技術理事 仲宗根徹也氏(写真右)。聞き手はガートナ

    楽天、性能向上を分散オブジェクトキャッシュで実現。将来のデータ構造変革のプラットフォームとしても期待
    koroharo
    koroharo 2010/07/28
    Oracleを使っているのが意外。というか、なぜかガッカリ感。
  • Twitterが分散フレームワーク「Gizzard」公開! Scalaで書かれたShardingを実現するミドルウェア

    Twitterが分散フレームワーク「Gizzard」公開! Scalaで書かれたShardingを実現するミドルウェア Twitterは独自に開発した分散フレームワークの「Gizzard」をオープンソースとして公開しました。GizzardはScalaで書かれたJavaVM上で動作するミドルウェアで、PHPRubyといったWebアプリケーションからの要求を自動的にデータベースに分散することで、大規模で可用性の高い分散データベースを容易に実現するためのものです。 Gizzard:フォルトトレラントな分散データベースを実現 The Twitter Engineering Blog: Introducing Gizzard, a framework for creating distributed datastores Twitterのブログにポストされた「Introducing Gizzard

    Twitterが分散フレームワーク「Gizzard」公開! Scalaで書かれたShardingを実現するミドルウェア
  • Rolling with Ruby on Rails

    Now, next, and beyond: Tracking need-to-know trends at the intersection of business and technology AI/ML Few technologies have the potential to change the nature of work and how we live as artificial intelligence (AI) and machine learning (ML). Future of the Firm Everything from new organizational structures and payment schemes to new expectations, skills, and tools will shape the future of the fi

    Rolling with Ruby on Rails
  • GAEの設計指針めも - あおうさ@日記

    とりあえず思いつくまま列挙。まだまだ変わる可能性は大きい。 正規化しない。RDBMSでいうところのJOIN済みのでっかいテーブル作れ。 SELECTはがんばらない。INSERT超がんばれ。 PKはString型にしてgae.encoded-pkを使用する。 PKに複合キーは使わない。(コンポジットインデックス使わない) Date型のプロパティは使わない。String型にする。 プリミティブ型はnullを許容しないので使わない テーブル間のjoinができない。→正規化せずJOIN済みのでっかいテーブルを作る 集約関数がない(group byできない)、count()で全件カウントできない →集約したい値は、集約用のエンティティを用意してInsert時に集計値を保存する(最大値/最小値も同様) 毎回対象データをすべて取得してループで集計するのは非効率(また最大1000件の制限がある)集約したい

    GAEの設計指針めも - あおうさ@日記
  • kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi

    先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か? スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています(端的!)*1 。Scalability を日語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ

    kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
  • kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi

    前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが(たぶん^^;)、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。(個人で開発している場合など、開発リソースが小さい場合はなおさら) そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います(もちろん、アルゴリズムも重要ですが)。 分散システムには複雑

    kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi
  • mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ

    今日は以前のエントリーで書くと述べたConsistent Hashingに関して語らせて頂こうかと思います。ただしConsistent Hashingはセミナーやカンファレンスなどでかなり語られていると思いますので、コンセプトに関しては深入りせず、実用性に着目したいと思います。 問題定義 分散されたキャッシュ環境において、典型的なレコードを適切なノードに格納するソリューションはkeyのハッシュ値に対しmodulo演算を行い、その結果を基にノードを選出する事です。ただし、このソリューションはいうまでもなく、ノード数が変わるとキャッシュミスの嵐が生じます。つまり実世界のソリューションとしては力不足です。 ウェブサイトのキャッシュシステムの基はキャッシュがヒットしなかったらデータベースにリクエストを発行し、レコードが存在したらキャッシュしてクライエントに返すという流れです。ここで問題なのが一瞬

    mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ
  • ConsistentHashing - コンシステント・ハッシュ法

    ConsistentHashing - コンシステント・ハッシュ法 目次 この文書について コンシステント・ハッシュ法 実例 実装 用途 コンシステント・ハッシュ法 この文書について "Tom White's Blog: Consistent Hashing" の日語訳です. http://weblogs.java.net/blog/tomwhite/archive/2007/11/consistent_hash.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 原文のライセンス: http://creativecommons.org/licenses/by-nc-sa/2.0/ 私は今までに何度かコンシステント・ハッシュ法にとりくんだことがある。 このアイデアをあらわした論文 ( David Karger らによる Consistent Hashing and R

  • Google Research Publication: The Google File System

    The Google File System Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung Abstract We have designed and implemented the Google File System, a scalable distributed file system for large distributed data-intensive applications. It provides fault tolerance while running on inexpensive commodity hardware, and it delivers high aggregate performance to a large number of clients. While sharing many

  • Bigtable: A Distributed Storage System for Structured Data - steps to phantasien t(2006-09-11)

    2006-09-11 近況 今月は貧乏なので慎しく暮らしている. 週末もひきこもりとしてオンラインの記事を読んで過ごすことに. ウェブを眺めているといいタイミングで Google の新作論文が出ていた. ありがとう, Google の中の人. これ. GFS, MapReduce, Sawzall とつづく Google インフラ N 部作の 4 章が幕をあげた. 実はデータベースも作ってるんだぜ, という話. BigTable という名前だけは以前から O'Reilly Radar などに登場していた. ようやく公式な文書があらわれた. BigTable は GFS をはじめとする Google インフラの上に作られた分散データベース. 少し変わったデータモデルと, 運用までワンセットのヘビーな実装を持つ. 実装の話もまあ面白いんだけれど, それよりデータモデルが印象的だった. 先にその

  • Oracle 10g RAC 講座 その1:事始め

    えーっと、ここ最近ずーっと仕事Oracle 10g RAC な DBMS 構築してます。Oracle はある程度知っているつもりだったのですが、RAC (Real Application Clusters)が激ムズです。Oracle 8i の時に NEC の ClusterPROつかって HA 構成の DBMS を設計運用したときは全貌が把握できていたのですが、RAC はなかなか思うように把握できていません・・・orz ※インストール自体はそれほど難しくないのですが、RAC は環境依存による障害切り分けが激しく困難です。そんなとき、RAC についての深い知識がないと、何のお役にも立たないなぁ〜なんて事を感じている今日この頃。 って事で、Oracle 10g RAC をマジメにお勉強することにしました。インストール前に、まず 10g RAC とは何んぞや?から学習しなければなりません。特

  • [ThinkIT] 第1回:Linux上で利用するOracle RACのメリット (1/3)

    「情報化社会」とは言い換えればデータ依存の社会です。今日ではデータがなければビジネスは成立しないといっても過言ではありません。日増しに増加していくデータにどう対処していけばよいのか、その重要なデータを保持するデータベースシステムの構成は各企業においても頭を悩ますところでしょう。 「万が一データベースがダウンしてしまったら?」 考えれば考えるほど頭が痛いというのが音ではないでしょうか。 これまで一般的だった単体形式では拡張性、可用性の部分で大きな問題があります。拡張しようにも、できることはせいぜいCPU/メモリ/ハードディスクの増設程度と、ハードウェアレベルでの拡張には限界がつきまといます。 可用性についていえば、1度サーバがダウンしてしまったら復旧するまで手出しができません。大切なデータを保持するシステムを任せるにはスタンドアロンではあまりに心許ないでしょう。 この悩みを解消するのがクラ

  • RDBMSは本当に便利なのか:やむにやまれず - CNET Japan

    最近スケーラビリティが花盛りですね。 一昔前からLAMPによるアーキテクチャが基セットで展開されていました。大企業的思想では、「そんなおもちゃみたいなセットでミッションクリティカルは乗り越えられないのだ!」とか言われ、一部では無視すらされてきたわけですが、最近になってやっと先人のノウハウが少しずつ世に出てきて、古い世代の人達も「そんなに安くてスケールさせながら使えると言うのなら…」と重い腰を上げ始めました。 ミッションクリティカルをLAMPスタックだけで網羅的にやるのはさすがに用途が違いすぎてチャレンジになってしまいますが、その中でもアクセスの膨大な大規模サイトを安定的に動かす…といった要件には有効で、ニーズもあることがやっと理解されてきたように思います。 最近ではmixiや、Livedoorの中の人が何かの講演会や雑誌でノウハウの発表をしていたり、Flickrの中の人も"Buildin

  • 1