|
|
本帖最后由 yulihua49 于 2021-2-7 20:26 编辑
再蹭个热度哈哈。
我那个课题的方案，且不说存储过程能否胜任，单说经济性：
我用的总共96核的计算服务器。用存储过程的话，96线程能不能够用，毕竟它的运算效能没办法与二进制指令代码相比。
那么，96核的licence需要多少投资？恐怕远超过硬件投资。
你说的一个观点我同意，你既然买了ORACLE，就应该把他的功能充分用起来。
我的方案虽然是把数据弄到外边计算了，但是原有的数据库资源也充分得到利用，2*16核的RAC系统也得到充分发挥。在系统活动期间，数据库基本达到满负荷。
这个算法（14，15，17楼），当年在我来之前，仅仅是这400W数据的计算部分（C++ + STL），与数据库没有任何关系，在2核服务器上就需要11个小时。如果在2*16的RAC系统，就算你能达到C++的性能，也需要40分钟。在96核服务器上也需要13分钟（纯计算，不包括数据存取时间）。并行度百分之百才有可能。我测试全部时间达到2.5分钟，连我自己都很惊讶。当时给我的任务就是把计算速度提上去，算法的事不由我管。我给出的对策是，我只负责调度任务，用并行的方法解决。
从34楼的系统架构图上可以看出，我的方案，并行是多维的。
读取数据的过程，计算过程，存入数据库的过程三者完全并行，计算过程本身也是并行。而最终结果，计算时间被忽略（证实一点：在纯计算任务，如果无穷增加并行度，计算时间趋于0），整个系统的处理时间，仅仅表现为数据存取时间。
而数据库引擎的自动并行的调度过程不可能这么精致。
结论是：
1. 假如你有这个水平能够在存储过程中完成这个算法。
2. 你能发挥系统的并行效能。
3. 计算效能能够匹敌二进制指令代码。
4. 不计成本。
也不可能达到我这个架构的性能水平。数据还是拿出来外边转一圈更快，更经济。而实际上这4条，1、3、4一条都做不到。2呢，你有可能能做到，但是系统的并行度本身达不到百分百，会差很多。
当然这只是我的一个玩具，证明一种思路。如果让所有的性能敏感系统都使用这个方案是不可能的。
|
|
楼主: Younth_0701
IP卡
狗仔卡
发表于 2021-2-2 23:05
显身卡
