質問編集履歴
5
誤字修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -30,7 +30,7 @@
|
|
|
30
30
|
|
|
31
31
|
|
|
32
32
|
|
|
33
|
-
やはりデータが増えれば増えるほどクエリの結果が返ってくる時間が長くなるので
|
|
33
|
+
やはりデータが増えれば増えるほどクエリの結果が返ってくる時間が長くなるので情報が膨大になるほど重すぎて使えないサービスといった状態になってしまうのでしょうか。
|
|
34
34
|
|
|
35
35
|
|
|
36
36
|
|
4
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -6,11 +6,11 @@
|
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
しかし、ユーザ投票による値や、報酬としてユーザにポイントを与えるなど、現時点での
|
|
9
|
+
しかし、ユーザ投票による値や、報酬としてユーザにポイントを与えるなど、現時点での直接的なログから算出可能な結果をオリジナルデータとしてデータベースに持つ意味がわかりません。
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
-
つまり、ユーザやアイテムが持つ現在の票の数やポイントは、操作ログのアクションとして値を持たせ、現在の総評や合計ポイントは動的に取得すればいいと思うのです。
|
|
13
|
+
つまり、ユーザやアイテムが持つ現在の票の数やポイントは、操作ログのアクションとして値を持たせ、現在の総評や合計ポイントは動的に計算して取得すればいいと思うのです。
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
@@ -18,11 +18,11 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
極端な話、メッセージの
|
|
21
|
+
極端な話、掲示板のようなメッセージの書き込みや、ユーザの名前や住所などの個人情報もユーザの操作ログとして「ユーザ」と「アクション」と「値」と「時間」で「誰がいつ何をした」と言った情報で全て管理することができると思います。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
このような設計をし
|
|
25
|
+
しかも、このような設計をした場合アンドゥや、編集履歴、データの差分など、あらゆる情報を手に入れることができると思うんです。
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
|
@@ -30,7 +30,15 @@
|
|
|
30
30
|
|
|
31
31
|
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
やはりデータが増えれば増えるほどクエリの結果が返ってくる時間が長くなるので時間が情報が膨大になるほど重すぎて使えないサービスといった状態になってしまうのでしょうか。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
しかし、その場合はmemcacheやキャッシュテーブルを利用して改善できると思うんです。
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
そういった理由から、データベースでオリジナルデータと呼べるものは基本的に操作ログであり、全てのデータは操作ログから出力するべきなのではないかと思ってしまうのです。
|
|
34
42
|
|
|
35
43
|
|
|
36
44
|
|
3
文章を修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -1,15 +1,37 @@
|
|
|
1
|
-
大規模なシステムに関わったことは
|
|
1
|
+
大規模なシステムに関わったことは無いのですが、メインのデータベースに保存するデータは基本的に操作ログで十分なのではないですか？
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
memcacheでは実現できない高速化
|
|
5
|
+
恐らくmemcacheでは実現できない高速化を図るために、RDBに一時的なキャッシュテーブルを作成するようなことはあると思います。
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
しかし、ユーザ投票による値や、報酬としてユーザにポイントを与えるなど、現時点での値を直接オリジナルデータとしてデータベースに持つ意味がわかりません。
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
つまり、ユーザやアイテムが持つ現在の票の数やポイントは、操作ログのアクションとして値を持たせ、現在の総評や合計ポイントは動的に取得すればいいと思うのです。
|
|
14
14
|
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
もしかしたらこのデータベースにログを保存するという考え方は常識なのかもしれませんが、少なくともRDBにログデータが保存されている現場を見たことがありません。
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
極端な話、メッセージのの書き込みや、ユーザの情報、住所などの情報もユーザの操作ログとして「アクション」と「値」と「時間」で管理することができ
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
このような設計をしていればアンドゥや差分、編集履歴など、あらゆる情報を手に入れることができると思うんです。
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
調べてみると、１つのテーブルに保存できるレコードの容量は、50TB以上（？）と膨大でした。
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
このような設計をした場合、やはりデータが増えれば増えるほどクエリの結果が返ってくる時間が長くなることが予測されますが、だとしてもmemcacheやキャッシュテーブルを利用して高速化ができると思いますのでやはり、データベースでオリジナルデータと呼べるものは基本的に操作ログなのではないかと思ってしまうのです。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
15
|
-
是非アドバイス下さい。
|
|
37
|
+
自分は、何か勘違いしてしまっているような気がしています。是非アドバイス下さい。
|
2
文章を改変
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -2,11 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
memcacheでは実現できない高速化があり、最悪消えても問題ないキャッシュ的なテーブルの作成が必要になることがあるのかもしれませんが、ユーザ投票による値や、商品購入して溜まったポイントなどの現時点での値を直接オリジナルデータとして持つ意味がわかりません。
|
|
5
|
+
memcacheでは実現できない高速化があり、最悪消えても問題ないキャッシュ的なテーブルの作成が必要になることがあるのかもしれませんが、ユーザ投票による値や、商品購入して溜まったポイントなどの現時点での値を直接オリジナルデータとしてデータベースに持つ意味がわかりません。
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
もしかしたら
|
|
9
|
+
もしかしたらデータベースにログを保存するという考え方は常識なのかもしれませんが、少なくともRDBにログデータが保存されている現場を見たことがありません。
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
1
初心者マークをつけた
test
CHANGED
|
File without changes
|
test
CHANGED
|
File without changes
|