CSVファイルは検索が速いって聞きました
ではなぜソートが遅いのでしょうか?
0002デフォルトの名無しさん2023/06/13(火) 08:52:56.97ID:JBnp9ago
べ、べつに遅くないし!
>>1君がバカなのは何故ですか
って言われて答えられないでしょうそれと同じ 0004デフォルトの名無しさん2023/06/13(火) 09:53:59.11ID:meEyuUg2
マジレスしとくと
スレタイの "10GB" と >>1 の質問が無関係だな 「…見なかったことにしといてやる!」と宣言すればおけ
0009デフォルトの名無しさん2023/06/29(木) 13:51:47.41ID:IO1TL2jD
10GBだから
0010デフォルトの名無しさん2023/06/30(金) 03:16:09.95ID:KO9roK1Y
昭∞!!!!
大∞!!!!!
昇∞!!!!!!
漠∞!!!!!!!
0011デフォルトの名無しさん2023/08/09(水) 07:21:27.86ID:Bb1AJAu+
>>1
速いと感じるか遅いと感じるかは個人の感覚の問題
何秒なら速いのか、何と比較して速いのか
他人が遅いというから遅いとか小学生かよ 0012デフォルトの名無しさん2023/08/09(水) 07:46:15.85ID:Aj0Whal0
0013デフォルトの名無しさん2023/08/09(水) 07:47:25.44ID:Aj0Whal0
CSVのソートが遅いのは社会的共同体の中で自然に共有されうる普遍的事実である
0015デフォルトの名無しさん2023/08/09(水) 11:06:02.05ID:qEKEd4/l
何をつかっても遅いものは遅いw
実装次第で遅くなりそうなケースだな
フレームワークとコピペだけで戦ってきたやつには荷が重いだろう
jsonやmessagepackよりは速いかも知れないな
0018デフォルトの名無しさん2023/08/10(木) 00:02:20.56ID:gjwqjVE1
10GBはファイルの大きさであって、データの件数ではないんだよな
10GB のデータをソートするには、
並べ替えた途中経過のデータも持っておく必要があるから、
100GBぐらいのメモリが必要なのでは?
メモリが少ないと、途中経過のデータをハードディスクに保存して、
メモリを空けないといけない。スワップ
0020デフォルトの名無しさん2023/08/10(木) 01:20:23.88ID:lIBN6+0k
0021デフォルトの名無しさん2023/08/10(木) 02:07:49.13ID:ljCEt4I+
ソートのキーだけでいい
メモリーに乗りそうな大きさに分割してソートして
それをマージソートするのが一番早いんじゃね?
0023デフォルトの名無しさん2023/08/10(木) 11:29:41.03ID:YYBOmFjO
>>20
レコード数が1でソートの必要がないかも知れない。 0024デフォルトの名無しさん2023/08/10(木) 11:33:16.87ID:YYBOmFjO
>>1
検索早くないのでは?要するにただのテキストの塊なので grep コマンドとか使って検索できるってだけのことで、その状態ではインデックスなしの全検索だから遅くなると思う。 0025デフォルトの名無しさん2023/08/10(木) 20:54:16.43ID:TWiH3Zx3
10GBのファイルを書き換えながらソートしているのかな?
ゲッ!!(/||| ̄▽)y-ξ⌒◇ヾ( ̄  ̄;)ジュッ
0030デフォルトの名無しさん2023/09/12(火) 12:29:39.47ID:QOX8wfhQ
何行何列か示せと
0031デフォルトの名無しさん2023/09/12(火) 12:38:34.37ID:A3YXlMvb
0033デフォルトの名無しさん2023/09/12(火) 14:42:44.77ID:A3YXlMvb
なぜ下げるんだい?
なんで10GBもあるデータをCSVで管理しようと思ったんだろうな
0035デフォルトの名無しさん2023/09/12(火) 17:11:08.62ID:zmLL4dpk
10GBもあるデータをCSVにしようとした訳ではなく
何も考えずにCSVで管理してたらいつの間にか10GBになったんだろう
0037デフォルトの名無しさん2023/09/14(木) 15:11:27.86ID:Ur1UGoF9
>>31
俺だったらなんでも良いからまずRDBに入れちゃうかも。
内容にもよるだろうが、とりあえずSQLiteとかな。 0038デフォルトの名無しさん2023/09/15(金) 19:50:24.13ID:V4ggyvBY
巨大なデータをSQLiteで処理するためのメモ
https://fanぶろぐs.jp/scripts/archive/11/0 まず各ブロック当たり1000行とかに分ける。ブロック単位でソートする。
1.ブロックA/B を連結してAB間でソート。 B=全体の数/2
2.ブロックA+1, B+1 で連結してソート
3. ブロックA+全体の数/2- 1(前半最後まで)、ブロックB+前半最後までを連結してソート
4.今度は全体の前半で1-3 風にブロックソート。後半〜最後までで1-3 風にブロックソート
5. 前半〜前半+3/4 でブロックソート、前半+2/4〜前半+4/4 でブロックソート、
......
・・・・
ってのを大昔 BASIC で作ったのですが、なぜかデータがゼロに
なってしまうバグが出て作るのを止めてしまいました。ちゃんちゃん。駄目じゃん俺。
0041デフォルトの名無しさん2023/10/04(水) 21:29:03.45ID:ja1//dn8
だいたいデータの入れ替えに時間が掛かるんだよな
メディアがHDDとかだと尚更
普通はインデックスで実データを間接参照させるんだが
まあ、やって無いんだろうなぁ
0042デフォルトの名無しさん2023/10/05(木) 11:43:25.54ID:AvBTKCCq
速度を優先するなら固定長CSVの採用をオススメする
各行へのランダムシークが出来るし並び替えに必要な行の入れ替えも可能になる
最近のutf-8などを使いたい場合は文字数での管理が難しくなるがあくまでもストレージ上でのサイズを基準にして
クラスタサイズも考慮し列サイズを決めていこう
検索性能を上げるには外部インデックスを作るしかないだろう
ファイルサイズは100倍ぐらいに増えるかもしれないが単純なファイルキャッシュだけで下手なDBでは敵わない速度が出せるだろう
>>31
125列のレコードが1億行あったらカンマだけで10GB超えるんだが ひとつが100MBくらいのファイルになるように
ディレクトリ構造でB木をつくって(アンバランスでもOK)
個々にソートしたものを最後に結合