我们使用内存虚拟文件系统的目的主要有两方面：一是为了提升一些比较频繁的文件读写操作的速度，二是因为频繁的文件读写操作一定程度上对硬盘等物理介质有可能造成比较大的损耗，超出一定范畴还可能造成损伤。而内存的特点是速度快，并且更适应高频次的读写，唯一的缺点是相对容量较小，但随着现在内存动辄达到16G或更高，对于一般的文件处理已经具备了用内存来进行的条件。
下面的例子，就是在实际工作中遇到的问题，问题场景是这样的： 某企业多少年所有的销售记录都保存在一堆Excel文件中，这些Excel文件有几十个，每个当中包含时间跨度不等的该企业所有销售记录，并且包含所有产品，虽然有产品序号可供标识，但并没有按产品拆分开。现在要对其进行整理，希望达到的目标有两个，第一是希望对数据进行汇总，第二是希望按产品序号对销售数据进行拆分，以便以后查询和统计。
对问题和具体情况进行进一步分析可以看出，整体数据量达到了近2个G，汇总和拆分工作用Excel当然也可以直接做，但Excel属于重量级软件，本身就慢，叠加数据量这么大以后就更难以接受，另外手工处理数十个大文件也不太好办。而数据量虽大，但并没有达到我们内存无法承载的程度，毕竟内存8个G以上现在已经基本成了标配。
Gox语言自带的内存虚拟文件系统包，好处之一就是不像一般的RamDisk软件那样，需要事先划分出固定大小的一块内存作为虚拟文件系统（虚拟硬盘），而是可以随着用量自行扩展占用的内存。
因此，我们可以这样设计：使用内存文件系统先将几十个Excel文件归并成一个大的CSV文件实现销售数据的汇总，然后再将其按产品序号拆分出一个个的小CSV文件，每个文件对应一个产品的销售记录。CSV文件的好处是，其实质其实是以行为基础的纯文本文件，因此用计算机程序处理非常方便，但也可以直接用Excel直接打开进行灵活的排序、筛选等处理。
下面第一段代码就实现了将几十个Excel文件归并为一个大的CSV文件。
// 给github.com/360EntSecGroupSkylar/excelize起一个简称为excel
excel = github_360EntSecGroupSkylar_excelize
// 给标准库包path/filepath起一个简称
filepath = path_filepath
// 设置文件操作的根目录，用于保存最后生成的汇总文件
basePathG = `d:\tmpx\sp`
// 从命令行获取要处理的所有Excel文件所在的文件夹路径
pathT = getParameter(argsG, 1, `D:\share\销售数据20200701`)
// 生成该目录下所有的Excel文件的列表
fileListT = tk.GenerateFileListRecursively(pathT, "*.XLSX", false)
// 新建一个内存虚拟文件系统
mfs = memfs.NewMemFS()
// 在内存文件系统中创建根目录下的output.csv文件
of, err = mfs.Create("/output.csv")
// 检查创建文件过程中是否出错，如果有错则输出信息后退出
checkError(err)
// 新建一个CSV文件的writer（写入器对象）
// 用于写入汇总的销售数据
w = encoding_csv.NewWriter(of)
// 循环遍历所有Excel文件进行处理
for i, v = range fileListT {
// 如果文件名以“~$”开头，说明是Excel的临时文件，跳过
if tk.Contains(v, "~$") {
continue
}
// 输出正在处理第几行的信息
pl("processing [%v/%v] %v ...", i+1, len(fileListT), v)
// 逐个打开包含销售数据的Excel文件
f, errT = excel.OpenFile(v)
checkError(errT)
// 获取第一个表所有行列的数据
// 结果是一个[][]string类型的二维数组
rowsT, errT = f.GetRows(f.GetSheetName(0))
checkError(errT)
// 因为所有Excel文件内格式都一样，并且第一行都是表头
// 因此，只有第一个文件才将表头（第一行）写入汇总CSV文件中
// 后面的文件都将跳过第一行，只写入后面的行
if i == 0 {
w.WriteAll(rowsT)
} else {
w.WriteAll(rowsT[1:])
}
// WriteAll函数会自己进行Flush操作，所以无需再手动刷新缓存
// 检查并处理写入中可能发生的错误
errT = w.Error()
checkErrf("failed to write output csv file: %v", errT)
}
// 确保要关闭输出文件
of.Close()
// 将内存文件中的输出文件拷贝到真实文件系统中
// 否则程序退出后，内存文件系统将不复存在
// 其中的文件当然也会丢失
// CopyFileTo函数中加入“-force”参数表示文件存在的话会覆盖
err = mfs.CopyFileTo(`/output.csv`, path_filepath.Join(basePathG, `saleOutput.csv`), "-force")
plv(err)
// pass函数一般用于脚本正常结束，保证不输出多余信息
// 如果是单脚本执行，也可以不写这一句
pass()
这样，我们就实现了所有销售数据归并到了一个大的CSV文件中。注意，所有原始的Excel文件格式要完全一致才能如此操作。
下面我们来以汇总的CSV文件为基础，将其按产品序号拆分成每个产品一个小CSV文件。每个拆分后的CSV文件将以该产品序号作为名称，再加上“.txt”后缀。
// 设置path/filepath包的简称
filepath = path_filepath
// 设置数据文件所在的根目录
basePathG = `d:\tmpx\sp`
// 设置输出的小CSV文件的目录
saleDataPathT = filepath.Join(basePathG, "saleData")
// 确保该目录存在，如果没有则创建它
tk.EnsureMakeDirs(saleDataPathT)
// 新建内存虚拟文件系统
mfs = memfs.NewMemFS()
// 在虚拟文件系统中确保创建根目录
mfs.EnsureMakeDirs("/")
// 打开上个例子中输出的汇总文件以备读取
f, err = os.Open(filepath.Join(basePathG, `saleOutput.csv`))
// 确保之后关闭该文件（defer后的函数将在本函数或脚本退出时被执行）
defer f.Close()
// 新建一个CSV的读取器对象用于从汇总文件中读取一条条的记录
r = encoding_csv.NewReader(f)
// 将序号清零
i = 0
// AppendLineToFile函数用于向输出文件中增加一行销售记录
// 参数中lineA表示要增加的销售记录，类型应为[]string，即字符串数组
// 每一项是一个字段的数值
// fileA是要追加写入的文件名称
func AppendLineToFile(lineA, fileA) {
// 在虚拟文件系统中打开要写入的产品销售数据文件
// 如果不存在，则创建它
fileT, err := mfs.OpenFile(fileA, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
checkErrf("failed to open file: %v", err)
defer fileT.Close()
// 新建一个写入器对象并写入该条记录
writerT := encoding_csv.NewWriter(fileT)
writerT.Write(lineA)
writerT.Flush() // 由于Write函数并不自带Flush，所以要手动进行
}
// 无限循环（因为不能预知文件有多少行，因此只能文件全部读取完后退出）
for true {
// 读取一行
line, err = r.Read()
// 将序号递增
i ++
// 如果到了文件结尾（文件读完），则中止循环
if err == io.EOF {
break
}
// 如果是其他错误，则退出程序执行
checkErrf("failed to read content: %v, line: %v", err, line)
// 第一行是表头，跳过
if i == 1 {
continue
}
// 汇总销售记录中的第4个字段（字段序号是3）代表了该记录的产品序号
// 因此，将该条记录添加到以此为名称的拆分销售数据文件中去
AppendLineToFile(line, `/`+line[3]+`.txt`)
}
// 最后将虚拟文件系统中的所有拆分销售数据文件拷贝到真实文件系统中
// CopyFilesTo用于将内存虚拟文件系统中某个目录下所有文件（包含子目录下的）拷贝到真实文件系统中
// 第一个参数是指定的源目录，第二个参数是文件pattern（“*”代表所有文件），第三个参数是目标路径，-force参数表示如果已存在某文件则覆盖写入
plvsr(mfs.CopyFilesTo("/", "*", saleDataPathT, "-force"))
至此，整个任务顺利完成。实际工作中，汇总文件总数据达到了2G，销售数据记录条数达到了3000多万条，拆分文件个数达到了3万多个。这个要用真实文件系统来做，估计很多开发者会心疼自己的硬盘，毕竟3000多万条记录意味着最终文件系统读取和写入次数就有至少6000多万次（实际上还不止，还有一些其他开销）。而用内存操作，用通俗的话说，“它就是干这个的”，内存也确实就是适合高频次的读写操作的。最后，将内存中的文件复制到真实文件系统中，仅需一次操作，损耗达到了最小，也实现了数据的持久化，避免了内存断电后数据丢失，完美实现了内存与硬盘的各司其职、各尽所长。
网友评论