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

編集履歴

回答編集履歴

3

冗長な記述は削除した

2021/01/19 02:59

投稿

miyabi-sun
miyabi-sun

スコア21503

answer CHANGED
@@ -1,26 +1,46 @@
1
1
  具体的な所として、
2
- 現状で全く問題がないのであればそのままでも大丈夫です。
2
+ 現状で問題がないのであればそのままでも大丈夫です。
3
3
 
4
- しかし、衝突に遭遇して
4
+ しかし衝突に遭遇して「排他制御」が必要と感じたら、
5
- 「これはファイルのロックが必要だろうな」と感じるようになってきたら
6
5
  それを実装する時間を使ってデータベースを勉強して使いましょう。
7
6
 
8
- データベースは一度勉強してしまえば良いだけなので、
7
+ データベースはファイルの読み書きに特化したソリューションですので、
9
- あちこちでファイルのロック処理を作るより遥かに全体的なコストは安く済むでしょう。
8
+ 多くのWebエンジニアに歓迎され、受け入れられています。
10
9
 
11
- > node.jsを使って小規模なシステムを制作（勉強）しています。
10
+ 仮に貴方がWebサービスを開発・運用しているチームに改めて参入した場合
11
+ ほぼ確実に何らかのデータベースは導入済みであるでしょう。
12
+ その場合はしかたない、学習することになります。
12
13
 
14
+ 実際のプロジェクトのコード読めばどうやって利用しているのか読めるので、
13
- 貴方が一生その規模で満足出来るなら問題ありません。
15
+ 意外と一瞬で使えるようになるものです。
14
- 特に学生・社内SEならばデータベースの存在意義が全く理解出来ないのは当然で、
15
- 大仰なデータベースを持ち出すべき場面もそんなにありません。
16
16
 
17
- 問題になるのは、貴方が所謂Webサービスを立ち上げる場合です。
18
- 特に他のITエンジニアと協業する規模になってくると
17
+ ---
19
- JSONによるファイル管理は選択肢から外れる事になるでしょう。
20
18
 
19
+ まずWeb上で情報を預かる場合の責任についてです。
20
+
21
+ 貴方が仮に恋人や友人とLineで会う約束をしていたとします。
22
+ しかし当日待ち合わせ場所に来ない……
23
+ よく調べてみたら、Lineのシステムの手違いでその約束が消えてて
24
+ 相手が知らないまま当日を迎えてしまっていて電話で発覚した。
25
+ 許せますか？
26
+
27
+ Web上で情報を預かるということは
28
+ 「例え無料だとしてもそれなりの責任が伴う」事を意味します。
29
+
30
+ この辺は「データの価値」をどの程度見積もるか評価・設計をしてください。
31
+ Lineは会社が潰れるレベルの価値に設定しているかと思います。
32
+ なのでそういう問題が起こらないよう、よく設計を練って堅牢なシステムを築いているはずです。
33
+
34
+ 100人のユーザーが訪れて同時に読み書きを要求して来ても
35
+ データが消えない事を保証出来なければならない。
36
+ 更にWebの利用者は目が肥えているので時間の掛かるサービスはすぐに「使えない」と見切ります。
37
+ 速度も重要視されます。
38
+
39
+ こういう世界で闘う事になる可能性は覚悟しておきましょう。
40
+
21
41
  ---
22
42
 
23
- Node.jsはシングルスレッドですので、
43
+ Node.jsはシングルスレッドですので1プロセスで動作させている場合は問題は起こらないでしょう。
24
44
  見た目は並列処理しているように見えても
25
45
  イベントループの仕組み上、基本的には1個の関数しか同時に動きません。
26
46
 
@@ -29,45 +49,27 @@
29
49
  破綻することはないでしょう。
30
50
 
31
51
  ファイルが肥大化すれば処理速度の面で悩まされる事になるでしょう。
32
- その場合はファイルを分けたり、ディレクトリを切ったりすることである程度は解消できそうですね。
52
+ 一般的に取られる下記のような手段を採用すると牙を向いて襲いかかってくる事になるでしょう。
33
53
 
34
- アイデアとして「書き込みのリクエスト」を受けた場合
35
- 提示報告みたいな仕組みで空き時間を利用して、
54
+ - サーバマシンを複数台に増やす
36
- ファイルに書き出していくような仕組みを上手く構築してやれば
37
- バズって利用者がアホ程伸びない限り上手くやっていくような仕組みを低コストで実現出来るでしょう。
55
+ - [fs.writeFile](https://nodejs.org/api/fs.html#fs_fs_writefile_file_data_options_callback)を使う
38
56
 
57
+ ディレクトリやファイルを個別に管理したり、ファイルの書き込みを遅延させたり
39
- しかし「サーバマシンを複数台に増やす」とか
58
+ アイデア次第で結構頑張れると思いますが、それって目的見失ってませんか？
40
- 速度が問題になったから[fs.writeFile](https://nodejs.org/api/fs.html#fs_fs_writefile_file_data_options_callback)を使おうと判断した瞬間牙を向いて襲いかかって来ることになるでしょう。
59
+ ファイルの整合性の担保が目的じゃないですよね、元々やりたいことがあったのでは？
41
60
 
61
+ ファイルの整合性の担保は、
62
+ それ自体を責任取って面倒みてくれるデータベースに任せましょうよって話です。
63
+
42
64
  ※セキュリティ絡みはまた別問題です。
43
65
  マシンが乗っ取られて正規の手段でデータベースにアクセスされて情報を持ち逃げされるようなケースがありえます。
44
66
  権限とかで縛ってマシン単位でアクセスを禁止すればパスワードなんかは守れたりしますけど……
45
67
 
46
68
  ---
47
69
 
48
- Web上で情報を預かる場合の責任についてです。
49
-
50
- 貴方が仮に恋人や友人とLineで会う約束をしていたとします。
51
- しかし当日待ち合わせ場所に来ない……
52
- よく調べてみたら、Lineのシステムの手違いでその約束が消えてて
53
- 相手が知らないまま当日を迎えてしまっていて電話で発覚した。
54
- 許せますか？
55
-
56
- まぁLineは流行っていますから
57
- そういった問題が発生しないよう頑張って構築しているんでしょうね。
58
-
59
- ともかく、Web上で情報を預かるということは
60
- 「例え無料だとしてもそれなりの責任が伴う」事を意味します。
61
-
62
- 100人のユーザーが訪れて同時に読み書きを要求して来ても
63
- データが消えない事を保証出来なければなりません。
64
- 更にWebの利用者は目が肥えているので時間の掛かるサービスはすぐに「使えない」と見切ります。
65
- 速度も重要視されます。
66
-
67
- ---
68
-
69
70
  テキストでファイルを管理する場合
71
+ 問題はファイルの保存時の衝突くらいでしょうか？
70
- 「排他制御」が必要となります。
72
+ 解決策は「排他制御」です。
71
73
 
72
74
  2000年前後のWebではCGIを使ったテキストチャットや掲示板サイトが多く存在しました。
73
75
  当時はJSONはなく、CSV等のファイル形式で保管していました。
@@ -75,14 +77,11 @@
75
77
 
76
78
  ファイルの書き込みは基本的に上書き、つまり複数の処理が同時に書き込むと後勝ちです。
77
79
  なので2つの処理が同時に書き込むと、先に書き込んだ方が消えます。
78
- こういう現象を衝突等と読んだりします。
79
80
 
80
- なので掲示板では複数ユーザーが同時に書き込むと、
81
+ 掲示板のケースで話を進めると複数ユーザーが同時に書き込むと、
81
- 先に書き込んだユーザーの発言が消えて、後から発言したユーザの書き込みだけが残ります。
82
+ 先に書き込んだユーザーの発言が消えて、後から発言したユーザ1人の書き込みだけが残ります。
82
- こういう不具合が頻発していました。
83
+ それに対抗するため、プログラマ達は「排他制御」を開発します
83
84
 
84
- それに対抗するため、CGIのプログラマ達は排他制御を開発します
85
-
86
85
  - 一時ファイルを沢山作る
87
86
  - ファイルをロックする仕組みを作る
88
87
  - 書き込みたい状況でロックされている場合は待つ
@@ -91,15 +90,17 @@
91
90
  しかし、そういう手段を講じても[デッドロック](https://e-words.jp/w/%E3%83%87%E3%83%83%E3%83%89%E3%83%AD%E3%83%83%E3%82%AF.html)等の不具合が発生して
92
91
  そもそも書き込めないんだが？みたいな現象に悩まされ続ける事になります。
93
92
 
94
- 単純にデータの書き込みというそれだけの処理に
93
+ 単純にデータの書き込みだけの為にクッソ頑張る事になるわけで、
95
- クッソ頑張る事になるわけで、
96
94
  コード量も作業時間もどんどん肥大化してヤバい事になりますね。
97
95
  (そもそもどうやって複数人が同時に書き込んでも大丈夫かを担保するねん？という事でテストもしにくい)
98
96
 
97
+ やりたい事は「複数ユーザの意思疎通」が目的の掲示板制作ですよね。
98
+ どうしてこうなった？
99
+
99
100
  ---
100
101
 
101
102
  ここでデータベースが登場します。
102
- データベースは大まかにこの辺を担当にしています。
103
+ データベースは大まかにこの辺を目的・担当にしています。
103
104
 
104
105
  - 超高速
105
106
  - 既に多数のデータを内包していてもデータ片の読み書き速度が落ちない

2

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

2021/01/19 02:59

投稿

miyabi-sun
miyabi-sun

スコア21503

answer CHANGED
@@ -1,48 +1,87 @@
1
+ 具体的な所として、
2
+ 現状で全く問題がないのであればそのままでも大丈夫です。
3
+
4
+ しかし、衝突に遭遇して
5
+ 「これはファイルのロックが必要だろうな」と感じるようになってきたら
6
+ それを実装する時間を使ってデータベースを勉強して使いましょう。
7
+
8
+ データベースは一度勉強してしまえば良いだけなので、
9
+ あちこちでファイルのロック処理を作るより遥かに全体的なコストは安く済むでしょう。
10
+
1
11
  > node.jsを使って小規模なシステムを制作（勉強）しています。
2
12
 
3
13
  貴方が一生その規模で満足出来るなら問題ありません。
4
14
  特に学生・社内SEならばデータベースの存在意義が全く理解出来ないのは当然で、
5
15
  大仰なデータベースを持ち出すべき場面もそんなにありません。
6
16
 
7
- 問題になるのは、貴方がプロとしてお金を貰って仕事をする場合です。
17
+ 問題になるのは、貴方が所謂Webサービスを立ち上げる場合です。
8
- 特に他のITエンジニアと協業するとなれば、
18
+ 特に他のITエンジニアと協業する規模になってくると
9
- 「JSONがあるからデータの保管は大丈夫」等と言っていると笑いものにされます。
19
+ JSONによるファイル管理は選択肢から外れる事になるでしょう。
10
20
 
11
- その理由を述べていきます。
21
+ ---
12
22
 
23
+ Node.jsはシングルスレッドですので、
24
+ 見た目は並列処理しているように見えても
25
+ イベントループの仕組み上、基本的には1個の関数しか同時に動きません。
26
+
27
+ なので[fs.writeFileSync](https://nodejs.org/api/fs.html#fs_fs_writefilesync_file_data_options)のような
28
+ 同期処理を使って待たせている場合、
29
+ 破綻することはないでしょう。
30
+
31
+ ファイルが肥大化すれば処理速度の面で悩まされる事になるでしょう。
32
+ その場合はファイルを分けたり、ディレクトリを切ったりすることである程度は解消できそうですね。
33
+
34
+ アイデアとして「書き込みのリクエスト」を受けた場合
35
+ 提示報告みたいな仕組みで空き時間を利用して、
36
+ ファイルに書き出していくような仕組みを上手く構築してやれば
37
+ バズって利用者がアホ程伸びない限り上手くやっていくような仕組みを低コストで実現出来るでしょう。
38
+
39
+ しかし「サーバマシンを複数台に増やす」とか
40
+ 速度が問題になったから[fs.writeFile](https://nodejs.org/api/fs.html#fs_fs_writefile_file_data_options_callback)を使おうと判断した瞬間牙を向いて襲いかかって来ることになるでしょう。
41
+
42
+ ※セキュリティ絡みはまた別問題です。
43
+ マシンが乗っ取られて正規の手段でデータベースにアクセスされて情報を持ち逃げされるようなケースがありえます。
44
+ 権限とかで縛ってマシン単位でアクセスを禁止すればパスワードなんかは守れたりしますけど……
45
+
13
46
  ---
14
47
 
15
- データベースが必要とされるのはこれが主な理由です
48
+ Web上で情報を預かる場合の責任についてです。
16
49
 
17
- - 超高速
18
- - 巨大なデータの読み書きでも速度が殆ど落ちない
19
- - 同時アクセスでもデータの整合性が失われない
20
-
21
50
  貴方が仮に恋人や友人とLineで会う約束をしていたとします。
22
51
  しかし当日待ち合わせ場所に来ない……
23
52
  よく調べてみたら、Lineのシステムの手違いでその約束が消えてて
24
53
  相手が知らないまま当日を迎えてしまっていて電話で発覚した。
25
54
  許せますか？
26
55
 
56
+ まぁLineは流行っていますから
57
+ そういった問題が発生しないよう頑張って構築しているんでしょうね。
58
+
27
- Web上で情報を預かるということは
59
+ ともかく、Web上で情報を預かるということは
28
60
  「例え無料だとしてもそれなりの責任が伴う」事を意味します。
29
61
 
30
- JSONに限りませんが、テキストファイルでデータを持つということは、
31
- 100人のユーザーが訪れて同時に保存やロードを要求して来てもデータが消えない事を保証出来なければなりません。
62
+ 100人のユーザーが訪れて同時に読み書きを要求して来ても
63
+ データが消えない事を保証出来なければなりません。
32
64
  更にWebの利用者は目が肥えているので時間の掛かるサービスはすぐに「使えない」と見切ります。
33
- 超高速にこなす事も求められます。
65
+ 速度も重要視されます。
34
66
 
35
67
  ---
36
68
 
37
- 例えば2000年前後のWebではPerl等のCGIを使ったテキストチャットや掲示板サイトが多く存在しました。
38
- その多くはCSV等のファイル形式で保管していました。
69
+ テキストでファイルを管理する場合
70
+ 「排他制御」が必要となります。
39
71
 
72
+ 2000年前後のWebではCGIを使ったテキストチャットや掲示板サイトが多く存在しました。
73
+ 当時はJSONはなく、CSV等のファイル形式で保管していました。
74
+ (JSONは`{}`や`[]`が第一行目と最終行目に来て包む形になりますから、追記が出来るCSVのがファイル管理のサービスに向いているでしょう)
75
+
40
- ファイルの書き込みは基本的に上書きですよね。
76
+ ファイルの書き込みは基本的に上書き、つまり複数の処理が同時に書き込むと後勝ちです。
77
+ なので2つの処理が同時に書き込むと、先に書き込んだ方が消えます。
78
+ こういう現象を衝突等と読んだりします。
79
+
41
- 掲示板では複数ユーザーが同時に書き込むと、
80
+ なので掲示板では複数ユーザーが同時に書き込むと、
42
- 後勝ちなので先に書き込んだユーザーの発言が消えて、後から発言したユーザの書き込みだけが残ります。
81
+ 先に書き込んだユーザーの発言が消えて、後から発言したユーザの書き込みだけが残ります。
43
82
  こういう不具合が頻発していました。
44
83
 
45
- それに対抗するため、CGIのプログラマ達はあらゆる手段を開発します
84
+ それに対抗するため、CGIのプログラマ達は排他制御を開発します
46
85
 
47
86
  - 一時ファイルを沢山作る
48
87
  - ファイルをロックする仕組みを作る
@@ -50,30 +89,46 @@
50
89
  - ファイルを複数に分けて頻繁なロック待ちを避ける
51
90
 
52
91
  しかし、そういう手段を講じても[デッドロック](https://e-words.jp/w/%E3%83%87%E3%83%83%E3%83%89%E3%83%AD%E3%83%83%E3%82%AF.html)等の不具合が発生して
53
- 書き込み処理に失敗して書き込みデータが飛ぶんだが？みたいな現象に悩まされ続ける事になります。
92
+ そもそも書き込めないんだが？みたいな現象に悩まされ続ける事になります。
54
93
 
55
94
  単純にデータの書き込みというそれだけの処理に
56
95
  クッソ頑張る事になるわけで、
57
96
  コード量も作業時間もどんどん肥大化してヤバい事になりますね。
58
97
  (そもそもどうやって複数人が同時に書き込んでも大丈夫かを担保するねん？という事でテストもしにくい)
59
98
 
99
+ ---
100
+
60
101
  ここでデータベースが登場します。
61
- データベースはこれらの対策等を使わなくても良いのです。
102
+ データベースは大まかにこの辺を担当にしています。
62
- データベースが致命的な処理は全て責任をもってよしなにやってくれる。
63
- 何時でもデータを預かってくれますし、取り出す時も一瞬、消える心配もまず無い。
64
103
 
104
+ - 超高速
105
+ - 既に多数のデータを内包していてもデータ片の読み書き速度が落ちない
106
+ - ファイルの排他制御
107
+
108
+ 特に[RDBMS](https://e-words.jp/w/RDBMS.html)はデータの担保の面で非常に堅牢です。
109
+ 手軽に導入できるMySQLやPostgreSQLは多くのWebエンジニアから愛されていますし、
110
+ 金融業界やNTTデータのような大企業でも愛用されるOracleなんてものもあります。
111
+
112
+ 一般的にNoSQLはRDBMSに多少担保の面で劣るものの、
113
+ スケールのしやすさ、複数台に増やして動作させる性能が高かったりして注目を集めています。
114
+ MongoDBはRDBMSとNoSQLの同居みたいなバランス感覚が絶妙で、
115
+ 中々使い勝手が良いみたいな話を聞きます。
116
+
117
+ とまぁ、データベースを使えば衝突や速度を稼ぐという事を責任とってやってくれますので、
118
+ メインの業務ロジックに集中できます。
119
+
120
+ ---
121
+
65
122
  データを預かる事に疲弊したWebエンジニアがデータベースを使わない理由がない。
123
+
66
124
  Webエンジニア達はデータベースの学習コストを甘んじて受け入れる事になりました。
67
125
  めでたし。
126
+ こんな感じの流れです。
68
127
 
69
- ---
128
+ 複数のWebエンジニアが協業して、
129
+ 大きなWebサービスを作り上げるとなれば、
130
+ まぁ、何らかのデータベースは使う事になります。
70
131
 
71
- 具体的な所として、
72
- 現状で全く問題がないのであればそのままでも大丈夫です。
73
-
74
- しかし、衝突上書きに対して
75
- 「これはファイルのロックが必要だろうな」と感じるようになってきたら
76
- それを実装する時間を使ってデータベースを勉強して使いましょう。
77
-
78
- データベースは一度勉強してしまえば良いだけなので、
132
+ 一人でも一度データベースを勉強して扱えるようになっておけば
79
- あちこちでファイルのロック処理を作るより遥かに全体的なコストは安く済むでしょう。
133
+ あっちこっちのプロジェクトで排他制御を書きまくるなんてこともせずに済みます。
134
+ 学習コストを割く価値は十分あると思います。

1

結論追加

2021/01/19 02:26

投稿

miyabi-sun
miyabi-sun

スコア21503

answer CHANGED
@@ -1,8 +1,8 @@
1
1
  > node.jsを使って小規模なシステムを制作（勉強）しています。
2
2
 
3
- 貴方が一生その規模で満足しているなら問題ありません。
3
+ 貴方が一生その規模で満足出来るなら問題ありません。
4
- 特に学生ならばデータベースの存在意義が全く理解出来ないでしょうし、
4
+ 特に学生・社内SEならばデータベースの存在意義が全く理解出来ないのは当然で、
5
- 個人開発レベルで大仰なデータベースを持ち出すべき場面もそんなにありません。
5
+ 大仰なデータベースを持ち出すべき場面もそんなにありません。
6
6
 
7
7
  問題になるのは、貴方がプロとしてお金を貰って仕事をする場合です。
8
8
  特に他のITエンジニアと協業するとなれば、
@@ -64,4 +64,16 @@
64
64
 
65
65
  データを預かる事に疲弊したWebエンジニアがデータベースを使わない理由がない。
66
66
  Webエンジニア達はデータベースの学習コストを甘んじて受け入れる事になりました。
67
- めでたし。
67
+ めでたし。
68
+
69
+ ---
70
+
71
+ 具体的な所として、
72
+ 現状で全く問題がないのであればそのままでも大丈夫です。
73
+
74
+ しかし、衝突上書きに対して
75
+ 「これはファイルのロックが必要だろうな」と感じるようになってきたら
76
+ それを実装する時間を使ってデータベースを勉強して使いましょう。
77
+
78
+ データベースは一度勉強してしまえば良いだけなので、
79
+ あちこちでファイルのロック処理を作るより遥かに全体的なコストは安く済むでしょう。