サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
okachimachiorz.hatenablog.com
前提 前提ですが。 transaction=Consistency/Isolationを担保する仕組みの話とする。 一般にtransactionが持つべき属性はACIDと言われる。C/Iに比べて、A/Dが“わかりやすい”のでAtomic/Durableの属性の方が人口に膾炙しているが、現在のtransactionではA/Dネタはあまり話題にならない。A/Dネタはローカルだけで見るのであれば普通にfile system /storageの話になる。元来Atomic/Durableはtransactionのコンテクストでは専らlogging / recoveryの話だった。そして、これは非同期のepoch-basedになるとそれ自体の取り扱い優先度が下がる。現代的なtransactionでは、「現時点ではread committedが保証されているFS/storageでA/Dの問題は(ある程度
[昨年に引き続き] Tsurugiについて 詳細は以下 okachimachiorz.hatenablog.com ・これは前回の繰り言 要するにRDBを作りましょう、という話。いろいろインメモリーでメニーコアとか、ECC(Epoch-based Concurrency Control)とか、いろいろ特長はあるけど、目標としている機能の一つに「writeバッチ処理に強い」というものがある。 ■バッチ処理の困難さ このあたりも繰り言にもなる。基本的にまず、そもそも論としてwrite処理は既存RDBとは相性が良くない。これは単純に整合性を持たせる(serializable)ためのコストが大きいことによる。そもそも相性の良くないwriteをさらに大量に、かつ一度に書き込むバッチはさらに重ねて相性が良くない。 以下、今年一年の進捗的な話 ■Tsurugiの現状として 現在、Tsurugiでは本格的
OceanVista http://www.vldb.org/pvldb/vol12/p1471-fan.pdf 基本的アーキテクチャは、DC間クラスターをインフラにおいて、高遅延・耐障害性を前提にした分散transactionの仕組みになっている。 どう見てもAlibabaのOceanBaseそのものではない。が、同じAlibabaグループでかつ、Oceanの名前をつけているので、関係はなくはないと思う。少なくとも同じグループまたは情報交換はしているのではないか。技術的な方向性を模索するプロトタイプに見える。 バックグラウンド的な与太話をすると、Alibabaは、というか中国的には、ITでの米国からの依存脱却(ポーズだけなのか、実際なのかは置いておいて)を目標として掲げているのは周知の通り。んで具体的な話としては、Alibaba的には脱Oracleが一つの目標になっている。この目線で見た
Project Tsurugi(劔)とAsakusaについて ついでにAsakusa advent calendarの分も ■Tsurugiの特にNEDOプロ部分について 日経の記事はこちら https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/03044/ 本紙はこちらからかな? https://www.nikkei.com/article/DGXMZO51692890R01C19A1000000/ ・NEDOのサイト https://www.nedo.go.jp/content/100891996.pdf ・スライドはここ drive.google.com ・togetterはここ https://togetter.com/li/1430683 本来であれば、あまり外向きに書く話ではないのですが、仮にも公金が入っていて、日経の方にも「
・ご案内 MVCC=Multi Version Concurrency Controlは、DBのTx技術の中でも比較的上位魔法に属し、あまたのTx系統の魔術を学ぼうとする魔術師の挑戦を退けてきた。しかしながら時代はメニー・コア/大容量メモリーの時代に入り、MVCC系統の呪文を唱えるための触媒のコストが下がりつつある。 その簡単な解説を試みる。 -Tx系呪文について Tx系のspellはDB界魔法の中では、いわゆる最高位の防御魔法に属する。言ってみれば多数の攻撃(これは物理攻撃はもちろん高度のSpell攻撃も含む)を捌き切ることがその特徴である。一般に最高位防御魔法は絶対防御系のものが多く、受ける攻撃をすべて無効化することが可能である代わりに術者側にも大きなペナルティを課すことが多い。この絶対防御系と異なりTx系は呪文発動中も術者も(余裕があれば)行動することが可能であり、そのアドバンテージ
どちらかと言うと関係者向け。 とある事情でロボットとかCVとか、いろいろAI系(の一歩手前)に関わることになっている。業務系IT屋と今後のマーケットの視点で書いておく。最初に断っておくが自分はロボットに関しては素人なのよ。なので、だからむしろこれから書くことは間違っている可能性もある。単純に「外側から見た考え方の一つ」だと思ってもらっていい。そのつもりで書いておく。 前提はNCやFAと言った工作機械の延長のものではなく、あくまで人手の代替を行える水準のものを想定する。ま、極論いうと「劣化版「鉄腕アトム」」だ。 現状全般 一般に言われていることであるが、日本は世界歴史上ないかつてないレベルの高齢化になっており、少子化対策の失敗からの労働力不足に思いっきり正面激突して半死半生である。こういう大惨事のさなかに、この労働力不足を真面目にロボットで補うという、まさかのSFチックなこれまた世界史上例の
本来、僕がどうこう書くものではないし、しかるべき人がしかるべき何かのコメントを書くべきだと思う。とはいえ、時代的なものも含めて、後につながる人が「発掘」できるようにはしておきたい。追悼文を書く。これはとある事情で、たまたまこういうタイミングだったいうこともあるので書く。 アンデルセンの高木誠一さんが亡くなられた。昨年のことだ。ちょうど一年たつ。 アンデルセンというのは、インストアベーカリーの最大手であり、FC(リトルマーメード)も展開している。一般の人もお世話になっている人もいると思うが、要するにパン屋さんだ。高木誠一さんはその創業者に連なる方で、亡くなられるまでアンデルセンの方向性に関する最終的な責任者でおられた。日本のパン業界(というかベーカリー)においては、ものすごくインパクトを与えた人であることは間違いない。 アンデルセンさん(以下敬称とか適当)は、僕個人の関わりで言えば、前々職・
Asakusa Advend Calnderの最終として 現状 2018/12月の現在の自分のタスクは、DBのMVCCでのTX制御の理論・アルゴリズムの設計になっている。要するにDBを作りましょうということで、そのコア部分をどうにかしなさい、ということになっている。それで、その前提として、今回のDB-Prjでの最大の眼目の一つを「Writeの強いRDB(OLTP)」ということにしている。 現在のRDBはそもそも原理的かつそのツールとしての特性上WriteというよりもReadにパフォーマンスが振られている。結果として、一般に、書き込みヘビーの業務系大型バッチ処理がRDBでまぁほぼ全敗になる。これは常識のまま、そろそろ30年くらいになるし、この辺が改善する見込みはほぼない。ということで、大規模(といってもさすがに最近のトレンドの規模感からはそう簡単には大規模とは言いがたいが)で複雑な一貫性を担
対象読者: 某Pjrに関わっている人全員。あとはSAPのHANAとかのHTAP系を使っている人。あとはDB系の人とかそっち系の人。 内容はRead only transaction anomalyがHTAPのなかでかなりの厄ネタになるという指摘と、その解決素案の提示になっている。前提知識はMVCC(MVTO、SSN、SSIとかその辺)。 ■Read only transaction anomaly MVが前提で発生するtransactionのanomalyのこと。整合的なsnapshotをとっていて、かつリードオンリーであるにもかかわらず、どのようなserialization orderをとっても論理的に起こり得ない状態を読み出してしまうskewを指す。 わかりやすい例をSSIの論文から持ってくる。 https://www.cse.iitb.ac.in/infolab/Data/Cours
SSN Serial Safty Net 原論文は以下 https://pdfs.semanticscholar.org/ecf9/821e0c4f1f28fb7eb42c5eaa8a92cf16ade9.pdf Txのserializabilityを判断する、いわゆるcertifierになる。実際はDBのTx処理のvalidatorの実装として組み込まれることが通常だと思う。ERMIA( http://www.cs.sfu.ca/~tzwang/ermia.pdf )ではそうなっている。想定としては下位レイヤーにSI(Snapshot Isolation)またはRC(Read Committed)な実装を想定している。 原理はTxのdependencyをトラックして、コミット時点でvalidationを行い、dependency cycleが発生する可能性が高いかどうか判断する。リードが
Asakusa 0.10.0について あけましておめでとうございます。今年もよろしくお願いします。 のっけからアレですが、これはAsakuas Advent Calendar 2017のエントリーなわけ(個人的には12/31までがクリスマスとかそんな感じの年末催事なのでそのつもり:2017/12/30に追記)(って書いてたら、年が明けたけど、個人的にはあと3ヶ月は2017年の感じなので:2018/1/4にさらに追記) Asakusaで、先日0.10.0をリリースしている。ある程度刻んでリリースして行く、というのがAsakusaのポリシーではあるが、今回のリリースはちょっとした節目にはなっている。 http://www.asakusafw.com/ ◆一つの区切りとして とうとうというか、今更というか、ようやくというか。MapReduceのサポートについて一つの道筋をつけた。Hadoop界隈
客先常駐は増加傾向に見える。 別に統計資料はないので、どちらかというと体感的なものだけど、ベンダーからユーザーへの常駐は増加している気がする。これはまぁスタイルはいろいろで、完全に委任契約のものから、継続SIを仕事として請負契約の形になっているが作業的には客先にずっといるというスタイルのものをある。ベンダーの人員というよりも、ベンダーの下請け・孫請けが常駐していることが多い。さらに、多くの場合、戦力になっているのは、フロントの一次受けではなくて、下請け・孫請けの部隊だったりする。そんなこともあるので、地方の中小企業の場合は、さすがにフロントのサヤ抜きが、馬鹿馬鹿しいので、直接に契約に切り替えることも多い。 いずれしても、SIという位置づけのものまで含めると、この種の「派遣の一種」のような常駐モードの人員は相当いて、SEから運用・コンサルまでITに関わる分野では、非常に幅広くかつ大きなビジネ
SQLServer2014「Hekaton」 MSの主要DB。論文がでているので、それをベースに自分の理解を書く。当然実装は公開されていないので、合ってるかどうかは知らない。また実際に製品にテストベンチを走らせたわけではないので、あくまで公表された論文ベースでの理解になる。まぁもう普通に使われているDBで、細かい機能云々についてはいろいろ資料がでているはず。そのあたりを見ればいいと思う。論文が公表されて、だいぶいろいろ手がはいっているとは思うので「アーキテクチャの設計」として読んでる。 ■論文の構成 基本的に三つの構成になっている。全体の枠組み・Txの処理を詳細に記述したもの・およびその厳密な証明。このうち、全体の枠組みは、Tx処理詳細のあとで書かれているので、若干の不整合がある。これはIndex実装の追加の話なので、多分パフォーマンス向上のためにRange Indexを追加したようだ。ト
記事とか詳細とかはこっち http://www.atmarkit.co.jp/ait/articles/1708/28/news097.html https://cloud.vmware.com/vmc-aws http://www.publickey1.jp/blog/17/vmwarevcloud_air.html まぁ概ねこんな感じ 単純に見れば、AWS上でVMWareが使えるので、VMで動いているシステムがそのままAWSで使えるようになりました。便利ですね。はい、おしまいの話ではある。が、それは二重の意味で「表層的」な見方だ。そもそもVMWareがクラウドから撤退し、AWSの軍門に降ったというエポックメイキングなものとして見るべきだと思う。 ・ハード調達の争いの決着 結局のところ、DCを含めたハードウェアの調達という点で、競争に決着がつきつつあるということかと。VMWareの規模を
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
最近はさすがに落ち着いてきた。もちろん一部では「人工」の「知能」という言い方に拘泥している一群もあるが、基本的に所謂「人工知能」は、SF的な人工知能ではなく、機械学習やそれに関連した統計的手法を利用したなんらかの仕組みである、ということのコンセンサスはとれつつある。現在言われている「人工知能」が「知能をもつ」とおもっているまともなIT屋はひとりもいない。(言いたいのは対偶) そもそも、知能の定義については、諸説いろいろあって、普通のIT屋だと一般にチューリングテストみたいなの持ち出すことが多い。冷静にみれば、あんなものが定義になるわけはなくて、個人的にはアレは天才チューリングをもってしても知能をformalizeできなかったギブアップ宣言とみている。ということで、そもそも何が知能か?という定義は個人的には難しいと思っている。 普通になんらかのデータのインプットがあって、プログラムがなんらか
MVCC系の実装プロトコルの代表例。 そのほかにMV2PL(実際は2V2PLが多い)とMVSGTがある。なおMVTOにも様々なバリエーションがある。理論自体は1980年後半から存在している。version無制限というのは、従来のH/Wでは非現実的だったが、近年のノードあたりのメモリーの大容量化やNVRAMの登場によってそれほどデタラメな前提ではなくなりつつある。適切にGCをかけることやversion traverseを工夫することでパフォーマンスを維持することができる。その結果最近のMVCC系のプロトコル実装はMVTOが多くなっているように見受けられる。というよりもほぼMVCC=MVTO一色の様相だ。実際、ベンチマークも数字は出ている。 (修正:MVCCの中にOCCではあるがMulti-versionを利用する形式のものをあり(MVOCC)、それもMVCCとすれば、MVCCはMVOCC+M
もう5年か、まだ5年というべきかちょっと判断に迷う。大抵の業務系のシステムがクラウドを始めるのは現実的には今年来年以降になるので、今の自分達の状況は多分、今後の業務系システムをクラウド移行したユーザの近未来になると思う。ので、予想的にまとめておく。本格的にクラウドを利用した業務アプリケーションの5年がどうなるかの一つの指針になるかと。 以降は別に統計データでもなんでもなく5年間を眺めてみて自分の印象。 ・障害:大規模は5年で2-3回程度。一度は業務に影響が出て客先にお詫びに行った。AWSだったけど、サポートからは「もう回復してるのでチケットクローズね」みたいな話だったと記憶している。その後は大体四半期に一回程度のN/W障害。障害は普通に起きているし、オンプレと比べてどうか、という比較では細かい障害件数は減った気はしていない。ただし、「ドカンと来るでかい障害」は確実に減った。 ・データ増加対
multiversionの基礎 自分用のMulti Version Concurrency Controlのまとめ MVCCの基礎理論をまとめておく。今後はここを参照する。 基本的にTX本とCC本から必要な部分をまとめている。 (一回まとめてるけど、Multi-version Conflict Serializability - 急がば回れ、選ぶなら近道 前回はそもそもCSRとの混線を防ぐという意味だったので、今回はもっと基本的なところからさらに。今回はCSRとの関係はガン無視。) 前置き:自分の考えを記録的に 基本的にMulti Version Concurrency Control (以下MVCC)は理論先行だった。これはMVCCのオーバへードがsingle-versionのパフォーマンスを凌駕できなかったことによる。以下の理由によりMVCCが今後は伸張すると考えている。 1.メモリー
遅めですが明けましておめでとうございます。そんな感じで。 基本的に社内向け。あとは特定のお客さん向け。 自分の意見を詳記しとく。あとこれは日本の話で、海外の状況は知りません。 ■「パブリック」クラウド ここでは、大規模メガクラウドを指す。よって、AWS・Azureあたりを考えている。国内クラウドとは明確に規模・技術力で差がついており、はっきり分けるべきと思っているので、ここではAWS・Azureとしている。多分SalesforceとかIBMのやつも入るとは思う。Googleのクラウドについては技術はぶっちぎりだけど、一般民間人には意図していること天才すぎて理解できる気がしないので範囲外とする。 基本的に「所有より利用を」コンセプトにし、使いやすさと低コストを全面に打ち出し、トレードオフとして共有故の仕組み/運用の「ある種の不透明性」を要求する仕組み。なお、不透明性ってのは、これは提供者の企
アドベントカレンダーのエントリーなんで、軽めに。 AsakusaはもともとHadoopでバッチ処理を開発・実行するためのフレームワークだ。これは別に今でもかわっていない。ただし、実行基盤は増えているし、推奨基盤も変わりつつある。現在のところの推奨基盤はバッチあたりで利用するデータ処理の規模が単ノードで完了するような場合はM3BPで、そうでない場合すなわち複数ノードにまたがるような場合は、Sparkを推奨している。これは僕らが経験した「すべてのワークロード」でSpark/M3BPがHadoopの特にMapreduceでの実行結果を凌駕しているためだ。AsakusaDSLはどのプラットフォームでも完全互換なので、コンパイルし直すだけでそのまま動く。MapreduceからSparkの移行は非常に簡単だ。ということで可能ならSpark/M3BPの方が速いので、そっち方がいいのではないでしょうか、と
まぁなんか適当に思うことを。 ■ハードの限界の露呈 ムーアの法則の限界はITのあり方を根本から変えると思う。この四半世紀、ITの現場レベルでは「困ったらハード増強」が一つの基本政策であったことは間違いない。ハードウェアの進歩は結果として、IT全体のパフォーマンスを上げ、結果として社会における有用性を増した。その一方でハードウェアの高進はソフトウェアの進化を止めていた側面は確かにある。 ソフトウェアのレイヤー、とくにミドルレイヤー〜アプリケーションのレイヤーでは、通信にしろ、分散処理にしろ、DBにしろ、OSにしろ、「業界全体としてトコトンできるレベルまでやったのか?」という意味では、実際はやっていないと思う。もちろん、各セグメントではそれなりに追求はしたけど、ドカドカ、金突っ込んで全部ひっくり返すというまでには至っていない。これはIT全体に言えることだけど、ソフトウェアにコストをかけるよりも
大分たってしまったけど、ようやく時間が空いたので、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が新規に高速実行エンジン(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 ベンチマーク対象
大規模会社、特に社会インフラ系の会社で売上も兆に届くところでのITのあり方は、中小規模の会社とは全く違います。システム構築、とくにSI的な観点からは、実際のプロジェクト単位で見たときに大規模システムと中小規模システムを便宜的に一緒にして考察することが多いのですが、俯瞰したときのあり方は、まったくの別ものです。 大規模な会社では情報システムは、大きな組織のバックエンドの一部であると同時に、企業を動かす歯車として欠くことできない存在になっています。「ITがない」という選択肢は企業活動としてありえません。システムのあり方が大企業と中小企業では異なるため、中小企業でITの必要性という点と、大企業でのITの必要性では意味が大きく違います。明確に区別する必要があります。 ■あり方 大規模企業の内部において、情報システムはその企業が存続するための重要な機能を担っており、それなしでは企業は成立しません。大
もともとは2016年の年の初めに書こうかと思っていたことですが、時間も経ってしまっていたところ、アリエルの井上さんとの対談 IT屋はバズワードを使ってはいけない……のか? (1/5):EnterpriseZine(エンタープライズジン) も あって、ちょうどいいので記録的に思うところを書いておきます。 ・前提 ここではITと言う漠然とした言い方になっていますが、日本で最もマーケットの大きい、いわゆる業務システムを対象にしています。いわゆるSIの対象になるところです。と言っても一概に言えないので、売上2000億円程度の大規模企業の、下の方から、中小企業までの話にしています。売上が兆円単位の規模の社会インフラ系のシステムは、その2 ITは必要悪か?その2 - 急がば回れ、選ぶなら近道 で考えます。業務システムなのでコンシューマーものは考えてません。 ・ITは必要悪という認識 基本的にユーザ企
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
1.目的 今後の分散DBでは、前提が分散ノードから分散コアに主体が移る。ムーアの法則の限界は、メニーコア化とノードの高密度化を推し進める。分散のノードではリードロックの問題とノード分散の相性の良さでSnapshot Isolation(以下SI)がほぼ前提であったが、RDMA等のハードウェアの技術革新でレイテンシーが改善されるのであれば、SILOのような(表面上は)単ノードのS2PLの改良版も有りになってくる。 そうなってくると理論的な背景も、SIを前提という話ではなくて、通常のConflict Serializability (以下CSR)も頭に置きながら話をおっていかないと理解が厳しい。 SI「だけ」であれば、なんとなくまぁセオリーでr-w依存での循環グラフだよね、ということを前提において議論を追いかけて、r-w依存はあとで復習して調べとけばなんとかやり過ごせる。が、通常のCSRも混線
次のページ
このページを最初にブックマークしてみませんか?
『急がば回れ、選ぶなら近道』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く