CSVファイルは検索が速いって聞きました
ではなぜソートが遅いのでしょうか？
「…見なかったことにしといてやる！」と宣言すればおけ
昭∞！！！！
大∞！！！！！
昇∞！！！！！！
漠∞！！！！！！！
CSVのソートが遅いのは社会的共同体の中で自然に共有されうる普遍的事実である
実装次第で遅くなりそうなケースだな
フレームワークとコピペだけで戦ってきたやつには荷が重いだろう
jsonやmessagepackよりは速いかも知れないな
10GBはファイルの大きさであって、データの件数ではないんだよな
10GB のデータをソートするには、
並べ替えた途中経過のデータも持っておく必要があるから、
100GBぐらいのメモリが必要なのでは？
メモリが少ないと、途中経過のデータをハードディスクに保存して、
メモリを空けないといけない。スワップ
メモリーに乗りそうな大きさに分割してソートして
それをマージソートするのが一番早いんじゃね？
>>1 検索早くないのでは？要するにただのテキストの塊なので grep コマンドとか使って検索できるってだけのことで、その状態ではインデックスなしの全検索だから遅くなると思う。
10GBのファイルを書き換えながらソートしているのかな？
ｹﾞｯ!!(/|||￣▽)ｙ-ξ⌒◇ヾ(￣ ￣；)ｼﾞｭｯ
なんで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)
個々にソートしたものを最後に結合
csvだから遅いとかはない、デシリアライズして云々するよりそのままテキスト（あるいはその部分文字列、フィールド）として比較するならむしろ有利
単にサイズの問題、メモリより十分小さいサイズに分割（今どきなら数GBなんで100MBあたり）して個別にソート、マージ
むしろテキストにシリアライズされたデータにおいて、最も実用的な類のフォーマットに入る
ブックマークへ