調べ物した結果

現役SEが仕事と直接関係ないことを調べた結果とか感想とか

データって一口に言うけど意識しないとまずいのでは


こんばんみAWSの勉強をしていてどうにも「データ」を「データ」のまま適当に認識して取り扱うと、
さっぱり理解が進まない気がしているの自分用に少し整理してみました。その他関連用語が多いので使いどころを含めて。

完全に個人の感覚なのであれですが。

目次

なにが気になったのか?

冒頭のとおり「データ」ってなんじゃ?という疑問。
データといっても、その性質によって名前がつけられています。
・ストリーミング
・キャッシュ
・記録
雑に分けてもこんな感じ。オンプレミスであれば、基本的にPCのメモリかもしくはSSDに打ち込まれるので、
開発する上では特に意識してこなかったんだけど、AWSサービスはインフラに近いところから選定が必要なので、この辺をほっておくとどうにもこうにも立ち行かず。
ちょっと一旦まとめてみようかいね。

「データ」が共通的に持っている性質

・データ構造
・タイムスタンプ
この二つは普遍的で必ず持っている。データ=情報といっても差し支えないかもしれない。
ある特定の時間(タイムスタンプ)における、特定のデータの抽出(データ構造)に名前をつけたものをデータと読んでいる。
Excelファイルもデータ「Excelデータ」、日次の感情や思い出などの記録は「日記」であったり。ここまではそらそうだ間があってあんまりではある。
この辺りは上記「記録」と記述しているが、データの基本的な形となる。

データ種別の判断

データ種別の判断は以下のことで決まっている。
・生存期間
ポイントはデータそのものに生存期間の属性は持っておらず、データを取り扱う方が勝手に決めている。
なので、同じデータ構造、タイムスタンプを持つ「データ」でも取り扱う側からすると「キャッシュ」であったり「記録」であったりする。

ストリーミング

そもそもデータではない。と思っている。ストリーミングにもデータ構造は持っているが、タイムスタンプの形が異なる。
タイムスタンプはその瞬間を切り取っているが、ストリーミングでは永続的に流れ続けている。データの連続がストリーミング。
そのくせにストリーミングデータ。なんていうからタチが悪いなぁなんて思ったりもする。一つのストリーミングは同じデータとして扱うが、
ストリーミングから切り取った一部のデータは同じデータとしては扱はない。同じデータ構造は持っているが。
1つの動画であれば、動画は「開始、終了」を属性に持つデータ構造の「データ」ではあるが、あるタイミングの動画は動画と言わず、
「静止画」というと思う。時間がずれれば「別の」静止画としてあつかう。静止画ももちろんデータ構造を持っている(RGBとか、まぁそのた)

キャッシュと記録

生存期間が極端に短いものを「キャッシュ」という。どの程度短いかはデータを取り扱う側に委ねられる。
1日以上保持するものを「キャッシュ」ということは少ないかもしれないが、それでも場合によりキャッシュと言うことはある。1年だとどうかはわからないが。
キャッシュにはもう少し使う側のイメージによるものがある。
アクセシビリティ
キャッシュの目的は「再利用」にあるので、データを一度保存した後にどこからか「利用」することが前提となる。
「記録」についても再利用は発生することもあるが、キャッシュを用いる場合は「記録」とするよりも「高速」にアクセスすることを求める場合が多い。
「記録」にするまえのデータを「キャッシュ」と呼ぶこともある。
「記録」から別のElastiCacheなどのメモリに展開したものを「キャッシュ」と呼ぶこともある。
dynamoDBなどのストレージに「記録」をしないデータも「キャッシュ」と呼ぶことがある。
いずれもこれは生存期間によって判断しているためで「キャッシュ」をS3などのストレージなどに保存して永続化したタイミングで「記録」となる。
ストリーミングで吐き捨てたデータについて「キャッシュ」と呼ぶことはないが「記録」の判断のためにストリーミングからデータとして取り出すことを
「キャッシュ」する。とは言うかもしれない。

同時編集からの観点

ストリーミング、およびキャッシュを複数のアカウントから意識的にアクセスすることは基本的にはない。同時編集を行う場合「記録」であることがほとんであろう。
したがって同時編集を意識しないといけないのはストレージサービスである
右記urlより、 AWS が提供するクラウドストレージサービス|AWS
S3
EBS
EFS
のこの辺りは抑えておきたい。S3、EFSは並列の読み込みに耐えうるが、EBSは向いていない。
その他は公式QAを参考にされたし
aws.amazon.com
また、ストレージサービスではないがデータの保管場所という観点では各種DBサービスも候補に上がってくる。
(キャッシュという意味ではSQSも近いものがあると思うが)
DBの比較についても公式を
AWS が提供するクラウドデータベース | AWS

キャッシュが曲者

基本的にキャッシュが全てをややこしくしている。キャッシュという観点でいけば、
インメモリに展開しているEC2とELBのスティッキーセッションでも構成なども上がってくる。
完全にクラウドのメリットを享受できるような構成ができればいいが。状況によりそうもいかない時もあるので、手段はなるべく多くしっておいて損はなさそう。
キャッシュについては本当にいろんなところに保管できるので、その時のベストというのを理解するのがなかなかしんどいなぁと感じる。

こんなところか?「データ」の切り口からAWSざっと眺めてみたけど、この方が記憶に定着しやすいかな。
セッションとか、ログイン情報とか。データ構造による切り口で攻めてみるのもありかな。