mysql.dataとsystem.data

この2つのデータベースの構造は、まったく同じです：

CREATE TABLE IF NOT EXISTS [metric_master] (
   [metric_id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT UNIQUE,
   [metric_desc] TEXT ASC UNIQUE )

CREATE TABLE IF NOT EXISTS [snapshot_master] (
   [timestamp_id] INTEGER NOT NULL,
   [metric_id] INTEGER NOT NULL,
   [metric_now] TEXT,
   [metric_diff] TEXT,
   PRIMARY KEY (metric_id, timestamp_id))

CREATE INDEX IF NOT EXISTS [timestamp_id_index] ON [snapshot_master] ([timestamp_id])

CREATE TABLE IF NOT EXISTS [timestamp_master] (
   [timestamp_id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT UNIQUE,
   [server_timestamp] INTEGER,
   [server_start_time] INTEGER,
   [server_uptime] INTEGER,
   [server_uptime_diff] INTEGER,
   [server_is_connected] INTEGER)

  CREATE INDEX IF NOT EXISTS [server_timestamp_idx] ON [timestamp_master] ([server_timestamp])

これからの説明を理解する上で、最も大事なのは、[snapshot_master]テーブルと[timestamp_master]テーブルの両方にある[timestamp_id]列です。そこで、MySQLとInnoDBでは、整合性と明瞭性を確保するために、[snapshot_master]から[timestamp_master]とを関連付ける外部キーを作成します。そして、この2つをクエリでJOINするか、SUBQUERYを使用します。

以上の基本的機能について解説します：

• SQL Diagnostic Managerがある種（Linux/procフォルダーからOSメトリックを取得）のSHOW VARIABLES/STATUSのようなステートメントを送信するたびに、現在の時刻に関する情報とともに、1行が“timestamp_master”テーブルにINSERTEDされ、そのステートメントで取り出されたメトリックが[snapshot_master]にINSERTEDされます。“snapshot_master”テーブルには、メトリックの詳細情報が保存されています。[timestamp_id]列は、メトリックのその時点の状態を識別します。また、SQL Diagnostic Managerデータベースのタイムスタンプは、unix_timestampsです。
• 実際には、必ずしもいつも[snapshot_master]にINSERTするわけではありません。何かがそのメトリックにINSERTEDされた後に、特定のメトリックが変更された場合のみ、再びINSERTを実行します。そのため、どこか特定の時点のメトリックの値を知りたいときは、その特定のメトリックの特定の時刻より前に保存された最新の値を探す必要があります。
• 最後に、[snapshot_master]には、メトリック名がないので注意してください。あらかじめサーバーがどのメトリックを返すかは、サーバーの詳細情報（バージョンと構成）によって異なるため、それを予測することはできません。また、サーバーがアップデートされることもあります。さらに、ディスク スペースを節約するため、テキスト説明が保存されるのは1回だけです。そのため、[snapshot_master]にあるのは、[metric_master]テーブルのテキスト説明を参照する[metric_id]列の番号だけです。したがって、クエリでメトリックの名前を返す場合や、メトリック名をWHERE句で使用する場合は、クエリで[metric_master]テーブルも参照する必要があります。SHOWステートメントを使い慣れていてそれが返す情報がわかるようになれば、[metric_master]テーブルの各行の意味も簡単に理解できます。

注意

ここで‘メトリック’は、SHOWステートメントで返る離散値の意味で使用しています（SHOW GLOBAL VARIABLES、SHOW GLOBAL STATUS、SHOW SLAVE STATUSなど）。SQL Diagnostic ManagerがWebインターフェイスで実行する計算は、どのような計算でも保存の後であり、前ではありません。ただし、メトリックをINSERTEDする場合は、同じメトリックについてその最新の保存値を検索して、差分を計算するため、保存前に計算を1回実行します。現在値と、この差分の両方とも保存されます（それぞれ[metric_now]列と[metric_diff]列に）。

以上のすべての処理がクエリで実行される様子を、わかりやすい例で以下に示します：

これは、グラフを追加するために実際に実行するクエリの例（サイズの大きなSQLiteデータベースに最適化したとき）です。

SELECT metric_now
FROM snapshot_master
WHERE snapshot_master.metric_id = my_metric_id
   AND snapshot_master.timestamp_id IN(
      SELECT MAX(timestamp_id)
      FROM snapshot_master
      WHERE metric_id = my_metric_id
      AND timestamp_id <= (
         SELECT MAX(timestamp_id)
         FROM timestamp_master
         WHERE server_timestamp <= my_metric_timestamp)
   )

実際には、SQLiteサポートでは、SUBQUERIESの使用を推奨し、ほとんどの場合、サイズの大きなデータベースで最大のパフォーマンスを発揮するため、SQLiteとのJOINSは推奨していません。このことは、私達が、同じ結果を返すさまざまなクエリのプロファイリングで経験したことでもあります。

udo.data

これは、カスタムSQLオブジェクト（CSO）のデータを保存するデータベースです。このデータベースには、3種類の表があります -  Snapshot_master、Column_master、timestamp_master。

CREATE TABLE [column_master]
   (id INTEGER NOT NULL PRIMARY KEY,    
    timestamp_id INTEGER NOT NULL,     
    udo_id INTEGER NOT NULL,    
    key_column_value VARCHAR(255),    
    column VARCHAR(255),
    UNIQUE([udo_id], [key_column_value], [column], [timestamp_id]));

CREATE TABLE [snapshot_master] ([timestamp_id] INTEGER NOT NULL,
   [metric_id] INTEGER NOT NULL,                                            
   [metric_now] TEXT,                                            
   [metric_diff] TEXT,                                            
   PRIMARY KEY (metric_id, timestamp_id));

CREATE TABLE [timestamp_master] (
   [timestamp_id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT UNIQUE,
   [server_timestamp] INTEGER,                                            
   [server_start_time] INTEGER,                                             
   [server_uptime] INTEGER,                                            
   [server_uptime_diff] INTEGER,                                            
   [server_is_connected] INTEGER, [udo_id] INTEGER);

events.data

このデータベースには、SQL Diagnostic Managerのイベントに関する情報を保存します。

CREATE TABLE [events]  (id INTEGER PRIMARY KEY AUTOINCREMENT,                                    
   first_seen INTEGER(5) NOT NULL,                                     
   last_seen INTEGER(5) NOT NULL,                                     
   down_count INTEGER(5) NOT NULL DEFAULT 0,                                     
   server_id VARCHAR(255) NOT NULL,                                     
   server_name VARCHAR(255) NOT NULL,                                     
   group_id INTEGER(5) NOT NULL DEFAULT 0,                                     
   counter_id INTEGER(5) NOT NULL DEFAULT 0,                                     
   grp VARCHAR(255),                                     
   name VARCHAR(255),                                    
   sampling_time_frame VARCHAR(255),                                     
   type INTEGER NOT NULL DEFAULT 0,                                     
   threshold VARCHAR(255),                                     
   value VARCHAR(255),                                     
   advice TEXT,                                     
   mail_alert VARCHAR(10) NOT NULL DEFAULT '',                                     
   down_count_override INTEGER(5) NOT NULL DEFAULT 0,                                     
   notify_stable_override VARCHAR(10) NOT NULL DEFAULT '',                                     
   smtp_alert_cnt INTEGER(5) NOT NULL DEFAULT 0,                                     
   snmp_alert_cnt INTEGER(5) NOT NULL DEFAULT 0,                                     
   ignored_timestamp INTEGER NOT NULL DEFAULT 0);

CREATE TABLE [timestamp_master](
   [timestamp_id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT UNIQUE,
   [server_timestamp] INTEGER UNIQUE);