记一次程序优化

入职一周，还算比较清闲。没有一些明确时间点的事情，所以目前的大部分时候，探索成分居多，绞尽脑汁做的某些架构设计，不谈结果，就过程而言，收获颇丰。
总的来说，蛮喜欢目前的状态，思考>编码。
今天下午，旁边的同事在做一个关于库上的检查，简单说就是判断数据库的某些字段是否唯一。
最开始是一条sql语句，大概是这样的：

select * from aaa group by aaa.bbb, aaa.ccc having count(*) > 1;

全表大概1000w的数据，第一次执行，用了16分钟。

我们的mysql是架在一台12核，128Gb内存的机器上，应该说资源是足够的，但是这样的执行时间，相比于oracle的2分钟左右的处理速度，还是慢了太多。
单纯select *大概在1分钟左右，所以大部分的开销在group by上，从这点上看，mysql的一些计算能力确实欠缺太多。

后来考虑优化，将select *的结果全部装入内存，然后进行查找。
思路上，没有任何问题，但他的实施是这样的：
判断重复时，使用了2个循环，如下：

vector data;

for (int i = 0; i < data.size(); i++)
{
    for (int j = i + 1; j < data.size(); j++)
    {
        if (data[i] == data[j])
        {
            //do some
        }
    }
}

这个代码执行了大概30分钟，仍然没有结果。
正好当时没事，就帮他做了一些优化。很显然，这样的一个唯一性检查使用穷举是有问题的，复杂度在O(N^2)，对于1000w这样的数量级，O(N^2)基本上是不可实现的。所以第一步的优化，就是将这个算法的复杂度降下来。
增加一个排序操作，这样，程序的处理流程将变为：
1 排序
2 两两比较，确定非唯一值

总体的复杂度为O(N logN)
在排序中，使用了stl的sort函数进行排序，程序整体执行一遍的时间为7分钟。刨掉出库select的1分钟，排序的时间在6分钟左右。这么说来，还是有些慢。这个时候，更好的优化方式是将算法更改为hash，这样时间复杂度将降为O(N)，那么将会有质的提升，但是考虑到stl的map是红黑树实现，复杂度为O(N logN)，并不是很好的选择，而自己重新写一个hash函数好像又比较麻烦。所以权衡了一下，还是继续从排序入手。

最开始，想要将排序操作转移到mysql上执行，也就是在出库的同时进行排序，需要把出库语句改为：

select * from aaa order by aaa.bbb, aaa.ccc;

这样之后，内存中只需要一次遍历就好，时间开销基本可以忽略，这条sql的执行时间为4分钟，虽然相比于前面有了一些提升，但还是不够理想，还需要进一步的优化。

在上文的程序中，我们发现全部的数据存储在一个vector里，每一条数据为一个string，因此核心的开销为string的operator < 比较操作。string是一个相对来说比较庞大的类，会造成许多的额外开销。
我们只需要比较2个字段的唯一性，完全可以将这两个字段拼接起来，存在一个char*中，之后的比较基于memcmp。
当然，可能有这样的问题，第一条记录的第一个字段为“123”，第二个字段为“456”；而第二条记录的第一个字段为“12”，第二个字段为“3456”，这样本来不等的两个字段，拼接后相同。解决方式也很简单，在“123”的结束位置加入一个特殊字符，再拼接，这样就可以了。
在更改为char*之后，数据的排序时间从原来的3分钟降到了40秒。

目前来看，总体的执行时间为1分钟40秒，其中出库1分钟，排序40秒。系统的整体瓶颈转移到了出库这里，这里的优化方式就相当明显了，我们只是用到了2个字段，完全没有必要select *，只需要将select语句改为：

select aaa.bbb, aaa.ccc from aaa;

这样更改后，出库的时间为13秒，整体的执行时间为50秒。

这个时间，已经完全符合要求了，但是为了追求更高的速度，继续将计算并行化，也就是说，充分利用cpu的多核计算能力，将任务尽可能的拆分为多个线程来完成。对于本例来说，我们并不需要整体有序的数据，因此，考虑hadoop的分桶思想，我们将取出的char*每位相加，得到的结果对10取余，将结果分散到10个线程去做，最后的执行结果为4秒钟。

经过上面的一步步优化，总共的执行时间为17秒。
(原文时间2014-1-15)