10GBのCSVファイルのソートが遅いのはなぜですか?
CSVファイルは検索が速いって聞きました
ではなぜソートが遅いのでしょうか? >>1君がバカなのは何故ですか
って言われて答えられないでしょうそれと同じ マジレスしとくと
スレタイの "10GB" と >>1 の質問が無関係だな 「…見なかったことにしといてやる!」と宣言すればおけ 昭∞!!!!
大∞!!!!!
昇∞!!!!!!
漠∞!!!!!!! >>1
速いと感じるか遅いと感じるかは個人の感覚の問題
何秒なら速いのか、何と比較して速いのか
他人が遅いというから遅いとか小学生かよ CSVのソートが遅いのは社会的共同体の中で自然に共有されうる普遍的事実である 実装次第で遅くなりそうなケースだな
フレームワークとコピペだけで戦ってきたやつには荷が重いだろう jsonやmessagepackよりは速いかも知れないな 10GBはファイルの大きさであって、データの件数ではないんだよな 10GB のデータをソートするには、
並べ替えた途中経過のデータも持っておく必要があるから、
100GBぐらいのメモリが必要なのでは?
メモリが少ないと、途中経過のデータをハードディスクに保存して、
メモリを空けないといけない。スワップ メモリーに乗りそうな大きさに分割してソートして
それをマージソートするのが一番早いんじゃね? >>20
レコード数が1でソートの必要がないかも知れない。 >>1
検索早くないのでは?要するにただのテキストの塊なので grep コマンドとか使って検索できるってだけのことで、その状態ではインデックスなしの全検索だから遅くなると思う。 10GBのファイルを書き換えながらソートしているのかな? ゲッ!!(/||| ̄▽)y-ξ⌒◇ヾ( ̄  ̄;)ジュッ なんで10GBもあるデータをCSVで管理しようと思ったんだろうな 10GBもあるデータをCSVにしようとした訳ではなく
何も考えずにCSVで管理してたらいつの間にか10GBになったんだろう >>31
俺だったらなんでも良いからまずRDBに入れちゃうかも。
内容にもよるだろうが、とりあえずSQLiteとかな。 巨大なデータを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 で作ったのですが、なぜかデータがゼロに
なってしまうバグが出て作るのを止めてしまいました。ちゃんちゃん。駄目じゃん俺。 だいたいデータの入れ替えに時間が掛かるんだよな
メディアがHDDとかだと尚更
普通はインデックスで実データを間接参照させるんだが
まあ、やって無いんだろうなぁ 速度を優先するなら固定長CSVの採用をオススメする
各行へのランダムシークが出来るし並び替えに必要な行の入れ替えも可能になる
最近のutf-8などを使いたい場合は文字数での管理が難しくなるがあくまでもストレージ上でのサイズを基準にして
クラスタサイズも考慮し列サイズを決めていこう
検索性能を上げるには外部インデックスを作るしかないだろう
ファイルサイズは100倍ぐらいに増えるかもしれないが単純なファイルキャッシュだけで下手なDBでは敵わない速度が出せるだろう >>31
125列のレコードが1億行あったらカンマだけで10GB超えるんだが ひとつが100MBくらいのファイルになるように
ディレクトリ構造でB木をつくって(アンバランスでもOK)
個々にソートしたものを最後に結合