自己研究下set的第三個模板參數(shù)
basic_string也同樣是第三個模板參數(shù)
  回復(fù)  更多評論
  

文件映射無助于增加進(jìn)程可用地址空間。除非你修改set的實現(xiàn)，把對節(jié)點的訪問直接
對應(yīng)到對文件的訪問，但是在大數(shù)據(jù)量的情況下，隨機(jī)訪問的效率很差。

關(guān)鍵還是在于減少內(nèi)存的使用上

1. stl 中的set使用紅黑樹實現(xiàn)的,一個節(jié)點有左,右,父節(jié)點三個指針和一個紅黑標(biāo)志位.32位系統(tǒng)下最少占用13個字節(jié),
考慮內(nèi)存對齊下,可能使用到16個字節(jié),在大數(shù)據(jù)量的情況下,為了保持這個樹結(jié)構(gòu),額外使用的內(nèi)存是很多的,可以考慮使用hash set.

2. url長度都比較長,可考慮計算md5 hash,減少存儲占用.

3. 不要妄想把所有數(shù)據(jù)都存在內(nèi)存,總會有內(nèi)存耗盡的時候,另外,如果程序異常或者崩潰,所有數(shù)據(jù)將丟失.

我以前實現(xiàn)的一種方式是,以數(shù)據(jù)庫為主要存儲,內(nèi)存作為優(yōu)先查詢cache.
1. 數(shù)據(jù)庫建散列表, 以十六進(jìn)制 0-F 開始,根據(jù)md5第一位決定存儲表,用于存儲md5值,并對md5建索引加快查詢.
2. 在內(nèi)存中用set或map保存md5值,查詢時先計算url md5值,再查詢內(nèi)存,如果不存在,則從數(shù)據(jù)庫加載.如為新url,先存入內(nèi)存.
3. 內(nèi)存總量到一定閥值,進(jìn)行數(shù)據(jù)保存,并清空內(nèi)存cache.

不過這種實現(xiàn)存在cache命中問題,你可以一次加載整張表,也可以用 like 查詢條件,減少數(shù)據(jù)庫返回的記錄數(shù).

已有的php實現(xiàn),內(nèi)存cache200萬條記錄,總內(nèi)存使用在1200M左右,可長時間運(yùn)行,沒有內(nèi)存使用問題.
  回復(fù)  更多評論
  

按你描述，問題可以拆成兩個，1是文件到內(nèi)存數(shù)據(jù)的轉(zhuǎn)換，2是數(shù)據(jù)的組織

一個一個來解決。問題1 用序列化就得了，boost還是什么的隨意
問題2 你可以不用把數(shù)據(jù)類（假設(shè)是用序列化）的本體放set/map里啊，自己用new來控制數(shù)據(jù)，map里只索引數(shù)據(jù)的引用或指針，那不就得了  回復(fù)  更多評論
  

CreateFileMappingObject?這個api是不是這么叫我忘記了
第二個是set最后一個模板參數(shù)，是一個allocator，用來控制set內(nèi)部的內(nèi)存。  回復(fù)  更多評論
  

現(xiàn)在首頁求助都成風(fēng)了。。。  回復(fù)  更多評論
  

回答你部分問題的說，
第一個，內(nèi)存映射會吃你的地址空間，所以也就是只有2G可用，在32bit下。
如果你需要巨大的空間，建議使用64bit，或者使用其他的存儲方案，比方說B-Tree；
第二個問題，關(guān)于Address Overlapping的問題，因為第一條，所以不會的。  回復(fù)  更多評論