10GBのCSVファイルのソートが遅いのはなぜですか？

**デフォルトの名無しさん** · 2023/06/12(月) 21:20:45.91

CSVファイルは検索が速いって聞きました
ではなぜソートが遅いのでしょうか？

**デフォルトの名無しさん** · 2023/08/10(木) 01:18:52.99

10GB のデータをソートするには、
並べ替えた途中経過のデータも持っておく必要があるから、
100GBぐらいのメモリが必要なのでは？

メモリが少ないと、途中経過のデータをハードディスクに保存して、
メモリを空けないといけない。スワップ

**デフォルトの名無しさん** · 2023/08/10(木) 01:20:23.88

>>18
レコード数を3とする、ソートせよ

**デフォルトの名無しさん** · 2023/08/10(木) 02:07:49.13

ソートのキーだけでいい

**デフォルトの名無しさん** · 2023/08/10(木) 10:55:32.60

メモリーに乗りそうな大きさに分割してソートして
それをマージソートするのが一番早いんじゃね？

**デフォルトの名無しさん** · 2023/08/10(木) 11:29:41.03

>>20
レコード数が1でソートの必要がないかも知れない。

**デフォルトの名無しさん** · 2023/08/10(木) 11:33:16.87

>>1
検索早くないのでは？要するにただのテキストの塊なので grep コマンドとか使って検索できるってだけのことで、その状態ではインデックスなしの全検索だから遅くなると思う。

**デフォルトの名無しさん** · 2023/08/10(木) 20:54:16.43

10GBのファイルを書き換えながらソートしているのかな？

**デフォルトの名無しさん** · 2023/08/13(日) 12:14:40.57

Diskのデフラグ並みだな

**デフォルトの名無しさん** · 2023/08/16(水) 10:29:29.77

ｹﾞｯ!!(/|||￣▽)ｙ-ξ⌒◇ヾ(￣￣；)ｼﾞｭｯ

**デフォルトの名無しさん** · 2023/08/27(日) 20:18:09.89

(　 Д )　ﾟ　ﾟ

**デフォルトの名無しさん** · 2023/09/01(金) 20:23:04.85

どないやねん、意味がわからん

**デフォルトの名無しさん** · 2023/09/12(火) 12:29:39.47

何行何列か示せと

**デフォルトの名無しさん** · 2023/09/12(火) 12:38:34.37

>>30
1億行、125列

**デフォルトの名無しさん** · 2023/09/12(火) 12:46:05.28

こんな頭の悪いスレ上げるのはなぜですか？

**デフォルトの名無しさん** · 2023/09/12(火) 14:42:44.77

なぜ下げるんだい？

**デフォルトの名無しさん** · 2023/09/12(火) 14:59:33.38

なんで10GBもあるデータをCSVで管理しようと思ったんだろうな

**デフォルトの名無しさん** · 2023/09/12(火) 17:11:08.62

10GBもあるデータをCSVにしようとした訳ではなく
何も考えずにCSVで管理してたらいつの間にか10GBになったんだろう

**デフォルトの名無しさん** · 2023/09/12(火) 18:09:26.28

そっかｗ

**デフォルトの名無しさん** · 2023/09/14(木) 15:11:27.86

>>31
俺だったらなんでも良いからまずRDBに入れちゃうかも。
内容にもよるだろうが、とりあえずSQLiteとかな。

**デフォルトの名無しさん** · 2023/09/15(金) 19:50:24.13

巨大なデータをSQLiteで処理するためのメモ
https://fanぶろぐs.jp/scripts/archive/11/0

**デフォルトの名無しさん** · 2023/09/15(金) 20:30:51.52

やさいい

**デフォルトの名無しさん** · 2023/09/27(水) 20:16:21.16

まず各ブロック当たり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 で作ったのですが、なぜかデータがゼロに
なってしまうバグが出て作るのを止めてしまいました。ちゃんちゃん。駄目じゃん俺。

**デフォルトの名無しさん** · 2023/10/04(水) 21:29:03.45

だいたいデータの入れ替えに時間が掛かるんだよな
メディアがHDDとかだと尚更
普通はインデックスで実データを間接参照させるんだが
まあ、やって無いんだろうなぁ

**デフォルトの名無しさん** · 2023/10/05(木) 11:43:25.54

速度を優先するなら固定長CSVの採用をオススメする
各行へのランダムシークが出来るし並び替えに必要な行の入れ替えも可能になる
最近のutf-8などを使いたい場合は文字数での管理が難しくなるがあくまでもストレージ上でのサイズを基準にして
クラスタサイズも考慮し列サイズを決めていこう
検索性能を上げるには外部インデックスを作るしかないだろう
ファイルサイズは100倍ぐらいに増えるかもしれないが単純なファイルキャッシュだけで下手なDBでは敵わない速度が出せるだろう

**デフォルトの名無しさん** · 2023/10/08(日) 19:41:45.47

>>31
125列のレコードが1億行あったらカンマだけで10GB超えるんだが

**デフォルトの名無しさん** · 2023/10/12(木) 21:43:44.24

ひとつが100MBくらいのファイルになるように
ディレクトリ構造でB木をつくって(アンバランスでもOK)
個々にソートしたものを最後に結合

**デフォルトの名無しさん** · 2024/11/08(金) 00:13:58.03

csvだから遅いとかはない、デシリアライズして云々するよりそのままテキスト（あるいはその部分文字列、フィールド）として比較するならむしろ有利
単にサイズの問題、メモリより十分小さいサイズに分割（今どきなら数GBなんで100MBあたり）して個別にソート、マージ
むしろテキストにシリアライズされたデータにおいて、最も実用的な類のフォーマットに入る

**デフォルトの名無しさん** · 2025/05/10(土) 00:23:13.60

とすと

**デフォルトの名無しさん** · 2025/05/10(土) 14:35:35.59

クソスレかとおもったら想像以上に真面目に考察してるスレだったw

**デフォルトの名無しさん** · 2025/05/10(土) 20:02:05.08

マジレスはあるかもしれんが別に真面目な考察はないだろ
実は良スレだったんだと雰囲気で既成事実にするな

**デフォルトの名無しさん** · 2025/05/12(月) 11:20:32.62

DBをエクスポートしたら数GB出てきたとか普通だけど