2018-10-08

IEEE754について。モダンなコンピュータはどのように少数を扱っているのか

IEEE754とは

小数の計算性能と移植性改善のために制定された。おそらく現代のほとんどのコンピュータや言語処理系が採用している少数を扱うときの規格。

値の表現方法について

その表現は符号部(sign)、指数部(exponent)、仮数部(fraction)に分けられる

f:id:yuyubu:20181008234719p:plain

value	start	end	length
sign	31	31	1
exponent	23	30	8
fraction	0	22	23

画像の出典:https://en.wikipedia.org/wiki/IEEE_754-1985

それぞれを組み合わせて以下のように少数を表現している

(-1)^sign * (1 + fraction) * 2^exponent-127

sign bitを符号の有無に利用している点はシンプルだが、仮数部および指数部は 1を足したり127を引いたりしていてややこしく、初見では理解しがたいため解説を後述する

仮数部はなぜ1を足しているのか。

これは科学的表記法を２進数に適応した場合を考えるとわかりやすい。

7.5025 + 10² = 750.25

これが科学的表記法。凡例は

m * 10ⁿ ただし 0 <= m < 1

これを2進数に適応すると

1.01110111001 * 2⁹ = 1011101110.01

となる。

２進で表現した小数は表現する数値が0以外の場合、科学的表記法に直すと仮数部の左端は必ず1になる。以下に適当な例をあげる

10進数	2進数	科学的表記法
0.75	0.11	1.1 * 2^ -2
12.5	1100.1	1.1001 * 2^ -3
33.25	100001.01	1.0000101 * 2^ -5

IEEE754ではこちらを省略するようになっている

IEEE754では，正規化された２進数の先頭の１を仮数フィールドの中で直接持たないようにした．したがって，仮数の実際の長さは，単精度では24ビットであり，倍精度では53ビット（1＋52）である．正確を期す場合には，頭に1を付けた24まビットの数値を指して“significand”という用語を使用し，23ビットの数値を指して“fraction”という用語を使用する．０には前に１が付かないので，ハードウエアが１を付加しないようにするために，特定の値が予約されている．

コンピュータの構成と設計 3.5章浮動小数点演算より抜粋(補足:倍精度小数点に関する記述を省いてある)

※予約されている特定の値は単精度浮動小数点の場合はオール0である

浮動小数点数の表現で省略した1を+1して戻すことで実際の値としている。

指数部はなぜ127を引いているのか

これはゲタばき表現、と呼ばれるものであり数値比較を単純にするために

00000000の状態を最小値に(2^ -127)にしたい
11111111の状態を最大値に(2^ 128)にしたい

という目標がある。ので8進数で0~255の値を計算した後、そこから127を引いてcの値に変換する。この操作をゲタばき(バイアス)という。

最も小さな負の指数を00...00と表し，最も大きな正の指数を11...11と表すような，表記法を用いることが望ましい．それをゲタばき表現（biasedrepresentation）と呼ぶ．ゲタばき表現をとる際に，実際の値を得るために，通常の符号なしの表現から引く数値をゲタ（bias）という．

コンピュータの構成と設計 3.5章浮動小数点演算より抜粋

まとめ

最上位ビット(31ビット目)は0で整数、1で負数の符号を表す
仮数部では科学的表記法の2進数表現と同じ考え方だが、最上位ビットになる「1」を省略する
指数部ではゲタばき表現を使って-127~128を表現する

コンピュータの構成と設計第5版上・下電子合本版

作者: デイビッド・A・パターソン
出版社/メーカー: 日経BP社
発売日: 2016/10/26
メディア: Kindle版
この商品を含むブログ (6件) を見る

2018-10-04

プログラマのためのSQL 読書会(28)に参加

勉強会 SQL

今回の勉強会では、標準SQLかどうかを判断できる無料の資料の存在を教えてもらったのがデカかったです。

プログラマのためのSQL 第4版

作者: ジョー・セルコ,Joe Celko,ミック
出版社/メーカー: 翔泳社
発売日: 2013/05/24
メディア: 大型本
この商品を含むブログ (16件) を見る

「30. 6 ベンダー拡張」から「31.6累積統計」まで読みました。
進捗72% →74%

30. 6 ベンダー拡張

この節でベンダー拡張のWindow関数として紹介されている以下の関数は、現在では全て標準SQLに入っているためベンダー拡張では無くなっている。

LEAD
LAG
FIRST_VALUE
LAST_VALUE

この節で書かれているベンダ間の差分は無くなっています。これはつまりどういうことかというと、Window関数に関して、一般的に普及している主要RDBMSはかなり高い水準でSQL標準に準拠しているということです。

そういえばMySQL8にWindow関数が対応したことが大きなニュースになっていましたね。時代がWindow関数に追いつきましたね。私も障害調査の時にWindow関数をかなりカジュアルに書きますが、まだまだ普及しているとは言い難いので、積極的に使っていきましょう。

標準SQLかどうかはどうやって見分けるか?

JISになったものは公開されているのでそちらをみる
- http://kikakurui.com/x3/X3005-2-2015-01.html
  - 上記リンクをmedian(Oracleの独自拡張)で調査したが該当するものがなかった
  - lead,lag,first_value,last_valueは発見できた
昔の99とかは本が出たのでそちらを参考

C.J.Dateの有名なサンプルデータについて

サンプルとして、デイトの有名な部品テーブルを利用しよう(Date,1983,1995a)。

Parts

part_nbr	part_name	part_color	part_wgt	city_name
p1	Nut	Red	12	London
p2	Bolt	Green	17	paris
p3	Cam	Blue	12	paris
p4	Screw	Red	14	London
p5	Cam	Blue	12	paris
p6	Cog	Red	19	London

とあるが、有名なのか?と話題を出したところ、誰も特に知らなかった。まだ本書の参考文献は量が多いことに加えて、巻末に纏めて書かれているため参照しにくい。帰宅後調査してみたところ

Dateに関して1983年と1995年の著作は以下のものがあるらしい

Relational Database Writings 1991-1994 [FACSIMILE], 1995, Addison Wesley Longman, ISBN 978-0201824599
Database : a primer, Addison Wesley, 1983, ISBN 978-0201113587

おそらくこの2冊からの引用ということだろう。

Relational Database Writings 1991-1994

作者: Date
出版社/メーカー: Addison Wesley
発売日: 1995/01/16
メディア: ハードカバー
この商品を含むブログを見る

Database: A Primer

作者: C. J. Date
出版社/メーカー: Addison-Wesley
発売日: 1983/11/01
メディア: ペーパーバック
この商品を含むブログを見る

余談だがカラム名でググってみたところ、

この本
セルコの投稿
この本のmedianの節を参考にしたと思われる発表スライド

のみがヒットした。セルコ以外の人が特に利用している様子が見当たらなかった。

JIS標準がカタカナ名末尾の'ー'をつけない理由

コンピュータ(JIS準拠)
コンピューター(非準拠)

JISの資料が多すぎて末尾のーを消すだけで規格書が1冊へる、という理由があるらしいが、ソースが不明。Wikipediaにも似たようなことが書かれている

JISの従来の表記規格では、後述のように一定の基準で長音符を省略していた。省略した理由は、当時の活字などの印刷コスト、紙面や画面上の表示スペース、記憶装置などの節約と言われている[要出典]。

次回は「31.6 累積統計」から

2018-10-04

分散処理本第39回に参加

勉強会 Distributed System

恒例の分散本(Distributed Computing: Principles, Algorithms, and Systems)を読む勉強会です。

分散システムでのデッドロック検知はサイト間での検知を如何にとるか、と言うのがポイントだと思います。今回勉強した2種類のアルゴリズムではサイト間でメッセージを送ってデッドロックを検知します

Distributed Computing: Principles, Algorithms, and Systems

作者: Ajay D. Kshemkalyani,Mukesh Singhal
出版社/メーカー: Cambridge University Press
発売日: 2011/03/03
メディア: ペーパーバック
この商品を含むブログを見る

10.7 Chandy–Misra–Haas algorithm for the AND model

Andモデルでのデッドロック検出は単純で、サイクルを検出できれば良い。tripletというメッセージをWFGの依存先の各ノードがサイト外である場合に送る。

triple(i,j,k)の形式は以下に示す通り
- i:デッドロック検出を開始したノード
- j:kに依存しているノード(かつkとは別サイト)
- k:jが依存しているノード(かつjとは別サイト)
送信するprobe:triplet(pi, pj, pk)
依存関係の配列:dependent_K(i)

f:id:yuyubu:20181003234144p:plain — 引用元:http://www.lnse.org/vol3/205-X0012.pdf

以下がアルゴリズム

f:id:yuyubu:20181003235635p:image:w600 — Algorithm 10.1 より引用

ポイントは以下の通り

サイクルの検出開始地点(Fig1の図で言うとP1がi=kのprobeを受け取った時点でデッドロックの検出が成功する。
- 上図(fig1)の例でだと(1,5,1)のprobeがi=kに相当する
検出開始ノードから送るprobeの内容とprobeを受け取ったノードが依存先にprobeを送る内容は同一

参考リンク:

元になってる論文6のDistributed deadlock detection, ACM Transactions on Computer Systems:https://www.cs.utexas.edu/users/misra/scannedPdf.dir/DistrDeadlockDetection.pdf
wikipedia:https://en.wikipedia.org/wiki/Chandy-Misra-Haas_algorithm_resource_model

10.8 Chandy–Misra–Haas algorithm for the OR model

基本的な考え方
- ORモデルの場合は一つのサイクルの検出でデッドロック検知とならない。
- ORモデルの定義として、複数のリソースに依存している場合、依存先のリソース全てでデッドロックが発生して初めてデッドロックとなる
- このため、WFGの各ノードは依存先のノード件数をローカル変数numでもつ
- 依存先のデッドロック検出(後述のreply受診時)の度に、numをデクリメントする。
- num＝0のノードはその先で全てデッドロックが起こっていると言うことなのでreply(i,j,k)を自分の依存元に返す

f:id:yuyubu:20181004001029p:plain — A->Aのデッドロックが最初に発生した時

アルゴリズム

f:id:yuyubu:20181004002209p:image:w600 — Algorithm 10.2 Chandy–Misra–Haas algorithm for the OR model より抜粋

最終的に上図のAはBからreply(A,B,A),つまりi=k=Aを受け取ってデッドロックの検知が完了する。

参考リンク:

図の引用元:http://www.cs.fsu.edu/~xyuan/cop5611/lecture10.html

読書会では「10.9 Kshemkalyani–Singhal algorithm for the P-out-of-Q model」まで突入したが、予習ができてないので内容がよくわからなかった。また、10.9をやりきっていないのでそちらは次回の予習で調べます。

次回は「10.9.2 The algorithm」から

2018-10-02

新卒入社したSESの会社を退職しました

新卒で入社して3年半ほど務めました。9月26日が最終出社日でした。前職でどのようなことを経験してきたか書いてみようと思います。

前職について
前職で担当した仕事&仕事に関連して学んだこと
私ができなかったこと、足りなかったこと
- 自社/協力会社の有志で勉強会
- コミュニケーション
今後

前職について

一応正社員契約でしたが、SESと呼ばれるものでお客様先に派遣されて勤務します。いわゆる客先常駐というやつです。メリットは短期間で複数の現場に派遣されるので、転職することなく複数の業界/現場で働くことができることだと思います。

前職で担当した仕事&仕事に関連して学んだこと

Salesforce

salesforceは簡単に言ってしまえばインフラとかミドルウェアの構築が一切不要なPaaSのことです。

簡単な顧客管理機能等がバインドされています。画面をクリックするだけで簡単なアプリケーションを作成することができます。

また

apexというjavaに似た言語
visualforceというhtmlに似たマークアップ言語*1
SOQLというSQLに似たクエリ言語

を組み合わせることで柔軟なアプリケーションの構築が可能です。割と少ない工数で形になるものが出来上がるので、前職のような小さい会社と相性がいいのかなという印象です。

Salesforce社は自社でprogateのようなSalesforceを学べる教育サイトTraiheadを持っており、これの出来が非常に良いです。

COBOL,Javaのマイグレーション

COBOLで書かれたシステムをJavaで書き直すという経験が出来ました。業務分析などはせずに基本的にCOBOLのソースを一行単位で一致するJavaに置き換えます。一応証拠としてJavaのソースに対応するCOBOLをコメントアウトして添えていました。こんな感じです。

//PRODUCT-NO     PIC 9(8). 👈移行後のJavaのコードに対応するCOBOLのコードをコメントアウトして残しておく
Integer productNo;        //👈 移行後のJavaのコード

デバッグスキル

諸事情により納期前のどうしてもバグが取れない5万行程度の機能のバグ取りの担当になりました。ほぼ新人の自分が完成できるか不安しかありませんでした。

とにかく自分が知っている道具は全て駆使しました。Eclipseの条件付きブレークポイントとか、Watch式とか。結局、EclEmmaというプラグインを導入してメソッドごとにカバレッジを取りながら、微妙テストデータを変えながら調査を行ったのが一番効きました。正しい値を出す/出さない時でカバレッジが変わっているメソッドに徹底的にブレイクポイントとWatch式を貼ってデバッグしました。

バグは結局全て見つかりました。

ryokin12[1][2]こういう複雑な変数名や[]内のindex
if分の大小条件

が微妙に違ったりしているものでした。見つかった時は創意工夫して結果が出たことが非常に嬉しかったし、納期にも間に合うことができました。でも汎用機からオープン系へのマイグレーションは社内にノウハウがあるような巨大なSIerでないとしんどいと思います。

テスト

テストをすることが多かったため在籍中にテストに関する本を5冊読みました

知識ゼロから学ぶソフトウェアテスト【改訂版】

作者: 高橋寿一
出版社/メーカー: 翔泳社
発売日: 2013/12/10
メディア: 単行本（ソフトカバー）
この商品を含むブログ (7件) を見る

テスト駆動開発

作者: Kent Beck,和田卓人
出版社/メーカー: オーム社
発売日: 2017/10/14
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

ソフトウェアテスト293の鉄則

作者: セムケイナー,ジャームズバック,ブレットペティコード
出版社/メーカー: 日経BP社
発売日: 2013/11/20
メディア: Kindle版
この商品を含むブログ (5件) を見る

レガシーコード改善ガイド (Object Oriented SELECTION)

作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
出版社/メーカー: 翔泳社
発売日: 2009/07/14
メディア: 大型本
購入: 45人クリック: 673回
この商品を含むブログ (157件) を見る

はじめて学ぶソフトウェアのテスト技法

作者: リー・コープランド,宗雅彦
出版社/メーカー: 日経BP
発売日: 2005/11/03
メディア: 単行本
購入: 24人クリック: 539回
この商品を含むブログ (51件) を見る

※5冊目は今読んでいます

テストは製品の品質を担保する重要なプロセスだと思っています。そこが軽視されていたり、いい加減だったりするのよくありません。今ではテストは知的興奮が大いにある物作りのエキサイティングな分野の一つだと思っています。

テストや品質保証を専門にキャリアを築いている人も社外で何度かあいました。そういう人の生き方は尊敬しているし、決してテスト=雑用では無いと思っています

偉そうなことを行っているが以下は自分もよくわかっていません

複雑な平行/並列処理が絡むテスト
大規模なシステムの負荷テスト
テストの自動化のためのテクニック(特にフロントエンド周り)

フロントエンド周りの知識

フロントエンド周りの技術は進歩というか変化が特に激しく、サーバーサイド側の人間が片手間で追従できるものでは無いと思っています。だからフロントエンド周りのスキルは時間をかけて基礎からじっくり勉強するつもりはありませんでしたが、どうしても作っているものに納得が行かなかったため何冊か本を読んで勉強しました。

作りながら学ぶ HTML/CSSデザインの教科書

作者: 高橋朋代,森智佳子
出版社/メーカー: SBクリエイティブ
発売日: 2013/12/14
メディア: 単行本
この商品を含むブログ (11件) を見る

改訂新版JavaScript本格入門 ?モダンスタイルによる基礎から現場での応用まで

作者: 山田祥寛
出版社/メーカー: 技術評論社
発売日: 2016/09/30
メディア: Kindle版
この商品を含むブログを見る

JavaScriptパターン ―優れたアプリケーションのための作法

作者: Stoyan Stefanov,豊福剛
出版社/メーカー: オライリージャパン
発売日: 2011/02/16
メディア: 大型本
購入: 22人クリック: 907回
この商品を含むブログ (76件) を見る

※３冊目は見事に途中で挫折していますね

yuyubu.hatenablog.com

フロントエンドエンジニアとして世間一般で通用する自信はありませんが、フロントエンド技術を利用しているチームの成果物の改善にはかなり貢献できたと思います。

フロントエンド技術(UI/UX)の本質的な難しさは,非技術者のもっとも関心が高くなる部分という点だと思います。現場によってはカジュアルな仕様変更などが多数発生します。

ここをしっかり戦い抜いていくには技術以外にも人間工学とか、心理学とかもしっかり抑えて「なぜそのデザインがBestなのか」を説得できる能力が必要だと思いました。

Javaとかオブジェクト指向とか

大学時代はほとんどJavaを触っていませんでした。趣味でAndroidアプリの入門書を一通りやったり、大学で1コマそういう授業があっただけでした。

Javaは動かし始めるまでに覚えないといけない概念が多いわりに、それが駆使できるのはもっと経験が必要なので、覚えた概念の恩恵みたいなものはイマイチわからなかった。結局最初はC言語によくわからないキーワードが大量に引っ付いたプログラムみたいな印象を受けました。

で就職してからはこれを使わなくてはならないと思って、Javaを本格的に学んだ。

なぜ、あなたはJavaでオブジェクト指向開発ができないのか―Javaの壁を克服する実践トレーニング

作者: 小森裕介,アクロクエストテクノロジー株式会社
出版社/メーカー: 技術評論社
発売日: 2004/12/01
メディア: 単行本
購入: 10人クリック: 217回
この商品を含むブログ (50件) を見る

オブジェクト指向でなぜつくるのか第2版

作者: 平澤章
出版社/メーカー: 日経BP
発売日: 2011/04/07
メディア: 単行本
購入: 6人クリック: 92回
この商品を含むブログ (20件) を見る

Effective Java 第3版

作者: Joshua Bloch,柴田芳樹
出版社/メーカー: 丸善出版
発売日: 2018/10/30
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

Javaは動かし始めるまでに覚えないといけない概念が多いわりに、それが駆使できるのはもっと経験が必要なので、覚えた概念の恩恵みたいなものはイマイチわからなかった。

大学時代分からなかったこの箇所がわかるような気がしてきた。だから必死で勉強しました。特に後者の2冊はとても勉強になった。 Javaのプロジェクトには数週間しか関われていないけど*2、Java及びその関連技術(JVM言語等)を自分の強みにしていきたいという思いがあります。

正規表現

業務で正規表現エンジンを作ったという話ではありません。*3

事務作業が8割くらいの時期があり、雑務にひたすら正規表現を使って進めることで退屈をしのいでいました。

きちんと本で勉強して覚えたわけではないけど、1ヶ月程度毎日ググりながら正規表現を書いていたので、機械的に行えば良いだけのテキスト変換、置換などは、加工対象の文字を大体見ただけでどういう正規表現を書けば良いか思いつくし、ほとんど空で書けるようになりました。

正規表現完全に理解した!と思って調子に乗ってネットにいい加減なこと書きまくって、ある日rubyの正規表現エンジン(Onigmo)を作ってる人から訂正コメントが飛んできて、自分は何も理解できてない、と自信を失ったりしたこともありました。

qiita.com

位置指定子っていう概念が微妙に理解できていないこと以外はだいたい実践的な部分では困らなくなった。あと計算量とかパフォーマンスの理解が不十分。

大学のころ、正規言語とかオートマトンの授業を取っていたので、この辺はきちんと勉強したいですね。

SQL&RDBMS

開発がやりたかったけど、結局規模の大きい保守案件に配属になった。データはたくさんあったので*4 SQLとRDBを勉強すると自分にも会社にも+になるだろうなと思い、勉強し始めた。

ある日バグの影響範囲を調査するため、再帰クエリが適応できそうな調査案件があった。他のメンバーはお手上げだったが、急いで技術調査をして調査のクエリを作った。その時復習した内容は以下の記事にまとめてあります

qiita.com

こういう風にやればできますよと提案して、結局自分が担当になってそのデータを調査、修正するクエリを書いた。あの時は純粋に学んできたことが活きた数少ない瞬間だった。自分にも会社にも+になったと思う。

Excel VBAや自作スクリプトによる調査の効率化

大規模なシステムだったので、目grepが厳しいのでExcel VBAやJavaScriptを使って効率的に調査をするツールを作成しました

VB.NETのクラスを調査するファイルを作っていて、

https://teratail.com/questions/118863

vbのこんな仕様に悩んだりしていました。

プログラムの解析を正規表現でゴリゴリ書いていましたが限界を感じました

http://leoclock.blogspot.com/2009/01/blog-post_27.html

仕事関係ないけどこの経験から少し言語処理系とかに興味を持つようになりました

セキュリティ

詳しくは書きませんが、システムのセキュリティ強化のため個人的に勉強していました。

体系的に学ぶ安全なWebアプリケーションの作り方第2版［リフロー版］　脆弱性が生まれる原理と対策の実践

作者: 徳丸浩
出版社/メーカー: SBクリエイティブ
発売日: 2018/09/20
メディア: Kindle版
この商品を含むブログを見る

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

作者: 小森裕介
出版社/メーカー: 技術評論社
発売日: 2010/04/10
メディア: 大型本
購入: 57人クリック: 1,242回
この商品を含むブログ (35件) を見る

色々指摘することができましたが、進捗にはマイナスでしかなかったので、迷惑だったかなと思います。

会社へのSlack導入

脱メールでのコミュニケーションを目標に、上司への提案でSlackをチームで採用していただきました。チーム、部という順番で広がっていったのでおそらく、退職後しばらく経てば全社的に使っていると思います。

これから中小企業で導入して見たいけど、使い方が良く分からない。。。という人は最近は技術コミュニティでもSlackを積極的に使っているので、そちらに参加して慣れながら活用方法を学んでいけば良いと思います。

私ができなかったこと、足りなかったこと

自社/協力会社の有志で勉強会

どうしても業務で経験できることには限界があるので、エンジニアには業務以外での技術研鑽が必要だと思います。 SESというのは客先の稼働時間が大事なので基本的に就業時間内に勉強はできませんが、もっと仕事で使っている技術やフレームワークについて、特に新人を含めた勉強会などができたらよかったと今になって思います。

ちなみに仲良くなったパートナー会社の社員さんには技術書を貸したり、JavaScriptの基本を教えたりしていた。

本の紹介を依頼され、他社の新人にリーダブルコードを貸した。チョイスは仕事中メソッド名や見やすいSQLのインデントに何度も悩み、他の開発者に相談している姿を何度も見たため。きっと役に立つと思う。
— yuYabu＠転職中 (@yuyabu2) March 2, 2018

コミュニケーション

私はお酒が飲めないこともあって、非常に人付き合いが悪かった。別に飲み会を欠席したことで非難されるようなことは1度くらいしかなかったけど、そういう所で信頼関係が結べていなかった所でスムーズに物事が運ばなかった面はあったと思います。

またあまり失礼とか気にせず思ったことを口にするタイプだったので、色々勉強して見ました。

yuyubu.hatenablog.com

まだまだ未熟者ですが日々修行中です

今後

働く前は開発こそ至高みたいな考え方があったけど、自宅学習でそれなりにスキルを高めて、問題解決ができれば保守/調査/テストも面白いと思いました。でも開発をあまりやらせてもらえなかったので開発をしたい思いが強いです

今後は以下の業務に関わってみたいです

Java関連技術を使ったWEBサービスの構築、運用、保守
DBA
データベースに関連する開発

最後になりましたが、前職では社長、前社長、前前社長をはじめ、様々な方々のお世話になりました。本当にありがとうございました。

*1:今はLightning Componentという技術が使われているそうですが、過渡期に抜けたので最近の事情は知りません

*2:COBOL マイグレーション案件を除く

*3:正規表現エンジンは作ってみたい。

*4:記憶が曖昧だが１億レコードのテーブルもあった

2018-09-30

Java読書会「現場で役立つシステム設計の原則」を読む会第2回に参加

遅れて午後から参加しました。今回は、書かれていることは確かに理想だけど...という切り口の議論が多かったように思います

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

作者: 増田亨
出版社/メーカー: 技術評論社
発売日: 2017/07/05
メディア: Kindle版
この商品を含むブログ (4件) を見る

かんしんごと vs かんしんじ?

(業務の) 関心事 ← 「かんしんじ」vs.「かんしんごと」で意見が割れている。自分は「かんしんじ」派かなぁ #javareading
— YutakaKato.jar (@kagaorange) September 29, 2018

#javareading

関心事=かんしんごと？かんしんじ？どっちの読みが正しい？という話になった。昔みた増田さんが話しているビデオだと「ごと」で読んでたような？

増田さんの発表を聞いた人のブログにも「関心ごと」と書かれているので多分「ごと」が適切だと思うのですがhttps://t.co/kn8w21bhpj
— yuYabu＠転職中 (@yuyabu2) 2018年9月29日

YutakaKatoさんと漢字の読みで張り合っています

www.youtube.com

私は著者が講演で「かんしんごと」と発音しているビデオ(1:28:2~)に影響を受け、これにつられて「かんしんごと」で通しています

なぜ「関心事」だけ「じ」と読むのでしょうか？

「心配事」はいわば和語扱い、「関心事」は漢語扱いだからです。

oshiete.goo.ne.jp

日本語の読み方的には「かんしんじ」が正しいようです😇。DDD界隈読みということもありえるのでしょうか。

まぁ漢字の読み方とかにこだわっているわけではありませんが、この本やたらと「関心事」という単語が出てくるので、どうしても気になってしまうのです。

なんと252回も！出てきますw

とりあえずDRYみたいなのは有害

共通しているからという理由でまとめてはいけない。ドメインの観点から検討して、本当に共通か？を意識して共通化する必要がある。
共通化というのは結果にすぎない。
とにかくDRY原則!というのが有害
日時系のAPIは日付概念はものすごく抽象化されているから便利に使える
- とりあえずなんとなく共通処理をまとめました、だと誰も使わない

https://qiita.com/tag1216/items/91a471b33f383981bfaa

ドメインを考えるのはすごく大変。重複クラスをまとめるだけなら脳みそを使わない。

Accountパターンの出どころは？

関心事のパターン	業務ロジックの内容
口座(Account)パターン	現在の値(現在高)を表現し、妥当性を管理する
期日(DueDate)パターン	約束の期日と判断を表現する
方針(Policy)パターン	様々なルールが複合する、複雑な業務ロジックを表現する
状態(State)パターン	状態と、状態遷移のできる/できないを表現する

業務ルールを記述するドメインオブジェクトの基本パターンより抜粋　

ちょっと議論の内容は失念したが、こういうプログラミングのプラクティスは

PoEAA
アナリシスパターン
エリックエバンスのドメイン駆動設計

エンタープライズアプリケーションアーキテクチャパターン (Object Oriented SELECTION)

作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート
出版社/メーカー: 翔泳社
発売日: 2005/04/21
メディア: 大型本
購入: 10人クリック: 635回
この商品を含むブログ (143件) を見る

アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)

作者: マーチンファウラー,Martin Fowler,堀内一,友野晶夫,児玉公信,大脇文雄
出版社/メーカー: ピアソンエデュケーション
発売日: 2002/04
メディア: 単行本
購入: 7人クリック: 89回
この商品を含むブログ (70件) を見る

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
出版社/メーカー: 翔泳社
発売日: 2011/04/09
メディア: 大型本
購入: 19人クリック: 1,360回
この商品を含むブログ (131件) を見る

などが元になっていたりするらしい。読書家な人が集まっているので「このパターンは一般的なやつ、このパターンはXXに乗ってるやつだね」という流れになったが、Accountパターンは何が元になっているか?という結論が出なかった。エリックエバンスの本は手元にあったので一応中を調べてみたが、それらしいものはなかった

PoEAAの訳はひどい
- とても読めたものではないので捨てた

粒度の小さいクラスを大量に作ることの是非

本書では単位や属性のクラスをかなり細かく作成していくが、クラス数が増えるほど依存関係が増えたり複雑になるので、とりあえずクラスを小さくすれば良いというものではない。

個人的に大事なことは責務が混ざらない程度に小さくすることだと思う

他技術的なトピックなど

適当に議論中に出たトピックをまとめます

for文でコレクションを確認しているコードはStream APIのAnyMatchなどを使うべき
JavaのStringクラスの方がクラス設計としては良いが、結果的にRubyが文字列をただのバイト列として扱っているやり方のほうが結果的に成功している
- JavaがStringクラスに採用している設計パターンが結果的に良くなかったという趣旨の話があった
JSR-305
- @NotNullなどのアノテーションの標準化
Kotlin最高
- Springの開発スピードが早い(Kotlinの開発がついていけてないらしい)

次回は「小さく分けたサービスを組み立てる」から

2018-09-28

CC本読み会第12回

勉強会 DB Transaction

Concurrency Control and Recovery in Database Systemsを読む勉強会です。

内容としてはロックのパフォーマンスに関してです。今回のポイントは競合の種類(Resource/Data)と競合を回避する手段(abort/block)がメインだと思いますよくわからない箇所があったので自宅で復習しました。

今回はp87から

3.12 LOCKING PERFORMANCE
- Resource and Data Contention
- Thrashing
- Blocking and Restarts
- Predeclaration
- A Bound on Workload
- MPL, Transaction Length, and Granularity
- Read Locks and Nonuniform Access

を読みました。次回は「3.13 TREE LOCKING」からになります。

Concurrency Control and Recovery in Database Systems

作者: Philip A. Bernstein,Vassos Hadzilacos,Nathan Goodman
出版社/メーカー: Addison-Wesley
発売日: 1987/02/01
メディア: ハードカバー
この商品を含むブログを見る

目次です

競合(Contention)に関して
競合に伴うパフォーマンス低下(Thrashing)について
競合の解決方法
- blockingとrestartsのパフォーマンスの比較
- 2PLの検討(Basic 2PL,Conservative 2PL)
性能限界 ~DC Thrashing ギリギリまでパフォーマンスをあげる~
他雑談

競合(Contention)に関して

競合には2種類ある。リソース競合とデータ競合。
- リソース競合(Resouce Contation):メモリやIO待ちなどのシステム的な部分
- データ競合(Data Contation):ロックに関連する競合
多かれ少なかれ多くのシステムは(物理上のスペックの上限があるので)リソース競合が発生しうる。
- リソース競合以外の競合としてデータ競合が定義できることは発展的な議論をするために便利な概念となる。
データ競合はリソース競合を緩和する可能性がある

Resource contention also hurts a pure restart policy more than a blocking policy. With the latter, some transactions are blocked in lock queues, so fewer transactions compete for resources. (Thus, data contention alleviates resource contention for a blocking policy.)

データ競合が起きてできることが少なくなると、リソースの利用率が下がる。

競合に伴うパフォーマンス低下(Thrashing)について

リソース競合,データ競合それぞれに応じてThrashingが発生する恐れがある
- DC Thrashing:ロックの取り合いによって生じるパフォーマンス劣化のこと(デッドロック含む)
- RC Thrashing:スタベーション,またはlive lockのこと
DCスラッシングに関してはDBMSのリソースが無限にあっても発生する恐れがある
DC Thrashing pointを超えてからトランザクションを増やすと、blockされていないトランザクションの数が減少する
- ブロック(ロック解放待ち)とデッドロックがDC Thrashingを引き起こす。特に後者は致命的。
- DC Thrashing point(Thrashingが起こり始める臨界点みたいなイメージ)
  - DC Thrashing point以降に1つのトランザクションの追加で複数(2以上)のトランザクションが平均的にブロックされてしまう
  - DC Thrashing pointを超えてロックキューが増加するとシステムの使用率がかなり低下する
- DC Thrashing point以降にシステムに負荷をかけるとパフォーマンスが大きく下がる

競合の解決方法

競合(Data Contation)の解決方法は2種類ある
- blocking戦略:ロックが解放されるまで待たせるロックキューを作る(waitさせる)
- restart戦略:専有しようとしたリソースがすでにロックされていた場合、トランザクションをabortして最初からやり直す
一般的なRDBMSの実装状況
- blocking戦略をとっているもの
  - MySQLはデフォルトは50秒待ち
  - MySQL Clusterは1.2秒
  - DB2は２分待ち
  - Oracleは永久待ち?
- restart戦略をとっているもの
  - SQLServerはabortしてredo(デフォルトは無限回試行する)
blocking/restartは設定で選べないのか?
- 中身の処理内容が全く違うので設定で切り替えるような問題ではない

blockingとrestartsのパフォーマンスの比較

restartする方が一見コストが高いように見える
- 再起動のコストを払う必要になるため
- 中断した箇所までのトランザクション処理の成果は捨てられるため
が実際にはblocking戦略の方が早く性能劣化(Thrashing)を引き起こす
blockingがrestartsより良いという理屈は次の状況が両方発生する場合に
- restartに時間がかかりすぎる → 実装によって回避可能
- リソース競合が頻繁に怒る → CPU数を増やすことによって回避可能
restartの方がblockingより応答時間は増える
- restert時にロック解放する必要があるため*1
ロックの取り合いをさせるくらいならアボートさせる方が良いというのが最近のDB界隈のトレンド
トランザクションは本来APエンジニアに見せるべきではない
- 本来ならAPエンジニアにはcheckpointを設定させるだけにするべき
ブロックは利己的
リスタートは自己犠牲的
abortは処理が重そうだけどlockの方が軽いのではというのが一般的だが、実態はabortさせてredoする方がパフォーマンスが良い。
- この本はrestart派
- 神林さんはblocking派
  - ただし単純なlockではなく後ろにずらす
    - 先日のsundialの論文の発表でも似たような事を言われていたような?
- 最近はトランザクションの量が多いので、キャッシュの汚染率が高い
  - 定説としてこの本に書かれている内容から時代が変わっている
    - ただこの本が古いという訳ではなく、lockとrestartのコストはアーキテクチャに依存するので随時計測する必要がある。

2PLの検討(Basic 2PL,Conservative 2PL)

Basic 2PLとConservative 2PLについて地球で一番わかりやすい解説はこちら

qiita.com

※以後Basic 2PLをB2PL,Conservative 2PLをC2PLと略します

理屈上はB2PLの方がC2PLよりロックを保持している時間が短い
一見B2PLの方がパフォーマンス上メリットがありそうである
ただしこれはデータ競合の発生が少ない場合のみ。
データ競合の発生が激しくなるにつれC2PLの方がロックを保持している時間が短くなる

この節p91の「Predeclaration」ですがなぜデータ競合が多いとC2PLが勝るのか、根拠がよくわかりませんでした。

結論としてはC2PLを導入することによって - デッドロック回避 - DCスラッシングの阻止(軽減) のメリットある。(後者の方が期待度が高い)

性能限界 ~DC Thrashing ギリギリまでパフォーマンスをあげる~

リソースが無限と考えても、トランザクションを増やしたり、並列化するとスループットは上がるが、どこかで下がるポイント(DC Thrashing)がある。

DC-thrashing thus defines an operating region the combination of parameters that affect the performance.

実はこれは計算で算出可能

N:MPL(multiprogramming level)多分トランザクション数
k:一つのtransactionが要求する平均lock数
D:データ資源

の時DC Waolkoad $W = k^{2}N/D \lt 1.5$

だから性能限界は

$k^{2}N/D \lt 1.5$

となる。が、これは

DBアクセスが一様的である前提
- ピークとかない。増減しない平均的な接続が常に発生するイメージ
リソース競合を考慮していない

なのでかなり楽観的な数値である。あくまで1.5というのはこの規模の数字である、という参考を示しているにすぎない。

MPLについて

MPL(並列化するプロセス数)は1.5D/k²以上あげるべきではない。
- N(MPL)をあげるとデッドロックが発生する率も上がる
- restartのコストが高い場合はさらにNを下げる必要がある

Long Transactionについて

以下の事象はスループットを下げる要因となる

トランザクションあたりのロック数
トランザクションが長い

そもそもトランザクションよりもロックが増えることによる影響が大きいのでトランザクションを分割することでworkloadをあげることができる

例えば

トランザクション数N,ロック数kを分割して
トランザクション数2N,ロック数k/2にする

前述の式

$W = k^{2}N/D$

に当てはめると

$(k/n)^{2}(2N)/D = k^{2}N/2D$ となり、これは分解前の $W=k^{2}N/D$ より倍よくなっている。

Granularity(粒度)について

Granularityの定義はchapter1のp2に書いてある

The size of the data contained in a data item is called the granularity of the data item.

小さいD(荒い granularity)は大きな範囲にロックがかかる
大きいD(細かい granularity)は小さな範囲にロックがかかる

Granularityが性能に及ぼす要因は3つある

1.ロックオーバーヘッド
- granularityが細かいほどロックが必要=オーバーヘッドが増える
2.データ競合
- granularityが荒いほどデータ競合が起こる可能性がある
- ただし、granularityが細かければ良いという訳ではない
  - 一般的にgranularityが細いほどロックが増える傾向にある
  - ロックが増えるともちろんロックの衝突(Data contation)も起こりやすくなる
3.リソース競合
- 前述したが、データ競合はリソース競合を改善する可能性がある
  - ranularityが荒いとリソース競合が起きにくい。
  - ranularityが細かいとリソース競合が起きやすい

上記の3要因を踏まえるとGranularityによるスループットの変化は以下のグラフのようになる

f:id:yuyubu:20180928005540p:plain — Granularityとスループットの関連。p95から引用したものに補足説明したもの

ただしこのグラフのようなスループット増減を必ずとるわけではない
- 例1:データベースの大部分にアクセスする長いトランザクションの場合
  - 粒度を細かくしても結局ロックが増えるだけなのでDの増加に対してkが伸び悩まないため①の性能劣化より後のスループット変化が起こらない
- 例2:短いトランザクションに関してはDの増加に伴うkの伸び悩みが早く起こるので①の性能劣化が現れない
  - いきなり右肩上がりのグラフになる
Read Lock
- 今まではWrite Lockを前提に考えてきたが、lockの何割かがread lockと考えるとパフォーマンスは工場する
アクセスの偏り
- アクセスの偏りが発生しているとworkload(負荷)増加の恐れがある

他雑談

MVCCは理解に3年かかる。説明できるようになるのに8年かかる
神林さんのdb tech showcase2018の発表ですが、資料公開/ブログで再整理される予定があるそうです!
ANSIのSQL標準の資料は、新しいものは有料だが、ベータ版は公開されていて読めるらしい
プログラミング言語のコンペでSQLを使って2位になったチームがあったらしい?
- ISUCONではない。
COBOLで作られたWEBサーバーがあるらしい?(プロジェクト)
- COBOLerにもなんでもCOBOLで実現する変態的な人がいるらしい

次回は「3.13 TREE LOCKING」から!

*1:ロック解放は時間がかかるような処理なのか?

2018-09-25

dbtech showcase Tokyo2018に参加

勉強会 DB

dbtech showcase Tokyo2018に参加

f:id:yuyubu:20180925232952j:plain

このカンファレンスは「プログラマのためのSQL」の参加者から聞いて知りました。大企業/メガベンチャーのDBの運用ノウハウだったりデータベースベンダーの方から最新の製品テクノロジなどが楽しく聞けた3日間でした。

ストレージ

A27:DBエンジニアのためにSSD Q&A集

SSDのセッション。内容は以下の4つ

1.製品寿命
2.TLC
3.enterprise向けssd
4.NVMe仕様SSD

#dbts2018

FW進化の歴史

0.何もしない(古いデータの読み取りがどんどん遅い)
1.読み出しごとにリフレッシュ(初回リードが毎回遅い)
2.定期的に強制リフレッシュ(余計な書き込みが発生する)
3.Patrol Read：アドホックにリフレッシュ(電圧が下がっている場所を発見する)
— yuYabu＠転職中 (@yuyabu2) September 20, 2018

SSDはHDDより爆速で早い、程度の認識しかなく、そこまで興味はなかったのですが、twitterのタイムラインが盛り上がっていたので急遽参加しました。

SSDの仕組みから始まり、寿命やコントローラーの説明、NVMeの展望などが語られました。

SSDはファームウェアは順調に進化しているが、それを利用するOSやFSはまだまだ技術に追いついていない(特にNVMe)という印象を持ちました。

企業システム向けのSSDはまだまだ進化の余地があり、今後ますます注目が集まってくる分野になると思います。

MySQL 8.0

ドキュメントベースのNoSQLデータベースとして利用しつつ、jsonの任意のデータを選択した仮想列を作成してそちらをSQLから参照するというテクニックが披露されました(x dev API)。MySQL8.0では他にもWindow関数が入ったりして大きく標準SQLに近づいたというか、自分の中でMySQL株が上がりまくりです。

トランザクション理論

A13・14:今後のDBのトランザクション処理のあり方について徹底討議する～"InvisibleWriteRule: トランザクションの書込み最適化" を中心に
C33:MVCCにおけるw-w/w-r/r-wのあり方とcommit orderのあり方の再検討～Sundial: Harmonizing Concurrency Control and Caching in a Distributed OLTP Database Management Systemを題材に

1日めのA13/14は忘れ物で*1遅れて参加したため、後半部分しか聞けませんでした。最近気になって購読し始めた「ぱと隊長日誌*2」の筆者の方や神林さん、kumagiさん(参加者)などなど、トランザクションに関する情報発信をされてる方々が勢揃いされていたので、面白いディスカッションだったと思う。

C33は事前に前倒しで開始する...との連絡が非公式にありましたが、5分前に到着したところすでに始まっており、前倒ししたのに10分程度延長されていた

DBTS2018 C33「MVCCにおけるw-w/w-r/r-wのあり方とcommit orderのあり方の再検討」にご興味のある皆様へ、神林さんから伺ったことを共有します。開演時刻を少し前倒しするかも（注：昨年も同様で、かつ終演時刻overの熱さ）。スライド公開予定：Noとなっているけど、公開するかも。（続く）#dbts2018
— ぱと (@pato_taityo) September 20, 2018

今日の神林さんの講演は予想通り前倒し開演、終演時刻ぶっちぎり（でも終わらない）だったな。でも、あの熱の入った講演スタイルは大好きだったりする。#dbts2018
— ぱと (@pato_taityo) September 21, 2018

発表内容としてはこちらの論文を読みながらMVCCやOCCを分散システムに適応するとどうなるか、という発表内容だった。

http://www.vldb.org/pvldb/vol11/p1289-yu.pdf

個人的に印象に残ったのが、

Sundialのアルゴリズムではロックに頼らず、時系列順(Timestamp Ordering)に頼ってデータの整合性を担保する
- サイト間で物理時間は同期しない。*3同期するのは順序のみで、順序同期なら技術的に可能らしい
実行順序を工夫することで、発生順ではありえない操作が実現できる

r1(x2)w2(x2)c2c1→w2(x2)r1(x2)c2c1

分散システムと普通のRDBMSではcommitの意味が違う
- 普通のRDBMS:データを保存する(ACID)
- 分散システム:データを確定させる(他のサイトから見えるようにする)

あとちなみに別セッションですが...

Amazonのマルチマスタなデータベースに関して分散システムの勉強会で話題に登りましたが...

マルチマスターでのデッドロックの検知はそんなに優しくない AWSはマルチマスターをやっているらしい(無謀？超絶技術？)

分散処理本第37回に参加

#dbts2018
amazonのマルチマスターのコンフリクト解決はcommit先勝ち。

競合する後続のトランザクションはどんなに長くてもロールバック(例外もある)
— yuYabu＠転職中 (@yuyabu2) September 21, 2018

書き込み競合は先勝ちとなっているようです。ではデッドロック検知は...気になりますねぇ(やっぱりタイムアウトなんでしょうか?)

大企業のDBA

他にもLINEさんのセッションやリクルートさんのセッションが面白かったです。普段は聞けない大企業のDB運用事例について聞くことができました。

#dbts2018
LINEが使ってるデータベース関連プロダクト

・REBMS
MySQL
Oracle
SQLServer
CUBRID(韓国Narva製)

・NOSQL
redis
mongoDB
HBase
elastic

※redisとMySQLがメイン
— yuYabu＠転職中 (@yuyabu2) 2018年9月20日

#dbts2018
NoSQLはキーバリュー,ドキュメント型
とかで分類するのは古い

NoSQLの新しい分類方法
- レスポンスタイム追求型
- 開発容易性追求型
— yuYabu＠転職中 (@yuyabu2) September 21, 2018

リクルートさんの方は社内事例の紹介という訳ではなく、昨今話題の様々なデータベース関連製品の紹介&整理でした。分量が多すぎて理解しきれていませんが、格DBやその使い分けに関してわかりやすく紹介されていました。

#dbts2018

LINEではMySQL Query Replayerを開発中!

ネットワークパケットからクエリを取得してリプレイするツール。

来年のdbtech show caseで発表予定か!?
— yuYabu＠転職中 (@yuyabu2) September 20, 2018

LINEさんは自社でMySQL関連のツールを色々作られているそうです(面白そう) １日目のYahooさんの発表も聞いておけばよかったと後悔。

勉強時間の大半をRDBMSに費やしていましたが、今までDBAの方のお話を聞く機会が今までなかったので刺激的でした。

*1:メガネ...これがないと発表会では何も見れない

*2:https://taityo-diary.hatenablog.jp

*3:やるなら原子時計とか使ってやる。今の技術でも難しいと聞いたことがある

IEEE754とは

値の表現方法について

仮数部はなぜ1を足しているのか。

指数部はなぜ127を引いているのか

まとめ

30. 6 ベンダー 拡張

標準SQLかどうかはどうやって見分けるか?

C.J.Dateの有名なサンプルデータについて

JIS標準がカタカナ名末尾の'ー'をつけない理由

10.7 Chandy–Misra–Haas algorithm for the AND model

10.8 Chandy–Misra–Haas algorithm for the OR model

前職について

前職で担当した仕事&仕事に関連して学んだこと

COBOL,Javaのマイグレーション

デバッグスキル

テスト

フロントエンド周りの知識

Javaとかオブジェクト指向とか

SQL&RDBMS

Excel VBAや自作スクリプトによる調査の効率化

セキュリティ

会社へのSlack導入

私ができなかったこと、足りなかったこと

自社/協力会社の有志で勉強会

コミュニケーション

今後

かんしんごと vs かんしんじ?

とりあえずDRYみたいなのは有害

Accountパターンの出どころは？

粒度の小さいクラスを大量に作ることの是非

他技術的なトピックなど

競合(Contention)に関して

競合に伴うパフォーマンス低下(Thrashing)について

競合の解決方法

blockingとrestartsのパフォーマンスの比較

2PLの検討(Basic 2PL,Conservative 2PL)

性能限界 ~DC Thrashing ギリギリまでパフォーマンスをあげる~

MPLについて

Long Transactionについて

Granularity(粒度)について

他雑談

ストレージ

MySQL 8.0

トランザクション理論

大企業のDBA

30. 6 ベンダー拡張