抱歉没办法直接回答问题，只是觉得这样的系统设计有点怪怪的~ 看了storage_zone上的回应，GreatShot说的很有道理~~ (先评估花在compile以及i/o上的时间会是多少，再决定要购买什麽装置) 不知道您的程式有试run过吗? compile program + al lot of .exe file + database~~ 如果 .exe档的个数固定，哪也许还ok， 但要是exe档个数会增加，这个系统run起来应该会非常的慢呵! 之前在作一些大型，但是功能简单的indexing时，还是都自己写程式来处理。 因为试过用DB来储存资料或是作indexing，overhead非常大~~~ 您叙述的产生并取得特定栏位的model，跟很久以前曾看过的TupleSpace有点像， 而且有一些套件可以使用(http://c2.com/cgi/wiki?TupleSpace)。 tupleSpace的model很简单:generate tuple，match tuple。 例如，假设系统内部有以下tuple被产生: ("foo", 1, 2, "baz", 23.2) (4, 5, 6) ("foo", 7, 2, 100, 89) ("bar", 9, 2, "xyzzy", 100.3) 那麽要是某个process执行以下的query， ("foo", ?int, 2, ?str, ?float) 就可以找到 ("foo", 1, 2, "baz", 23.2) 这个tuple。 另外，使用直译式程式语言，透过 eval(以Perl为例)，来执行新产生的function， 那就不用花时间在compile呵? ※ 引述《bero (bero)》之铭言： : 回应前篇推文： : 这个系统有很多大大小小不同的exe档 : ﹙a-life，一开始原始的exe档都不大，部分作为基础架构的exe则都不大，但经过 : 几个generation之後会出现一些比较大的exe档，每次演化都会增减exe档的原始 : 码，增加的比减少的多，如下：﹚ : 假设现在我要作一个很基本的动作﹙每个执行档随时都在做类似的动作﹚ : 1.搜寻一资料表某一栏位值，搜寻该栏位每列资料中符合某条件的资料 : 2.依据每列资料所对应的栏位做搜寻，寻找符合的每一列 : 3.直到该每列资料不再对应到任何符合的列为止 : 4.将最後得到的所有列资料的程式码片段依据某列资料的「描述」作字串连接 : 5.compile这个字串成exe : 6.取代原有exe : 资料库部分： : 程式码片段也会不停增长。大约一万五千多笔列资料，列成长不多，但资料可能成倍 : 成长，例如现在有五千笔资料约3G好了，可能经过两个generation这五千笔资料变成 : 需要6G : 在storage_zone版有与版友讨论了一下，归纳如下：﹙这是我对该版友的答案的解读 : ，若有解读错误，请板上大大多多指教^^﹚ : ﹙以iRAM为解决方案﹚ : 1.OS精简化，放在一片iRAM上即可﹙或1~3片iRAM作raid﹚ : 2.DB档案分置不同片的iRAM上，不做raid。除非该DB档案超过4G才作raid : 3.大的程式码档案/exe档/文字档案全部放在iRAM的raid上﹙超过百MB的﹚ : 4.资料库部分，可采memory storage方式﹙资料要符合规定﹚ : 文字档会百MB的原因是这个系统会利用一些形式语言的字串去纪录资料 : 不断累加，该字串会非常长 : 所以其实我也不知道自己是需要大量I/O还是快速的I/O反应 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.230.222.123