RDBMSのインデックスサイズを無難に見積もる方法

RDMSを使うからには大量のデータを扱うことが多いです。しかし、システムを運用していく上で、漠然と多いだけでなく、何MBなのか何GBなのか、増加率はどれくらいなのか、を見積もることが大切です。

RDMSのテーブルには型を定義します。型にはそれぞれサイズがあるので、計算は可能です。 INT型なら4byte、DATETIME型なら8byteといった値です。

しかし、VARCHARやTEXT型といった可変長カラムならまだしも、インデックスのサイズを見積もるのはなかなか困難です。 INT型のカラムにインデックスを張ればサイズは2byte！とか決まっていれば計算できるのですが、そうでもないのです。一応計算式は存在していますが、あくまで見積もりの式で、最大でこれくらいになる、という値しか求まりません。

実際私も業務でDBのサイズの見積が必要になって困ったので、インフラのDBチームの人、いわゆるDBのスペシャリストに相談してみました。

すると、「ダミーデータ作って、インデックス調べて、推定レコード数の比を使う」のがベターなようです。

MySQLの場合、各テーブルのサイズを取得することができます。

USE {DB_NAME};

で使用するDBを選択した状態で、次のコマンドを実行します。

select
    table_name, 
    engine, 
    table_rows, 
    avg_row_length,  
    floor((data_length+index_length)) as all_Byte,  #総容量
    floor((data_length)) as data_Byte,  #データ容量
    floor((index_length)) as index_Byte   #インデックス容量
from
    information_schema.tables  
where
    table_schema=database()  
order by
    (data_length+index_length) desc

データ容量というのが型とレコード数から決定される実際のデータで使用している容量、インデックス容量というのがインデックスで使用している容量です。

実際の運用で1000000レコード程度になる見積もりなら、 1000レコードのデータを投入してDBのサイズを求めて、1000倍して見積もり値を算出する、という手法です。

恐らく、ダミーデータも、なるべくなら実際に使われるレコードの一部、というのが理想です。主キー以外はどんな値でもダミーデータとしては成立しますが、カーディナリティが高いのと低いのでインデックスのサイズとかも変わってきたりするのでしょうか。 (そこまではスペシャリストに聞きませんでした。)

意図しないデータ量になって後からストレージの増設が必要にならないようにしっかり見積もっておきたいですね。