大文件定位某一行？

[kaiser1992]

现有一个很大的文件(比如 40G 的文本)，假如我随机定位某一行，怎么样实现最快（时间和空间）？
希望 V 友们想什么说什么，畅所欲言

[shyling]

2333，先把它分成多个文件啊。。。例如 n 行一个文件。。。

[sola97]

社工库的既视感

[Fishdrowned]

其实并行只是理论上的优化方法，实际上 cpu 处理的速度应该是高于磁盘的吞吐量的（几百 MB/s，不考虑随机读的 iops 是因为这个可以规避）

[wangyucn]

@kaiser1992 `不建索引`等于`每次查询都要浪费一次建索引的时间`

想想如果你的要定位的行在文件靠后的位置，因为每行长度不固定，没索引势必要遍历整个文件。

我看不出不建索引有什么优势。也许你的意思是你这个查询只需要做一次？如果只做一次就直接遍历吧。

[ashfinal]

@realpg ultraedit 如果要搜索的话，还要遍历整个文件。这是不是意味着搜索的时候特别慢？

[realpg]

@ashfinal #65
具体没试过啊 我是没那种在几十个 G 的文本文件里找一个东西的需求 你可以自己试试

[sampeng]

从应用场景来说，如果只是达成这个目的。。我可能直接先把文件分成 n 个小文件。比如 1G 一个。。然后再算 seek 的目标在哪个文件里面。
只是做而做，感觉没有啥意义。。再快也没什么卵用

[ashfinal]

@realpg 我没有 windows，没有 ultraedit，也没有大文件……

[billlee]

@Fishdrowned #6 如果是一块硬盘，并发只会更慢

[SlipStupig]

elastic search

[rogerchen]

kv 数据库不就是为楼主而生。

[michael2016]

楼主，抬出我的意大利炮。。。

[lybtongji]

倍增法

[ashfinal]

@vjnjc MacVim 打开 227.6 MB 的文件也就 1s 左右，可以尝试禁用插件、关闭高亮等法子试试。

@realpg 我知道了！搜索是不耗时的，但是统计匹配项绝壁卡爆（因为需要遍历）。期待有人实验下证实我的想法。

[chunk]

很多人关注点都在建索引上,但建索引的算法很依赖于数据的 pattern(比如如果是日志文件,每行的长度差不多)

[elvodn]

让给文件那边直接给原生 int 数组二进制文件方便

[kotokz]

比 grep 快的当然有
the silver search, ag
ripgrep, rg

ripgrep 是 rust 写的，vsc 最近版本也集成了，蛮火

[kaiser1992]

@ashfinal 搜索不耗时？？

[ashfinal]

@kaiser1992 只搜索屏幕内容，而不是整个文件。

耗时小到不计。

[kaiser1992]

@ashfinal 你的 MacVim 读取文件是直接都读到内存了吧，你看看能否打开上 10G 的文件？