タグ

ブックマーク / okachimachiorz.hatenablog.com (5)

  • SILO再考〜次世代DBのアーキテクチャとして - 急がば回れ、選ぶなら近道

    大分たってしまったけど、ようやく時間が空いたので、db tech showcase Tokyo 2016 http://enterprisezine.jp/dbonline/detail/8466 で話した内容を記録的に書いておく。あとはSILOの解説を特に自分用に論文の4章を中心に整理しておく。あとはついでに自分の思うところも記す。 ・SILO 元論文はこちら、執筆陣はMITのLiskov一派とEddie Kohler 現在のDB研究の第一線のメンバー。 http://people.csail.mit.edu/stephentu/papers/silo.pdf SILO以降、大きくDBベースのアーキテクチャの考え方は変わりました。ほとんど全ての分散系OLTPはSILOを程度の大小はあるとはいえ、意識していると言っても過言ではないでしょう。前世代ではほぼ「空想か?」ぐらいの扱いだった分散t

    SILO再考〜次世代DBのアーキテクチャとして - 急がば回れ、選ぶなら近道
  • ビットコインとブロックチェーンと分散合意 - 急がば回れ、選ぶなら近道

    先日、分散システムをいろいろやっているメンバーで集まって、話題のブロックチェーンとかビットコインやらの勉強会をやってので、まとめておく。 いろいろ意見はあると思うけど、勉強会では問題意識は大体、共有できたと思う。まずは、キーノートやってもらったS社のMさんに感謝申し上げます。すごくわかりやすかった。やはり分散系をやっている人からの解説は、視点とか問題意識が同じなので参考になる。 以下、自分の個人的見解。合っているかどうかはシラン。 1. 現状の「ブロックチェーンとビットコイン」(以下オリジナルとする)は、そのままでは分散合意とは関係ない。 これはクリアだと思う。端的にいうとビザンチン将軍問題とは「まったく関係ない。」 だから「ブロックチェーンとビットコイン」がビザンチン将軍問題の解決になっているという話は、まずは「まとはずれ」だと思う。現状の「ブロックチェーンとビットコイン」は、分散合意は

    ビットコインとブロックチェーンと分散合意 - 急がば回れ、選ぶなら近道
  • 設計と実装の狭間で - 急がば回れ、選ぶなら近道

    ・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて(懐古趣味の老人を除いた)皆さんが毛嫌いするCOBOL+汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず

    設計と実装の狭間で - 急がば回れ、選ぶなら近道
  • 業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道

    某DevLoveというところで話をしろ、ということでありましたので、いろいろ話をして来ました。 http://devlove.doorkeeper.jp/events/1733 まとめはこちら http://togetter.com/li/387189 あと、しんやさんの詳細なブログがこちら http://d.hatena.ne.jp/absj31/20121009/1349795347 スライドはこちら http://www.slideshare.net/okachimachi/devlove1 以下、ちょっと自分なりにまとめを。 ■自分なりにどう話したか 自分の仕事的にはHadoopとAsakusaでの課題解決が現在の業です。ただ、Asakusaの位置づけとして、SIのための道具立てという側面が強く、また結果として会社も直接・間接にSIにはかかわっているので、割と現状の問題も意識して

    業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道
    komlow
    komlow 2012/10/14
  • MapReduceは今後どうなるのか? - 急がば回れ、選ぶなら近道

    2012年の現在、割と悩んでいるのでメモっておく。 年度末ぐらいに再調査の予定。・・なので暫定ですよ。 まず前提として、現行のHadoopの実行フレームワークであるMapReduceは、実行効率は決して良くはないです。この辺が割と辛い。 とはいえ、大規模並列処理を一般的に行うという観点での品質や取り回しを考えた場合、”結果として”非常にバランスがとれており、普及している。その上で、このMapReduceですが、今後の見通しについては、潮流は今のところ二つに割れているよう見える。ので、その辺のメモ。 ■YARN 一つの方向性は、現在のHadoop2.0系で実装されているMapReduce2.0、というか、MapReduceとは別の実行基盤を利用するという方向ですね。すなわちBSPや、MPIを利用する。要は、今までの並列処理の成果をそのまま利用しましょう、という流れに近い。 MapReduce

    MapReduceは今後どうなるのか? - 急がば回れ、選ぶなら近道
  • 1