曾经风光无限的天涯社区关门大吉了，itpub这个论坛不知道还能撑多久?

newkid

w39 发表于 2023-6-7 17:42
ORACLE太贵了。相比MYSQL价格一个天上一个地下。性能上也没有特别突出的地方。另外，信息安全上对国企、央 ...

现在恐怕连盗版的也没人用了，也没有人愿意学习，这才是最致命的。

newkid

yulihua49 发表于 2023-6-7 17:33
老家伙来支持一下，坚持度过寒冬。国内去IOE，ORACLE使用企业减少了很多。生意不景气，没啥人需要企业信息 ...

老哥已经光荣退休了，我们还要搬砖啊。你以前做的oracle项目还在运行吗？

w39

newkid 发表于 2023-6-7 21:51
现在恐怕连盗版的也没人用了，也没有人愿意学习，这才是最致命的。

这不就是拉里·埃里森所期望的嘛
严厉打击盗版以及排斥中国市场

yulihua49

newkid 发表于 2023-6-7 21:52
老哥已经光荣退休了，我们还要搬砖啊。你以前做的oracle项目还在运行吗？

还在运行中，无法代替。
因为它获取的数据，别的渠道获取不了，它的数据对不对也没有验证机制。

yulihua49

w39 发表于 2023-6-7 17:42
ORACLE太贵了。相比MYSQL价格一个天上一个地下。性能上也没有特别突出的地方。另外，信息安全上对国企、央 ...

感觉目前还是性能wudi的，功能最全的，比较难代替。
当你把它用到jizhi，那个性能无敌了。

能与它匹敌的有DB2，但是DB2的可靠性似乎差点。一个系统，连续使用几个月后会因内存问题而崩溃。每日监督看，内存并没有泄露。可能是内存过分碎片化了。

MYSQL真不行。

mricoo

留个脚印

newkid

yulihua49 发表于 2023-6-8 16:07
还在运行中，无法代替。因为它获取的数据，别的渠道获取不了，它的数据对不对也没有验证机制。

从你以前发的信息来看，你的逻辑体现在C语言层面，数据库执行的都是比较简单的读写类的SQL? 这样不是很容易替代吗?

yulihua49

newkid 发表于 2023-6-9 00:00
从你以前发的信息来看，你的逻辑体现在C语言层面，数据库执行的都是比较简单的读写类的SQL? 这样不是很容易 ...

算法问题。他是由同济大学提供的算法。我的任务就是为它调度资源。算法我看了，是有一些问题（没有考虑怎么走有空座，有始发站，怎么走换乘走行距离短。上海地铁换乘走行距离都不长，北京不同。据此对该支路的阻尼系数加权即可解决），也可以改进。对领导提出了我的意见，领导说，你不要管算法的事。所以我说它的数据有问题，但是没有其他办法获取数据。也没法验证。他们每天，各线各站各车次的客流量都是靠这个系统提供。

这个算法相当复杂，是根据每一个UD（User Data）进站，进站时间，出站，出站时间。还有运行图，猜算他走了那条线路，并且把费用按距离分劈到各个线路。以前是按最短路径分劈。这两个数据是有不小的差距，但是没办法证明哪个对。
当年他们的版本，进行一个400万UD的计算（4核服务器，100多个线程），需要11个小时。没办法使用。经过我的处理（96（3*32)核服务器，96线程），2.5分钟即可计算完毕。而且稳定运行多年，没人敢动这个系统。现在估计每天1000万了。
计算1000个UD，250ms。每个250微秒。某时刻到达某站台，最快下趟车是哪个车次，这个检索3微秒。在数据库里怎么做。

〇〇

11个小时 vs 2.5分钟, 厉害

newkid

yulihua49 发表于 2023-6-10 09:08
算法问题。他是由同济大学提供的算法。我的任务就是为它调度资源。算法我看了，是有一些问题（没有考虑怎么 ...

我完全同意你对这个算法的评价，华而不实，过度复杂，无法校验，难以服众。
你用了并行计算让这个垃圾算法变成了可用。
如果要把它移植到数据库用PLSQL来取代C语言，那么不知道要慢多少倍，这是很蠢的做法。
我的建议是查静态表来实现分配，400万表连接秒级出结果，这才是数据库应该干的事情。
不过我今天的问题不在这里，我是说既然全部都在C语言里面实现，ORACLE是不是可以换成其他库？
但是你的代码好像用了一些ORACLE特有的数据字典，所以要移植也有点费劲，估计没人敢动它。