钢筋混凝土的UNIX C编程技巧（一、内存映射表）[原创]

dkknight

不知道楼主的查询函数是如何实现的
不过在下以为在装入共享内存时,可以采用快速排序qsort()
查找的时候采用快速查找bsearch()
这样越是数据量大越是能体现出采用此中方法的好处
目前我对百万级数据量的处理都是采用此种方法,效果还不错

frompinge

在内存足够的情况下，使用共享内存，装载后快速排序，查询时二分查询。效果的确很明显。但在内存不足以装载合部数据的情况下，（比如数据大于N个G），系统会自动进行页面切换，使用二分查找的话，仍然显慢（系统资源耗费过大），这时候如果能使用一次或二次HASH，效率依然不错。
个人处理案例：某银行,日终批量，原有表都在千万级，日终批量时间5-6小时，优化后不到1小时。
但是，感觉如果对此类公用函数（装载/查询/更新/备份/切换/一致性）越提炼，慢慢就向数据库的方向去了。后来懒了，其实觉得数据库本身亦有太多学问，对大表的操作，在不同的环境配置下差别亦很大，都需要自己不断去测试的。

FH

日终的时候在内存里做倒是头一次听说。
出现意外了怎么办？比如说地震，瞬间电源全部切断，机器被烧毁，……等等，帐务怎么办？岂不是成了无头的乱账？客户的利益怎么保证？
我希望楼上的把这家机构披露出来，好让坛子里的各位早做打算。毕竟谁攒俩钱儿也不容易，是吧？

frompinge

这就是我上面说到的一致性问题了。楼上也用不着大惊小怪的，仔细想想数据库是怎么做的，不是一样的道理吗？

cellar

原帖由 "FH" 发表：
日终的时候在内存里做倒是头一次听说。
出现意外了怎么办？比如说地震，瞬间电源全部切断，机器被烧毁，……等等，帐务怎么办？岂不是成了无头的乱账？客户的利益怎么保证？
我希望楼上的把这家机构披露出来，好让..........

看了很多C++版的贴子，发现FH老师总是持反对意见哦，我觉得FH老师知识面非常广，说的也很有见地，只是话语稍赚刻簿了些，这对于发贴者恐怕多少也是个打击，不利于我们这些菜菜学习啊：）

FH

原帖由 "cellar" 发表：

看了很多C++版的贴子，发现FH老师总是持反对意见哦，我觉得FH老师知识面非常广，说的也很有见地，只是话语稍赚刻簿了些，这对于发贴者恐怕多少也是个打击，不利于我们这些菜菜学习啊：）

呵呵，承蒙夸奖，不敢当！
确实我有时候说话是刻薄了些，但我觉得我没有恶意。
有些时候坛子里的一些同志喜欢使用祈使句，而其提供的结论或方法又确实是禁不住推敲的，这种时候我就比较容易冲动，生怕个别人将初学者引上歧路，也就慌不择言了。
谢谢阁下的提醒，俺以后一定多多注意。

linux_newbie

FH的帖子很有启发性，确实如果只在某个时刻由一个进程进行一次更新的话，这样当然避免了并发，但是你如何又保证这些被你缓存了的修改能够最后提交到数据库中去呢？例如在你更新的那个时刻之前OS crash了，内存属于volatile storage，掉电后信息丢失，client所做的修改如果仅仅只buffer保存在内存中，那么全部修改将丢失。或者你这个表中存储的信息根本就无须保证这种语义？

这就是我上面说到的一致性问题了。楼上也用不着大惊小怪的，仔细想想数据库是怎么做的，不是一样的道理吗？

数据库一般都是通过stable storage来实现一致性。通常也就是指硬盘。一般数据库都有log，有一套recovery机制，在内存掉电、系统crash的情况下，可以根据stable storage来恢复。可能接下来再问，硬盘也可能坏，怎么办？一般再使用物理冗余的方式，例如硬盘阵列。阵列坏了？首先这个错误应该马上被检测到，然后系统可以拒绝服务。如果还检测不出来继续运行，可能会混入错误的数据，这种概率太小，那就祷告吧。

odin_free

c版的气氛真好啊~~~看来得多学习斑竹的管理

aero

[quote]原帖由 "odin_free"]c版的气氛真好啊~~~看来得多学习斑竹的管理[/quote 发表：


呵呵，和从前差的远呢。

yimian0706

不错，很经典