質問編集履歴
3
追記
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -204,7 +204,7 @@
|
|
|
204
204
|
|
|
205
205
|
・特定のデータ群(アカウントのような)を持ち、その中の各項目が時々変化する。
|
|
206
206
|
|
|
207
|
-
・このデータ群は特定urlで指定できるが、変更
|
|
207
|
+
・このデータ群は特定urlで指定できるが、urlは変更、データ群は削除される可能性もある
|
|
208
208
|
|
|
209
209
|
|
|
210
210
|
|
|
@@ -214,11 +214,11 @@
|
|
|
214
214
|
|
|
215
215
|
・特定のデータ群に関するテーブルを作成し、そのデータ群の各項目の変化を時系列的にDB保存
|
|
216
216
|
|
|
217
|
-
・特定のデータ群自体の死活監視のため、「指定urlの変更、削除」等を死活
|
|
217
|
+
・特定のデータ群自体の死活監視のため、「指定urlの変更状況、データ群の削除並びに復活」等を死活監視テーブルに保存
|
|
218
|
-
|
|
218
|
+
|
|
219
|
-
・もし、特定データ群が削除されていたら論理削除で以後クローリングはしない。
|
|
219
|
+
・もし、特定データ群が削除されていたら論理削除で以後クローリングはしない。(時々復活していないか確認するので、非常に優先度の低いデータ群として登録することも)
|
|
220
|
-
|
|
220
|
+
|
|
221
|
-
・指定urlが変更された場合、元の指定urlを持つテーブルから、新urlを検索できそうな関連情報を引き出し、再取得を試みる。
|
|
221
|
+
・指定urlが変更された場合、元の指定urlを持つテーブルから、新urlを検索できそうな関連情報を引き出し、再取得を試みる。そして、再取得が可能、つまり、url変更があれば、死活監視テーブルを更新し、以後新urlでクローリングできるように自動化
|
|
222
222
|
|
|
223
223
|
・特定のデータ群について、特定の項目の変化だけをトリガーとして別の操作を行う(メール通知や別のクローリング処理)
|
|
224
224
|
|
2
目的の明確化
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -184,7 +184,7 @@
|
|
|
184
184
|
|
|
185
185
|
|
|
186
186
|
|
|
187
|
-
### 問題点
|
|
187
|
+
### クラス設計に関する問題点
|
|
188
188
|
|
|
189
189
|
|
|
190
190
|
|
|
@@ -198,6 +198,38 @@
|
|
|
198
198
|
|
|
199
199
|
|
|
200
200
|
|
|
201
|
+
### 対象サイトについて
|
|
202
|
+
|
|
203
|
+
|
|
204
|
+
|
|
205
|
+
・特定のデータ群(アカウントのような)を持ち、その中の各項目が時々変化する。
|
|
206
|
+
|
|
207
|
+
・このデータ群は特定urlで指定できるが、変更・削除される可能性もある
|
|
208
|
+
|
|
209
|
+
|
|
210
|
+
|
|
211
|
+
このようなデータ群に対し、
|
|
212
|
+
|
|
213
|
+
|
|
214
|
+
|
|
215
|
+
・特定のデータ群に関するテーブルを作成し、そのデータ群の各項目の変化を時系列的にDB保存
|
|
216
|
+
|
|
217
|
+
・特定のデータ群自体の死活監視のため、「指定urlの変更、削除」等を死活管理テーブルに保存
|
|
218
|
+
|
|
219
|
+
・もし、特定データ群が削除されていたら論理削除で以後クローリングはしない。
|
|
220
|
+
|
|
221
|
+
・指定urlが変更された場合、元の指定urlを持つテーブルから、新urlを検索できそうな関連情報を引き出し、再取得を試みる。
|
|
222
|
+
|
|
223
|
+
・特定のデータ群について、特定の項目の変化だけをトリガーとして別の操作を行う(メール通知や別のクローリング処理)
|
|
224
|
+
|
|
225
|
+
|
|
226
|
+
|
|
227
|
+
という操作をしたい。
|
|
228
|
+
|
|
229
|
+
|
|
230
|
+
|
|
231
|
+
|
|
232
|
+
|
|
201
233
|
|
|
202
234
|
|
|
203
235
|
うまく、まとめられませんが、ご意見がほしいです。
|
1
途中の追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -10,13 +10,13 @@
|
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
-
勿論、元の質問において、外部ストレージを利用するトランザクションの管理が面倒な方法も破棄した訳ではない
|
|
13
|
+
勿論、元の質問において、外部ストレージを利用するトランザクションの管理が面倒な方法も破棄した訳ではないです。
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
17
|
とりあえず、ここで質問をして元の質問を再編集できるようにします。
|
|
18
18
|
|
|
19
|
-
(元の質問が丸投げ的になっている思って、こう
|
|
19
|
+
(元の質問が丸投げ的になっている思って、このようにしました。)
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
@@ -66,7 +66,7 @@
|
|
|
66
66
|
|
|
67
67
|
・並列化
|
|
68
68
|
|
|
69
|
-
・WEBアクセス時のその他の制御パラメータ(UAなど)
|
|
69
|
+
・WEBアクセス時のその他の制御パラメータの容易な変更(UAなど)
|
|
70
70
|
|
|
71
71
|
|
|
72
72
|
|
|
@@ -92,9 +92,11 @@
|
|
|
92
92
|
|
|
93
93
|
そのため、みなさんがどうしているか意見を伺いたい次第です。
|
|
94
94
|
|
|
95
|
-
|
|
95
|
+
(その会社に直接メールを送りつけて質問してよいのかと・・・)
|
|
96
|
-
|
|
96
|
+
|
|
97
|
+
|
|
98
|
+
|
|
97
|
-
一応、オブジェクト指向についての書籍・文献はいくつか目を通し
|
|
99
|
+
一応、オブジェクト指向についての書籍・文献はいくつか目を通した事があります。
|
|
98
100
|
|
|
99
101
|
|
|
100
102
|
|
|
@@ -108,7 +110,7 @@
|
|
|
108
110
|
|
|
109
111
|
|
|
110
112
|
|
|
111
|
-
そこで、基本的に「クラスにするべき情報は何か」という観点で見ていきます。
|
|
113
|
+
そこで、自分は基本的に「クラスにするべき情報は何か」という観点で見ていきます。
|
|
112
114
|
|
|
113
115
|
|
|
114
116
|
|
|
@@ -140,11 +142,11 @@
|
|
|
140
142
|
|
|
141
143
|
・テキストだけでなく、それに対応する画像等のファイルも取得する場合、スクレピング後に対象ファイルのリンクに対し再びクローリングするため。
|
|
142
144
|
|
|
143
|
-
(ここらへんをヘッドレスブラウザならプログラム上の一行の処理で複数の画像へのリクエストをしてくれそうだが、結局、取得してきた画像がどのテキストに対応するのかを解析する行為がスクレイピングなら
|
|
145
|
+
(ここらへんをヘッドレスブラウザならプログラム上の一行の処理で複数の画像へのリクエストをしてくれそうだが、結局、取得してきた画像がどのテキストに対応するのかを解析する行為がスクレイピングと同様なので、それならヘッドレスブラウザはいらない)
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
146
|
+
|
|
147
|
+
|
|
148
|
+
|
|
147
|
-
・一度クローリングした生のデータを別ストレージに保存して、スクレピング処理させるのは、余計なアクセスが生じそうで、それなら一括処理させるべきという考え
|
|
149
|
+
・一度クローリングした生のデータを別ストレージに保存して、スクレピング処理させるのは、余計なアクセスが生じさせそうであり管理が面倒(ただし、生データが残る恩恵はあるが捨てることにする)、それなら一括処理させるべきという考え
|
|
148
150
|
|
|
149
151
|
|
|
150
152
|
|
|
@@ -152,43 +154,59 @@
|
|
|
152
154
|
|
|
153
155
|
|
|
154
156
|
|
|
155
|
-
|
|
157
|
+
取得・解析クラスから、「スクレピング後の整形データ」や、「画像等の項目の存在確認した情報を保持した状態」を合わせ持つ特定のデータ構造(これをどうするかも悩み中で後ほど説明)を受取り、それをもとにDB問い合わせを行う。
|
|
158
|
+
|
|
159
|
+
|
|
160
|
+
|
|
156
|
-
|
|
161
|
+
・対象データが変化していれば、更新処理
|
|
162
|
+
|
|
157
|
-
|
|
163
|
+
・特定の変更があれば、通知クラスに知らせる、もしくは、特定の変更の通知必要性の確認自体を通知クラスに担当させるべきであり、更新処理後、毎回通知クラスへ更新処理のレコードの差分を送信する
|
|
164
|
+
|
|
158
|
-
|
|
165
|
+
・対象データが消えていれば、その存在確認をするために、DB内の過去の取得データから、対象データに関係する元の特定項目などの情報をDBから取得(これを取得・解析クラスに送信し、取得・解析クラスは対象データの取得をリトライする)
|
|
166
|
+
|
|
167
|
+
|
|
168
|
+
|
|
159
|
-
|
|
169
|
+
#### 通知クラス
|
|
170
|
+
|
|
171
|
+
|
|
172
|
+
|
|
160
|
-
|
|
173
|
+
保存・読出クラスから送信されたDB変更の差分についての情報を解析し、通知必要性を確認する。
|
|
174
|
+
|
|
175
|
+
|
|
176
|
+
|
|
161
|
-
|
|
177
|
+
#### 取得データクラス
|
|
178
|
+
|
|
179
|
+
|
|
180
|
+
|
|
162
|
-
|
|
181
|
+
取得データも、特定の構造を持つので、これを整形するメソッドなどを持たせても良いかもしれません(すると、スクレピングの処理がこちらに移る？)
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
182
|
+
|
|
183
|
+
|
|
184
|
+
|
|
185
|
+
|
|
186
|
+
|
|
187
|
-
###
|
|
187
|
+
### 問題点
|
|
188
|
+
|
|
189
|
+
|
|
190
|
+
|
|
188
|
-
|
|
191
|
+
以上のようなクラス設計をしていますが、これはオブジェクト指向や管理性からどう評価されるのでしょうか？
|
|
192
|
+
|
|
193
|
+
|
|
194
|
+
|
|
189
|
-
|
|
195
|
+
各クラスの役割を見ると、これ以上は分離できないように思えます。また、文献のリンク先の「クラスにするべき情報は何か」という観点で見ると、どちらかというと動詞をクラス化してしまっています。それでも、何かの情報(データ取得状況などの管理状況)を保持しているならクラス化しても問題ないようにも思えます。
|
|
190
|
-
|
|
196
|
+
|
|
197
|
+
|
|
198
|
+
|
|
199
|
+
|
|
200
|
+
|
|
201
|
+
|
|
202
|
+
|
|
191
|
-
|
|
203
|
+
うまく、まとめられませんが、ご意見がほしいです。
|
|
204
|
+
|
|
205
|
+
|
|
206
|
+
|
|
207
|
+
|
|
208
|
+
|
|
209
|
+
|
|
192
210
|
|
|
193
211
|
|
|
194
212
|
|