gpt4 book ai didi

xml - 尽可能快地处理 40M 的文档(和索引)

转载 作者:数据小太阳 更新时间:2023-10-29 02:16:56 40 4
gpt4 key购买 nike

祝你有美好的一天。所以我的问题基本上是这样的,我需要处理 37.800.000 个文件。

每个"file"真的不止这些,我有的是:

  • 37.800.000 个 XML 文档。
  • 超过 120.000.000 张 Tiff 图片。

每个 XML 文档都引用一个或多个 Tiff 图像,并为其所代表的图像提供一组通用关键字。

我需要构建的是一个解析每个 XML 文件的系统(不仅有我需要的关键字,还有很多垃圾)。对于每个文件,它需要在数据库中存储索引(作为列)和图像的路径(也在数据库中),路径只是因为我认为将图像也存储在里面不是一个好主意.

最终目的是用户可以使用索引关键字搜索数据库,系统加载与该索引关联的图像。

我已经使用 XPath 构建了解析器,并且还定义了数据库的架构(这很简单)。但是我遇到了两件事,这导致我的系统工作非常缓慢并且偶尔会抛出 SQLExceptions:

我想,为了在处理文件时不填满 pc 内存,我需要一种分页代码但相反,以便将相应的项目发送到数据库(例如,每 1000 个文件打包一次),所以,如何实现这是我的第一个问题。

第二个是 XML 文件不是连续命名的,所以我需要像这样处理重复项:当尝试索引和现有图像或图像时(通过查看其唯一键名是否也在数据库中),我需要将该图像索引日期与最新的索引图像进行比较,以查看必须删除哪些重复项(系统只关注最新索引,通过查看索引文件日期关键字)。

有人知道如何解决这个问题吗?我正在使用 Java 作为解析器,使用 JSP 作为图像搜索门户,同时还使用 MySQL。

提前致谢。

这是其中一个索引文件的结构。

图像文件位于“FileInfo”元素的“dwFileName”属性中。当前索引文档的文件名为“DW5BasketFileName”。如果有多个具有相同索引的图像,则除了扩展名(它以 001 开头并继续计数)之外,还有更多索引文件是相等的。

每个文档的平均大小为 4KB。

<DWDocument DW5BasketFileName="DOCU0001.001">
<FileInfos>
<ImageInfos>
<ImageInfo id="0,0,0" nPages="0">
<FileInfo fileName="c:\bandejas\otra5\D0372001.DWTiff" dwFileName="D0001001.DWTiff" signedFileName="D0372001.DWTiff" type="normal" length="66732" />
</ImageInfo>
</ImageInfos>
</FileInfos>
<FileDatas />
<Section number="0" startPage="0" dwguid="d3f269ed-e57b-4131-863f-51d147ae51a3">
<Metadata version="0">
<SystemProperties>
<DocID>36919</DocID>
<DiskNo>1</DiskNo>
<PageCount>1</PageCount>
<Flags>2</Flags>
<StoreUser>DIGITAD1</StoreUser>
<Offset>0</Offset>
<ModificationUser>ESCANER1</ModificationUser>
<StoreDateTime>2009-07-23T21:41:18</StoreDateTime>
<ModificationDateTime>2009-07-24T14:36:03</ModificationDateTime>
</SystemProperties>
<FieldProperties>
<TextVar length="20" field="NO__REGISTRO" id="0">10186028</TextVar>
<TextVar length="20" field="IDENTIFICACION" id="1">85091039325</TextVar>
<TextVar length="40" field="APELLIDOS" id="32">DYMINSKI MORALES</TextVar>
<TextVar length="40" field="NOMBRES" id="33">JHONATAN OSCAR</TextVar>
<Date field="FECHA_DEL_REGISTRO" id="64">1985-10-10T00:00:00</Date>
</FieldProperties>
<DatabaseProperties />
<StoreProperties DocumentName="10/10/1985 12:00:00 a.m." />
</Metadata>
<Page number="0">
<Rendition type="original">
<Content id="0,0,0" pageNumberInFile="0" />
<Annotation>
<Layer id="1" z_order="0" dwguid="5c52b1f0-c520-4535-9957-b64aa7834264">
<LayerLocation x="0" y="0" />
<CreateUser>ESCANER1</CreateUser>
<CreateTime>2009-07-24T14:37:28</CreateTime>
<Entry dwguid="d36f8516-94ce-4454-b835-55c072b8b0c4">
<DisplayFlags>16</DisplayFlags>
<CreateUser>ESCANER1</CreateUser>
<CreateTime>2009-07-24T14:37:29</CreateTime>
<Rectangle x="6" y="0" width="1602" height="20" flags="0" size="10" color="#ffffff" bkgcolor="#000000" />
</Entry>
<Entry dwguid="b2381b9f-fae2-49e7-9bef-4d9cf4f15a3f">
<DisplayFlags>16</DisplayFlags>
<CreateUser>ESCANER1</CreateUser>
<CreateTime>2009-07-24T14:37:31</CreateTime>
<Rectangle x="1587" y="23" width="21" height="1823" flags="0" size="10" color="#ffffff" bkgcolor="#000000" />
</Entry>
<Entry dwguid="9917196d-4384-4052-8193-8379a61be387">
<DisplayFlags>16</DisplayFlags>
<CreateUser>ESCANER1</CreateUser>
<CreateTime>2009-07-24T14:37:33</CreateTime>
<Rectangle x="0" y="1836" width="1594" height="10" flags="0" size="10" color="#ffffff" bkgcolor="#000000" />
</Entry>
<Entry dwguid="3513e0c8-a6c9-42ec-ae9c-dc084376fcdb">
<DisplayFlags>16</DisplayFlags>
<CreateUser>ESCANER1</CreateUser>
<CreateTime>2009-07-24T14:37:35</CreateTime>
<Rectangle x="0" y="0" width="23" height="1839" flags="0" size="10" color="#ffffff" bkgcolor="#000000" />
</Entry>
</Layer>
<DW4CheckSum dwCheckSum="1479972439" dwDate="131663617" dwTime="319564778" dwImageSize="66732" dwSource="0" source="" />
</Annotation>
</Rendition>
</Page>
</Section>
</DWDocument>

最佳答案

我想说,这里的第一个问题来自磁盘访问时间。即使您的 xml 文件只有 1k,它们也会达到 37GB 的数据,这需要时间来阅读。对此无能为力。

但是,您可以确保不会浪费额外的时间进行其他不必要的阻塞计算。

  1. 如果数据库也在同一个磁盘中,批处理应该远大于 1000,您希望在内存允许的情况下尽可能少地访问数据库(如果 xml 文件连续存储在磁盘中)
  2. 确保尽快释放变量,以便垃圾收集器可以释放内存。
  3. 您想在计算机等待读取文件时执行 xml 解析,因此您应该设置另一个线程来并行执行这些任务。

至于你的第二个问题,你可以为每个图像,对具有相同索引的图像执行更新 sql 语句,如果没有更新行,则将此图像插入新行。这是否会比使用选择后跟插入/更新更好,取决于您拥有的重复项的百分比。

我假设 xml 文件的创建速度不会比您处理它们的速度快,如果是这种情况,您需要做的就是将已经处理过的文件名保存到数据库或到一个平面文件并在下次启动时读回它们,确保您不必重新开始。

关于xml - 尽可能快地处理 40M 的文档(和索引),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1575552/

40 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com