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

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

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

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

2. url長度都比較長,可考慮計(jì)算md5 hash,減少存儲(chǔ)占用.

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

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

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

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

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

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

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

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

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