现在有一篇文章,长度就和一般的新闻长度差不多
另外我数据库里有整理好的100万个关键词,现在需要用关键词去匹配文章里是否包含该关键,并返回关键词的列表!
必须用PHP实现,现在最头疼的就是效率问题,各位老大请赐教!

解决方案 »

  1.   

    2个 都hash 然后 分块匹配?
      

  2.   

    能不能先把关键词先缓存到文件,这样不需要去读db,估计会快点。但 100W 个去匹配一个新闻,这个的效率才是主要问题,暂时想不出好的办法
      

  3.   

    本帖最后由 xuzuning 于 2011-07-21 18:05:42 编辑
      

  4.   

    你现在的算法是什么呀,能先说一下吗?另外,100w 的关键词,光把这个加载到内存就挺耗时的了吧?……
    ————————————————————————————————
    基于CSDN论坛提供的插件扩展功能,自己做了个签名档工具,分享给大家,欢迎技术交流 :)
      

  5.   

    我没有你那么奢侈!下了一个 现代汉语常用词表en.txt 导入到数据库。大约5.6万字词
    然后做以下测试
    $s = '关键词我已经导入数据库了,也已经做好索引了,现在就是怎么才能提高匹配效率的问题回唠叨老大,我自己玩的,把全宋词、全唐诗分割以后得到的数据,垃圾数据分词我试过了,和原来数据至少一半都对不上了,而且效率也高不到哪儿去';//清空分词表
    mysql_query('TRUNCATE TABLE myword');
    $ar = str_split($s, 4); //按两个字切割
    $ar = array_merge($ar, str_split(substr($s, 2), 4));
    $ar = array_merge($ar, str_split($s, 6));
    $ar = array_merge($ar, str_split(substr($s, 2), 6));
    $ar = array_merge($ar, str_split(substr($s, 4), 6));//插入分词表
    foreach($ar as $c) {
      mysql_query("insert into myword values ('$c')");
    }
    $rs = mysql_query('select a.word, count(*) as cnt from myword a, word b where a.word=b.word group by b.word');
    while($r = mysql_fetch_assoc($rs)) {
      echo "$r[word] $r[cnt]<br />";
    }瞬间就完成了,所以没有测试速度。才能 1
    得到 1
    而且 1
    分割 1
    关键 1
    关键词 1
    就是 1
    垃圾 1
    唠叨 1
    老大 1
    哪儿 1
    匹配 1
    去 2
    数据 4
    数据库 1
    索引 1
    唐诗 1
    提高 1
    问题 1
    现在 1
    效率 2
    一半 1
    已经 2
    以后 1
    原来 1
    怎么 1
    至少 1
    自己 2
      

  6.   

    这种做法确实很强悍!这个“纯 SQL 解决方案”很有创意,haha不过按楼主给出的数据量来估计,词库数据量约 20 倍,待处理正文数据量姑且也算 20 倍,总的计算量就按 400 倍计算吧,再考虑到数据库 IO 瓶颈的因素,实际的性能表现不一定乐观。
      

  7.   

    之前的做法是将文章分词,存入关键字表,一个关键字可与多篇文章关联,然后根据关键字很容易定位到文章
    像LZ这种关键词比对有啥具体应有否?像过滤垃圾/屏蔽词什么的没可能有100w之巨吧。
      

  8.   

    我试着做了一个算法,简单介绍一下:预处理:根据词表构建一个树型结构的词典,词中的每一个字是一个节点,下一个字就是它的子节点。然后把这个数据结构写到一个 PHP 文件中,便于加载使用。实际匹配:加载树型结构的词典,然后对待处理文本进行线性扫描,在这个过程中跟词典进行比对,把发现的关键词统计下来。试验环境下,我找了一个 4w 多个词的词表,待处理文本约 2000 字。预处理过程用了约 20s,生成的 PHP 文件约 1.7M;匹配处理过程中,加载树型词典用了 0.29s,扫描匹配用了 0.03s。暂时没有找到 100w 的词表,所以不好判定实际效果。这个算法一个很大的不确定因素就是树型词典的加载问题,因为数据规模比较大,加载的速度和内存开销都有可能成为瓶颈,关于这个问题我前一段时间碰巧开贴提问,已经结贴,可以参考 关于 PHP 中巨型数据对象的内存开销问题的研究代码就先不贴了,我想先了解一下楼主现在的算法,免得露怯  :P
      

  9.   

    其实你需要的是快速定位,至于词牌名、曲牌名、诗人、典故等是次要的
    你可以将句子按内码(gbk)首字符分别保存于字典文件中(也就16个文件)
    这样可以缩小检索的范围,速度自然也就快了