客先常駐について - 急がば回れ、選ぶなら近道
客先常駐は増加傾向に見える。 別に統計資料はないので、どちらかというと体感的なものだけど、ベンダーからユーザーへの常駐は増加している気がする。これはまぁスタイルはいろいろで、完全に委任契約のものから、継続SIを仕事として請負契約の形になっているが作業的には客先にずっといるというスタイルのものをある。ベンダーの人員というよりも、ベンダーの下請け・孫請けが常駐していることが多い。さらに、多くの場合、戦力になっているのは、フロントの一次受けではなくて、下請け・孫請けの部隊だったりする。そんなこともあるので、地方の中小企業の場合は、さすがにフロントのサヤ抜きが、馬鹿馬鹿しいので、直接に契約に切り替えることも多い。 いずれしても、SIという位置づけのものまで含めると、この種の「派遣の一種」のような常駐モードの人員は相当いて、SEから運用・コンサルまでITに関わる分野では、非常に幅広くかつ大きなビジネ
SQLServer 2014 “Hekaton”再考 - 急がば回れ、選ぶなら近道
SQLServer2014「Hekaton」 MSの主要DB。論文がでているので、それをベースに自分の理解を書く。当然実装は公開されていないので、合ってるかどうかは知らない。また実際に製品にテストベンチを走らせたわけではないので、あくまで公表された論文ベースでの理解になる。まぁもう普通に使われているDBで、細かい機能云々についてはいろいろ資料がでているはず。そのあたりを見ればいいと思う。論文が公表されて、だいぶいろいろ手がはいっているとは思うので「アーキテクチャの設計」として読んでる。 ■論文の構成 基本的に三つの構成になっている。全体の枠組み・Txの処理を詳細に記述したもの・およびその厳密な証明。このうち、全体の枠組みは、Tx処理詳細のあとで書かれているので、若干の不整合がある。これはIndex実装の追加の話なので、多分パフォーマンス向上のためにRange Indexを追加したようだ。ト
Cicada：Dependably Fast Multi-Core In-Memory Transactions - 急がば回れ、選ぶなら近道
Cicada: Dependably Fast Multi-Core In-Memory Transactions https://www.cs.cmu.edu/~hl/papers/cicada-sigmod2017.pdf SIGMOD2017で発表されている。現状の分散OLTPのアーキテクチャをうまくまとめて、欠点をうまくカバーアップし、言って見れば次世代MVCCの一つの形を提示している。その上で、現在世界最高のパフォーマンスを叩き出している。現時点で世界最速DB（ただし自称）。 現状の分散OLTPは大きな流れは、SILO/Foedus/MOCC/等のOCC系、すなわち2PLをベースにした実装で理論上はmonoversionでのserializableの実現を行っている方式と、Hekaton/HyPer/Bohm/ERMIAといったMVCC系、すなわちMVTOの派生をベースにしてmu
multi-versionの基礎 - 急がば回れ、選ぶなら近道
multiversionの基礎 自分用のMulti Version Concurrency Controlのまとめ MVCCの基礎理論をまとめておく。今後はここを参照する。 基本的にTX本とCC本から必要な部分をまとめている。 （一回まとめてるけど、Multi-version Conflict Serializability - 急がば回れ、選ぶなら近道 前回はそもそもCSRとの混線を防ぐという意味だったので、今回はもっと基本的なところからさらに。今回はCSRとの関係はガン無視。） 前置き：自分の考えを記録的に 基本的にMulti Version Concurrency Control （以下MVCC）は理論先行だった。これはMVCCのオーバへードがsingle-versionのパフォーマンスを凌駕できなかったことによる。以下の理由によりMVCCが今後は伸張すると考えている。 1.メモリー
「パブリッククラウドvsプライベートクラウドの終わり」の始まり - 急がば回れ、選ぶなら近道
遅めですが明けましておめでとうございます。そんな感じで。 基本的に社内向け。あとは特定のお客さん向け。 自分の意見を詳記しとく。あとこれは日本の話で、海外の状況は知りません。 ■「パブリック」クラウド ここでは、大規模メガクラウドを指す。よって、AWS・Azureあたりを考えている。国内クラウドとは明確に規模・技術力で差がついており、はっきり分けるべきと思っているので、ここではAWS・Azureとしている。多分SalesforceとかIBMのやつも入るとは思う。Googleのクラウドについては技術はぶっちぎりだけど、一般民間人には意図していること天才すぎて理解できる気がしないので範囲外とする。 基本的に「所有より利用を」コンセプトにし、使いやすさと低コストを全面に打ち出し、トレードオフとして共有故の仕組み/運用の「ある種の不透明性」を要求する仕組み。なお、不透明性ってのは、これは提供者の企
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
ビットコインとブロックチェーンと分散合意 - 急がば回れ、選ぶなら近道
先日、分散システムをいろいろやっているメンバーで集まって、話題のブロックチェーンとかビットコインやらの勉強会をやってので、まとめておく。 いろいろ意見はあると思うけど、勉強会では問題意識は大体、共有できたと思う。まずは、キーノートやってもらったS社のMさんに感謝申し上げます。すごくわかりやすかった。やはり分散系をやっている人からの解説は、視点とか問題意識が同じなので参考になる。 以下、自分の個人的見解。合っているかどうかはシラン。 1. 現状の「ブロックチェーンとビットコイン」（以下オリジナルとする）は、そのままでは分散合意とは関係ない。 これはクリアだと思う。端的にいうとビザンチン将軍問題とは「まったく関係ない。」 だから「ブロックチェーンとビットコイン」がビザンチン将軍問題の解決になっているという話は、まずは「まとはずれ」だと思う。現状の「ブロックチェーンとビットコイン」は、分散合意は
Asakusa 0.8 with M3BP - 急がば回れ、選ぶなら近道
Asakusaが新規に高速実行エンジン（M3BP）をサポートした。M3BPはメニーコア特化型のC++で実装されたDAGの実行エンジンになる。ノーチラスとFixstarsの共同開発のOSSで、単ノード・メニーコアでの「処理の高速化」に振っている。いわゆるIn-memoryの実行エンジンで、ノードのCPUコアを使い切ることを目標しており、余計な機能はすべて削った。データがサーバ・メモリーに乗るクラスのバッチ処理であれば、ほぼ物理限界までパフォーマンスをたたき出す。 http://www.asakusafw.com/release/20160412.html 実際のベンチマークは以下のwhite paperにある。 http://www.asakusafw.com/wp/wp-content/uploads/2016/04/M3forBP_WP_JA_2016Apr12.pdf ベンチマーク対象
Storage Class Memory - 急がば回れ、選ぶなら近道
ACMの2016 Jan.の会報の記事に上がっていたので、面白かったのでちょっとまとめておきます。 http://cacm.acm.org/magazines/2016/1/195724-non-volatile-storage/abstract 前提として、SCM（Storage Class Memory）について書いておくと、いわゆる不揮発性メモリー(Non-Volatile memory)で、次世代の主流になるだろうとは言われています。DRAMまでのレイテンシーは出ていないので、DRAMのリプレースにはならないと思われる（のが今の常識）ですが、ストレージとしては最速で、一般にDiskの1000倍（3桁）は速い。が、値段は30倍と言われていますね。 ・ハイライトハイライトは以下 ・The aged-old assumption that I/O is slow and computat
Multi-version Conflict Serializability - 急がば回れ、選ぶなら近道
1.目的 今後の分散DBでは、前提が分散ノードから分散コアに主体が移る。ムーアの法則の限界は、メニーコア化とノードの高密度化を推し進める。分散のノードではリードロックの問題とノード分散の相性の良さでSnapshot Isolation(以下SI）がほぼ前提であったが、RDMA等のハードウェアの技術革新でレイテンシーが改善されるのであれば、SILOのような(表面上は）単ノードのS2PLの改良版も有りになってくる。 そうなってくると理論的な背景も、SIを前提という話ではなくて、通常のConflict Serializability (以下CSR)も頭に置きながら話をおっていかないと理解が厳しい。 SI「だけ」であれば、なんとなくまぁセオリーでr-w依存での循環グラフだよね、ということを前提において議論を追いかけて、r-w依存はあとで復習して調べとけばなんとかやり過ごせる。が、通常のCSRも混線
TX本勉強会終了 - 急がば回れ、選ぶなら近道
先日をもって無事に読了しました。記念に記録しておきます。 読んだ本はこれ Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery http://www.amazon.co.jp/Transactional-Information-Systems-Algorithms-Concurrency/dp/1558605088/ref=sr_1_1?ie=UTF8&qid=1370746124&sr=8-1&keywords=transactional+information+systems 始まったのが、2011年の秋からだったので、ほぼ一年半かかりました。スタート時点は10名ほどいたメンバーも徐々にいなくなり、最後は不動の4人のレギュラー
全IT関係者が知っておくべき「1-copy-snapshot isolation」 - 急がば回れ、選ぶなら近道
snapshot isolationを分散環境に適用する場合の「基本」の内容のまとめになります。（基本自分用のメモなので、間違っていたらすみません） まずワーディングの整理 ・snapshot isolation TXの分離レベルとしてのsnapshot isolation（以下SI）は、現在のRDBMSのTX管理では、ほぼ実装的にはデファクトと見ていいと思います。ただしANSIの規定のISOLATION_LEVELには定義がないので、どのあたりに位置づけるのかは、DB実装のそれぞれの取り扱いにより異なります。とはいえ、どのDBでもほぼSERIALIZABLEに近い位置づけにしているところが多いですね、というか、SI（特にSerializable SI）ぐらいでないとserializableに現実的には近づけないというのが実態かと思います。（勿論理論上はS2PLで実装は可能ですが、まぁパフ
Making Snapshot Isolation Serializable 再考 - 急がば回れ、選ぶなら近道
Making Snapshot Isolation Serializable 再考 ■2013年的な位置付け まずちょうど年度の開始なので、今年は自分的にはRDBMS関連の位置付けとか整理しておきます。去年の後半あたりからの匂いですが、NoSQL的な発展と合わせて、本格的なDB回帰が始まっている感じです。NoSQL系のほぼ致命的な弱点の一つがtransaction処理であることは指摘も多いところです。要するにデータが書き込めても不整合が発生しますね、ということになってしまいます。これではなかなか使えない、というのが現状でしょう。 なので、RDBMの最良のノウハウであるtransaction処理とNoSQL的な分散処理をちゃんと整合性とれるようにしましょう、という自然な流れは従前よりもより強い要請が働くでしょう。(できるかどうかは別ですが。) それで、そろそろなんかその手のものがRDBMSサ
A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道
元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。（尚、当然ですが、内容が正確かどうかは
Mapreduce2.0 - 急がば回れ、選ぶなら近道
次世代Hadoopの開発が進んでいる。現状の推移では、少なくとも分散クラウドでの「OSSインフラ」としてはHadoopが最有力候補であることは間違いない。クラウド上での分散処理基盤での技術競争ではGoogleやAmazonが相当抜きんでいる現在、それに対抗しうる可能性があるOSSはHadoopの潮流の延長線上にしか考えられない。その形としてHadoop-MapReduce2.0があるように見える。現在の状態で自分なりの次世代Hadoopの理解をまとめておく。基本的に全部は見切れていないので、そのあたりはあしからず。基本的に次世代Hadoopの仕組みは大きく二つの要素からなる 現在のところの柱はHDFSとMapreduce2.0の二つだ。 まずMapReduce。これは従来の「MapReduce」というものからはほど遠い。むしろ「任意」の分散処理実行フレームワークにたいして、適切なリソースを
HbaseとHadoopMR - 急がば回れ、選ぶなら近道
Hbase勉強会のまとめの延長として 今後の考え方をまとめておきます。 まずは前提として <一般論> Hbaseにかぎらず、NoSQL系一般に言えることではあるが Usecaseを意識して利用する事が必要だ、ということだと思う。 最近の傾向としては、Googleでも顕著だけど、 一定の用途をターゲットにして 特定のミドルを開発するという方法が結構多い。 Hbaseもその流れはあるので、 そのあたりは意識する必要はあるかもしれない。 Hbaseついては、注目するとすればFacebookになるかな。 http://www.cloudera.com/resource/hw10_hbase_in_production_at_facebook いずれにしても、割とうまくいっているUsecaseの情報の有用性は 他の技術よりも高いと思う。 基本的に単純に分散KVSを使いたいならHbaseにこだわる必要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
