Cloud

@hamhei氏による『MyCloudの話と、みんなで世界(のファイルシステム)をぶち壊そう』

[2010-07-25 14:38]

前半戦: MyCloud

  • 質問タイム:
    • オンラインストレージをつかっている人→5,6人 (50%)
    • 携帯でオンラインストレージをつかっている人→2,3人
  • googlezon→究極のロックイン(パロディ epic 2015 2005ごろに発表されたかな?)
  • MyCloud: 複数のデータクラウドに分散してデータを保存してくれる。
  • クラウドサービスをつかいたおしたいけど、自分の情報は一切わたしたくない!
  • 携帯: 紛失件数 25万件/年だし記憶容量は小さいし
  • そこでAES暗号化+分散配置でプライバシー保護
  • ロックイン回避
    • クラウドベンダの倒産はこわい。
    • Gmailの月額使用料が980円になったらこわい。(すぐに止めるのはむつかしいはず)
  • 可用性
    • 1クラウド稼働率99.9% =526分/年。
    • 3クラウドつかうと 31msec/年。
    • ここまでくるとMyCloud自体の安定性が問題になってくるけど。
    • PCが故障しても鍵とかアカウントがわかれば継続して利用できる。
    • MyCloudの方がそのままつかうより3倍くらい速くなる。
    • 時間帯によってクラウドの速度に波があるので、そのときどきでいちばん速いのを使うようにする。
    • uploadは冗長に保存する分があるのでそんなに速くならない。
    • ファイル毎に冗長度は変えらえる。(フォルダというものはない)
    • クライアントソフトは小さいのでダウンロードしてきてすぐつかえる。
    • どかんというFSキットをつかってファイルシステムにみせるのはちょっと手間。(安定してないらしいし)
  • ストライプサイズ
    • 大きなファイルは0.5MBくらいにちぎって保存。
      • chunk sizeとthruputの関係は山形になる。
      • 大きのときに落ち込むのはlast spurtの関係か?
    • 小さくちぎるとオーバヘッドがあるが、compound procedureみたいにできるといいけど、リクエストをまとめて要求する形式はないようだ。
    • 可変にするとか
  • MyCloud立ち上げ時にすべてのクラウドからテキスト形式のメタデータをとってくる。
    • 特徴的な拡張子のテキストファイルにいろいろ書いてある。
  • クラウドが停止したときにRAIDのように再構成をできたらいいな。
  • RACS
    • SOCC国際会議
    • 似たようなやつ
    • 細かく評価している
    • proxyとして実装してamazon S3プロトル
    • proxyならクライアントは自由になる
    • proxyにロックインされる? 認証とかめんどい。
    • webdavでもいいかな by shudo
  • AES暗号化+単純コピーによる分散じゃなくて、符号化で分散したらいいかな。
    • 閾値機密分散法? 遅かった。
  • EC2からつかう方が本題?
    • 複数クライアントのときにMyCloud方式だと問題になる?
  • 上書きアップロードで不整合はおこらないはず。たぶん。
  • チェックサムはないけどあった方がいいかも。

後半戦: One More Thing: MyCloudFS

[2010-07-25 16:10]

  • 質問タイム:
    • デスクトップがアイコンであふれる人?
    • Windowsだとよごれる?Macの方がきれい?
      • 会場から:つかいなれてない方がよごれるとの意見も。
  • そもそもいまのファイルシステムがおかしい。
    • ディレクトリ構造は人間の記憶に依存しているのでそこが限界になる。
  • ファイル管理をしたくない
    • 参照すべきファイルをおしえてほしい(忘れていたとか)
  • semantic filesystem:すべてのファイルにインデックスをつけろ! → むり
  • wiki:
    • 階層ディレクトリじゃなくて
    • ソーシャルタグ
  • メールの分類とか
  • 自動でインデックスをつけてほしい
    • さりげなく→でないとwindowsのイルカのように消されてしまう。
  • demo: twitterでつぶやくとキーワードを抽出してMyCloud上で全文検索してくれる。
    • 全文検索+それで関係するファイルも提示してくれる。
    • 近いatimeのファイルには関連があると想定。
      • atimeを参照したかったがうまく更新されない問題。
  • どうやったら提示したファイルが適切だったかのフィードバックができるか?
    • 特に「これは間違っている」とか
  • eclipseのpluginで過去に同時に表示したファイルを、強調表示、というのがあった。
    • 論文があってアンケート調査されていた。指標:DOI?
  • 首藤さんの写真管理術
    • 「日付-カテゴリ」のフォルダをつくってぶちこんで人手で管理。picasaになげたり。
  • 首藤さんのデバイスの大きさの分布調査
    • 携帯,PDA,iPad,notePC,desktop
    • デバイス間をつなぐのがクラウドサービス。データの入口の制約がなくなる。
  • 階層構造とはメタデータサーチのある形態のひとつ
  • 全文検索
    • デスクトップサーチ
    • 画像にはよわい
    • ディレクトリ構成が変わると再インデックスにまたされる問題
  • メディアファイルへのタグ付け方法
    • アンカーテキスト(画像の近くに配置されるテキスト)をつかっているが個人の場合はそういうものがない。タイトルくらい。
  • タイムマシンコンピューティング
    • Jun Rekimoto ACM UIST'99 1999
    • 超整理法の影響をうけている。
    • 時系列で管理する。
    • 先行研究:Rooms(デスクトップ;2D),pile(3D),lifestreams(時系列)
    • 空間的管理形態
    • デスクトップのキャプチャをとって時系列に再現。→ Time Scape (モックアップ)
      1. デスクトップまきもどし
      2. 3次元形態 (年表っぽい)
      3. カレンダー形態
      4. 未来にも移動できる。TODOとかアラームっぽくつかえる。
      5. その後の展開をきかないが、、、
  • GoogleMini
  • OSからすればファイルシステムはバイト列のコンテナでしかない。
  • WinFS:RDBをのっけただけ。
  • ファイルアクセス解析法
    • "ファイル検索に向けたアクセスログからのファイル間関連度の導出"
    • 全てのファイルの使用期間を記録
    • 共起情報から関連度を算出
  • 階層ディレクトリ構造だとroot dirにアクセスが集中する。 by shudo
  • システムベンダーはposix semanticsを実装しないと売れない。アプリ屋ならなんでもできる。

[2010-07-25 17:31] end

DVCSとCAP定理

920f9dd5.jpgDVCS(Distributed Version Control)をCAP定理の観点でみたらどうか。

CAP定理とは:

  • 一貫性 (Consistency)
  • 可用性 (Availability)
  • 分割耐性 (Partition Tolerance)

集中リポジトリ方式では:

  • 一貫性 → CVS/Subversionだと楽観的ロックでリポジトリは常に一貫性が保たれている。
  • 可用性 → サーバが止まったりオフラインになると更新系は利用できなくなる。参照系はクライアントがキャッシュを持っていれば可能。
  • 分割耐性 → ネットワークから切れたらおしまい。

DVCSでは:

  • 一貫性 → あきらめて、人間が解決する。
  • 可用性 → リポジトリは常にローカルマシン上にあるので止まることがない。
  • 分割耐性 → リビジョンIDを、順序数からハッシュ値にすることでIDの衝突を避ける。
記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2018-11-15
    • 今日の練習 2018-11-15
    • 今日の練習 2018-11-13
    • 今日の練習 2018-11-11
    • 今日の練習 2018-11-11
    • 今日の練習 2018-11-10
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ