データベーススペシャリスト試験（DB）を受験してよかった6のこと

 Posted on 2021年10月12日  |  1 minutes  |  193 words  |  morifuji

こんばんは、ちょうど数日前にDBスペシャリストの試験を受けてきました。やっと試験勉強から解放されたのでずっとやりたかったロマンシングサガ3を遊びまくろうと思います

せっかく試験を受けてすぐの状態なので勉強・受験してどうなったか記録に残しておこうと思います

伝えたいこと

RDBについて興味を持っていて勉強してましたが、ついにDBスペシャリストの試験を受けてきました

せっかくなのでDBスペシャリスト試験を受けてよかったこと+αを紹介したいと思います

DBスペシャリストとは？

１．対象者像 高度IT人材として確立した専門分野をもち、データベースに関係する固有技術を活用し、最適な情報システム基盤の企画・要件定義・開発・運用・保守において中心的な役割を果たすとともに、固有技術の専門家として、情報システムの企画・要件定義・開発・運用・保守への技術支援を行う者 https://www.jitec.ipa.go.jp/1_11seido/db.html

午前Ⅰ 午前Ⅱ 午後Ⅰ 午後Ⅱ
試験時間 9:30～10:20 (50分) 10:50～11:30 (40分) 12:30～14:00 (90分) 14:30～16:30 (120分)
出題形式 多肢選択式 （四肢択一） 多肢選択式 （四肢択一） 記述式 記述式
出題数 解答数 出題数：30問 解答数：30問 出題数：25問 解答数：25問 出題数：3問 解答数：2問 出題数：2問 解答数：1問
  • 毎年秋に開催されています
  • 1日で合計5時間もの試験を受けさせられる（のでとてもしんどい）
  • SQLの穴埋め問題や要件にあったテーブル定義を考える問題などがあ割と実務的
  • SQLは「標準SQL規格」というものに則って出題されるため、ベンダー固有な問題は出ない
  • 大体合格率は15%ほど、他のIPAの試験と比べて高い（のでお得だと感じてる）

よかったこと

1. 文章から同時にテーブル定義が雑に頭に浮かぶようになる

午後1・午後2の問題では提示された業務要件を満たすテーブル定義・リレーションを答える問題が頻出するため、だんだん慣れてくる

/img/2021-10-12.png
  • ユーザー
    • 主キー: ユーザーID
    • カラム: ユーザーID, パスワード, 主務グループID
  • グループ
    • 主キー: グループID
    • カラム: グループID, 親グループID,
  • ユーザー兼務グループ
    • カラム: ユーザーID, グループID
  • 予約, ロール…

2.DBの内部的な動作がざっくり分かるようになる

  • 索引探索・表探索によるデータへのアクセス違い
    • （前の勉強会で話した内容）
  • クラスタ化インデックス
    • データの並び順を表すインデックス。その並び順にデータが並ぶ
  • 大雑把なテーブルサイズの見積方法
    • ページサイズ * 見積もり行数 / ((ページサイズ - ページヘッダ) * (1 - 空き領域率） / 平均行長)
  • 大雑把な処理性能の見積方法
    • トランザクション数 * 1トランザクションあたりのデータページアクセス数 * (CPUの1データページ当たりの処理時間 + バッファヒット率 * ストレージへのI/O時間)

いずれも一般的なRDBの話であって具体的なベンダーの話ではない。 なので実際の案件に当て嵌めようとするとベンダー固有の特徴を捉えないといけない。

3.テーブル定義の不備に気づきやすくなる

提示されたテーブル定義の登録時異常や更新時異常を答えさせる問題も多いため、実務の上でも気づきやすくなります。

例えば、「ユーザーの識別はメアド+組織IDで行いたい」という要望が出てきたが、パスワードリセット時の入力項目はメアドだけ →ユーザーを識別するのはメアドだけでは不可能なので組織IDも入力項目として必要であることに気づける

4.クラスタリング・物理分割の使い所・勘所が分かるようになる

クラスタリング

複数台のDBでクエリを実行することができる仕組み。主にクエリのスループットを増やすことができる。ただし慎重に検討しないと逆にスループットが落ちる可能性もある。

物理分割（パーティション）

  • 区分キーと呼ばれるカラムの値に従ってテーブルが別々にされる仕組み。RDBの内部的に別々にされるだけなのでアプリケーションからは1つのテーブルに見える
  • where句に区分キーを指定している場合は参照するテーブルが絞られて高速に動作する。
  • テーブルを別々にする方法はレンジパーティショニング, リストパーティショニング, ハッシュパーティショニングなどの方法がある。
  • 巨大なログのテーブルを年月日の区分キーでレンジパーティショニングするのが鉄板

5.デッドロックの発生リスクをとても気にするようになる

実はデッドロックってめちゃくちゃ簡単に発生するんです…

パターン1

例えば、「ポイント付与申請データを順番に読み取り、各データごとに記載のポイントを該当のユーザーに対して付与する」というバッチ処理があり、具体的に以下の処理をする

  • 1.トランザクション開始
  • 2.select * from ポイント付与申請データ
  • 3.各行に対して update ユーザー set ユーザー.ポイント = ユーザー.ポイント + ポイント付与申請データ.付与ポイント where ユーザー.id = :id
  • 4.50件ずつまとめてコミット

もしも上記バッチ処理を並列に2つ走らせようとするとデッドロックが発生する

パターン2

例えば、「Paypayみたいに、特定の相手に送金する機能」というオンライン処理があり、具体的に以下の処理をする

    1. トランザクション開始
    1. 自身の銀行口座に対してupdate 銀行口座 set 銀行口座.残高 = 銀行口座.残高 - X where 銀行口座.id = :myId
    1. 自身の銀行口座に対してupdate 銀行口座 set 銀行口座.残高 = 銀行口座.残高 + X where 銀行口座.id = :otherId
    1. 2件まとめてコミット

もしも上記オンライン処理が、特定の2者間で同時に起こった場合にデッドロックが発生する

なぜ発生するか

  • トランザクションは、途中で他のトランザクションがデータを変更しないようにするために、変更しようとするデータにロックをかける
  • もし変更時にロックがかかっていたらロックが解除されるのを待つ
  • ということは、パターン1はこんな手順で起こる
    • 1.トランザクションAがユーザーXにポイントを付与
    • 2.トランザクションBがユーザーYにポイントを付与
    • 3.トランザクションAがユーザーYにポイントを付与しようとするがロック待ち
    • 4.トランザクションBがユーザーXにポイントを付与しようとするがロック待ち
  • パターン2はこんな手順で起こる
    • 1.トランザクションAがユーザーXにポイントを付与
    • 2.トランザクションBがユーザーYにポイントを付与
    • 3.トランザクションAがユーザーYにポイントを付与しようとするがロック待ち
    • 4.トランザクションBがユーザーXにポイントを付与しようとするがロック待ち

もっと発生条件は細かく、RDBのISOLATION_LEVELというものに依存していてとてもややこしい

https://bellsoft.jp/blog/system/detail_586

6.「スペシャリスト」を名乗れる

（合格すればの話ですが）「スペシャリスト」を名乗れます

多分お客さんからの信頼の初期値が少し上がるでしょう（初期値だけですが）

最後に

もし興味持った方は、40時間ぐらい勉強すれば取れるのでぜひ受けてみてくださいー

僕は受かってガッキーと結婚します

tech  データベーススペシャリスト試験（DB）  資格  IPA情報処理技術者試験 

See also