库外替重的技术：

我觉得大家讨论那篇文章写得不怎么样，至少技术上不怎么样。
链表能够用来大数据量查重，简直是开玩笑，原因我不解释了。

从计算机数学的角度上来说，什么查找算法最适合查重，似乎没有争议，B树。
实际的应用中，B树往往不是简单的B树运算，而是涉及了一些数据块内存缓存、末层叶子节点的散列运算等。今天的各种商业数据库，无论是高端Oracle，还是低端mysql，都是采用了B树算法，这一点应该充分说明了这个算法的特点（高效率，低开销）。

我不明白为什么大家总是在争议是Oracle剔重技术好，还是实时数据库性能好，这一点很是奇怪。Oracle的剔重技术相关于一套 B树算法+锁管理机制+Redo+Undo，这加起来的消耗至少是B树算法本身的2倍。实时数据库取决于它考虑的内容，你考虑得越复杂，你的性能也就越差，这一点毋庸置疑。作为商业软件，他们这么考虑的确没有任何错误。可是，实际计费软件中需不需要呢？我们为什么要为我们不需要的功能增加消耗，增加成本呢？
    在针对计费领域，我们还可以考虑CRC或MD5的方法（这一点那篇文章中提到了）来减少关键字大小。还可以考虑按照服务号段、通话时间散列数据文件等等。

Ref：
===============================================================================
    一般的库外剃重所占用的主机资源开销相当于入库所占用的主机资源开销的比例是多少（可以用相应主机的价格比表示），如果这个比例超过5%，我认为数据库唯一索引更经济和更实用。
===============================================================================
我认为是只要有5%的差距，我就应该选择库外剔重。何况，实际上通过上述原理，应该很明显的看出来这种性能的差距。

同样的机器上，如果你文件剔重的速度没有达到数据库的4倍，不要认为Oracle太快了，而是你的程序太慢了，改进算法。（改进之前，建议你先学习数学知识，不要把那些理论上的什么二分查找，链表算法等简单数据结构都搬过来，那都是理论，不可以作为实际用途的）

技术本身没有好坏，关键在于你怎么用，在那里用。数据库不错，可是不能用作查重。B树也不错，可是，不能用作客户查询。