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.メモリー
SIで得るものはあるのか？ - 急がば回れ、選ぶなら近道
「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？ 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
Hadoopは汎用機の夢を見るか？ - 急がば回れ、選ぶなら近道
オープン系の歴史は、基本的に汎用機との戦いでした。個人的にも自分の戦いも、わりとまじめに汎用機との戦いでした。Linux? おもちゃですね。Java? 飲めるの？Object指向? 品質高いの? ・・・まぁこんな感じでしたね。確かにLinuxはもはや標準になりました。Javaでの開発は普通になりました。Object指向以外の開発はまぁ普通にないですね。・・・しかし、残念ながら基幹バッチは未だに汎用機です。汎用機は未だに現役であり、基幹処理の根っこは、いまだ汎用機で動いています。信頼性は突出しているし、パフォーマンスもバッチ処理に関しては依然として最強だと言えるでしょう。新人COBOLな人のバッチが、ハイパーなOracle使いのSQLバッチを軽く凌駕する事は、まだ普通にあります。・・・なぜか？ 多重度が違いすぎますね。 汎用機はハードウェアからOSレベルまですべて、多重度が上がる事を前提に処
AWSと国内DCサービス - 急がば回れ、選ぶなら近道
自分的な話題なので書いておきたい。 まず立場的はっきりさせて置く。AWSを基本的にはエンタープライズ・ユースで考えています。もっと直裁にいえば、Asakusaの実行基盤として、すなわちEnterpise Hadoopの実行基盤として見ています。クラウドの利用は単社ではできないことをできるのが特長であり、それは現時点では分散処理です。多数のノードを利用する分散処理は、単社で持つにはコスト的にペイしません。ので、一種のハードの共同利用としてクラウドを利用すべきです。単純にレンタル・サーバーの延長上で見るのであれば、クラウドのメリットはないでしょう。分散処理を一定の計算資源を利用して行うことがクラウドでできるかどうかがポイントと考えています。AWSは十二分にこの目的には合致しています。特にパブリックではないVPCの存在は非常に大きい。 （分散処理としてHadoopMapReduceが最適か？とい
「我々40代は何をすべきか」 - 急がば回れ、選ぶなら近道
今日、株主総会で会社の役員を正式に辞めた。 移行にカウントダウンだ。 キリも良いので、＋あとちょっと酔っ払っているので書く。 これは会社を作る前から考えていたことでもあるけど ここ1-2年で痛感していることでもある。 「我々40代は何をすべきか」 まず、世代的なお話から。 現状を見よう。 正直に言って、今の20代のエンジニアの人達のレベルは高い。 勿論、そうでない人もいるけど、 特にトップノッチの人達の水準は高い。 それに比較して40代以上は残念ながら、相対的に低い。 これは一重に教育の水準が上がったということもあると思う。 コンピューターサイエンスや情報工学のコースも 充実してきていると思うし、何より勉強することが普通である、 というが20代の世代的な常識になっていると思う。 要はスタート地点が我々の時よりも前になっている、 ということだと思う。素晴らしいことだ。 さて、我々40代はどう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
