3

私は社内の予測ダイヤラ製品を持っているソフトウェアショップで働いており、DO-NOT-CALLリストに従うためのソリューションを実装する必要があります。

基本的に、私は電話をかける必要のある顧客/見込み客のデータベースと、電話をかけられない電話番号のデータベースを持っています。システムは予測ダイヤラーであるため、操作のパフォーマンス、時間平均などに基づいて、ログに記録されたシステムユーザーごとに多かれ少なかれコールをダイヤルします。通常、この「マジック」番号は、ログに記録されたエージェントごとに約3〜4回の呼び出しです。

予測ダイヤラの電話番号リポジトリはPostgreSQLデータベースです。予測ダイヤラはデータベースから一連の番号を取得し、その束をダイヤルするコマンドをpbxに送信します。その後、ビジネスロジックは、有効な通話をコールセンターの担当者などに転送します(これは私の場合は関係ありません)。問題は電話の前にあります)。

呼び出し禁止リスト機能を実装する必要があります。この電話禁止リストは、政府機関からCSVファイルで毎日提供されます。新しいCSVファイルを受け取るたびに、古いdo-not-call-listを削除して、新しいファイルを配置する必要があります。

それを実装するための私の最初の考えは、バッチ処理を実行し、DO NOTCALLLISTを現在の顧客データベースと相互参照することでした。ただし、両方のデータベースのサイズによっては、相互参照のパフォーマンスが非常に高くなり、一晩で完了できない場合もあると思います。私は以前にバッチ処理でこの種の問題を抱えていましたが、それを見るのは良いことではありません。

私の2番目のアイデアは、大規模な機関がクレジットカードやユーザー認証/承認などの高性能で高スループットの承認システムをどのように処理するかを考えたときに思いついたものです。DO NOT CALL LIST番号の認証サービスを作成し、ダイヤラのアルゴリズムを変更して、ダイヤルする前にこの認証サービスに対して各番号をチェックするのが適切だと思いました。

私はここで作話をしているだけなので、どちらのアイデアが最適か、または完全に間違っていて別の方向に目を向けるべきかどうかはわかりません。だから、私の質問は:あなたの推薦は何でしょうか?CSVファイルをメモリに保存しますか?LDAPを使用しますか?MySQLを使用しますか?PostgreSQL?バッチ処理はしますか?それとも私は間違いなくねじ込まれていますか?

このような問題を抱えているのは私が世界で初めてではないことを私は知っているので、私に教えてください。

4

1 に答える 1

2

可能なエントリの広大なスペースから多数のエントリを見つけるというあなたの挑戦は、 DNSブラック/ブロックリストを思い出させます。

rbldnsdは、DNSBLゾーンにサービスを提供するために特別に作成された小型で高速なDNSデーモンです。このデーモンは、djbdnsパッケージにあるDanJ.Bernsteinのrbldnsプログラムに触発されました。Googleからのより多くのrbldnsd

名前ベースのゾーンをサポートしているため、番号のリストをENUMスタイルのURIに変換できます。たとえば、+1-555-4242は2.4.2.4.5.5.5.1.e164.arpaになります。次に、これはrbldnsdデータファイルに入力され、メモリにコンパイルされ、他のブロックリストと同様にアクセスされます。デフォルトのエントリは、can-callを意味します。または、エントリが存在する場合は、DoNotCallエントリが与えられます。

バッチ変換の問題はまだありますが、それはやや単純なスクリプトであり、PerlまたはAWKで行うことはかなり可能です。また、受信したCSVファイルを複数のファイルに分割して並列処理し、最終的にマージできる場合もあります。

于 2009-04-17T20:17:20.987 に答える