前回は、さまざまな記憶装置や媒体が生まれては消えながら、多様な記憶デバイスが存在してきたこと、そしてそれらを組み合わせてシステムが構築されてきたことを振り返った。
そして、それらをいかに使いこなすかという点において、「うまく使い分ける」という発想が重要であることを確認した。
では、その使い分けは、何を基準に行えばよいのだろうか。
記憶デバイスの選択は、どうやって行われてきたのか。
基本的な方向性は、「安い」「速い」の二つの軸であろう。
この二つの指標は、長い時間をかけて記憶装置の進化を方向づけてきた。
容量単価は下がり、速度は向上し、それに合わせてシステムの構成も変わってきた。
「より安く、より速く」という判断は、きわめて合理的だったと言える。
しかし実際の運用の現場では、この二軸だけでは説明できない選択が数多く存在する。
高速ではない媒体に、あえて重要なデータを置く。
コストが高くなるにもかかわらず、冗長化を行う。
頻繁に使うわけではないのに、低遅延の領域に配置する。
「安い」「速い」という基準だけでは、これらの判断は説明できない。
では、何が判断を分けているのか。
その起点は、デバイスではなく、データそのものにある。
データの性質からしか説明できない選択がある
同じ容量のデータであっても、扱い方がまったく異なることがある。
それは、データごとに「性質」が異なるからだ。
業務のためのデータ。
記録として残すデータ。
分析のために蓄積されるデータ。
残すこと自体が目的となるデータ。
同じ「ファイル」という形をしていても、その意味は同じではない。
意味が違えば、置き方も変わる。
ここで初めて、ストレージの選択は「速度」や「容量」だけでは決められないものになる。
データは、それぞれ違う目的で存在している
データは、単に保存されるために存在しているわけではない。
必ず「何に使うか」という目的を持っている。
日々の業務を動かすためのもの。
あとから参照するための記録。
将来の分析に備える素材。
長く残し続けること自体が意味になるもの。
目的が変われば、求められるストレージの姿も変わる。
ここで、選択の起点はデバイスから離れ、
「どのようなデータなのか」という問いへと移っていく。
データごとに“待てる時間”が違う
すぐに取り出せなければならないデータがある。
多少待っても問題のないデータがある。
今すぐ使う予定はないが、いつか必要になるかもしれないデータもある。
速度は、単なる性能指標ではない。
そのデータが「どれだけ待てるか」という性質の表れでもある。
ここで初めて、「速いこと」の意味が定まる。
すべてを高速にする必要はない。
必要な場所にだけ速さが求められる。
変わり続けるデータ、変わらないデータ
書き換えられ続けるデータがある。
追記されながら成長していくデータがある。
一度書いたら、そのまま動かないデータもある。
この違いは、見た目には分かりにくい。
しかし、ストレージとの相性を大きく左右する。
頻繁に更新されるデータは、書き込み性能や耐久性を必要とする。
ほとんど変化しないデータは、安定した保管が優先される。
データの「変化の仕方」が、置き場所を決めていく。
失えないデータがある
ここで、もう一つの視点が現れる。
失っても問題のないデータと、失ってはならないデータがある。
この違いは、容量や速度では測れない。
それは「価値」の問題である。
重要なデータほど、守るための仕組みが必要になる。
冗長化やバックアップは、コストの問題ではなく、価値に対する設計になる。
ここに至って、ストレージの選択は、
単なる性能比較から「守るための構成」へと変わっていく。
データは時間の中に存在している
データには寿命がある。
短期間だけ使われて消えていくもの。
数年にわたって参照されるもの。
長く残し続けることが前提となるもの。
時間が変われば、データの価値の形も変わる。
役割が終わったあとに、記録として残る場合もある。
ここでストレージは、「保管場所」という意味を越え、
時間の中でデータを支える器としての役割を持ち始める。
ここまで見てくると、ストレージの選択は、
「どのデバイスを使うか」という問題ではなくなっている。
データがどのような目的を持ち、
どれだけ待てるのか、
どれほど変化し、
どれほどの価値を持ち、
どのくらいの時間の中に存在するのか。
その性質の組み合わせによって、置き場所が決まっていく。
ストレージは「デバイスで選ぶ」のではない。
「データの性質から設計される」のである。
関連記事
関連外部リンク
https://aws.amazon.com/jp/s3/storage-classes/intelligent-tiering
https://cloud.google.com/blog/ja/products/databases/introducing-bigtable-tiered-storage