データは天体と同じように重力を持ち、アプリケーションやサービスを引きつけるのだろうか。VMwareのDave McCrory氏は2010年、ブログでこのデータの重力という概念の素案を発表したが、最近、この考えを数学的に定義した。DataGravity.orgという新しいサイトで、氏はデータの重力の公式を概説し、コミュニティにこの公式を検討し、実際に使ってみてほしいと呼びかけている。
データの重力についての2011年の記事でMcCrory氏はこの概念の基本を説明している。
データの重力とはデータは質量を持っているということに関する理論です。データ(質量)が蓄積されると、重力が発生します。データの重力はサービスやアプリケーションを引きつけます。サービスやアプリケーションがデータにアクセスする時に広い帯域幅や低遅延を求められることが引力を生み出します。
このデータの重力の法則はコミュニティで大きな反響を起こした。最近開催されたGigaOM Structureやその他のカンファレンスでしばしば議論の対象になり、あなたのデータにとって"データの重力"は何を意味するかという記事も書かれた。この記事ではJon Brockmeier氏が巨大な重力を生み出すかもしれないデータストレージへ、よく考えずに投資することに注意を促している。
iTunesのような1人が使うアプリケーションにしろ、企業全体が関わるプロジェクトにしろ、データの重力について考える必要があります。一度データが生まれたら、重力場を除去するのは大変です。
データの重力が強くなればなるほど、データストレージソリューションの選択には注意が必要です。一度、大量のデータがあるストレージにたまったら、別のストレージに移行するためのコストを正当化するのは(不可能ではないにしろ)難しいです。
DataGravity.orgで、McCrory氏はデータの重力の法則を定量化する方法を説明している。手始めに、氏はデータの質量を計算に取り組んだ。
重力を把握するには質量を計算する必要があるということを学びました。物理学ではたいしたことはないのですが、質量をデータの重力のような抽象的な概念に適用するのはとても難しいです。試行錯誤した結果、データの質量についての公式とアプリケーションの質量についての公式を生み出しました(両方とも、今後変更する可能性はあります)。
データの質量はデータの大きさ(データのサイズ、単位はメガバイト)とデータの密度(データの圧縮率)の乗算で求める。
また、アプリケーションの質量はアプリケーションの大きさ(メモリ使用量とディスク使用量の合計)とアプリケーションの密度(メモリの圧縮率とディスクの圧縮率とCPU使用量の合計)の乗算で求める。
また、データの重力のネットワークに対する影響を考慮するため、ネットワークの遅延、帯域幅、秒間のリクエスト数、リクエストの大きさの平均を表す変数が組み込まれている。氏はInfoQのインタービューに答えて、多くの変数を検討し、最終的には捨てたことを明かした。データの質量に対する作成/読み取り/更新/削除の処理の影響やストレージの種類も公式に反映しようとしたが、最終的には次の公式がデータの重力の重要な側面を捉えているという結論に達した、と言う。
氏の考えでは、この公式で算出される数値はデータが存在しているネットワークに対して相対的だ。氏によれば、ひとつのネットワークがひとつの宇宙であり、あるデータの質量はある特定の宇宙の中に存在する。同じネットワークに属するデータの重力は効果的に比較できるが、異なるネットワークに属するデータの重力を比較する方法については、McCrory氏も、まだ十分な情報が得られていない。
DataGravity.orgには、データの重力の使い方がいくつか紹介されている。
重力を生み出すデータに引きつけられる要因(データの重力の増加)
- アプリケーションやサービスが低遅延を必要とする
- アプリケーションやサービスが広い帯域幅を必要とする
- より大きなデータの質量をよりすばやく作成したい
- HPCを利用している
- Hadoopやリアルタイム処理を利用している
重力を生み出すデータに抵抗したり、重力を生み出すデータから遠ざかる要因(データの重力の減少)
- ロックインされるのを避けようとすること
- アプリケーションの移植性
- 遅延の増加や帯域幅の減少に対する弾力性(つまり、可用性)
データの重力とデータの質量には他の使い方もある。
- データの質量を比較してデータの移行やデータの配置場所を決定する
- データの質量の増減を見積もる
- データの重力の増加を見積もる
この公式は現在も手が加えられている。McCrory氏は実世界での適用例を積極的に探している。