在巨大的日志文件中搜索数百种模式

Question

我必须从网络服务器的 htdocs 目录中获取大量文件名，然后使用此文件名列表来搜索大量存档日志文件以查找这些文件的上次访问情况。

我计划在 C++ 中使用 Boost 来实现这一点。我会首先获取最新的日志，然后向后读取它，检查每一行是否有我得到的所有文件名。

如果文件名匹配，我会从日志字符串中读取时间并保存其上次访问的时间。现在我不需要再寻找这个文件，因为我只想知道上次访问的情况。

要搜索的文件名向量应该迅速减少。

我想知道如何使用多线程最有效地处理此类问题。

我是否对日志文件进行分区并让每个线程从内存中搜索日志的一部分，如果线程有匹配项，它会从文件名向量中删除该文件名，还是有更有效的方法来执行此操作？

Answer 1

尝试使用 mmap，它会减少你大量的脱发。我感觉很快，并且以一种奇怪的心情回忆起我的 mmap 知识，所以我写了一个简单的东西来帮助你开始。希望这有帮助！

mmap 的优点在于它可以轻松地与 OpenMP 并行化。这也是防止 I/O 瓶颈的好方法。让我首先定义 Logfile 类，然后我将介绍实现。

这是头文件 (logfile.h)

#ifndef _LOGFILE_H_
#define _LOGFILE_H_

#include <iostream>
#include <fcntl.h>
#include <stdio.h>
#include <string>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

using std::string;

class Logfile {

public:

    Logfile(string title);

    char* open();
    unsigned int get_size() const;
    string get_name() const;
    bool close();

private:

    string name;
    char* start;
    unsigned int size;
    int file_descriptor;

};

#endif

这是 .cpp 文件。

#include <iostream>
#include "logfile.h"

using namespace std;

Logfile::Logfile(string name){
    this->name = name;
    start = NULL;
    size = 0;
    file_descriptor = -1;

}

char* Logfile::open(){

    // get file size
    struct stat st;
    stat(title.c_str(), &st);

    size = st.st_size;

    // get file descriptor
    file_descriptor = open(title.c_str(), O_RDONLY);
    if(file_descriptor < 0){
        cerr << "Error obtaining file descriptor for: " << title.c_str() << endl;
        return NULL;
    }

    // memory map part
    start = (char*) mmap(NULL, size, PROT_READ, MAP_SHARED, file_descriptor, 0);
    if(start == NULL){
        cerr << "Error memory-mapping the file\n";
        close(file_descriptor);
        return NULL;
    }

    return start;
}

unsigned int Logfile::get_size() const {
    return size;
}

string Logfile::get_title() const {
    return title;
}

bool Logfile::close(){

    if( start == NULL){
        cerr << "Error closing file. Was closetext() called without a matching opentext() ?\n";
        return false;
    }

    // unmap memory and close file
    bool ret = munmap(start, size) != -1 && close(file_descriptor) != -1;
    start = NULL;
    return ret;

}

现在，使用此代码，您可以使用 OpenMP 来工作共享这些日志文件的解析，即

Logfile lf ("yourfile");
char * log = lf.open();
int size = (int) lf.get_size();

#pragma omp parallel shared(log, size) private(i)
{
  #pragma omp for
  for (i = 0 ; i < size ; i++) {
     // do your routine
  }
  #pragma omp critical
     // some methods that combine the thread results
}

Answer 2

将日志文件解析为数据库表 (SQLite ftw)。其中一个字段将是路径。

在另一个表中，添加您要查找的文件。

现在它是派生表上的简单联接。像这样的东西。

SELECT l.file, l.last_access FROM toFind f
LEFT JOIN ( 
    SELECT file, max(last_access) as last_access from logs group by file
) as l ON f.file = l.file

toFind 中的所有文件都将在那里，并且对于在日志中找不到的文件，last_access 将为 NULL。

Answer 3

好吧，这已经是几天前的事了，但我花了一些时间编写代码并在其他项目中使用 SQLite。

我仍然想将 DB-Approach 与 MMAP 解决方案进行比较，只是为了性能方面。

当然，如果您可以使用 SQL 查询来处理您解析的所有数据，那么它会为您节省大量工作。但我真的不关心工作量，因为我仍在学习很多东西，我从中学到的是：

这种 MMAP 方法 - 如果你正确实现它 - 在性能上绝对优越。如果您实现“字数统计”示例，您会注意到它的速度快得令人难以置信，该示例可以被视为 MapReduce Algo 的“hello world”。

现在，如果您想进一步从 SQL 语言中受益，正确的方法是实现您自己的 SQL-Wrapper，它也通过在线程之间共享查询的方式使用 Map-Reduce 类型。

您也许可以在线程之间按 ID 共享对象，其中每个线程处理它自己的数据库连接。然后它查询数据集中它自己的部分中的对象。

这比仅以通常的方式将内容写入 SQLite DB 要快得多。

毕竟您可以说：

MMAP 是处理字符串处理的最快方法
SQL 为解析器应用程序提供了强大的功能，但如果您不实现用于处理 SQL 查询的包装器，它会减慢速度