RDBに保存するデータは基本的に操作ログの情報だけで良いのではないですか？

大規模なシステムに関わったことは無いのですが、メインのデータベースに保存するデータは基本的に操作ログで十分なのではないですか？

恐らくmemcacheでは実現できない高速化を図るために、RDBに一時的なキャッシュテーブルを作成するようなことはあると思います。

しかし、ユーザ投票による値や、報酬としてユーザにポイントを与えるなど、現時点での直接的なログから算出可能な結果をオリジナルデータとしてデータベースに持つ意味がわかりません。

つまり、ユーザやアイテムが持つ現在の票の数やポイントは、操作ログのアクションとして値を持たせ、現在の総評や合計ポイントは動的に計算して取得すればいいと思うのです。

もしかしたらこのデータベースにログを保存するという考え方は常識なのかもしれませんが、少なくともRDBにログデータが保存されている現場を見たことがありません。

極端な話、掲示板のようなメッセージの書き込みや、ユーザの名前や住所などの個人情報もユーザの操作ログとして「ユーザ」と「アクション」と「値」と「時間」で「誰がいつ何をした」と言った情報で全て管理することができると思います。

しかも、このような設計をした場合アンドゥや、編集履歴、データの差分など、あらゆる情報を手に入れることができると思うんです。

調べてみると、１つのテーブルに保存できるレコードの容量は、50TB以上（？）と膨大でした。

やはりデータが増えれば増えるほどクエリの結果が返ってくる時間が長くなるので情報が膨大になるほど重すぎて使えないサービスといった状態になってしまうのでしょうか。

しかし、その場合はmemcacheやキャッシュテーブルを利用して改善できると思うんです。

そういった理由から、データベースでオリジナルデータと呼べるものは基本的に操作ログであり、全てのデータは操作ログから出力するべきなのではないかと思ってしまうのです。

自分は、何か勘違いしてしまっているような気がしています。是非アドバイス下さい。

coco_bauer

2015/11/17 06:56

質問者の「操作ログ」の定義を教えて下さい。「ポイントの現時点での値」と「操作ログ」のイメージが一致しないのです。

行動規範の内容に同意します

回答3件

ベストアンサー

やはりデータが増えれば増えるほどクエリの結果が返ってくる時間が長くなるので情報が膨大になるほど重すぎて使えないサービスといった状態になってしまうのでしょうか。

はい、そうなります。

しかし、その場合はmemcacheやキャッシュテーブルを利用して改善できると思うんです。

キャッシュ系の技術はリアルタイム性を犠牲にして性能を出すものなので、
キャッシュの元になるデータをどのように作りだすかが技術的なハードルになると思います。

そういった理由から、データベースでオリジナルデータと呼べるものは基本的に操作ログであり、全てのデータは操作ログから出力するべきなのではないかと思ってしまうのです。

理論的には可能だと思いますが、現実的にはパフォーマンスの問題があってかなり難しいと思います。
HW/SWのスペックが現在の数百万倍くらいになれば可能なのかもしれません。
40年前のコンピュータの性能では不可能だったことが今は普通に行われていたりするので、
不可能とは言い切れないと思います。

もしかしたらこのデータベースにログを保存するという考え方は常識なのかもしれませんが、少なくともRDBにログデータが保存されている現場を見たことがありません。

アプリケーションのデータとして使うためでは無く、「ユーザの操作履歴を確認/監査する」という要求がある場合は保存することはよくありますが、それはあくまで「ユーザの操作履歴を確認/監査する」ためだけであって、アプリケーション全体の元データとして使うためではありませんね。

投稿2015/11/17 11:06

tanat

総合スコア18713

パフォーマンスが必要な例としては、
例えば友人関係を作れるSNSを作るとした場合、
10万人ユーザが居る場合はだれか一人の友人関係を知るために10万人全員の全操作ログを走査しないといけません。データが全てオンメモリにあって、数千個のCPUがあるような状態であればキャッシュで何とかなるかもしれませんが、それで得られるパフォーマンスは多分500円/月のVPSと似たようなものだと思います。

逆に、将棋の対局などは開始から終了までの差し手を全てログとして保存してそこから常にリアルタイムに現状を表示してもそこまで重くならないはずなので実現可能だと思います。

投稿2015/11/17 19:03

tanat

総合スコア18713