【IT】NoSQLってなんなん？ただのデータ型の配列に見えるが

1 : 2022/09/25(日) 11:07:36.95 ID:09C3U8tVM: NoSQLとは？メリット・将来性について分かりやすく解説
https://and-engineer.com/articles/YeP-wRAAAJMQLYuh
SQLみたいな操作する言語はないんだろ？
2 : 2022/09/25(日) 11:09:02.12 ID:ooetvZQE0: Elasticsearchと違うの？なんなの？
3 : 2022/09/25(日) 11:10:06.32 ID:zskR2EIS0: わしのエ口画像動画置き場がまさにこれ
4 : 2022/09/25(日) 11:10:42.89 ID:09C3U8tVM: >>3
ドキュメント型ってやつか
5 : 2022/09/25(日) 11:12:57.23 ID:y9NLQjyg0: よくわかんねーからjsonぶち込んでた
6 : NG NG: 使ったことないけど、マップ（ハッシュ、連想配列）みたいな感じでデータを扱えるDBの仕組みってことじゃないん？
いちいちSQLみたいな言語使わなくていいからデータの出し入れが楽だよみたいな
7 : 2022/09/25(日) 11:16:51.61 ID:2eI3zSfW0: awsのdynamodb使ったことある
8 : 2022/09/25(日) 11:17:06.39 ID:HprsiwVx0: 要はDictionaryやCollectionデカくした感じか
10 : NG NG: >>8
フロントエンドにデータ読み込んでおいてやる場合は、まさしくそんな感じだと思う
使ったことないけども、多分そう
9 : NG NG: とくに、なんか条件付けてデータを絞り込んだりしなくて
IDをキーとして取り出せばいいし、どうしても絞り込みたかったら取得後にやってもそんなに負担かかりませんよみたいな規模の時は
SQL使って格納せんでもええやんか？　なんならフロントサイドに情報持っててもいいじゃんか？みたいな
そういう時に使うんじゃない？
11 : 2022/09/25(日) 11:19:49.78 ID:X9nEdHBy0: 独自のクエリー言語あるNoSQLもあるよ
単純なkvsだと複雑な問い合わせがそもそもできないというか不要で連想配列的な使い方になる
16 : NG NG: >>11
へえ
NoSQLはNoQueryLanguageではないってことね
12 : 2022/09/25(日) 11:20:49.88 ID:RrzLk42Wa: でっかいエクセルのことだよ
13 : 2022/09/25(日) 11:22:10.49 ID:YqqPD9Ep0: 連想配列で充分なんだけど、ちょっとデータの規模が大きいときに使うって感じなんかな？
14 : 2022/09/25(日) 11:27:05.89 ID:Ph+luWbK0: つーか大企業の既存のＤＢだとコスパ悪いから
その機能制限や特化のバージョンってだけ
15 : 2022/09/25(日) 11:28:34.37 ID:NNho0PMyr: ただのゴミ
本末転倒
18 : 2022/09/25(日) 11:44:23.14 ID:1XyfUmb1a: 単なるストレージってイメージ
結局データとして自由に扱うには
RDBに放り込んで使いそう
19 : 2022/09/25(日) 11:46:17.80 ID:UZVtVtw80: カード型データベースのことか
20 : 2022/09/25(日) 12:03:07.77 ID:UHjNN/ZX0: cap定理すべてを満たす最強のdbは存在しないからな
21 : 2022/09/25(日) 12:06:44.55 ID:uLs8ZsH+0: まあほとんどの場合、keyから取り出したり更新したりするので十分だからね
それをアプリケーション依存でないのがいいよねってこと
22 : 2022/09/25(日) 12:07:23.60 ID:AXZxcS0hd: データをシンプルなキーバリュー形式で持つから分散してスケールさせやすいんだっけ
RDBでよくある正規化やロックをあまりかっちりやらず大規模でリードオンリーなデータを扱うやり方に相性がいいイメージ
23 : 2022/09/25(日) 12:08:10.63 ID:X9nEdHBy0: ポスグレredisあとはお好みのクラウドのオブジェクトストレージ
これで大抵何とかなる
24 : 2022/09/25(日) 12:29:23.83 ID:nV/ypweQ0: 利点はわかるんだが、「やっぱりRDBでいいよね」って言う
29 : 2022/09/25(日) 12:42:40.38 ID:qiCU90qc0: >>24
ならないと思うよ
そもそも代用分じゃなく使う目的が違うから
おまけにAWSがこれの設計思想ベースだし
32 : 2022/09/25(日) 12:44:20.56 ID:aBH9cAya0: >>29
とょっとなに言ってるかわかんねーな
25 : 2022/09/25(日) 12:33:02.04 ID:+/UclG/h0: 今はハッシュタグ検索は使えないと不便だよなって思う
でも意外と実装出来ない
28 : NG NG: >>25
ハッシュタグをキーとするNpSQLのテーブル作って
その中に実データのID（ばりゅー）のリストを格納するとかじゃだめなの
ハッシュタグを外したら、リストからそのIDのデータを外すだけでええやん
データ削除はちょっと処理重くなるけど、リストにしておけば取得時にはソートしなくていいから、取得は速いでしょ
34 : 2022/09/25(日) 12:47:40.00 ID:+/UclG/h0: >>28
一度やってみるかな
おっさん社内プログラマーだから新しいこと苦手だわ
26 : 2022/09/25(日) 12:38:46.41 ID:lRIRPdso0: NoSQLは既存のRDBでは対応できない特別な要件に対応させるためにあると思えばいい
汎用性はRDBが高いと思う
27 : 2022/09/25(日) 12:41:17.85 ID:qiCU90qc0: dynamoやJSONみたいなやつね
んでこれAWSでもその思考で使うしその割に技術者いないから最小限の努力で高収入得られる美味しい分野ですよ
30 : 2022/09/25(日) 12:42:49.81 ID:qiCU90qc0: データ構造ベースの設計思想だし
31 : 2022/09/25(日) 12:44:08.13 ID:xCmTxrlU0: JOINとかサブクエリとか関数がやってくれてること全部自分でやるの無理
昔の人はNDBで自前やってたんだよねぇ
33 : 2022/09/25(日) 12:46:09.27 ID:uSf5456lM: ただのキーバリューストアやろ
しらんけど
35 : 2022/09/25(日) 12:48:38.43 ID:r4diPdgO0: エクセル方眼紙に書くくらいならこれ使えってことだろ
36 : 2022/09/25(日) 12:49:00.45 ID:ix0c1ibO0: rdbmsはスケールアウトするのが難しい
ユーザー数が数千万超えるようなソシャゲとかだとドキュメント型のdbが向いてる
38 : 2022/09/25(日) 12:56:47.45 ID:uLs8ZsH+0: >>36
難しい問題だよな
顧客管理ならRDBMSでしたいって思うだろ、
ソシャゲみたいにアホみたいにアカウント作られてその中のごく一部に課金するユーザがいるってモデル
ソシャゲ会社が一番DBに向き合っているって感はある(もちろんそんなのは表に出ることはほぼないからユーザの知らんところだけど)
37 : 2022/09/25(日) 12:52:18.71 ID:MPSjN8tm0: 元々はビッグデータの高速操作のために流行ったやつだけど
今はbigqueryが引くほど高速だから今から使う意味は全く無い
39 : 2022/09/25(日) 13:11:18.53 ID:gDuOK3MM0: NoSQLってネーミングが糞だよね
40 : 2022/09/25(日) 13:17:24.22 ID:X9nEdHBy0: タグ検索はAND検索もサポートしたいなら全文検索エンジン使ってしまうのが楽
41 : 2022/09/25(日) 13:22:11.70 ID:a2ck5g2Ia: 使い分けろよアホ