- 1 名前：デフォルトの名無しさん mailto:sage [2022/12/08(木) 12:29:27.06 ID:Nq8u2KPWd.net]
- この板はプログラムを作る人のための板です。
あらゆる質問はまず
スレ立てるまでもない質問はここで
スレにしてください。
次スレは>>980が立てること
【前スレ】
スレ立てるまでもない質問はここで 162匹目
https://mevius.5ch.net/test/read.cgi/tech/1666337882/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
- 320 名前：デフォルトの名無しさん mailto:sage [2023/01/04(水) 21:02:00.45 ID:AvzaDUce0.net]
- SHLVL
- 321 名前：デフォルトの名無しさん mailto:sage [2023/01/04(水) 21:20:26.95 ID:oLi3mo910.net]
- >>317
一概に言えるもんでもないだろう。クライアント/サーバーといっても同一ノード上の通信なら
ディスクアクセスと比べたら無視していいくらい速い。
- 322 名前：デフォルトの名無しさん mailto:sage [2023/01/04(水) 21:22:51.87 ID:lFNs7lW+0.net]
- >>317
> 通信が必要ないからシーケンシャルアクセスが速いのは当たり前じゃない？
まさかと思うけど100万件のデータから100万件を抽出する話なのか？w
> 処理時間の差も件数に比例するから件数が多いときに速く感じるのも当たり前だと思う
件数に比例とか言ってる時点でお前さんわかってないだろ...
- 323 名前：デフォルトの名無しさん [2023/01/04(水) 21:36:29.87 ID:QxUfEWbZ0.net]
- ストアドよりインデックスが速いよ。
https://mevius.5ch.net/test/read.cgi/db/1094134263/l50
正論。
- 324 名前：デフォルトの名無しさん mailto:sage [2023/01/04(水) 22:03:56.19 ID:gEBE6zIG0.net]
- 何の基準もなく「ぶっ飛びに早い」というふわっとした発言に深掘りしても
おったまげな情報は得られないだろう
正月から空虚なマウントの取り合いが繰り広げられるだけ
- 325 名前：デフォルトの名無しさん mailto:sage [2023/01/04(水) 22:57:00.83 ID:1JQ1gS/7r.net]
- >>313-324
https://i.imgur.com/IAd9fMX.jpg
- 326 名前：デフォルトの名無しさん mailto:sage [2023/01/04(水) 23:09:49.56 ID:lFNs7lW+0.net]
- 測定条件も書いてない単なる表になんの価値があるんだ？
そもそも例えばPostgresSQL 100万件で150秒とかインデックス張ってないにしても遅すぎる
- 327 名前：デフォルトの名無しさん mailto:sage [2023/01/04(水) 23:26:14.42 ID:1JQ1gS/7r.net]
- >>326
1億件のレコードから1万件/10万件/100万件を主キーで1件ずつSELECTした場合の速度
- 328 名前：デフォルトの名無しさん [2023/01/04(水) 23:29:55.56 ID:gVbSXgMqM.net]
- M1優勝できるレベルのネタだなw
- 329 名前：デフォルトの名無しさん mailto:sage [2023/01/04(水) 23:37:16.27 ID:lFNs7lW+0.net]
- SQLite 1万件: 0.06秒 ÷ 10,000件 = 6μs/件
これオンメモリーじゃね？
てかソースは出せないのか？
- 330 名前：デフォルトの名無しさん [2023/01/05(木) 00:06:55.48 ID:iqc5j6UOd.net]
- >>325
馬鹿はこんなソースを鵜呑みにするんだな
その上商用データベースはないし
- 331 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 00:38:18.87 ID:HRGQlaN+r.net]
- >>329
SQLiteはファイルシステムのI/Oより高速
https://i.imgur.com/JCfmbMF.jpg
>>330
商用で使われてるけど？
馬鹿は何も知らないんだな
https://i.imgur.com/833qmGW.jpg
https://i.imgur.com/uhnM01O.jpg
- 332 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 01:37:59.87 ID:sCQ59Dgt0.net]
- >>331
329は、"基本オンメモリで動作するSQlite"と、"通常ディスクで動作する(オンメモリもできなくはない)他DB"、
それらをそれぞれデフォかなんかわからない環境で比較してることに意味はあるの？ってことじゃないの？
両方オンメモリ(インメモリ)ならどうなるのかな？
たとえばMySQLならInsertが数十倍になった記憶はある(メモリの仕様にも依存するだろうけどね)
330は、商用データベースという言い方はちょっとズレてて、
商用ライセンスとサポートがないんじゃないのってことじゃないかな
使う案件によっては影響出るからね
- 333 名前：デフォルトの名無しさん [2023/01/05(木) 01:48:13.14 ID:iqc5j6UOd.net]
- >>331
馬鹿は商用データベースの意味がわからんような馬鹿か
- 334 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 02:03:08.48 ID:2xtdBLfB0.net]
- 別にケチ付けるまでもなく普通の結果じゃね
SQLiteはシンプルで排他であるがゆえにオーバーヘッドも少なく動くし
ファイル動作でもOSによるキャッシングも効きやすく（そこを割り切ったからこそのシンプルなDB）
デフォルトで理論値出やすいし
- 335 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 05:33:44.92 ID:O+NRT3S+0.net]
- >>331
> SQLiteはファイルシステムのI/Oより高速
これはBLOBの話
こんなのは他のDBMSでも同じだぞ
>>334
インプロセスでネットワークのオーバーヘッドが無いとか他のDBMSが持ってるような権限チェックや利用ログ機能が無いとかあるから特に単純なSQLで比較するとSQLiteが圧倒的に有利であるのは間違いない
ただそれにしても6μs/件を出そうとしたらI/Oアクセスあると相当難しい
そもそも
>>308 > SQLiteはレコード数100万件を超えるとSELECTが他のRDBMSよりぶっ飛びで速くなる
って書いてたから対象レコードの話かと思ったら単なる繰り返しの回数みたいだしそもそも他のDBMSを含めてリニアに増加してるから「100万件越えたらぶっ飛びで速くなる」なんてどこから出てきたのか謎すぎる
- 336 名前：デフォルトの名無しさん [2023/01/05(木) 06:58:12.29 ID:oM1k4p980.net]
- SQLiteは大規模なデータベースは無理なんだよ。
その点で住み分けは出来る。
とはいえ、SQLiteで9割カバー出来るだろな。
第一推奨がSQLite。
- 337 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 12:01:45.56 ID:nNkP0Ncc0.net]
- こんなん、条件が特殊でしょw
- 338 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 12:18:31.66 ID:uXoq84mk0.net]
- >>336
DB自体の規模はあまり問題ではない
SQLiteが無理なのは複数の人が同時にアクセスするようなDBで、その時点でDBのユースケースの9割からは外れる
- 339 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 13:09:47.11 ID:HRGQlaN+r.net]
- >>335
少しは自分で調べたらどうか
でお前はSQLiteが速いと困るのか？
https://i.imgur.com/ItEYKwm.jpg
https://i.imgur.com/gqG2W2l.jpg
https://i.imgur.com/cPWRc0D.jpg
https://i.imgur.com/U57Du7x.jpg
https://i.imgur.com/B87Btlk.jpg
- 340 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 13:21:32.96 ID:jGVXI03l0.net]
- ファイル型のデータベースって言ったらユニケージやろ
https://www.usp-lab.com/qa.html#exclusiveProcessing
ロールバックはシンボリックリンクを手作業で張り替えればいいから安全
- 341 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 13:24:28.43 ID:/79BsoYR0.net]
- 情報はありがたいが出典は書いてほしいな。
- 342 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 14:39:37.45 ID:O+NRT3S+0.net]
- >>339
１万件のselectで0.11sだったのに5,000件だと1.1sとかえらく遅くなったなw
そもそもSQLite 2.7.6って20年近く前のリリースやぞ...
https://www.sqlite.org/chronology.html
まあこの頃のPostgresSQLは遅いので有名だったからこんなもんじゃね？
- 343 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 14:50:56.99 ID:vkZCL/K50.net]
- ウェイトフリー、ロックフリーのキューにいれてシリアル化? 、直列化? すれば
多重アクセスでもSQliteでいいか?
- 344 名前：デフォルトの名無しさん mailto:sage [2023/01/05(木) 14:53:54.58 ID:vkZCL/K50.net]
- Lock-freeとWait-freeアルゴリズム 出典: フリー百科事典『ウィキペディア（Wikipedia）』
Lock-freeとWait-freeアルゴリズムとは、共有データにロックをかけてアクセスを防ぐアルゴリズムとは違い、複数のスレッドが同時並行的に、ある対象データを壊すことなしに読み書きすることを可能にするアルゴリズムである。
Lock-free とはスレッドがロックしないことを意味しており、全てのステップにおいてシステムが必ず進行する。
Wait-free とは、他のスレッドの動作に関係なく、スレッドがいかなる操作も有限のステップで操作を完了させられることを指す。
Wait-free なアルゴリズムは Lock-free である。
銀行預金の例
例えば、銀行口座への預金プログラムを作るとする。それぞれのスレッドをATMとする。
ロック方式のやり方の場合、1つ目のATMが預金をするとき、ほかのATMが同時に預金残高を変更しないよう、ロックをかける。
さもないと、同時に処理してしまうと、最終的な預金残高に不整合が起きうる。
この処理を Lock-free にするには、すべての預入要求を管理するスレッドを作り、そこに、Wait-free のキューを作り、
ATMはそのキューに対して非同期にロックをかけることなく預入要求を入れ、預入要求を管理するスレッドはキューから順次取り出し、預金残高を更新する。
このやり方の方が、わざわざ Lock-free の預金アルゴリズムを作るよりも、プログラミングは楽である。
さらに、この手法は、キューがWait-freeであるので、Lock-free なだけでなく、Wait-freeでもある。
預金残高の書き換え処理をn並列で行いたいなら、n個Wait-freeキューを作り、口座番号をnで割った余りでどのキューに入れるか決めるという方法で対応できる。
- 345 名前：デフォルトの名無しさん [2023/01/06(金) 00:44:53.18 ID:Hz2m3Wai0.net]
- sndvol.exeやeartrumpetなどのアプリごとの音量調整アプリはどうやって実現させているのでしょうか
アプリごとに音量調整できるWindowsAPIがあるのですか？
|
 |
