質問編集履歴
3
追記文追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -50,4 +50,12 @@
|
|
|
50
50
|
２：パーティション
|
|
51
51
|
アカウントID毎にパーティションを作成する事でdelete処理をパーティション単位で行う事が可能と考えていますが
|
|
52
52
|
アカウントによっては途中で凍結が行われ、削除されるアカウントが存在し、頻繁に変動をする予定なので
|
|
53
|
-
動的にパーティションを追加、削除をするのは管理として難しいのではないかとゆう考えです。
|
|
53
|
+
動的にパーティションを追加、削除をするのは管理として難しいのではないかとゆう考えです。
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
###追記
|
|
57
|
+
いくつものご回答いただきありがとうございます。
|
|
58
|
+
一度自分で回答内容をそれぞれ試してみたいので、質問欄は少し期間を開けてOpenのままにさせていただきます。
|
|
59
|
+
後に回答していただける方のご意見も全て読ませていただきます。
|
|
60
|
+
ベストアンサーについては、ある程度自分で触った後に私と同じような質問者の方のご意見もふまえて選定させていただく予定です。
|
|
61
|
+
皆さん貴重なご意見ありがとうございます。m(__)m
|
2
具体的な質問内容の修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
### 質問内容の目標
|
|
2
2
|
・１日毎に100億件を超えるデータの更新を行う
|
|
3
|
-
|
|
3
|
+
・大量のデータを高速に取り扱う方法
|
|
4
4
|
### 詳細
|
|
5
5
|
|
|
6
6
|
現在、Twitterアカウントのフォロワー情報を管理するシステムを構築しています。
|
1
文字を見やすく整列
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
|user_table|status_table|
|
|
15
15
|
|:--|--:|
|
|
16
16
|
|id|user_id|
|
|
17
|
-
||follower_id
|
|
17
|
+
||follower_id|
|
|
18
18
|
|
|
19
19
|
user_tableはその他名前等のデータが格納され、idはprimaryな状態です。
|
|
20
20
|
|
|
@@ -30,12 +30,14 @@
|
|
|
30
30
|
status_tableとまったく同じ内容のテーブルをもう一つ作成しています（tmp_status_table）
|
|
31
31
|
|
|
32
32
|
tmp_status_tableに当日のフォロワー状態を格納し、status_tableには前日のデータを格納する事で
|
|
33
|
-
集計を行う際に前日
|
|
33
|
+
集計を行う際に、前日と当日のテーブルを比較する事で対応を考えています。
|
|
34
|
+
(比較の際はWhere文でuser_idを指定しまとめて取得※効率悪いです・・)
|
|
34
35
|
|
|
35
36
|
### 問題点について
|
|
36
|
-
アカウント100万件につきフォロワー数平均１万なので、status_tableではおよそ100億件のデータが格納されており
|
|
37
|
+
アカウント100万件につきフォロワー数平均１万なので、status_tableではおよそ100億件のデータが格納されており
|
|
38
|
+
tmp_status_tableにも約100億件が格納されています
|
|
37
39
|
|
|
38
|
-
集計を確認し終えた際に、前日のデータを全て削除しなくてはならず
|
|
40
|
+
問題として、集計を確認し終えた際に、前日のデータを全て削除しなくてはならず
|
|
39
41
|
当日のデータをtmp_status_tableへ移行した後に当日のデータも全て削除する必要が有る為
|
|
40
42
|
かなりの負荷（200億件のDeleteと100億件のinsert）がかかる事となる為、現実的な速度は見込めないとゆう点が問題として有ります。
|
|
41
43
|
|