すごく古い時代に存在してたトランザクション/マスターの考え方をそろそろ新しいネーミングで復活させるべき時代じゃないかと思い始めた今日この頃

すごく古い時代に存在してたトランザクション/マスター

まだ世の中が磁気テープ装置と磁気ディスク装置(ただし小容量で高額)だったころ
トランザクションデータは磁気テープに書き込んで、夜間バッチで磁気ディスクを更新する時代
この頃のトランザクションデータは今のRDBが持ってるトランザクションと同じような意味だった気がする
＃だって仕事では直接関わってない世代だから詳しく知らないもんｗ

RDB時代のトランザクション/マスターの考え方

トランザクションは更新があるデータ、マスターは更新が少ないデータに変質した
実はマスターデータと言っているデータはある意味トランザクションデータにもなり得るので、実は境目が曖昧
あくまで更新頻度の問題だったり、たくさん参照されるデータって意味でしか使われてない
＃この辺がずっと気持ち悪くて、個人的には嫌いだった(用語としては便利なので使ってた)

これからのトランザクション/マスターの考え方

これからというか、既に起きてる気がするんだけど・・・
トランザクションは"ほぼ追記だけ"していき発生の事実だけを安全に保存
その直後からゆっくりマスターを更新して、トランザクションを処理終了にする
この流れは磁気テープとリアルタイム性が変化しただけの「すごく古い時代に存在してたトランザクション/マスター」と同じって事になる

こんな事を考えた理由を時系列に

AWS環境を触ってるとリアルタイムなデータの発生を即座にRDBで処理するのは止めた方が良いんじゃないかと
スパイクアクセスがあるような環境だと特にRDBには向いてないしなぁ〜って
じゃあ全面的にRDB捨ててDynamoDBか？っていうとRDBの便利な特徴を捨てる気にはなれない
最終的にRDBに入れば良くて、その中間にKinesisとかDynamoDBとかSQSとか置けばスパイクアクセスもある程度耐えれて、データもロストせずにRDBのコストも押さえれて良いなぁ〜
というか、それって昔磁気テープ装置があった頃のトランザクション/マスターに戻ってね？
システムのDB設計とかも実は昔のトランザクション/マスターの考え方とリアルタイム化したマスター更新を組み合わせた方が処理が楽じゃね？
なんか、足回りのいろんなライブラリは既に揃ってね？
じゃあ前に関わったことのあるXXXXはこんな感じでやると・・・あっ、こっちの方が絶対楽になる
というか、データからの情報みたいに階層構造が本来あるよね〜って事か？
なんかすっごい素直な設計になる気がしてきたぞ〜
まぁRDBだけで済むんならこんな設計しなくても良いけど、クラウド環境のRDBって旧来の環境に比べて速いって言えない気がするし
＃当たり前だけどお金を積めば比例して速くなるね
それに中間バッファをAWSが高可用性と一緒に提供してくれてるならそれを使わない理由が見当たらない
AWS恐るべし・・・

そんなこんなで平均スループットを保ちつつ、スパイクアクセスに耐えるには・・・ってアーキテクチャとDBの設計方針が出来たとさ。
めでたしめでたし
＃考えただけで実案件ではやってません（ｷﾘｯ