2018-05-06

MySQL のテーブル定義から外部キー制約を推測するツールを作った

GW 中の自分へのプチ課題として、表題の通りのツール hakagi(葉鍵, Leaf and Key) を作りました。ツール名には特に意味はありません。

テーブル名やカラム名から外部キー制約を張れるような気がするカラムを選出し、制約追加のための ALTER TABLE をするクエリを吐き出したりします。

なぜ作ったのか

外部キー制約は言うまでもなくデータの不整合を避けるのに有用ですが、いくつかの理由からこれを用いない選択肢も存在すると思われます。この辺りについては以下の記事なども参考にすると良さそうです。

外部キー制約を設けないことによるデメリットも幾つか生じると思っていて、その一つで自分が気になっている点として、「ER 図をツールで自動生成しにくい」があります。例えば MySQL Workbench は sql ファイルや稼働する MySQL データベースから ER 図を自動生成してくれる機能を持ちますが、エンティティ間のリレーションは外部キー制約を無くすと追えなくなります。この問題に対する緩和策として SchemaSpy を用いれば主キーをベースに外部キー制約を推測して ER 図生成を行ってくれます。しかしながらこの推測のルールはあまり小回りが効くものではありません。

SchemaSpy のやっているような制約の推測を、図の自動生成とは分離してシンプルに扱い、かつルールを細かく追加したり ON/OFF したりしたい。そう考え今回紹介するツールの実装を開始しました。

実装など

ワンバイナリでサクッと動かしたい希望があったため Go で書いています。 MySQL データベースからテーブル定義や主キーの情報を集めるため information_schema データベースを参照し、推測を行って制約追加クエリを標準出力に出します。現在サポートする推測ルールは以下の通りです。

あるカラム名と同じ名前の、別のテーブルのカラムが存在し、かつそれが id という名前ではなくそのテーブルで主キーである場合外部キー制約を追加する
あるカラム名が <別のテーブル名の単数形>_id であり、かつ別のテーブルで id が主キーである場合外部キー制約を追加する

標準出力に最終的に吐き出すフォーマットとしては今後は必要であれば PlantUML をサポートしたりしてもいいかも、と考えております。

動作例

以下のような、外部キー制約が全く設けられていないテーブル定義があったとします。

CREATE TABLE IF NOT EXISTS users (
  id    INT UNSIGNED NOT NULL AUTO_INCREMENT,
  name  VARCHAR(255) NOT NULL,
  age   INT UNSIGNED NOT NULL,
  email VARCHAR(255) NOT NULL,
  PRIMARY KEY(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS contents (
  id    INT UNSIGNED NOT NULL AUTO_INCREMENT,
  title VARCHAR(255) NOT NULL,
  text  TEXT NOT NULL,
  user_id INT UNSIGNED NOT NULL,
  PRIMARY KEY(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS content_comments (
  content_comment_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  text               TEXT NOT NULL,
  content_id         INT UNSIGNED NOT NULL,
  user_id            INT UNSIGNED NOT NULL,
  PRIMARY KEY(content_comment_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS content_comment_reactions (
  content_comment_id INT UNSIGNED NOT NULL,
  user_id            INT UNSIGNED NOT NULL,
  reaction_id        INT UNSIGNED NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS reactions (
  id        INT UNSIGNED NOT NULL AUTO_INCREMENT,
  image_url VARCHAR(255) NOT NULL,
  PRIMARY KEY(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

これをベースに MySQL Workbench で ER 図を生成すると以下のようになります。

f:id:syu_cream:20180506200831p:plain

これに対し hakagi はいくつか外部キー制約を追加するクエリを吐き出してくれます。

$ ./hakagi -dbuser root -targets hakagi_example
ALTER TABLE content_comment_reactions ADD CONSTRAINT FOREIGN KEY (content_comment_id) REFERENCES content_comments(content_comment_id);
ALTER TABLE content_comment_reactions ADD CONSTRAINT FOREIGN KEY (user_id) REFERENCES users(id);
ALTER TABLE content_comment_reactions ADD CONSTRAINT FOREIGN KEY (reaction_id) REFERENCES reactions(id);
ALTER TABLE content_comments ADD CONSTRAINT FOREIGN KEY (content_id) REFERENCES contents(id);
ALTER TABLE content_comments ADD CONSTRAINT FOREIGN KEY (user_id) REFERENCES users(id);
ALTER TABLE contents ADD CONSTRAINT FOREIGN KEY (user_id) REFERENCES users(id);

このクエリも用いることで、以下のような ER 図を生成することができました。

f:id:syu_cream:20180506201000p:plain

おわりに

まだ少ないサンプルに対して少ない推測ルールを適用しているだけなので、誤った推測結果が出たり推測が足りなかったりする場面があるかもしれません。このツールを用いる場面が数多くあれば、そこで出てきたユースケースを元にツールを機能拡張していきたいところです。

2018-04-18

技術書典4にサークル名「まいにちがきんようび。」で暗号通貨とDNSの本を配布します　

直前のお知らせになりますが、技術書典4 に「まいにちがきんようび。」というサークル名で参加して技術系薄い本を配布します！

techbookfest.org

以下のような内容になっています！

基礎から説明する暗号通貨 @lunatic_star
今日から始める IOTA @syu_cream
エンジニアのための DNS(再)入門(初級者編) @m_bird
エンジニアのための DNS(再)入門(中級者編) @kdmn

(表紙イラスト @fuga_romantica )

配布部数は 50 程度になる予定です。また販売価格は一冊 500 円を予定しています。電子書籍での販売も予定しているため、もし売り切れるようなことがあれば（あるのかな...）そちらをご検討頂ければ幸いです。ぜひ当日、会場にてお会い出来れば嬉しいです！！！

2018-01-30

何気ない発言で師匠を傷付けるスマートコントラクトを実装してみた

はじめに

コインチェックの例の騒動を受け、なんだか僕もブロックチェーンネットワーク上で何かワチャワチャしたくなってみました。ちょうど Ethereum が気になっていたこともあり、ちまたには傑作アニメの発言が流行っていることも助けて、試しに発言ボット的なスマートコントラクトを実装してみることにしました。

ツール群

geth という Go 製 Ethereum CLI が有名っぽいのでこれを利用してみます。 --dev オプションを付与することで開発用の一時ネットワークを構築できるようです。

またスマートコントラクトの実装には Ethereum VM のコードを書くのに一番使われているらしい、 JavaScript っぽい構文にも見える Solidity を使ってみます。

ハマったこと

着手してみたのですが、Solidity 固有の？独特な attribute 指定とかがあってつらい感じでした。また文字列結合が + 演算子でサクッとできたりもしないようでつらみを覚えます。とりあえず今回は solidity-stringutils でお茶を濁します。

成果物

以下になります。

github.com

不用意なメソッドをコールするといろいろな師匠を傷つけてしまいます。

> BBNM.mambo.call()
"Your casual \"mambo\" hurt a samba master."
> BBNM.ole.call()
"Your casual \"ole\" hurt a flamenco master."

ご注意ください。

2018-01-04

第1回WSA研究会に参加してみた振り返り

あけましておめでとうございます。年末年始はほぼ寝て過ごしていました。

表題の通り、去年に第1回WSA研究会というイベントに参加したのでその振り返りなどをさくっと書いていきます。

第1回WSA研究会全体への雑感

発表内容は以下の通りで、名前の通り Web System Architecture の体系化や選定、流行りの Microservices 、ストレージに関する内容が多かった印象です。

websystemarchitecture.hatenablog.jp

イベント中ははてなさんの会議室の一角を利用して割と近い距離感のなか発表者が事前準備したスライドと共に発表し、聴衆が様々なコメントをしていく形式です。発表時間15分,質疑応答15分というスケジュールのなか、発表自体も質疑もなかなかの盛り上がりをみせ、充実した時間になったのではないかと感じます。

このイベントで個人的に興味深かった特徴の一つとして、実稼働させた、あるいはさせようとしているシステムで抱える課題の延長線上に発表内容が立っていることが多かった点があります。（特に matsumotory さんの FastContainer の話などは実稼働しているサービスで評価もしている）

個人的な振り返り

"Reusable TDI infrastructure" と題して、 markdown 付きインフラテストコードを実行する構想について話しました。予稿はこちら（業務と絡めるロジックが思いつかずプライベートで行ってます、ということで内容は個人の意見ですということで）

speakerdeck.com

反省点としてやはり既存技術のサーベイが結構不足していた点があります。後から知ったことですが、 NII が Literate Computing for Reproducible Infrastructure とうたう構想で Jupyter Notebook ベースの Infrastructure as code 基盤を作っているようだったり、関連するソリューションは探せばもっと出てきそうです。

合わせて他の参加者の方へのコメントも積極的に行ってみたつもりなのですが、果たしてそれらがどれほど良いフィードバックになったかどうか。余計なことを言っていないかどうかは内省すべきところかな・・・と感じました。

おわりに

普段あまり意識することの無い観点を意識でき、良い刺激になる会でした。折角こういった議論の場が発足したわけですし、日々の業務の中でも課題の一般化を行いアウトプットをしていくという活動をより多く取り入れ、成果を持ち込めるようにしていきたいところです。

2017-12-22

WSA 研 #1 予稿 "再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み"

第1回WSA研究会という催し物に出る予定でそれ用の予稿を書いたのですが、折角なのでブログにも掲載しておこうと思います。あとで更新するかもです。

再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み

　Infrastructure as code や CI/CD の文化の広がりやインフラ構成の複雑化に伴い、 Test Driven Infrastructure といったインフラ構成をテスト可能にすることで安定稼働を目指す取り組みがなされている。

　Test Driven Infrastructure の実践方法としては 1) Ansible や Chef などといった構成管理ツールに特化したテストツールを使う 2) Serverspec などといった構成管理ツールとは独立したツールを使う方針が考えられるが、前者はツールに非常に依存しかつ独特の DSL を要求される、後者はツール特有の学習コストが要求されるといった課題がある。

　実践方法とは別に、インフラ構成やテストに関する情報を残すことも重要である。これは Google の Site Reliability Engineering の序論に記されている "実装は一時的なものだが文書化された理論は重要" との記述や、 Serverspec が可読性を重要視して実装されたことからも汲み取れる。

　本研究ではこれらの背景を加味しつつ、前述の実践方針の 2) のような構成管理ツールとは独立した形で、かつ低い学習コストで Test Driven Infrastructure を目指す。その実現方法として現在、 Harmonium というツールを試験的に実装している。このツールは現状、 Markdown に埋め込まれたシェルスクリプトを実行するツールである。 Harmonium によるテストコードの実行は bats と似たアプローチであるが、ドキュメントを Markdown で書けてかつ独自の記法を要求しないという差分がある。 Markdown は GitHub などのサービスの WebUI 上でレンダリング可能で運用上親和性も高く、テストコードに対する情報を付与しやすい。またシェルスクリプトを用いることで運用者はシェルの知識をそのまま利用することが可能で、別途 Ruby や Serverspec などのシンタックスを習得する必要がなくなる。現在 Harmonium は golang で実装しており、ツールはワンバイナリで実行可能となるため、 Serverspec をローカルで実行する際に発生する Ruby や依存ライブラリを導入する手間などが軽減される。

参考

　参考にした文書やソフトウェア。本研究で提案する Harmonium は特に Jupyter Notebook に大きく影響を受けている。 Jupyter Notebook はノートブック形式で実装とは別に Markdown で文書を残し、他者と共有ができる。 Jupyter は Cloud Datalab でベースに用いられるなど、データ分析でよく使われるツールとなっている。

　余談だが Harmonium はブラウザ自動テストのためのツール Selenium やアプリ自動テストのためのツール Appium に触発されて命名した。

2017-12-17

RocksDB の mruby binding "mruby-rocksdb" を作った

これは mruby Advent Calendar 2017 17 日目の記事です。

本記事は表題の通りの内容になります。 Advent Calendar のネタがどうしても思い浮かばず、ふと去年の自分の記事を振り返ってきたところ KVS の mrbgem を書いてたので、コードをある程度使いまわして似たようなネタで行くかと考えた次第です。

RocksDB について

Facebook が公開している KVS です。 LMDB とか LevelDB 、 K2HASH と同じような、組み込みの KVS 型 NoSQL って分類できるものかなと思います。

http://rocksdb.org/

特徴としては、フラッシュストレージに対する書き込みのパフォーマンスに配慮されている点があるかなと思います。さらなる詳細に関してはおそらく web 上に資料やベンチマーク結果などがシェアされていると思うのでそれらに譲ることにします。

mruby-rocksdb について

概要

RocksDB の mruby binding です。リポジトリは以下の通り。

github.com

RocksDB が C++11 以降を要求することもあり C で書くのも面倒だな・・・と思ってしまったので C++11 以降前提で実装しています。とは言っても半分くらいのメソッドは Ruby で実装してしまいました。だらしねぇな。

また mruby-k2hash と同様、サポートするメソッドは Ruby の DBM class ライクにしてあります。

使用例

mirb で触ってみるテストです。

$ ./bin/mirb
mirb - Embeddable Interactive Ruby Shell

# open
> db = RocksDB.new("./rocksdb")
 => #<RocksDB:0x101501570>

# store
> db['key1'] = 'value1'
 => "value1"

# fetch
> db['key1']
 => "value1"

> db['key2'] = 'value2'
 => "value2"

# each
> db.each do |k,v|; puts "key: #{k}, value: #{v}"; end
key: key1, value: value1
key: key2, value: value2
 => #<RocksDB:0x101501570>

# delete
> db.delete('key2')
 => nil

# etc ...
> db.to_hash
 => {"key1"=>"value1"}
> db.to_a
 => [["key1", "value1"]]
> db.map do |k,v|; k + ' map to ' + v; end
 => ["key1 map to value1"]

mirb で触ってみるテストでした。

おわりに

次はもっと書いたこと無いタイプの mrbgem 書いてみたいものです。

2017-11-21

文フリで配布するSF小説書いた

#bunfree 文ガクサークル大文妄、2017年11月23日の文学フリマ東京に、出ます。【ウ-77, 78】の合体劇場。ジャンルはSF、短編創作小説集、頒布価格は50円(予定)。
未来でもきっと僕らは、アイも変わらず生き続けてるんだって、そんな風に思うのだ。
— えむばーど@文フリ東京【ウ-77,78】11/23 (@m_bird) 2017年11月15日

こちらで配布される SF 小説集に拙作を寄稿しました。イベント詳細はこちらになります。

モチーフにしたのは認知行動療法とルールベースのフィルタリング処理、そして昨今騒がれている Twitter の凍結騒ぎだったりします。 SF 小説なんて書いたのは人生初で、これらがうまく伝わるか、そもそも読者に伝わるものがあるのかが不安なところですが、もしご興味を持っていただけましたらお手にとってみていただけると幸いです。

なぜ小説を書いたのか

普段得られない体験をしたかったのと、自分が今に至るまでのモチベーションの源泉として何かを作りたいという気持ちが深く根ざしておりそれが(普段ブログに書くような)技術要素以外でも作用するか確認してみたかった次第です。執筆完了した今の状態では、まぁそれなりに得られるものがあったかも・・・というくらいの温度感。

なにはともあれ

みんな今週 23 日木曜日は東京流通センターへ Go!

ブログ・ア・ラ・クレーム

技術的なメモとかライフログとか。

MySQL のテーブル定義から外部キー制約を推測するツールを作った

なぜ作ったのか

実装など

動作例

おわりに

技術書典4にサークル名「まいにちがきんようび。」で暗号通貨とDNSの本を配布します

何気ない発言で師匠を傷付けるスマートコントラクトを実装してみた

はじめに

ツール群

ハマったこと

成果物

第1回WSA研究会に参加してみた振り返り

第1回WSA研究会全体への雑感

個人的な振り返り

おわりに

WSA 研 #1 予稿 "再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み"

再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み

参考

RocksDB の mruby binding "mruby-rocksdb" を作った

RocksDB について

mruby-rocksdb について

概要

使用例

おわりに

文フリで配布するSF小説書いた

なぜ小説を書いたのか

なにはともあれ