スレ立てるまでもない質問はここで 163匹目

スレ立てるまでもない質問はここで 163匹目 at TECH

325:デフォルトの名無しさん
23/01/04 22:57:00.83 1JQ1gS/7r.net
>>313-324
URLﾘﾝｸ(i.imgur.com)

326:デフォルトの名無しさん
23/01/04 23:09:49.56 lFNs7lW+0.net
測定条件も書いてない単なる表になんの価値があるんだ？
そもそも例えばPostgresSQL 100万件で150秒とかインデックス張ってないにしても遅すぎる

327:デフォルトの名無しさん
23/01/04 23:26:14.42 1JQ1gS/7r.net
>>326
1億件のレコードから1万件/10万件/100万件を主キーで1件ずつSELECTした場合の速度

328:デフォルトの名無しさん
23/01/04 23:29:55.56 gVbSXgMqM.net
M1優勝できるレベルのネタだなw

329:デフォルトの名無しさん
23/01/04 23:37:16.27 lFNs7lW+0.net
SQLite 1万件: 0.06秒 ÷ 10,000件 = 6μs/件
これオンメモリーじゃね？
てかソースは出せないのか？

330:デフォルトの名無しさん
23/01/05 00:06:55.48 iqc5j6UOd.net
>>325
馬鹿はこんなソースを鵜呑みにするんだな
その上商用データベースはないし

331:デフォルトの名無しさん
23/01/05 00:38:18.87 HRGQlaN+r.net
>>329
SQLiteはファイルシステムのI/Oより高速
URLﾘﾝｸ(i.imgur.com)
>>330
商用で使われてるけど？
馬鹿は何も知らないんだな
URLﾘﾝｸ(i.imgur.com)
URLﾘﾝｸ(i.imgur.com)

332:デフォルトの名無しさん
23/01/05 01:37:59.87 sCQ59Dgt0.net
>>331
329は、"基本オンメモリで動作するSQlite"と、"通常ディスクで動作する(オンメモリもできなくはない)他DB"、
それらをそれぞれデフォかなんかわからない環境で比較してることに意味はあるの？ってことじゃないの？
両方オンメモリ(インメモリ)ならどうなるのかな？
たとえばMySQLならInsertが数十倍になった記憶はある(メモリの仕様にも依存するだろうけどね)
330は、商用データベースという言い方はちょっとズレてて、
商用ライセンスとサポートがないんじゃないのってことじゃないかな
使う案件によっては影響出るからね

333:デフォルトの名無しさん
23/01/05 01:48:13.14 iqc5j6UOd.net
>>331
馬鹿は商用データベースの意味がわからんような馬鹿か

334:デフォルトの名無しさん
23/01/05 02:03:08.48 2xtdBLfB0.net
別にケチ付けるまでもなく普通の結果じゃね
SQLiteはシンプルで排他であるがゆえにオーバーヘッドも少なく動くし
ファイル動作でもOSによるキャッシングも効きやすく（そこを割り切ったからこそのシンプルなDB）
デフォルトで理論値出やすいし

335:デフォルトの名無しさん
23/01/05 05:33:44.92 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:デフォルトの名無しさん
23/01/05 06:58:12.29 oM1k4p980.net
SQLiteは大規模なデータベースは無理なんだよ。
その点で住み分けは出来る。
とはいえ、SQLiteで9割カバー出来るだろな。
第一推奨がSQLite。

337:デフォルトの名無しさん
23/01/05 12:01:45.56 nNkP0Ncc0.net
こんなん、条件が特殊でしょw

338:デフォルトの名無しさん
23/01/05 12:18:31.66 uXoq84mk0.net
>>336
DB自体の規模はあまり問題ではない
SQLiteが無理なのは複数の人が同時にアクセスするようなDBで、その時点でDBのユースケースの9割からは外れる

339:デフォルトの名無しさん
23/01/05 13:09:47.11 HRGQlaN+r.net
>>335
少しは自分で調べたらどうか
でお前はSQLiteが速いと困るのか？
URLﾘﾝｸ(i.imgur.com)
URLﾘﾝｸ(i.imgur.com)
URLﾘﾝｸ(i.imgur.com)
URLﾘﾝｸ(i.imgur.com)
URLﾘﾝｸ(i.imgur.com)

340:デフォルトの名無しさん
23/01/05 13:21:32.96 jGVXI03l0.net
ファイル型のデータベースって言ったらユニケージやろ
URLﾘﾝｸ(www.usp-lab.com)
ロールバックはシンボリックリンクを手作業で張り替えればいいから安全

341:デフォルトの名無しさん
23/01/05 13:24:28.43 /79BsoYR0.net
情報はありがたいが出典は書いてほしいな。

342:デフォルトの名無しさん
23/01/05 14:39:37.45 O+NRT3S+0.net
>>339
１万件のselectで0.11sだったのに5,000件だと1.1sとかえらく遅くなったなw
そもそもSQLite 2.7.6って20年近く前のリリースやぞ...
URLﾘﾝｸ(www.sqlite.org)
まあこの頃のPostgresSQLは遅いので有名だったからこんなもんじゃね？

343:デフォルトの名無しさん
23/01/05 14:50:56.99 vkZCL/K50.net
ウェイトフリー、ロックフリーのキューにいれてシリアル化? 、直列化? すれば
多重アクセスでもSQliteでいいか?

344:デフォルトの名無しさん
23/01/05 14:53:54.58 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:デフォルトの名無しさん
23/01/06 00:44:53.18 Hz2m3Wai0.net
sndvol.exeやeartrumpetなどのアプリごとの音量調整アプリはどうやって実現させているのでしょうか
アプリごとに音量調整できるWindowsAPIがあるのですか？