こんにちは。ServiceNow担当のSNです。

今回はDatabase Indexについてご紹介します。
Database Indexとは、テーブル内の特定の項目を「探しやすくするための目次」のような仕組みです。
主にリストの表示が遅い場合や、データベースへのクエリがボトルネックになっている処理に対して作成することで、速度の向上が見込めます。

Database Indexの効果(デモ)

実際にその効果を見てみましょう。
前提として、カスタムテーブルを作成し、サンプルデータを50万件登録しました。
その中から”demo99999″という文字列を持つレコードを繰り返し検索します。

ここでのポイントはレコードの更新はしない点です。
先述したとおり、インデックスはあくまでも「目次」のようなものなので、レコードを探す際に真価を発揮します。

では、出力結果を見てみましょう。

合計で53951(ms)かかりました。

続いてクエリで使用される「u_text」のインデックスを作成、キャッシュクリア後に再度実行してみます。

処理時間は279(ms)に短縮されました。大幅に早くなりましたね。
今回の例のように、for文やwhile文の中で繰り返しクエリをする際に特に効果がでやすいです。

Database Indexの作成方法

1. 1. 1. ナビゲーションメニューから[System Definition] > [Tables]を開く

      2. Database Indexを作成したいテーブルのフォームを開く

      3. [Database Indexes]関連リストの[New]ボタンを押下

         

      4. [Available]からインデックスを作成したい項目を選ぶ

         

      5. [Create Index]を押下

      6. 作成完了後に通知を受け取りたい場合は[Email me]を選択し、メールアドレスを入力して[OK]ボタンを押下

         (今回は[Do not notify me]で進めます。)

         

      7. メッセージが表示されるので、再度[OK]ボタンを押下

         

      8. 裏でインデックスを作成するジョブが流れるので、しばらく待って画面を再表示すると、、、

         

   できました！！！！

    

   注意点

   Database Indexは強力な仕組みですが、作成時にはいくつか重要な注意点があります。

   1. Database Indexは慎重に検討してから作成する

      冒頭で述べた通り、Database Indexはテーブル内の特定の項目を「探しやすくするための目次」のようなものです。
      目次は、増やしすぎると管理が難しくなり、場合によっては更新処理(登録・更新・削除)の負荷にもつながります。

      そのため、インデックス追加は「とりあえず貼る」のではなく、まず既存ロジック/クエリの見直しを行い、それでも改善しない場合に検討します。

      ServuceNowには、実行に時間のかかっているクエリを確認する仕組み(Slow Query)や、その結果をもとにインデックス候補を提示する機能(Index Suggestion Engine)も用意されています。
      ただし、提示されている内容はあくまで参考情報であり、そのまま作成すべきかどうかは個別に判断する必要があります。

   2. Task、CMDB系のテーブルでは挙動が異なる

      まず、カスタムテーブルを継承したカスタムテーブルの場合を考えます。

      ・親テーブルと子テーブルは、それぞれ別のテーブルとして管理されます
      ・子テーブルに作成したインデックスは、そのテーブルだけに影響します

      そのため、「このテーブル専用の検索を速くしたい」という目的でインデックスを貼るのは、比較的安全です。

      一方で、TaskやCMDB系のテーブルは仕組みが異なります。
      Taskを継承したテーブルには　Incident、Change、Problem　などがあり、
      CMDB(Configuration item)を継承したテーブルには　Computer、Database、Application　などがあります。

      見た目は別々のテーブルですが、Database Indexはそれらをまとめた親テーブル(Task/CMDB)に対して生成されます。
      つまり、
      ・Incident用に作成したDatabase IndexはTaskに作られ、
      ・Computer用に作成したDatabase IndexはCMDB(cmdb_ci)に作られます

      コンピュータ[cmdb_ci_computer]を継承したカスタムテーブルを例に説明します。

      1件カスタムフィールド[u_comment]を作成したので、こちらにDatabase Indexを作成してみます。

      

      作成した結果がこちらです。

      

      カスタムテーブルのフィールドなのに、Tableは「cmdb」になっていますね。
      カスタムテーブルのフィールドのつもりで作成したインデックスが、CMDB全体にも影響する可能性があるということです。

       

      また、一度スルーしましたが、「a_str_34」って何？「u_comment」じゃないの？　という疑問が出てくると思います。
      ここからは「a_str_34」がなぜ作成したカスタムフィールド[u_comment]とわかるか　についてお話します。

      ServiceNowには、[sys_storage_alias]テーブルというものが存在します。
      ここでは、物理的にどのテーブルのカラムか、どのような命名がされているかを確認することができます。

      実際に今回の例を見てみます。
      Tableに対象テーブル
      Element nameに対象カラムを入れて検索をかけると、、、

      

      Storage aliasから「u_comment」に対応する「a_str_34」を見つけることができましたね。
      以上の例のように、Task、CMDB系テーブルにおけるDatabase Indexでは、エイリアス名という特殊な形で表示される点に注意が必要です。

   3. Database Indexの検索はコツが必要

      Table Definitionから表示されるDatabase Index一覧(v_index_creator)は、
      通常のリストのような検索や絞り込みには向いていません。
      そのため、インデックス数が多い場合は、

      ・Column(エイリアス名)でソート
      ・該当する名前の位置までスクロールして目視確認

      という方法が、現実的な探し方になります。

      これはv_index_creatorの仕様によるものであり、
      検索で目的のインデックスが出てこないのは、バグや操作ミスではありません。

   4. 本番環境での作成タイミングにも注意する

      Database Indexの作成は、
      対象テーブルのサイズによっては一時的に負荷がかかる処理です。
      特に本番環境では、

      ・バッチ処理
      ・DiscoveryやScheduled job

      と重ならないよう、オフピーク時間での実施を検討しましょう。

1. まとめ

   Database Indexは適切に使えば検索やリスト表示を大きく改善できる一方で、
   貼り方を誤ると影響範囲が想定以上に広がることがあります。

   まずは、クエリやロジックを見直し、必要性と根拠を確認できた場合にのみ、
   慎重に追加することが重要です。

   本記事が、
   Database Indexを「気軽に貼る」のではなく、
   「根拠を持って使う」ための判断材料になれば幸いです。