有效地将大文件读入地图

Question

我正在尝试编写代码以在 Haskell 中执行以下简单任务：使用该字典查找单词的词源，该字典存储为一个大的 tsv 文件 (http://www1.icsi.berkeley.edu/~demelo/etymwn/)。我想我会（使用 attoparsec）将 tsv 文件解析为一个 Map，然后我可以根据需要使用它来有效地查找词源（并做一些其他的事情）。

这是我的代码：

{-# LANGUAGE OverloadedStrings #-}

import Control.Arrow
import qualified Data.Map as M
import Control.Applicative
import qualified Data.Text as DT
import qualified Data.Text.Lazy.IO as DTLIO
import qualified Data.Text.Lazy as DTL
import qualified Data.Attoparsec.Text.Lazy as ATL
import Data.Monoid

text = do
    x <- DTLIO.readFile "../../../../etymwn.tsv"
    return $ DTL.take 10000 x

--parsers
wordpair = do
    x <- ATL.takeTill (== ':')
    ATL.char ':' *> (ATL.many' $ ATL.char ' ')
    y <- ATL.takeTill (\x -> x `elem` ['\t','\n'])
    ATL.char '\n' <|>   ATL.char '\t'
    return (x,y)

--line of file
line = do
    a <- (ATL.count 3 wordpair)
    case (rel (a !! 2)) of 
        True -> return . (\[a,b,c] -> [(a,c)]) $ a
        False -> return . (\[a,b,c] -> [(c,a)]) $ a
    where rel x = if x == ("rel","etymological_origin_of") then False else True

tsv = do 
    x <- ATL.many1 line
    return $ fmap M.fromList x

main = (putStrLn . show . ATL.parse tsv) =<< text

它适用于少量输入，但很快就会变得太低效。我不太清楚问题出在哪里，并且很快意识到即使是像查看文件的最后一个字符这样的琐碎任务，在我尝试时也会花费太长时间，例如与

foo = fmap DTL.last $ DTLIO.readFile "../../../../etymwn.tsv

所以我的问题是：在方法和执行方面，我主要做错了什么？有关更多 Haskelly/更好代码的任何提示？

谢谢，

鲁本

Answer 1

请注意，您要加载的文件有 600 万行，并且 您有兴趣存储的文本包括大约。 120 MB。

下界

为了建立一些下限，我首先创建了另一个 .tsv 文件，其中包含 etymwn.tsv 文件的预处理内容。然后我计时了 让这个 perl 程序读取那个文件：

my %H;
while (<>) {
  chomp;
  my ($a,$b) = split("\t", $_, 2);
  $H{$a} = $b;
}

这大约花了。 17 秒，所以我希望任何 Haskell 程序都能 慢慢来吧。

如果此启动时间不可接受，请考虑以下选项：

1. 在 ghci 中工作并使用“实时重新加载”技术来保存地图 使用Foreign.Store package 以便它通过 ghci 代码重新加载持续存在。 这样，您只需在迭代代码时加载一次地图数据。
2. 使用持久键值存储（例如 sqlite、gdbm、BerkeleyDB）
3. 通过客户端-服务器存储访问数据
4. 减少您存储的键值对的数量（您需要全部 600 万对吗？）

Chris Done 在这篇博文中讨论了选项 1：

• Reload Running Code in GHCI

选项 2 和 3 将要求您在 IO monad 中工作。

解析

首先，检查tsv函数的类型：

tsv :: Data.Attoparsec.Internal.Types.Parser
          DT.Text [M.Map (DT.Text, DT.Text) (DT.Text, DT.Text)]

您返回的是地图列表，而不仅仅是一张地图。这看起来不像 对。

其次，正如@chi 所建议的，我怀疑使用attoparsec 是懒惰的。 特别是，它必须验证整个解析是否成功， 所以我看不出它如何无法避免创建所有已解析的行 在返回之前。

要真正懒惰地解析输入，采取以下方法：

toPair :: DT.Text -> (Key, Value)
toPair input = ...

main = do
  all_lines <- fmap DTL.lines $ DTLIO.getContent
  let m = M.fromList $ map toPair all_lines
  print $ M.lookup "foobar" m

您仍然可以使用attoparsec 来实现toPair，但您将使用它 逐行而不是整个输入。

字节字符串与文本

根据我的经验，使用 ByteStrings 比使用 Text 要快得多。

这个版本的toPair 用于 ByteStrings 比对应的快 4 倍左右 文本版本：

{-# LANGUAGE OverloadedStrings #-}
import qualified Data.ByteString.Lazy.Char8 as L
import qualified Data.Attoparsec.ByteString.Char8 as A
import qualified Data.Attoparsec.ByteString.Lazy as AL

toPair :: L.ByteString -> (L.ByteString, L.ByteString)
toPair bs =
  case AL.maybeResult (AL.parse parseLine bs) of
    Nothing    -> error "bad line"
    Just (a,b) -> (a,b)
  where parseLine = do
          A.skipWhile (/= ' ')
          A.skipWhile (== ' ')
          a <- A.takeWhile (/= '\t')
          A.skipWhile (== '\t')
          rel <- A.takeWhile (/= '\t')
          A.skipWhile (== '\t')
          A.skipWhile (/= ' ')
          A.skipWhile (== ' ')
          c <- A.takeWhile (const True)
          if rel == "rel:etymological_origin_of"
            then return (c,a)
            else return (a,c)

或者，只使用普通的 ByteString 函数：

fields :: L.ByteString -> [L.ByteString]
fields = L.splitWith (== '\t')

snipSpace = L.ByteString -> L.ByteString
snipSpace = L.dropWhile (== ' ') . L.dropWhile (/=' ')

toPair'' bs = 
  let fs = fields bs
  case fields line of
    (x:y:z:_) -> let a = snipSpace x
                     c = snipSpace z
                 in
                 if y == "rel:etymological_origin_of"
                   then (c,a)
                   else (a,c)
    _         -> error "bad line"

加载地图的大部分时间都花在解析线条上。 对于 ByteStrings，这大约是 14 秒。加载所有 600 万行 与 50 秒相比。用于文本。

Answer 2

为了补充this answer，我想指出 attoparsec 实际上对“基于拉取”的增量解析有很好的支持。您可以通过方便的parseWith 函数直接使用它。为了更精细的控制，您可以手动输入解析器parse 和feed。如果你不想担心这些，你应该可以使用pipes-attoparsec 之类的东西，但我个人觉得管道有点难以理解。