侃一下关于程序的“柔性”

nannan5000 · 发表于 2011-9-20 15:53

yulihua49 发表于 2011-9-20 15:43
还好，我的框架支持存储过程。甚至可以在客户端直接调存储过程，带参考游标的。这可就是有状态服务了， ...

说白了还是你们架构设计的好

yulihua49 · 发表于 2011-9-20 16:16

本帖最后由 yulihua49 于 2011-9-20 16:27 编辑

nannan5000 发表于 2011-9-20 15:53
说白了还是你们架构设计的好

多谢，
希望能有更多的好思路。

其实我们这个架构，N多年前就有个应用（那时还没有DAU），客户端直接调存储过程，根本不写应用服务，只写存储过程。
结果就是不断的改。

这个架构是由网络包装器和数据库包装器构成，本贴讨论的是数据库包装器。

nannan5000 · 发表于 2011-9-20 16:50

对于简单的crud 没什么比较性

前台后台都一样

关键就是批量数据和复杂查询的处理上

yulihua49 · 发表于 2011-9-20 17:31

本帖最后由 yulihua49 于 2011-9-20 17:34 编辑

nannan5000 发表于 2011-9-20 16:50
对于简单的crud 没什么比较性

前台后台都一样

OLTP复杂SQL用的不多，太过复杂的SQL的确不是DAU的长项。这时，可以调用直接执行语句，或存储过程。
我常说，20/80法则，你用20%的精力解决80%的问题。
这里讨论柔性的问题。我们提供了程序的柔性，减小了程序的开发维护成本。其实性能只要不是太差，都是可接受的。hibernate就很受欢迎。
尽管如此，DAU依然高效。敢跟sqlldr叫板的框架有几个？

yulihua49 · 发表于 2011-11-2 15:42

本帖最后由 yulihua49 于 2011-11-2 16:08 编辑

yulihua49 发表于 2011-9-20 17:31
OLTP复杂SQL用的不多，太过复杂的SQL的确不是DAU的长项。这时，可以调用直接执行语句，或存储过程。
我 ...

最近抽空又做了些功课，还是前边的分页下载服务。
DAU如果每次都去查列属性，列修正，主键列，那它的性能的确比存储过程差（在那个存储过程的功能并不完备的条件下），
存储过程的交易吞吐量大约是2500TPS，而DAU是1800TPS左右。
但是我可以改进，常用的表可以保存一个模板库。这个下载服务收到表名，先在模板库查找，如果没有在从数据库生成。这样改进的结果，在保持程序的柔性的同时，性能大为改观，吞吐量一下提高到5400TPS。
虽然这样对比有失公平，但还是可以说明一些问题。1是存储过程不支持使用模板，就不能用此类招数。2是体现了中间件服务器对数据库引擎的负载分担作用。这个数据库引擎在DAU下只有20%的负载，中间件服务器几乎是100%的CPU负载（瓶颈），可以看到的潜力是，如果有5台中间件服务器，
整个系统的吞吐量有望达到27000TPS的极限，而存储过程（它的数据库引擎CPU负载大约86%）只有大约到2700TPS的潜力。在一个企业里，数据库服务通常是由
昂贵的小型机+磁盘阵列系统实现的，购置或扩充代价昂贵。而中间件服务器则是廉价的PC服务器，可容易配备成阵列。
还是这个想法，每个交易让数据库引擎尽量少干活，让他为更多的交易服务。

yulihua49 · 发表于 2011-11-2 15:58

本帖最后由 yulihua49 于 2011-11-2 15:59 编辑

yulihua49 发表于 2011-9-20 17:31
OLTP复杂SQL用的不多，太过复杂的SQL的确不是DAU的长项。这时，可以调用直接执行语句，或存储过程。
我 ...

OAD批量插入测试结果：
t_OAD 批量插入测试，15104行，执行主机与数据库不在一台机器上，G网。
10000/批:TIMEVAL= 519704 //批太大了反而不好
1000/批：TIMEVAL= 483283
100/批： TIMEVAL= 609713
10/批： TIMEVAL=1116234
2/批: TIMEVAL=2915680
1/批： TIMEVAL=4832975 （微秒）

OLTP通常的批量是10-100/批。供参考。