|
|
本帖最后由 yulihua49 于 2013-4-26 12:54 编辑
newkid 发表于 2013-4-25 22:07 ![]()
我被你搞得稀里糊涂的。你真的试过我的方法？我看了你582楼的贴，似乎你入库之前就进行了那个所谓的“清分” ...
是的，这么大的架构，当然是整体解决方案，不能只为了玩压数据库的游戏。
我想说的是，这个系统，即使包含了相当复杂的计算，仍然能够以超过简单加载的速度运行，显示了架构的能力和DAU的效率，当然是OCI的效率，我只不过自认为发挥的还不错。
一般会说，这么多数据，仅仅加载就需要多少多少时间，再加上计算的时间，在计算时还要从数据库提出来，算完了再加回去，一共需要多少多少时间。。。。我回答：全部任务完成，就一趟，连加载带计算，比单纯加载数据库还快。
你能相信吗？
你的方案为什么会慢？
首先，存储过程，不知道如何使用RAC，多个节点可以并行的，你没有用上，这点还不如sqlldr，它还是有可能使用多节点的。
其次，你没有并行，压缩、传输、解压缩、转移加载，都是串行的。
你知道光压缩这些数据需要多少时间吗？20分钟！解压也需要差不多的时间。
1200W的数据，我只要7分钟完成一切。早已满足要求。干完活了，没事，玩压数据库的游戏。数据库还没压满，我估计极限应该3分钟能完，照这个努力。
回过头来，再说。
我把数据分成小包，多线程并行压缩，传输，解压，计算，入库，回执。一个流水线，各个环节是并行的，每个环节内多个包同时处理，也是并行的，二维并行。
一些包在压缩，一些包在传输，一些在解压，一些在计算，一些在入库，同时的。
而你呢，即使完成了传输，加载过程里，读出，解析CSV，插入，存储过程能把这3个环节并行吗？至少还可以用到多核。
实际上，先插入，再计算这个模式我们也有，叫做“反刍”，主要是用于于因某种原因在加载时未计算的数据在某时刻补充计算。
读出其中十几个列，计算出另外的十几个列，update之。
由于读出和update在一个盘，并行度较差，update比insert开销也大，这过程，处理1200W需要16分钟。别小看这16分钟，为了启动这个试验，要把1200W的标志改为“未计算”，一条SQL干了35分钟！
这就是架构的优势！一个复杂的计算要比一个简单的SQL快得多。
|
|
楼主: yulihua49
IP卡
狗仔卡
发表于 2013-4-25 23:28
显身卡
楼主
