teratail
回答率
85.35%
teratail header banner
teratail header banner
質問するログイン新規登録
トップNode.jsに関する質問node.jsにてjsonファイルをデータベースとして使うデメリットを教えてください

編集履歴

回答編集履歴

3

冗長な記述は削除した

2021/01/19 02:59

投稿

miyabi-sun
miyabi-sun

スコア21203

test CHANGED
@@ -1,48 +1,88 @@
1
1
  具体的な所として、
2
2
 
3
- 現状で全く問題がないのであればそのままでも大丈夫です。
3
+ 現状で問題がないのであればそのままでも大丈夫です。
4
-
5
-
6
-
4
+
5
+
6
+
7
- しかし、衝突に遭遇して
7
+ しかし衝突に遭遇して「排他制御」が必要と感じたら、
8
-
9
- 「これはファイルのロックが必要だろうな」と感じるようになってきたら
10
8
 
11
9
  それを実装する時間を使ってデータベースを勉強して使いましょう。
12
10
 
13
11
 
14
12
 
15
- データベースは一度勉強してしまえば良いだけなので、
13
+ データベースはファイルの読み書きに特化したソリューションですので、
16
-
17
- あちこちでファイルのロック処理を作るより遥かに全体的なコストは安く済むでしょう。
14
+
18
-
19
-
20
-
21
- > node.jsを使って小規模なシステムを制作（勉強）しています。
22
-
23
-
24
-
25
- 貴方が一生その規模で満足出来るなら問題ありません。
26
-
27
- 特に学生・社内SEならばデータベースの存在意義が全く理解出来ないのは当然で、
28
-
29
- 大仰なデータベースを持ち出すべき場面もそんなにありません。
30
-
31
-
32
-
33
- 問題になるのは、貴方が所謂Webサービスを立ち上げる場合です。
34
-
35
- 特に他のITエンジニアと協業する規模になってくると
15
+ 多くのWebエンジニアに歓迎され、受け入れられています。
16
+
17
+
18
+
36
-
19
+ 仮に貴方がWebサービスを開発・運用しているチームに改めて参入した場合
20
+
37
- JSONによるファイル管理は選択肢から外れる事になるでしょう。
21
+ ほぼ確実に何らかのデータベースは導入済みであるでしょう。
22
+
38
-
23
+ その場合はしかたない、学習することになります。
24
+
25
+
26
+
39
-
27
+ 実際のプロジェクトのコード読めばどうやって利用しているのか読めるので、
28
+
40
-
29
+ 意外と一瞬で使えるようになるものです。
30
+
31
+
32
+
41
- ---
33
+ ---
34
+
35
+
36
+
42
-
37
+ まずWeb上で情報を預かる場合の責任についてです。
38
+
39
+
40
+
43
-
41
+ 貴方が仮に恋人や友人とLineで会う約束をしていたとします。
42
+
44
-
43
+ しかし当日待ち合わせ場所に来ない……
44
+
45
+ よく調べてみたら、Lineのシステムの手違いでその約束が消えてて
46
+
47
+ 相手が知らないまま当日を迎えてしまっていて電話で発覚した。
48
+
49
+ 許せますか？
50
+
51
+
52
+
53
+ Web上で情報を預かるということは
54
+
55
+ 「例え無料だとしてもそれなりの責任が伴う」事を意味します。
56
+
57
+
58
+
59
+ この辺は「データの価値」をどの程度見積もるか評価・設計をしてください。
60
+
61
+ Lineは会社が潰れるレベルの価値に設定しているかと思います。
62
+
63
+ なのでそういう問題が起こらないよう、よく設計を練って堅牢なシステムを築いているはずです。
64
+
65
+
66
+
67
+ 100人のユーザーが訪れて同時に読み書きを要求して来ても
68
+
69
+ データが消えない事を保証出来なければならない。
70
+
71
+ 更にWebの利用者は目が肥えているので時間の掛かるサービスはすぐに「使えない」と見切ります。
72
+
73
+ 速度も重要視されます。
74
+
75
+
76
+
77
+ こういう世界で闘う事になる可能性は覚悟しておきましょう。
78
+
79
+
80
+
81
+ ---
82
+
83
+
84
+
45
- Node.jsはシングルスレッドですので、
85
+ Node.jsはシングルスレッドですので1プロセスで動作させている場合は問題は起こらないでしょう。
46
86
 
47
87
  見た目は並列処理しているように見えても
48
88
 
@@ -60,23 +100,27 @@
60
100
 
61
101
  ファイルが肥大化すれば処理速度の面で悩まされる事になるでしょう。
62
102
 
63
- その場合はファイルを分けたり、ディレクトリを切ったりすることである程度は解消できそうですね。
64
-
65
-
66
-
67
- アイデアとして「書き込みのリクエスト」を受けた場合
68
-
69
- 提示報告みたいな仕組みで空き時間を利用して、
70
-
71
- ファイルに書き出していくような仕組みを上手く構築してやれば
72
-
73
- バズって利用者がアホ程伸びない限り上手くやっていくような仕組みを低コストで実現出来るでしょう。
103
+ 一般的に取られる下記のような手段を採用すると牙を向いて襲いかかってくる事になるでしょう。
74
-
75
-
76
-
104
+
105
+
106
+
77
- しかし「サーバマシンを複数台に増やす」とか
107
+ - サーバマシンを複数台に増やす
78
-
108
+
79
- 速度が問題になったから[fs.writeFile](https://nodejs.org/api/fs.html#fs_fs_writefile_file_data_options_callback)を使おうと判断した瞬間牙を向いて襲いかかって来ることになるでしょう。
109
+ - [fs.writeFile](https://nodejs.org/api/fs.html#fs_fs_writefile_file_data_options_callback)を使う
110
+
111
+
112
+
113
+ ディレクトリやファイルを個別に管理したり、ファイルの書き込みを遅延させたり
114
+
115
+ アイデア次第で結構頑張れると思いますが、それって目的見失ってませんか？
116
+
117
+ ファイルの整合性の担保が目的じゃないですよね、元々やりたいことがあったのでは？
118
+
119
+
120
+
121
+ ファイルの整合性の担保は、
122
+
123
+ それ自体を責任取って面倒みてくれるデータベースに任せましょうよって話です。
80
124
 
81
125
 
82
126
 
@@ -92,51 +136,11 @@
92
136
 
93
137
 
94
138
 
95
- Web上で情報を預かる場合の責任についてです。
96
-
97
-
98
-
99
- 貴方が仮に恋人や友人とLineで会う約束をしていたとします。
100
-
101
- しかし当日待ち合わせ場所に来ない……
102
-
103
- よく調べてみたら、Lineのシステムの手違いでその約束が消えてて
104
-
105
- 相手が知らないまま当日を迎えてしまっていて電話で発覚した。
106
-
107
- 許せますか？
108
-
109
-
110
-
111
- まぁLineは流行っていますから
112
-
113
- そういった問題が発生しないよう頑張って構築しているんでしょうね。
114
-
115
-
116
-
117
- ともかく、Web上で情報を預かるということは
118
-
119
- 「例え無料だとしてもそれなりの責任が伴う」事を意味します。
120
-
121
-
122
-
123
- 100人のユーザーが訪れて同時に読み書きを要求して来ても
124
-
125
- データが消えない事を保証出来なければなりません。
126
-
127
- 更にWebの利用者は目が肥えているので時間の掛かるサービスはすぐに「使えない」と見切ります。
128
-
129
- 速度も重要視されます。
130
-
131
-
132
-
133
- ---
134
-
135
-
136
-
137
139
  テキストでファイルを管理する場合
138
140
 
141
+ 問題はファイルの保存時の衝突くらいでしょうか？
142
+
139
- 「排他制御」が必要となります。
143
+ 解決策は「排他制御」です。
140
144
 
141
145
 
142
146
 
@@ -152,19 +156,13 @@
152
156
 
153
157
  なので2つの処理が同時に書き込むと、先に書き込んだ方が消えます。
154
158
 
155
- こういう現象を衝突等と読んだりします。
159
+
156
-
157
-
158
-
160
+
159
- なので掲示板では複数ユーザーが同時に書き込むと、
161
+ 掲示板のケースで話を進めると複数ユーザーが同時に書き込むと、
160
-
162
+
161
- 先に書き込んだユーザーの発言が消えて、後から発言したユーザの書き込みだけが残ります。
163
+ 先に書き込んだユーザーの発言が消えて、後から発言したユーザ1人の書き込みだけが残ります。
162
-
163
- こういう不具合が頻発していました。
164
+
164
-
165
-
166
-
167
- それに対抗するため、CGIのプログラマ達は排他制御を開発します
165
+ それに対抗するため、プログラマ達は「排他制御」を開発します
168
166
 
169
167
 
170
168
 
@@ -184,9 +182,7 @@
184
182
 
185
183
 
186
184
 
187
- 単純にデータの書き込みというそれだけの処理に
185
+ 単純にデータの書き込みだけの為にクッソ頑張る事になるわけで、
188
-
189
- クッソ頑張る事になるわけで、
190
186
 
191
187
  コード量も作業時間もどんどん肥大化してヤバい事になりますね。
192
188
 
@@ -194,13 +190,19 @@
194
190
 
195
191
 
196
192
 
193
+ やりたい事は「複数ユーザの意思疎通」が目的の掲示板制作ですよね。
194
+
195
+ どうしてこうなった？
196
+
197
+
198
+
197
199
  ---
198
200
 
199
201
 
200
202
 
201
203
  ここでデータベースが登場します。
202
204
 
203
- データベースは大まかにこの辺を担当にしています。
205
+ データベースは大まかにこの辺を目的・担当にしています。
204
206
 
205
207
 
206
208
 

2

まぁまぁ酷かったので大改造しました。もう一度読んでみてください。

2021/01/19 02:59

投稿

miyabi-sun
miyabi-sun

スコア21203

test CHANGED
@@ -1,3 +1,23 @@
1
+ 具体的な所として、
2
+
3
+ 現状で全く問題がないのであればそのままでも大丈夫です。
4
+
5
+
6
+
7
+ しかし、衝突に遭遇して
8
+
9
+ 「これはファイルのロックが必要だろうな」と感じるようになってきたら
10
+
11
+ それを実装する時間を使ってデータベースを勉強して使いましょう。
12
+
13
+
14
+
15
+ データベースは一度勉強してしまえば良いだけなので、
16
+
17
+ あちこちでファイルのロック処理を作るより遥かに全体的なコストは安く済むでしょう。
18
+
19
+
20
+
1
21
  > node.jsを使って小規模なシステムを制作（勉強）しています。
2
22
 
3
23
 
@@ -10,148 +30,238 @@
10
30
 
11
31
 
12
32
 
13
- 問題になるのは、貴方がプロとしてお金を貰って仕事をする場合です。
14
-
15
- 特に他のITエンジニアと協業するとなれば、
16
-
17
- 「JSONがあるからデータの保管は大丈夫」等と言っていると笑いものにされます。
18
-
19
-
20
-
21
- その理由を述べていきます。
22
-
23
-
24
-
25
- ---
26
-
27
-
28
-
29
- データベースが必要とされるのはこれが主な理由です
33
+ 問題になるのは、貴方が所謂Webサービスを立ち上げる場合です。
34
+
35
+ 特に他のITエンジニアと協業する規模になってくると
36
+
37
+ JSONによるファイル管理は選択肢から外れる事になるでしょう。
38
+
39
+
40
+
41
+ ---
42
+
43
+
44
+
45
+ Node.jsはシングルスレッドですので、
46
+
47
+ 見た目は並列処理しているように見えても
48
+
49
+ イベントループの仕組み上、基本的には1個の関数しか同時に動きません。
50
+
51
+
52
+
53
+ なので[fs.writeFileSync](https://nodejs.org/api/fs.html#fs_fs_writefilesync_file_data_options)のような
54
+
55
+ 同期処理を使って待たせている場合、
56
+
57
+ 破綻することはないでしょう。
58
+
59
+
60
+
61
+ ファイルが肥大化すれば処理速度の面で悩まされる事になるでしょう。
62
+
63
+ その場合はファイルを分けたり、ディレクトリを切ったりすることである程度は解消できそうですね。
64
+
65
+
66
+
67
+ アイデアとして「書き込みのリクエスト」を受けた場合
68
+
69
+ 提示報告みたいな仕組みで空き時間を利用して、
70
+
71
+ ファイルに書き出していくような仕組みを上手く構築してやれば
72
+
73
+ バズって利用者がアホ程伸びない限り上手くやっていくような仕組みを低コストで実現出来るでしょう。
74
+
75
+
76
+
77
+ しかし「サーバマシンを複数台に増やす」とか
78
+
79
+ 速度が問題になったから[fs.writeFile](https://nodejs.org/api/fs.html#fs_fs_writefile_file_data_options_callback)を使おうと判断した瞬間牙を向いて襲いかかって来ることになるでしょう。
80
+
81
+
82
+
83
+ ※セキュリティ絡みはまた別問題です。
84
+
85
+ マシンが乗っ取られて正規の手段でデータベースにアクセスされて情報を持ち逃げされるようなケースがありえます。
86
+
87
+ 権限とかで縛ってマシン単位でアクセスを禁止すればパスワードなんかは守れたりしますけど……
88
+
89
+
90
+
91
+ ---
92
+
93
+
94
+
95
+ Web上で情報を預かる場合の責任についてです。
96
+
97
+
98
+
99
+ 貴方が仮に恋人や友人とLineで会う約束をしていたとします。
100
+
101
+ しかし当日待ち合わせ場所に来ない……
102
+
103
+ よく調べてみたら、Lineのシステムの手違いでその約束が消えてて
104
+
105
+ 相手が知らないまま当日を迎えてしまっていて電話で発覚した。
106
+
107
+ 許せますか？
108
+
109
+
110
+
111
+ まぁLineは流行っていますから
112
+
113
+ そういった問題が発生しないよう頑張って構築しているんでしょうね。
114
+
115
+
116
+
117
+ ともかく、Web上で情報を預かるということは
118
+
119
+ 「例え無料だとしてもそれなりの責任が伴う」事を意味します。
120
+
121
+
122
+
123
+ 100人のユーザーが訪れて同時に読み書きを要求して来ても
124
+
125
+ データが消えない事を保証出来なければなりません。
126
+
127
+ 更にWebの利用者は目が肥えているので時間の掛かるサービスはすぐに「使えない」と見切ります。
128
+
129
+ 速度も重要視されます。
130
+
131
+
132
+
133
+ ---
134
+
135
+
136
+
137
+ テキストでファイルを管理する場合
138
+
139
+ 「排他制御」が必要となります。
140
+
141
+
142
+
143
+ 2000年前後のWebではCGIを使ったテキストチャットや掲示板サイトが多く存在しました。
144
+
145
+ 当時はJSONはなく、CSV等のファイル形式で保管していました。
146
+
147
+ (JSONは`{}`や`[]`が第一行目と最終行目に来て包む形になりますから、追記が出来るCSVのがファイル管理のサービスに向いているでしょう)
148
+
149
+
150
+
151
+ ファイルの書き込みは基本的に上書き、つまり複数の処理が同時に書き込むと後勝ちです。
152
+
153
+ なので2つの処理が同時に書き込むと、先に書き込んだ方が消えます。
154
+
155
+ こういう現象を衝突等と読んだりします。
156
+
157
+
158
+
159
+ なので掲示板では複数ユーザーが同時に書き込むと、
160
+
161
+ 先に書き込んだユーザーの発言が消えて、後から発言したユーザの書き込みだけが残ります。
162
+
163
+ こういう不具合が頻発していました。
164
+
165
+
166
+
167
+ それに対抗するため、CGIのプログラマ達は排他制御を開発します
168
+
169
+
170
+
171
+ - 一時ファイルを沢山作る
172
+
173
+ - ファイルをロックする仕組みを作る
174
+
175
+ - 書き込みたい状況でロックされている場合は待つ
176
+
177
+ - ファイルを複数に分けて頻繁なロック待ちを避ける
178
+
179
+
180
+
181
+ しかし、そういう手段を講じても[デッドロック](https://e-words.jp/w/%E3%83%87%E3%83%83%E3%83%89%E3%83%AD%E3%83%83%E3%82%AF.html)等の不具合が発生して
182
+
183
+ そもそも書き込めないんだが？みたいな現象に悩まされ続ける事になります。
184
+
185
+
186
+
187
+ 単純にデータの書き込みというそれだけの処理に
188
+
189
+ クッソ頑張る事になるわけで、
190
+
191
+ コード量も作業時間もどんどん肥大化してヤバい事になりますね。
192
+
193
+ (そもそもどうやって複数人が同時に書き込んでも大丈夫かを担保するねん？という事でテストもしにくい)
194
+
195
+
196
+
197
+ ---
198
+
199
+
200
+
201
+ ここでデータベースが登場します。
202
+
203
+ データベースは大まかにこの辺を担当にしています。
30
204
 
31
205
 
32
206
 
33
207
  - 超高速
34
208
 
35
- - 巨大なデータの読み書きでも速度が殆ど落ちない
36
-
37
- - 同時アクセスでもデータの整合性が失われない
38
-
39
-
40
-
41
- 貴方が仮に恋人や友人とLineで会う約束をしていたとします。
42
-
43
- しかし当日待ち合わせ場所に来ない……
44
-
45
- よく調べてみたら、Lineのシステムの手違いでその約束が消えてて
46
-
47
- 相手が知らないまま当日を迎えてしまっていて電話で発覚した。
48
-
49
- 許せますか？
50
-
51
-
52
-
53
- Web上で情報を預かるということは
54
-
55
- 「例え無料だとしてもそれなりの責任が伴う」事を意味します。
56
-
57
-
58
-
59
- JSONに限りませんが、テキストファイルでデータを持つということは、
60
-
61
- 100人のユーザーが訪れて同時に保存やロードを要求して来てもデータが消えない事を保証出来なければなりません。
62
-
63
- 更にWebの利用者は目が肥えているので時間の掛かるサービスはすぐに「使えない」と見切ります。
64
-
65
- 超高速にこなす事も求められます。
66
-
67
-
68
-
69
- ---
70
-
71
-
72
-
73
- 例えば2000年前後のWebではPerl等のCGIを使ったテキストチャットや掲示板サイトが多く存在しました。
74
-
75
- その多くはCSV等のファイル形式で保管していました。
76
-
77
-
78
-
79
- ファイルの書き込みは基本的に上書きですよね。
80
-
81
- 掲示板では複数ユーザーが同時に書き込むと、
82
-
83
- 後勝ちなので先に書き込んだユーザーの発言が消えて、後から発言したユーザの書き込みだけが残ります。
84
-
85
- こういう不具合が頻発していました。
86
-
87
-
88
-
89
- それに対抗するため、CGIのプログラマ達はあらゆる手段を開発します
90
-
91
-
92
-
93
- - 一時ファイルを沢山作る
94
-
95
- - ファイルをロックする仕組みを作る
96
-
97
- - 書き込みたい状況でロックされている場合は待つ
98
-
99
- - ファイルを複数に分けて頻繁なロック待ちを避ける
100
-
101
-
102
-
103
- しかし、そういう手段を講じても[デッドロック](https://e-words.jp/w/%E3%83%87%E3%83%83%E3%83%89%E3%83%AD%E3%83%83%E3%82%AF.html)等の不具合が発生して
104
-
105
- 書き込み処理に失敗して書き込みデータが飛ぶんだが？みたいな現象に悩まされ続ける事になります。
106
-
107
-
108
-
109
- 単純にデータの書き込みというそれだけの処理に
110
-
111
- クッソ頑張る事になるわけで、
112
-
113
- コード量も作業時間もどんどん肥大化してヤバい事になりますね。
114
-
115
- (そもそもどうやって複数人が同時に書き込んでも大丈夫かを担保するねん？という事でテストもしにくい)
116
-
117
-
118
-
119
- ここでデータベースが登場します。
120
-
121
- データベースはこれらの対策等を使わなくても良いのです。
122
-
123
- データベースが致命的な処理は全て責任をもってよしなにやってくれる。
124
-
125
- 何時でもデータを預かってくれますし、取り出す時も一瞬、消える心配もまず無い。
209
+ - 既に多数のデータを内包していてもデータ片の読み書き速度が落ちない
210
+
211
+ - ファイルの排他制御
212
+
213
+
214
+
215
+ 特に[RDBMS](https://e-words.jp/w/RDBMS.html)はデータの担保の面で非常に堅牢です。
216
+
217
+ 手軽に導入できるMySQLやPostgreSQLは多くのWebエンジニアから愛されていますし、
218
+
219
+ 金融業界やNTTデータのような大企業でも愛用されるOracleなんてものもあります。
220
+
221
+
222
+
223
+ 一般的にNoSQLはRDBMSに多少担保の面で劣るものの、
224
+
225
+ スケールのしやすさ、複数台に増やして動作させる性能が高かったりして注目を集めています。
226
+
227
+ MongoDBはRDBMSとNoSQLの同居みたいなバランス感覚が絶妙で、
228
+
229
+ 中々使い勝手が良いみたいな話を聞きます。
230
+
231
+
232
+
233
+ とまぁ、データベースを使えば衝突や速度を稼ぐという事を責任とってやってくれますので、
234
+
235
+ メインの業務ロジックに集中できます。
236
+
237
+
238
+
239
+ ---
126
240
 
127
241
 
128
242
 
129
243
  データを預かる事に疲弊したWebエンジニアがデータベースを使わない理由がない。
130
244
 
245
+
246
+
131
247
  Webエンジニア達はデータベースの学習コストを甘んじて受け入れる事になりました。
132
248
 
133
249
  めでたし。
134
250
 
135
-
136
-
137
- ---
138
-
139
-
140
-
141
- 具体的な所として、
251
+ こんな感じの流れです。
142
-
143
- 現状で全く問題がないのであればそのままでも大丈夫です。
252
+
144
-
145
-
146
-
253
+
254
+
147
- しかし、衝突上書きに対して
255
+ 複数のWebエンジニアが協業して、
148
-
256
+
149
- 「これはファイルのロックが必要だろうな」と感じるようになってきたら
257
+ 大きなWebサービスを作り上げるとなれば、
150
-
258
+
151
- それを実装する時間を使ってデータベースを勉強して使いましょう。
259
+ まぁ、何らかのデータベースは使う事になります。
152
-
153
-
154
-
260
+
261
+
262
+
155
- データベースは一度勉強してしまえば良いだけなので、
263
+ 一人でも一度データベースを勉強して扱えるようになっておけば
156
-
264
+
157
- あちこちでファイルのロック処理を作るより遥かに全体的なコストは安く済むでしょう。
265
+ あっちこっちのプロジェクトで排他制御を書きまくるなんてこともせずに済みます。
266
+
267
+ 学習コストを割く価値は十分あると思います。

1

結論追加

2021/01/19 02:26

投稿

miyabi-sun
miyabi-sun

スコア21203

test CHANGED
@@ -2,11 +2,11 @@
2
2
 
3
3
 
4
4
 
5
- 貴方が一生その規模で満足しているなら問題ありません。
5
+ 貴方が一生その規模で満足出来るなら問題ありません。
6
6
 
7
- 特に学生ならばデータベースの存在意義が全く理解出来ないでしょうし、
7
+ 特に学生・社内SEならばデータベースの存在意義が全く理解出来ないのは当然で、
8
8
 
9
- 個人開発レベルで大仰なデータベースを持ち出すべき場面もそんなにありません。
9
+ 大仰なデータベースを持ち出すべき場面もそんなにありません。
10
10
 
11
11
 
12
12
 
@@ -131,3 +131,27 @@
131
131
  Webエンジニア達はデータベースの学習コストを甘んじて受け入れる事になりました。
132
132
 
133
133
  めでたし。
134
+
135
+
136
+
137
+ ---
138
+
139
+
140
+
141
+ 具体的な所として、
142
+
143
+ 現状で全く問題がないのであればそのままでも大丈夫です。
144
+
145
+
146
+
147
+ しかし、衝突上書きに対して
148
+
149
+ 「これはファイルのロックが必要だろうな」と感じるようになってきたら
150
+
151
+ それを実装する時間を使ってデータベースを勉強して使いましょう。
152
+
153
+
154
+
155
+ データベースは一度勉強してしまえば良いだけなので、
156
+
157
+ あちこちでファイルのロック処理を作るより遥かに全体的なコストは安く済むでしょう。