单个 XML 文件为 100G 级别(客户拿 XML 文件当数据库。。。),现在需要在一台内存 1G 以内的机器上解析这些 XML 文件,主要是检索 XML 的某个节点的数据,可能会有少量的修改某个节点数据的操作
这种情况下,c++,c,java,python,中有哪些比较成熟的 XML 处理类库?因为某些原因,只能从这 4 中语言中选
1
Soar360 2022-09-23 09:29:23 +08:00
无所谓吧,这么大了。只能用 Reader 和 Writer 配合着干活儿了。
|
2
tool2d 2022-09-23 09:42:54 +08:00
我处理过几百 G 的 tif 文件,但是那个文件格式,有专门针对大型文件的特殊优化,读写都不需要很多内存。
纯 XML 就不一样了,上百 G 只能硬扫一遍了。 取巧的话,就当一个二进制文件处理,只搜索关键词和修改,不增加节点,不加长文件。 |
3
CaptainD 2022-09-23 09:56:49 +08:00
可以看看这个做个参考,我曾经用它处理几十 g 的 xml ,但是内存用量会慢慢增加,并不是纯流式,可能是我代码有缺陷
https://python3-cookbook.readthedocs.io/zh_CN/latest/c06/p04_parse_huge_xml_files_incrementally.html |
4
wangxiaoaer 2022-09-23 10:10:24 +08:00
随便找个 SAX 解析器就可以吧,不要 DOM 解析器。
https://stackoverflow.com/questions/26310595/how-to-parse-big-50-gb-xml-files-in-java |
5
reallynyn 2022-09-23 10:20:12 +08:00
100g 的 xml 文件???如果是分为 n 个 block 的还好办,如果都写在一个 block 里面。。你得解析 100g 的文本才能找到 closure ,这就很恐怖。。
|
6
jones2000 2022-09-23 12:02:19 +08:00 1
给 XML 文件做一个索引文件, 查询通过索引文件定位到文件偏移位置。插入,修改,删除以后更新索引文件。自己搞一下,不难。同时操作可能需要锁文件。
|
7
jifengg 2022-09-23 14:33:54 +08:00
随便说说,既然是当数据库用,那么应该满足:1 、标签结构相对简单(自己写解析代码不容易出问题); 2 、有大量是重复的数组(可以流式处理);
是否可以考虑自己写一个读写代码?写的代价有多大不清楚。 |
8
wxf666 2022-09-23 14:41:33 +08:00
上百 GB 的 XML ,咋修改某些节点?
若要在偏开头位置插入一字节的数据(或实际等效操作,如 999 修改为 1000 ),岂不要整个 100GB 往后挪 1 字节?? |
9
wxf666 2022-09-23 15:06:43 +08:00
@LuckyPocketWatch Python 有个 lxml 库*(该库是对 libxml2 的包装,速度很快)*,支持你说的『不需要解析树,查询某个节点』场景( SAX )
文档地址: https://lxml.de/tutorial.html#event-driven-parsing 另外,不考虑转成数据库嘛?我觉得这个场景,SQLite 的速度都能吊打 XML 。。 |
10
ipwx 2022-09-23 15:13:07 +08:00
你这个场景,要么自己做一个类似数据库的索引,直接根据索引定位 XML 文件内容。最后你会得到一个 custom database 。要么你干脆做一个读写抽象层,读的时候从数据库读,写的时候更新 XML 与数据库。
==== 另外吐槽一下 “可能会有少量的修改某个节点数据的操作” 在 XML 层面,凡是你修改了任何一个节点的数据,你都得把 100G 文件重新拷贝一份。我知道你希望找到一个假象中的类库,对于 XML 层面甚至可以原地修改。但是很抱歉,在操作系统原理上,这个是不可能的。 否则要数据库干嘛? |
11
ipwx 2022-09-23 15:13:44 +08:00 1
“可能会有少量的修改某个节点数据的操作”
反正我觉得就这一条,你就应该说服你的客户把 XML 换成数据库。因为在操作系统原理上,这个操作要做得快就是不可能的。 |
12
lookStupiToForce 2022-09-23 15:25:26 +08:00
每个星期都能在 v 站上被奇葩实现刷新三观
今天见到用 XML 当持久化大型数据库的了👍而且还要在 1g 内存的机器上解析 |
13
BigR 2022-09-23 17:18:20 +08:00
Sax 或 Stax 吧。采用流模型方式处理,比较节省内存。
|
14
v2eb 2022-09-23 19:21:41 +08:00 via Android
这文件以前咋保存这么大的
|
15
mizuBai 2022-09-24 16:25:47 +08:00 via iPhone
安利一下 HDF5 ,读写大量数据性能很好
|
16
wxf666 2022-09-26 11:28:27 +08:00
@mizuBai 没怎么用过。这货能利用索引,只读 几 KB ~ 几十 KB ,就能找到指定节点数据吗?
我觉得如果楼主 @LuckyPocketWatch 要换存储格式,这点很重要 另外,简单搜了搜资料,很多人都说 feather parquet pickle 等格式都比 hdf5 读写速度快、体积小 看来 csv 很不适合存大量数据了( json xml 同理) |