传统的 pdf 索引解决方案与基于图形的版本相比
Traditional pdf indexing solution compared to graph-based version
我的目的是索引包含 pdf 文件(以及其他文件类型)的任意目录,其中关键字存储在列表中。我有一个传统的解决方案,我听说基于图形的解决方案使用例如SimpleGraph 可以更 elegant/efficient 并且独立于目录结构。
基于图的解决方案(例如 SimpleGraph)会是什么样子?
传统解决方案
//
List<File> pdfFiles = this.explorePath(TestPDFFiles.RFC_DIRECTORY, "pdf");
List<PDFFile> pdfs = this.getPdfsFromFileList(pdfFiles);
…
for (PDFFile pdf:pdfs) {
//
if (org.apache.commons.lang3.StringUtils.containsIgnoreCase(pdf.getText(), keyWord)) {
foundList.add(pdf.file.getName()); // here we access by structure (early binding)
// - in the graph solution by name (late binding)
}
}
基本上,对于 SimpleGraph,您将使用模块的组合
- 文件系统
- PDF系统
使用 FileSystem 模块,您可以收集目录中的文件图并过滤它以仅包含扩展名为 pdf 的文件 - 然后您使用 PDFSystem 分析 PDF 以获得 page/text 结构 - 有已经在 simplegraph-bundle 模块中对此进行了测试用例,展示了它如何使用一些 RFC pdf 作为输入。
我现在添加了索引测试,见下文。
核心功能取自旧测试,搜索单个关键字并允许将其作为参数:
List<Object> founds = pdfSystem.g().V().hasLabel("page")
.has("text", RegexPredicate.regex(".*" + keyWord + ".*")).in("pages")
.dedup().values("name").toList();
这是一个 gremlin 查询,它将通过一次调用在整个 PDF 文件树中搜索来完成大部分工作。我认为这更优雅,因为您不必关心输入的结构(tree/graph/filesystem/database,等等...)
JUnit 测试用例
@Test
/**
* test for https://github.com/BITPlan/com.bitplan.simplegraph/issues/12
*/
public void testPDFIndexing() throws Exception {
FileSystem fs = getFileSystem(RFC_DIRECTORY);
int limit = Integer.MAX_VALUE;
PdfSystem pdfSystem = getPdfSystemForFileSystem(fs, limit);
Map<String, List<String>> index = this.getIndex(pdfSystem, "ARPA",
"proposal", "plan");
// debug=true;
if (debug) {
for (Entry<String, List<String>> indexEntry : index.entrySet()) {
List<String> fileNameList = indexEntry.getValue();
System.out.println(String.format("%15s=%3d %s", indexEntry.getKey(),
fileNameList.size(), fileNameList));
}
}
assertEquals(14,index.get("ARPA").size());
assertEquals(9,index.get("plan").size());
assertEquals(8,index.get("proposal").size());
}
我的目的是索引包含 pdf 文件(以及其他文件类型)的任意目录,其中关键字存储在列表中。我有一个传统的解决方案,我听说基于图形的解决方案使用例如SimpleGraph 可以更 elegant/efficient 并且独立于目录结构。
基于图的解决方案(例如 SimpleGraph)会是什么样子?
传统解决方案
//
List<File> pdfFiles = this.explorePath(TestPDFFiles.RFC_DIRECTORY, "pdf");
List<PDFFile> pdfs = this.getPdfsFromFileList(pdfFiles);
…
for (PDFFile pdf:pdfs) {
//
if (org.apache.commons.lang3.StringUtils.containsIgnoreCase(pdf.getText(), keyWord)) {
foundList.add(pdf.file.getName()); // here we access by structure (early binding)
// - in the graph solution by name (late binding)
}
}
基本上,对于 SimpleGraph,您将使用模块的组合
- 文件系统
- PDF系统
使用 FileSystem 模块,您可以收集目录中的文件图并过滤它以仅包含扩展名为 pdf 的文件 - 然后您使用 PDFSystem 分析 PDF 以获得 page/text 结构 - 有已经在 simplegraph-bundle 模块中对此进行了测试用例,展示了它如何使用一些 RFC pdf 作为输入。
我现在添加了索引测试,见下文。
核心功能取自旧测试,搜索单个关键字并允许将其作为参数:
List<Object> founds = pdfSystem.g().V().hasLabel("page")
.has("text", RegexPredicate.regex(".*" + keyWord + ".*")).in("pages")
.dedup().values("name").toList();
这是一个 gremlin 查询,它将通过一次调用在整个 PDF 文件树中搜索来完成大部分工作。我认为这更优雅,因为您不必关心输入的结构(tree/graph/filesystem/database,等等...)
JUnit 测试用例
@Test
/**
* test for https://github.com/BITPlan/com.bitplan.simplegraph/issues/12
*/
public void testPDFIndexing() throws Exception {
FileSystem fs = getFileSystem(RFC_DIRECTORY);
int limit = Integer.MAX_VALUE;
PdfSystem pdfSystem = getPdfSystemForFileSystem(fs, limit);
Map<String, List<String>> index = this.getIndex(pdfSystem, "ARPA",
"proposal", "plan");
// debug=true;
if (debug) {
for (Entry<String, List<String>> indexEntry : index.entrySet()) {
List<String> fileNameList = indexEntry.getValue();
System.out.println(String.format("%15s=%3d %s", indexEntry.getKey(),
fileNameList.size(), fileNameList));
}
}
assertEquals(14,index.get("ARPA").size());
assertEquals(9,index.get("plan").size());
assertEquals(8,index.get("proposal").size());
}