我在一家软件商店工作，该商店有一个内部预测拨号产品，我们需要实施一个服从DO-NOT-CALL列表的解决方案。
基本上，我有一个数据库，其中包含我需要呼叫的客户/潜在客户，以及另一个包含我无法呼叫的电话号码的数据库。由于系统是预测拨号器，根据操作的性能，时间平均值和内容，它将为每个已记录的系统用户拨打或多或少的呼叫。通常这个“魔术”号码是每个记录的代理人大约3-4个电话。
预测拨号器的电话号码存储库是PostgreSQL数据库。预测拨号器从数据库中挑选出一堆数字并向pbx发送命令以拨打该组，然后业务逻辑继续将有效呼叫转移到呼叫中心职员等等（这与我的无关）问题是在电话会议之前）。
我需要实现do-not-call列表功能。这个拒收讯息清单将由政府机构以CSV文件的形式每天提供给我们公司。每当我收到一个新的CSV文件时，我都必须清除旧的拒绝呼叫列表，然后放置新的。
我首先考虑实现它是进行批处理，与我当前的客户数据库交叉引用DO NOT CALL LIST。但我认为，根据两个数据库的大小，交叉引用会非常注重性能，有时无法在一夜之间完成。我之前遇到过批量处理这样的问题，看起来不是一件好事。
当我想到大型机构如何处理高性能和高吞吐量授权系统（例如信用卡或用户身份验证/授权）时，我的第二个想法出现了。我认为为DO NOT CALL LIST号码创建一个认证服务，并且在拨号之前更改我的预测拨号器的算法以检查每个号码与该授权服务是否整洁。
由于我只是在这里喋喋不休，我不知道哪个想法是最好的，或者我是否完全错了，应该向另一个方向看。所以，我的问题是：你的建议是什么？将DO NOT CALL CSV文件存储在内存中？使用LDAP？用MySQL？ PostgreSQL的？做批处理的事情？还是我绝对搞砸了？
我知道我不是世界上第一个遇到这类问题的人，所以请赐教。
答案 0 :(得分：2)
您在大量可能的条目中找到一些条目的挑战让我想起了DNS black/block lists。
rbldnsd是一个小而快的DNS 特别制作的守护进程 提供DNSBL区域。这个守护进程是 灵感来自Dan J. Bernstein的rbldns 程序在djbdns包中找到。 More rbldnsd, from Google
它支持基于名称的区域，因此您可以将数字列表转换为ENUM样式的URI - 例如+ 1-555-4242变为2.4.2.4.5.5.5.1.e164.arpa。然后将其输入到rbldnsd数据文件中，编译到内存中并像任何其他阻止列表一样进行访问。默认条目表示可以调用，或者如果条目存在，则会给它一个DoNotCall条目。
你仍然遇到批处理转换问题，虽然它是一个稍微简单的脚本，很可能与Perl或AWK有关。您也可以将传入的CSV文件拆分为多个文件，以进行并行处理和最终合并。