fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

SQLアンチパターン読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」に参加しました

2014/8/19(火) SQLアンチパターン読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」に参加してきました。

DoorKeeper
http://sqlap.doorkeeper.jp/events/13963

以下の書籍をターゲットとした読書会なのです。

SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。

参加者は11人かな。新規の方がお一人参加されました。
この日は21章「シュードキー：ニートフリーク(疑似キー潔癖症)」がターゲットでした。

■ 発表
今回は @a_suenami さんが発表担当でした。
シュードキーニートフリーク from Akira Suenami

事業部再編でID付け替えが大変だった体験談や、PostgreSQLのUUIDの話とか、本にない話題が良いですね～

■ ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。
20140819_sqlap1.jpg

以下、個人メモ。
---

■ 自動採番

■ GUID (UUID)
  • UUIDが必要になるほどの厳密さを求められる場面はそれほど多くなく、AUTO_INCREMENTで十分なことが多い。
  • オートインクリメントだと、トラフィックが多くなると採番がボトルネックになって待ち行列に並ぶことがある。
  • Twitterはオートインクリメントを当初採用していたが、性能的に立ちいかなくなった。
  • 連番じゃなくていいいから時系列に並んでほしい、という場合に、UUIDかSERIALか、どちらを選ぶかの勝負になる。
  • UUIDはバージョンが5つある。バージョン１とバージョン４がよく使われる。
    • バージョン１：　MACアドレスとUUIDの生成日時によるもの。時系列性がある。
    • バージョン４：　疑似乱数によるもの。
  • UUIDが重複する可能性は0ではなく、天文学的な大きい数字を分母にすることで重複する確率を0に近づけている。
  • UUIDは16バイト必要なので、容量が大きくなることが欠点。


■ 読書会の前日くらいにQiitaで賑わっていた採番ネタ

■ 採番とソート順序
  • SELECT文で複数件を取得する際、必ずしもInsert順や採番順に並ぶとは限らない。
  • MySQLのInnoDBはクラスタインデックスなので大体は挿入順に表示されるが、MyISAMはそうとは限らない。
  • 挿入順序と表示順序をわけるため、表示順序制御用のカラムを追加することがある。
  • あとは、更新日付のカラムでソートする等。


■ 採番値と業務上の意味付け
  • 採番されたIDが顧客に見えると、とんでもないことになることがある・・・
  • 「社長はIDが１じゃないとダメだから、IDを更新して」みたいに、採番IDに職群等級を反映させようとしたり・・・
  • なので、自動採番されたIDは顧客から隠して、顧客に見せるためのIDを別に用意することがある。
  • これは本章の最後にもあるように、「技術でなく、コミュニケーションの問題」である。


■ システム統廃合と採番
  • システムの統廃合があると、IDが破綻することが多い。
  • システム移行で新旧システムを並行稼働させる場合、どちらにも採番しないといけないので大変・・・
  • 新システムの方はIDを100万から開始で連番を振る、といったように、範囲で新旧を分けることはよくやる。
    • ただし、欠番が発生する。
    • 範囲の設計をミスると新側が旧側の採番に追いつかれたりとか・・・・ｗ


■ マルチテナントアーキテクチャと採番
  • マルチテナントアーキテクチャの場合、同一テーブルに複数テナントが同居するので、テナントIDとかカンパニーIDで分ける。
  • そのため、各社がIDを奪い合って、必ずしも連番にはならない。
  • 他にも、契約会社ごとに採番テーブルを用意しないといけなかったりすることがある。
  • 結果として、５章のEAVとかになることがある・・・


■ シーケンスブロックのアーキテクチャパターン
  • まあまあ連番であってほしいけど並行性も高くしたい、という場合に使用できる。
  • 複数のノードを用意し、各ノードがIDをブロック（例えば10個とか）の単位で事前に採番し、キャッシュしておく。
  • クライアントは、各ノードに採番を依頼する。ノードが複数あるので、採番のアクセスを散らすことが可能。
  • ノードの採番キャッシュが尽きると、再度、そのノードは複数のIDをブロックとして纏めて採番し、キャッシュする。
  • 各ノードが1回で確保するIDのブロック幅は調整可能。
  • 利点は、ノードを複数用意することで一列待ちを発生させないようにできること。
  • 欠点は、シャットダウンするとキャッシュにある採番値が消えるので、欠番が発生すること。なのでブロック幅で調整する。
  • ググると、J2EEデザインパターンの「PK Block Generatorパターン」に似ているっぽい？


■ I/O競合の低減
  • 採番もI/O競合の低減が重要だが、I/O競合の低減を目的とした技術としてOracleの「逆キーインデックス」がある。
  • 採番テーブルをハッシュパーティションにすることで、論理的には連番だけど物理的にI/Oを散らすことが出来る。


■ 行のナンバリング（21.5.1節）
  • Limit句はSQL標準ではないが、使い方が簡単なので多くのDBMSに採用された。
★感想：
弊社のフレームワークにも、欠番を許す採番部品と欠番を許さない採番部品の2種類があります。
その使い分けについてはこれまであんまり考えたことがなかったのですが、この章を読んで腑に落ちた。
「擬似キーの欠番は埋めない」と言い切ってる点、あと、上司の説得の仕方まで言及してくれている点が秀逸。
あと、最後の節でコミュニケーションにまで解決策として言及している点が素晴らしいですね。
他にも、擬似キーと自然キーの使い分けについても考えさせられたりと、とても勉強になりました。

今回で21章が終わり、だいぶ終わりが見えてきた感じです。
参加者のみなさま、ありがとーございました。


■おまけ：過去の「SQLアンチパターン読書会」ブログ

1章：SQLアンチパターン読書会 「ジェイウォーク」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-65.html

2章：SQLアンチパターン読書会 「ナイーブツリー」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-70.html

3章：SQLアンチパターン読書会 「IDリクワイアド」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-73.html

3章：SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-77.html

4章；SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-84.html

5章：SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-90.html

6章：SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-94.html

7章：SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-97.html

8章：SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-105.html

9章：SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-109.html

10章：SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-115.html

11章：SQLアンチパターン読書会 「ファントムファイル」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-118.html

12章：SQLアンチパターン読書会 「インデックスショットガン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-121.html

13章：SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-128.html

14章：SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-130.html

15章：SQLアンチパターン読書会 「ランダムセレクション」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-133.html

16章：SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-134.html

17章：SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-136.html

18章：SQLアンチパターン読書会 「インプリシットカラム」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-138.html

19章：SQLアンチパターン読書会 「リーダブルパスワード」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-140.html

20章：SQLアンチパターン読書会 「SQLインジェクション」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-144.html


アジャイルサムライ横浜道場　特別編「エンジニアのための現場で使えるコミュニケーション 〜チーム作り〜」に参加しました

2014/8/5(火) アジャイルサムライ横浜道場　特別編「エンジニアのための現場で使えるコミュニケーション 〜チーム作り〜」に参加してきました。

DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/12146

以下の書籍をターゲットとした勉強会？なのです。

アジャイルサムライ−達人開発者への道−アジャイルサムライ−達人開発者への道−
(2011/07/16)
Jonathan Rasmusson

商品詳細を見る


場所はいつもの横浜市西公会堂　2号会議室です。
参加者は12人くらいでしょうか。
今回は久々の特別編ということで、コミュニケーションやチーム作りに関するワークショップをやりました。
ファシリテータはライフ・コーチの「ちば たけし」さんと「かぜはれ けいいち」さんです。

以下、個人メモ。


■　チームの成長プロセス
Forming → Storming → Norming → Transforming の4段階あるとのこと。

（引用：日経ビジネスオンライン「最強組織を作るチームビルディング術」）

Formingは「コミュニケーションの量」、Storimingは「コミュニケーションの質」、Normingは「互いの合意」、Transformingは「互いの祝福」がポイントだそうな。

また、ワークショップで成長させるためのモデルとして、「Kolbの経験学習サイクル」というものもあるそうな。

■ ワークショップ
ということで、今日のテーマであるチームビルディングを体験するため、さっそくワークショップをやりました。
お題は、「古新聞紙を使って、15分間でペーパータワーを作る」です。指示は、たったこれだけ。
4人くらいのチームを３つ作り、各チームでお題に取り組みました。

ウチのチームは、「とりあえず、まずタワーらしきものを作ってみて、そこからどう改善するか考えよう」という方針で行きました。
まず作ってみて、そっからフィードバックを得て改善に繋げる、という考えです。
というのもウチのチームは全員、マシュマロ・チャレンジの経験者だったので、タワーを作る難しさを肌で知っていたのもあるのかと。
あと、評価基準としてはひとまず「美しさ」ではなく「高さ」としました。
これは特に指示が無かったので、チームで最初に合意しておきました。

・・・んで、ウチのチームが作り上げたもの！じゃじゃーん！
20140805_yokohamadojo1.jpg

三角柱となるよう新聞紙を折り、上から見ると六角柱になるように、三角柱を交互に乗せる方式です。
この方式のポイントは、シンプル、というとこですかね。
比較的早い段階で、チームで合意してこの方式でタワーを組み立てました。
シンプルであるため、組み立ても比較的早く終わり、フィードバックから試行錯誤する時間も確保することができました。
なかなかの出来栄えだと思います。

さて、他所のチームはというと・・・

お隣さんのチームの成果物！
20140805_yokohamadojo2.jpg

カオスｗ
メンバー各々が個別に工夫を重ねて、最後に無理やり合体した感満載です。
このタワーは、ウチのチームと対極のような感じですねー

そして3つ目のチームのタワーはというと・・・
20140805_yokohamadojo3.jpg

まさかのマシュマロチャレンジ古新聞版ｗ
新聞紙を細く丸めて、それら3本を新聞紙の帯で縛って束ね、三脚のようなオブジェクトを組み合わせる構造です。
これは斬新だ・・・
■ 共有タイム

ワークショップ終了後、コーチのお二方が参加者に問いかける形で、チーム間の共有の時間が取られました。
そんとき出た意見は下記参照。

■ 開始時の状況はどうだったか？
  • 「とりあえずやってみよう」という感じ

■ グループで何を共有したか？
  • 三角柱を重ねて作ろう
  • 「高さ」を目指そう

■ 終わった時の状況は？
  • チームで目的を共有できた。
  • ウチのチームはシンプルだけど、他の２チームは複雑。仕様変更とか無理でしょｗ
  • 隣のチームは、メンバーがひたすら手を動かして、バラバラに作っていたとのこと。
  • 隣のチームは、「高い」ではなく「面白い、楽しい」を目指した、とのこと。

■ 手を動かしながら、何を見ていたか？
  • タワーそのもの
  • 作業の結果を見てた
  • 他の人の作業状況を見てた

■ リーダーはいたか？
  • ウチのチームは三角柱を作って積み上げる単純作業なので、リーダーは必要なかった。
  • 細い棒を束ねたチームは、リーダーっぽい人がいたとのこと。

■ まとまりはあったか？
  • ウチのチームは比較的、まとまりがあった。
  • 隣のチームは、まるで纏まってなかったとのことで、３歳児が寄せ集まって作った感じ、とのこと。
■ 実際の現場での取り組み

次は、実際の現場でのチームビルディングについて、各チームごとにディスカッションしました。
そんとき出た意見は下記参照。
  • 人数が少ない時は暗黙知で行けたが、人数が多くなると、ストーミングの状態になった。
  • ストーミングからノーミングへ推移する上で、暗黙知を形式知にして見える化したのが効果的だった。
  • Qiita:Teamというツールを使って情報をチームで共有した。
    • チームで共有する際は、「自分はこう思う」的なことをまずwikiに書いて「ポエム」というタグを付けるようにしている。
    • それを見て良いと思ったら「いいね」を付けるような仕組みを導入した。
  • 人数が少ないと、ストーミングとノーミングの期間が短いように思う。
    • 本当に？それはまだフォーミングの段階なのでは？
  • お互いの強みを共有することが大事。
  • 相手のことがわかったからといって、上手くいくとは限らない。
■ ワークショップをやる上でのポイント

ワークショップをやる上で、いくつかポイントがあるそうです。
  • 明確な目標を掲げる。
  • どんなプロセスを参加者に経験してほしいかを決めておく。
  • 意図的な介入をする。（敢えてストーミングの状況を作り出してみるとか）
■ その他、お役立ち情報や宣伝など


その他、スライドで紹介されていた理論やプロセスがいくつかあった↓。調べてみよう。
  • SL理論
  • PM理論
  • エゴグラム
  • MBTI
■ 感想：
久々の特別回でしたが、楽しかった～
マシュマロチャレンジみないな感じで、各チーム、ワイワイガヤガヤと手を動かしたりしてｗ

あと、チームビルディングに関するいろんな情報を仕入れたり意見交換できたので、これも有意義でした。
チームビルディングはアジャイルに限らず使えるものなので、今回得た知識を活かせるチャンスは多いと思う。
この日のスライド、復習のために是非公開してほしいです。

コーチのちばさんとかぜはれさん、スタッフのみなさん、参加者のみなさん、ありがとーございました。

-->