現実世界のHaskell

このブログはすでにHaskell言語自体について多くのことを書いており、その実用的な応用に関するいくつかの記事があります。 ここで、本番環境での言語のもう1つの実際の応用について、感動的に語ります。

データの説明

私はテレコムで働いています：固定電話、インターネット、IPテレフォニー。 タスクには、PBX、IPテレフォニーサーバーからのトラフィックの処理、現在の課金のサポート、ソフトウェアの作成、ネットワーク、ドメインの管理が含まれます（はい、「すべての取引のジャック」）。 最近、組織に新しい機器がインストールされ、まったく異なる原理で動作し、それに応じてトラフィックも変更されました。 現在、古いステーションと新しいステーションの2つのバージョンがあります。 新しいトラフィックは、バイナリ形式とテキスト形式で複製されます。 バイナリはまったく私たちには向いていません（ただし、一部の人は知らないうちに「なぜそこにいるのですか。それを自分で請求します！」）。 古い機器からのトラフィックはまだ進行中であり、ローカルDBMSのサービスを使用して、確立されたスキームを使用してパートナーと一緒に投げています。 新しいステーションからのトラフィックに同じサービスを設定することは可能ですが、いくつかの機能が発見されました。 新しいステーションのトラフィックは、15分ごとに個別のファイルに書き込まれます。 合計で、月に約3,000個のそのようなファイルが取得されます（理想的には-31日間で2976、30日間で2880）。 狂気のために、各ファイルを個別にインポートすることはありません。 それらはすべてテキストであり、コールレコードは行ごとに配置されるため、それらを1つにマージすることも可能です。 手動マージは次のようになります。先月のみファイルを選択し、コマンドラインで最も単純なマージスクリプトに追加します。 ファイル名の形式は固定されているため、合併を自動化できます。年と月を解析するだけです。 Linuxは、 Bash 、 Perl、またはPythonのいずれかを使用します。安価で陽気ですが、1回の操作でWindowsマシンにインストールするのではなく、 PowerShellでも同様です。 そしてcmdは、私たちがよく知っている倒錯です。 ;）最後に、DBMSツールを使用してマージおよびインポートした後でも、多くの手動SQL作業が必要だったため、トラフィック自体にも驚きが見つかりました。 一般に、これらの要因はどうにかしてHaskellのタスクにうまく発展しました。そのとき（2011年4月から5月）、研究を始めました。



したがって、1か月あたり約3,000の15分ファイル。 機器では、間隔を変更し、15分ではなく、5、10、30、45などの他の値を設定できます。ファイルの数とサイズはそれぞれ変更されます。 ファイル名の例（2011年5月9日09:30:00）：

  999992011050909300081.txt
 99999-機器に縫い付けられた識別子（明らかな理由により、私はそれを9つに置き換えました）
      2011-年
          05-月
            09-日
              09-時間
                30分
                  00-秒
                    81-おそらく10分の1秒の乱数。 

サブスクライバーが増え、各ファイルのサイズは着実に増加しています。 現在、ファイルごとに平均240行がありますが、夏季の季節的な沈下があり、休暇に出かけた人は少なくなりました。 9月には、1.5〜2倍のアクティビティの増加が見込まれます。



通話記録は多様です。 フィールドの数が異なるレコードにはいくつかの異なるタイプがあります。 R210のようなエントリは非常にまれであり、その意味を理解できませんでした（以降、トラフィックデータはランダムデータに置き換えられます）。

  | R210 | 2011-06-24 21：43：53 | 2011-06-24 01：43：52 | 1 | 

ご覧のとおり、レコードタイプ識別子、開始日、終了日（ISO 8601 / SQL形式）、および何らかの理由で1つのフィールドのみがあります。 フィールドは、レコードの先頭と末尾にある垂直バーで区切られているため、実際にはさらに1つのフィールド、つまり5があります。インデックス0のフィールドが最初の垂直バーの前にあると想定すると便利です。 その後、重要なフィールドのカウントダウンは1から始まります。



通常の呼び出しは、R200などのレコードに記録されます。 すでに152のフィールドがあり、これは機器上で再構成できます。一部のフィールドを追加、一部を削除、その他はフォーマットを変更できます。

  | R200 | 99999 | 111111 | CR、CS、AM | 1 | 1 | 3022 | 222222 | 333333 ||| 2011-06-23 11：33：58 | C | 2011-06-23 11：34：22 | S | 0 | 16 | 1 |||||| 1 | 1 |||||| 3 | 162 | 17 | 1 | 12 | 24 ||||||||||| 16 | 0 |||| || 192.168.1.172 || 192.168.1.12 |||||| 8 | 8 | 20 | 20 | 64 | 64 | 20 | 0 | 0 | OS | 7777 | 8888 | 555555 | 666666 | 0 | 8 | 9 | ||| OS | 19 ||| 30 | 10 | 42 | 43 |||||||||||||| 1 ||||||| 1 | 1 | 0 | 3 || 222222 ||||| || 2 | 1 || 333333 ||||||||||||||||||||||||||||||||||||| 

インデックス[ 7、8、9、12、14、36、112、122 ]のフィールドに興味があり、最終的には、DBMSにインポートしすぎないように、不要なものをすべて除外したいと思います。 生データから必要なものだけを選択すると、次の行が得られます。

 記録：3022 | 222222 | 333333 | 2011-06-23 11：33：58 | 2011-06-23 11：34：22 | 24 | 222222 | 333333
インデックス：7 | 8 | 9 | 12 | 14 | 36 | 112 | 122

インデックス| 説明
 ---------------------------
 7 | 知多の市外局番
 8、112 | 発信番号
 9、122 | 着信番号
 12 | 会話の開始日時
 14 | 終了日時
 36 | 秒単位の通話時間 

他のすべてのフィールドは特に必要ありません。 あなたが見るように、いくつかは一般に空ですが、他の意味は不明です。 （変更された）IPアドレスが、RTPトラフィックが通過する電話ネットワークインフラストラクチャの2つのボードに属していない限り。 これらのフィールドをインポートすることにより、ボードの負荷を調査できます。 おそらく将来的には便利になるでしょう。



トラフィックエントリは1行ずつタイトです。 他の種類のレコードもあるかもしれませんが、それらは私たちにとって興味深いものではありません。 関税については、タイプR200のレコードのみで十分です。 しかし、トラフィックの視覚的な調査中に、別の興味深い事実が明らかになりました。 コールは、同じ番号から開始され、同時に開始されることもありますが、通話時間は異なりました。 最初は、情報が不完全な状況で、ある種のグリッチだと思った。人が同じ番号から同時に電話をかけることはできないからだ。 その後、パターンが見え始め、最終的に、私は問題が何であるかを理解しました。 1つの電話番号に対するこのようなレコードの例を次に示します。わかりやすくするために、余分なフィールドはすべて捨てました。

  | 7 | 8 | 9 | 12 | 14 | 36 |
 | 3022 | 222222 | 333333 | 2011-05-23 13：07：54 | 2011-05-23 13：37：54 | 1800 |
 | 3022 | 222222 | 333333 | 2011-05-23 13：07：54 | 2011-05-23 13：59：40 | 3106 |

 | 3022 | 444444 | 555555 | 2011-05-23 14：53：52 | 2011-05-23 15：23：52 | 1800 |
 | 3022 | 444444 | 555555 | 2011-05-23 14：53：52 | 2011-05-23 15：53：52 | 3600 |
 | 3022 | 444444 | 555555 | 2011-05-23 14：53：52 | 2011-05-23 16：00：50 | 4018 |

 | 3022 | 666666 | 777777 | 2011-05-23 19：15：55 | 2011-05-23 19：45：54 | 1800 |
 | 3022 | 666666 | 777777 | 2011-05-23 19：15：55 | 2011-05-23 20：15：54 | 3600 |
 | 3022 | 666666 | 777777 | 2011-05-23 19：15：55 | 2011-05-23 20：45：54 | 5400 |
 | 3022 | 666666 | 777777 | 2011-05-23 19：15：55 | 2011-05-23 20：47：17 | 5483 | 

塩が何であるかを見ることができるようになった後、これらの記録を何千もの類似の記録の中、余分なフィールド、文字、数字の中から見つけるのは簡単ではありませんでした。 一般的に、それは運、直観、または魔法のいずれかでした。 :)そして答えは簡単です。30分（1800秒）ごとの機器は、何かが起こった場合に「会話のマイルストーン」をマークします。 会話の最後の29分が何らかの形で失われたとしても、信頼性を高めるために、過去3時間の会話全体が何度も記録されました。 最後のレコードには、実際のデータがあります。 おそらく、機器では、マイルストーンの期間を何らかの方法で変更できますが、これまでのところ、その数は次のようになっています。 [1800、3600、5400、7200、9000、9000以上。]結果レコードのフィールド。 おそらく、不必要なものをより良い方法で除外するために、将来これを検討する価値があるかもしれませんが、今のところ、このシリーズの期間を持つすべてのレコードを単純に破棄することにしました。 理論的には、ここでは通常の通話の一部が失われますが、このためには、1秒に正確に30分間話す必要があります。 この確率は非常に小さく、ボリュームはそれほど大きくないので、大きな数の法則が何らかの形でサンプルに影響を与えます。 この現象を創造的に「1800秒の問題」と呼びました。

プログラムについて簡単に

合計で、必要なファイルをマージして有用な情報を除外する4つのプログラムを作成しました。 最初は、パーサーとマージャーでした。2つのプログラムは別々に作成され、マージと呼ばれる3番目のプログラムに結合されていました。 それらはすべて非常にゆっくりと動作し、多くのメモリを消費しましたが、タスクに対処しました。 500 MBのメモリが消費されている状態で（スワップが機能したため、さらに10分間）1か月のデータ（240行の3000ファイル= 720000行）を処理できました。 とても、とても怖い結果です。 また、タスクは月に1回行う必要がありましたが、私のパートナーはHaskellを軽しました。 確かに、 Haskellはそれとは何の関係もありません。 私はプログラムでこれを初心者の機能主義者の多くの典型的な間違いにしたが、これは曲がったアルゴリズムが非常にひどくうまく機能しなかったためである。 しかし、彼らは働いた！ さらに：プログラム（およびそれらの最大のものはわずか150の有用な行を取る）は、コマンドラインから設定することができます。 利用可能な機能は次のとおりです。



1.パラメーターなしのモードで作業します。 デフォルトではフィールドが取得され、先月のファイルが取得されます。

2.パラメーターを使用したモードで作業します。

-フィールド[<フィールドインデックスのリスト>]-取得するフィールド（パーサーフィールド[1、24、55]）;

-（yyyy、mm）-処理する月（合併（2011、5））;

-W-（「待機」という言葉から）ワークアウト後にコンソールウィンドウを閉じないでください。

3.結果は3つのファイルでした。

-yyyy.mm.txt-今月の生のトラフィックを持つすべてのファイルがマージされました。

-processed.txt-今月に必要なフィールドのみを含むファイル。

-yyyy.mm.txt.log-生の未加工ファイルがリストされ、要約情報が書き込まれるログファイル（行数、ファイル、日付範囲）。

4.プログラムは、処理されたトラフィックの統計と例を表示します。



何回か使用しましたが、もちろん、プログラムを最初から書き直しました。 古いコードには、多くの曲がったコード、不必要な自転車、愚かなアルゴリズム、奇妙な解決策がありました。 その結果、同じ機能と同じデータセットを持つ4番目のプログラムNgnParserは10分間ではなく10秒間動作し、10 mbのメモリしか消費しません。 速度では、差はほぼ2桁で、少なくとも1つはメモリにあります！ プログラムを遅くするような混乱は何だったのでしょうか？ 私と同じ熊手を踏んだ人がいると思います。曲がった手よりも言語の遅れを信じている人がいると思います-理由もなく、理由もなくインターネット上で非常に多くの悲鳴があります... Haskellは素晴らしい言語です。 これらのプログラムを書くのは簡単でした。 それぞれについて、2営業日しかかかりませんでした。 そして、私は多くの喜びを得たたびに。 Cで同じことをした場合、どれほどの苦痛があるか想像できません。

最初のプログラム

最初のプログラムは簡単なものから始めました。 とりあえず、コマンドラインツールを使用して必要なファイルを1つ（merged.txt）にマージしました。パーサーのタスクは、トラフィックを解析し、識別子R200で必要なレコードを除外することでした 大量のテキストを処理するには、特別なByteString文字列型を使用する方が便利です。 ただし、通常の文字列型ほど便利ではありません。 ByteStringが文字列自体の最適化された実装である場合、 Stringは文字のリスト、つまり[Char]です。 Stringはその性質上非常に便利ですが、ビッグデータではリストのパフォーマンスが大幅に低下します。 プログラムの最初のバージョンでは、強力なブレーキと大きなメモリのむさぼりを引き起こしたのは、 文字列といくつかの愚かな決定でした。 しかし、その後、生産性ではなく、開発の速度が心配になりました。 プログラムのプロトタイプを非常に迅速に作成しました。 外観は次のとおりです（リビジョン2）：

replaceChars :: Char- > Char- > Char- > Char

replaceChars whatC withC c = if c == whatC then withC else c



interestFields :: [ 文字列 ] -> [ Int ] -> [ 文字列 ]

interestFieldsのtakeWhat = undefined- スタブ



isR200 :: [ 文字列 ] -> Bool

isR200 s = （ head s ） == "R200"



processLine :: 文字列 -> 文字列

processLine s = if isR200 sInWords then unwords （ interestFields sInWords [1、2、3] ） else [ ] -[1,2,3]-フィールドのテスト

ここで、 sInWords = words （ map （ replaceChars ' | ' '' ） s ）



processString :: 文字列 -> [ 文字列 ]

processString s = map processLine （ lines $ s ）



メイン:: IO （ ）

メイン= 行う

str < -readFile "merged.txt"

putStrLn （挿入" \ r \ n " （ processString $ str ） ）

タイプChar- > Char- > Char- > Charの replaceCharsという奇妙な関数にすぐに気付くことができます。 アイデアはこれでした：ラインレコードを取り、垂直バー「|」を置き換えます スペースを使用し、 words関数を使用して文字列を単語に分割します。

sInWords = words （ map （ replaceChars ' | ' '' ） s ）

sInWordsを実行した結果、次の変換が得られます。

"| R200 | 99999 | 111111 | CR、CS、AM | 1 | 1 | 3022 | 222222 | 333333 ||| 2011-06-23 11：33：58 |" ->

「R200 99999 111111 CR、CS、AM 1 1 3022 222222 333333 2011-06-23 11:33:58」 ->

[ 「R200」 、 「99999」 、 「111111」 、 「CR、CS、AM」 、 「1」 、 「1」 、 「3022」 、 「222222」 、 「333333」 、 「2011-06-23」 、 「 11:33:58 " ]

残念ながら、日時フィールドも2つの別々のフィールドに分割されます。 後で、これを回避するために、設計をさらに複雑にし、最初にこのフィールドのスペースをアスタリスクに置き換えてから返します。 その結果、ラインレコードはさらに多くの変換を経ました。



置換 ''-> '*';

「|」を置き換える -> '';

単語機能による単語分割。

フィールドのリストを処理し、目的のインデックスを持つフィールドを取得します。

unwords関数を使用してフィールドをマージします。

置換 ''-> '|'

置換 '*'-> ''



さらに、これらのひどい変換の後、受信したフィールドの数はソースフィールドの数と一致しませんでした。空のフィールドが最終的に完全に消えたためです（上記の変換例を参照）。 すべてのレコードで、空のフィールドまたは塗りつぶされたフィールドが同じ場所にあると便利です。そうしないと、不快なアーティファクトが発生します。 ご覧のとおり、コードは冗長であるだけでなく、見苦しいものです。 私はその漸近的な複雑さを評価することすら想定していません。 彼女はO（n ^ 2）をはるかに超えていたと思います。 さらに、リビジョン12に近づくと、二重の縦線が原因で失われたフィールドに対して何かを行う必要があることに気付きました。 そして別の変換を追加しました：

-「||」とマークされた空のフィールドが正しく処理されるように、それらの間にスペースが挿入されます。

refieldDoubles :: 文字列 -> 文字列

refieldDoubles [ ] = [ ]

refieldDoubles （ ' | '： [ ] ） = "|"

refieldDoubles （ ' | '： ' | '：ss ） = "| |" ++ （ refieldDoubles （ ' | '：ss ） ）

refieldDoubles （ s： [ ] ） = [ s ]

refieldDoubles （ s：ss ） = s： （ refieldDoubles ss ）

したがって、各行に別の完全なパッセージを追加しました！ まあ、真実-猿の労働。 ただし、かなりの作業を行う必要がありました。 代わりにData.String.Utilsモジュールのsplit関数を使用するか、独自のバージョンを作成します。 次に、レコード行に沿って1回パスするだけで、正しいフィールドの内訳を取得できます。

「|」を分割します "| R200 | 99999 | 111111 | CR、CS、AM | 1 | 1 | 3022 | 222222 | 333333 ||| 2011-06-23 11：33：58 |" ->

[ "" 、 "R200" 、 "99999" 、 "111111" 、 "CR、CS、AM" 、 "1" 、 "1" 、 "3022" 、 "222222" 、 "333333" 、 "" 、 "" 、 "2011-06-23 11:33:58" 、 "" ]

私は何を言うことができます... facepalm言葉ではなく、感情だけ。

どのような改善が可能ですか

経験豊富なHaskellistsは、コードがばらばらのスタイルを使用していないことにすでに気づいており（その時点ではまだ感じていませんでした）、ケースの構築、サンプルとの比較、またはあらゆる種類のセキュリティ表現はほとんどありません。 結果として、そのような単純なコードでさえ、場所で読むことは困難です。 いくつかの関数を書き留めるより良い方法は次のとおりです。

replaceSymbols s = map （ replaceChar ' | ' '' ） （ map （ replaceChar '' ' * ' ） s ）

-->

replaceSymbols = map （ replaceChar ' | ' ''。replaceChar '' ' * ' ）





isR200 s = （ head s ） == "R200"

-->

isR200 （ "R200" ： _ ） = True

isR200 _ = False





replaceChars whatC withC c = if c == whatC then withC else c

-->

replaceChars whatC withC c | c == whatC = withC

| それ以外の場合 = c





processLine s = if isR200 sInWords then unwords （ interestFields sInWords [ 1、2、3 ] ） else [ ]

ここで、 sInWords = words （ map （ replaceChars ' | ' '' ） s ）

-->

processLine s | isR200 sInWords = unwords （ interestFields sInWords [ 1、2、3 ] ）

| それ以外の場合 = [ ]

ここで、 sInWords = words 。 map （ replaceChars ' | ' '' ） $ s





processString s = map processLine （ lines $ s ）

-->

processString = map processLine 。 行

通常、 インターカレート関数"\ r \ n"はunlinesに置き換える必要がありました。 より短く、より明確になり、テストでは、 unlinesは優れたパフォーマンスを示しました-少なくとも30％：

  ItemsCnt testUnlines（ns）testIntercalate（ns）パーセント
 10 23.84 34.05 29.9
 100 22.70 34.62 34.4
 1000 23.28 35.48 34.3
 10000 22.17 35.48 37.5
 50,000 22.13 33.26 33.4
 100000 21.06 35.47 40.6
 200000 22.70 34.05 33.3 

しかし、まだ経験の浅い間、私は不要な自転車をブロックしたため、 プレリュードモジュールからでも標準機能を知りませんでした。 ただし、今でも、最小限の労力で、要素のリストから目的のインデックスを持つ要素を選択する方法を実際には理解していません。 古いプログラムと新しいプログラムのコードを比較します。

-古いコード：

-引数1-生の食品のリスト

-引数2-必要なインデックスのリスト

takeInterest :: [ 文字列 ] -> [ Int ] -> [ 文字列 ]

takeInterest _ [ ] = [ ]

takeInterest ss （ n：ns ） = [ ss !! n ] ++ takeInterest ss ns



-新しいコード：

-引数1-バッテリー

-引数2-必要なインデックスのリスト

-引数3-生フィールドのリスト

collectFields :: Int- > [ Int ] -> [ 文字列 ] -> [ 文字列 ]

collectFields _ _ [ ] = [ ]

collectFields idx fis （ s：ss ） | idx ` elem` fis = s：collectFields （ idx + 1 ） fis ss

collectFields idx fis （ s：ss ） | それ以外の場合 = collectFields （ idx + 1 ） fis ss

最初のケースでは、インデックスのリストを反復処理し、安全でない関数を使用して要素を引き出します!! 。 2番目のケースでは、バッテリーを使用してフィールドのリストを繰り返し処理し、インデックスのリストでバッテリーが見つかった場合、コレクションのバッテリーインデックスで現在のフィールドを取得します。 そこと末尾の再帰があります。 ただし、テストによると、新しいコードは40％遅くなりました。 おそらくこの場合、古いコードを返す価値があります。新しいプログラムをさらに高速化するためです。

  ItemsCnt takeInterest（ns）collectFields（ns）パーセント
 10 17.33 36.84 52.9
 100 20.58 36.84 44.1
 1000 21.67 37.92 42.8
 10000 21.13 36.84 42.6
 50,000 21.67 37.92 42.8 

進む

次のプログラムである合併は、先月のすべてのテキストファイルを1つに結合することになっています。 （毎回手動でやりたくはありませんでした。ご存知のように、怠lazは進歩の原動力です。）質問が発生しました：先月の予定をどうやって知るのですか？ はい、一般的には簡単です。現在の日付を取得して1か月を差し引きます。 このプログラムは月の初めにのみ使用されることになっていたため、問題は予想されませんでした。 現在の日付と、一般に日付と時刻の操作は、 時間モジュールにあります。 ファイルシステム構造の操作は、 System.Directoryモジュールにあります。 どちらの関数も主にIOモナドで機能しますが、その時点ではまだモナドコードを組み合わせる方法を実際には知りませんでしたが、最終的には不気味に見えます（マージ、リビジョン14）。

メイン:: IO （ ）

メイン= 行う

args < -getArgs

curDir < -getCurrentDirectory

dirContents < -getDirectoryContents curDir

curTime < -T. getClockTime

monthAgoTime <- $ Tを返します 。 addToClockTime （ T. TimeDiff 0 （ -1 ） 0 0 0 0 0 ） curTime

calendarMonthAgoTime < -T. toCalendarTime monthAgoTime

多分DateRange = case args

（ a：b： _ ） -> readDateRange （ unwords [ a 、 b ] ）

_- >ちょうど$ defaultDateRange calendarMonthAgoTime

ケース maybeDateRange of

ただdr- > do

let fsToMerge = filesToMerge dirContents dr

let fsToMergeCountStr = $ length fsToMergeを表示

let mergeLog = （ newFileName dr ++ ".log" ）

dateRangeMsg = "DateRange：" ++に drを表示 させます

fsContents < -merge fsToMerge

writeFile （ newFileName dr ） （ fsContentsの展開）

writeFile mergeLog （ fsToMerge ++ printfのインライン化を解除します \ n ％s \ n合計ファイル：％s " dateRangeMsg fsToMergeCountStr ）

putStrLn （ fsContentsのインライン化を解除）

putStrLn dateRangeMsg

--putStrLn（ "マージするファイル：" ++ fsToMergeのインライン展開を解除）

putStrLn （ printf "ファイルの数：％s。ファイルリストについては％sを参照してください。" fsToMergeCountStr mergeLog ）

何もない-> putStrLn （ "無効な日付範囲。" ）

このコードが何をするのか、私もそれに入ることはお勧めしません...しかし、古いプログラムの最新バージョンが膨大な量のメモリを食い込んだため、将来の巨大なエラーの芽が忍び込んだのはここです。 このコードから呼び出されるマージ関数を考えてみましょう。

merge :: [ 文字列 ] -> IO [ 文字列 ]

merge fsToMerge = mapM readFile fsToMerge

制御するファイルのリストを受け取り、それらを読み取り、その内容のリストを返します。 コードには次の2行があります。

する

...

fsContents < -merge fsToMerge

writeFile （ newFileName dr ） （ fsContentsの展開）

...

重要な点は、 fsContentsのインライン展開です。 つまり、すべてのファイルのすべての生のコンテンツが1回にまとめられ、結果ファイルに詰め込まれました。 後に、パーサーと合併が組み合わされたとき、パーサーパーツの処理に転送されたのはこの膨大な量のデータでした。覚えているのは、大量の置換、パス、その他のオーバーヘッドがあることです。 パーサーとマージからコンパイルされた古いプログラムでは、このコードは次のようになります。

する

...

fsContents < -readFilesToMerge fsToMerge

let mergedContents = fsContentsのラインを解除します

writeFile （ newFileName dr ） mergedContents

let writtenContentStr = unlines $ processData nedeedFields mergedContents

...

そして、それは単に面倒なだけでなく、データフローの概念に対する重大な違反です。 次のようになります。

 スキーム1
        _____ _____ _____ 
       |  |  |  |  |  |
 A1-> | F（A1）|  -> B1-> | G（B1）|  -> C1-> | H（C1）|  ->結果1->保存
       | _____ |  | _____ |  | _____ |

        _____ _____ _____
       |  |  |  |  |  |
 A2-> | F（A2）|  -> B2-> | G（B2）|  -> C2-> | H（C2）|  ->結果2->保存
       | _____ |  | _____ |  | _____ |

        _____ _____ _____ 
       |  |  |  |  |  |
 A3-> | F（A3）|  -> B3-> | G（B3）|  -> C3-> | H（C3）|  ->結果3->保存
       | _____ |  | _____ |  | _____ |


 ...-> ...-> ...-> ...-> ...-> ...->結果n->保存 

そして、それは次のようになりました：

 スキーム2
     ____________________ ____________________ ____________________
    |  |  |  |  |  |
    |  |  |  |  |  |
    |  |  |  |  |  |
 A-> |  F（A）|-> B-> |  G（B）|-> C-> |  H（C）|->結果->保存
    |  |  |  |  |  |
    |  |  |  |  |  |
    | ____________________ |  | ____________________ |  | ____________________ | 

部品の順次処理とすべての処理の違いをすぐに感じました。 今、私は知っています：一度にすべての作業を行う価値はありません。データをバッチで発行するメカニズムを作成する方がよいでしょう。メモリ内で効果的かつ高速になります。 そして、他のすべてに加えて、2番目のスキームに従って作成されたプログラムは並列化できません。 ホラー、一言で言えば...



後で、ほとんどすべての場所でStringをByteStringに置き換えて、古いプログラムを最適化しようとしました。 もちろん、ゲインはわずかでしたが、霧のファンを分散させることはできません。



言うまでもなく、私は新しいプログラムであるNgnTrafficを作成しました。NgnTrafficはすでに通常の知識を持っていますか？ 多くのことが観察されています。 プログラムは、 Main 、 Constants 、 DataProcess 、 FileListProces 、 Options 、 Tools 、 Typesのモジュールに分かれています。 もちろん、スキーム1が使用され、 文字列の代わりに、 ByteString型（厳密なバリアント）が最初に使用されました。 コードは、手間がかからないスタイルでさえ、よりコーミングされています。 そして、最も重要なことは、行動の原則が変わったことです。 最初に、処理されるファイルのリストが収集されます-この部分は、古いプログラムの類似部分に似ています。 ただし、ファイルは一度に1つの大きな変数に読み込まれるのではなく、それぞれ個別に読み込まれます。 その内容はすぐに処理され、行が解析され、レコードがフィルタリングされ、必要なフィールドが取り出されます。 結果は結果ファイルに追加されます。 その結果、「ディスクからの読み取り（ F（An） ）-文字列の処理（ G（Bn） ）-ディスクへの結果の書き込み（ H（Cn） ）」というサイクルがあり、ファイルの数が非常に多くなります。 さらに、もちろん、ある文字を別の文字に置き換えることはありませんが、 Data.ByteString.Char8モジュールの単純な分割関数があります。これは、レコード文字列を1つのパスでフィールドに分割し、それ自体がパフォーマンスの途方もないシェアを獲得します。 スキーム1を満たす関数は次のとおりです。

プロセス ' :: ResFilePath- > FieldIndexes- > FilePath- > IO （ ）

プロセスのresFile fis targetFile = do

fileContents < -C. readFile targetFile

let processResult = processData fis述語fileContents

C. appendFile resFile processResult



プロセス:: ResFilePath- > [ FilePath ] -> FieldIndexes- > IO String

process _ [ ] _ = 「処理するファイルがありません」を 返す

プロセスresFile fs fieldIndexes = do

C. writeFile resFileC 。 空っぽ

mapM_ （プロセスのresFile fieldIndexes ） fs

「すべてOK」を 返し ます

ここで、processは結果ファイルの名前、処理するファイルのリスト、および必須フィールドのインデックスを取ります。 インデックスはコマンドラインから取得できるため、この関数の引数として出力されます。 processは、各ファイル名を順番に取得し、関数process 'を適用します（行mapM_（process' resFile fieldIndexes）fs ）。 彼女はすでにファイルの主な仕事をしています。 processData関数は、ファイルのコンテンツの処理を行います。 R200レコードのフィルタリングに加えて、新しいプログラムで述語メカニズムが作成されたことは興味深いことです。どのレコードも利用可能な述語と照合でき、述語自体に必要なものを簡単に追加できます。 これまでに2つのことが行われました。インデックスxのフィールドは、フィールドのリストに属し、そのリストに属していません。 これは、述部のタイプです。

データ述語= NotInList [ C. ByteString ]

| InList [ C. ByteString ]

タイプ PredicateMap = [ （ FieldIndex 、 Predicate ） ]

そして、これらは与えられた定数述語です：

述語:: PredicateMap

述語= [ （ 1 、 InList [ C. pack "R200" ] ） 、

（ 36 、 NotInList （ map C. pack [ "1800" 、 "3600" 、 "5400" 、 "7200" 、 "9000" 、 "10800" 、 "12600" 、 "14400" 、 "16200" 、 "18000" 、 「19800」 、 「21600」 、 「23400」 ] ） ） ]

フィールド1が「R200」に等しく、フィールド36が「問題1800秒」のリストにないレコードのみが述語を満たすと推測するのは簡単です。 スクリーニングはcheckPredicateおよびexamineFields関数で発生します 。

checkPredicate ::述語-> C ByteString- > Bool

checkPredicate （ NotInList l ） str = （ not。elem str ） l

checkPredicate （ InList l ） str = elem str l



examineFields :: Int- > PredicateMap- >フィールド-> Bool

examineFields _ _ [ ] = True

examineFields idx preds （ s：ss ） = case L. ルックアップ IDX

ちょうどpred -> （ checkPredicate pred s ） && （ examineFields （ idx + 1 ） preds ss ）

なし-> examineFields （ idx + 1 ） preds ss

examineFields関数はfoldrを介して実行できることがわかりましたが、それはささいなことです。



一般的に、完了した作業に満足しています。 これはまれです-しかし、私はNgnTrafficコードが好きです。 そして、私は特に、異なるプログラムで、異なる時間に、異なる知識で書かれた同じプログラムの例で目に見えるようになった進歩が好きです。 「さらに特別な」私は、これが実際の生産で使用されるHaskellの実際のプログラムであるという事実が好きです。



彼らが何と言っても、 Haskellは素晴らしい言語であり、私がこれまで働いた中で最高のものです。



リビジョンのパーサーソース： [2] 、 [6] 、 [12]

合併のソース（合併統合プログラムを含む）： [13] 、 [14] 、 [16] 、 [23]

NgnTrafficのソース



PS Yet Another Monad Tutorialの次の部分の翻訳も近日中に利用可能になります。

PPS同志steckのおかげでプログラムへのリンクが修正されました 。

PPPS同志のgoderとjack128のおかげで、いくつかのエラーを修正しました 。