内存。如果逻辑简单也可以考虑直接存储成文件，毕竟文件读取比数据库快。

<div class='quote_title'>pmh905001 写道</div><div class='quote_div'><div><strong>我在研究一个产品时形成了两种方案：</strong></div><div>方案一：xml配置脚本文件拆分成数据库库表，控制依赖于存在于库表的节点的状态信息并以及存放在库表中逻辑关系。</div><div>方案二：xml文件映射到java数据结构中，控制依赖于数据结构的状态以及数据结构中的逻辑关系，数据库作为当前运行数据的备份（用来恢复中断的运行）以及存放运行历史。</div><div><strong>数据量分析：</strong></div><div>要求支持上万个节点的控制，逻辑比较简单，并发量比较大，对性能、稳定性要求很高。</div><div><strong>分析：</strong></div><div>方案一：控制的逻辑依赖于数据库。问题在于数据库和程序是两个部件，需要将xml脚本拆分成不同的库表，用以表示其复杂的控制逻辑；控制的过程中程序需要不断轮询数据库中存放的状态信息。</div><div>方案二：控制的逻辑依赖于内存中的数据结构，以内存为主。需要将xml脚本映射成内存数据结构，逻辑控制根据该数据结构保存每个节点的状态进行控制。外部的对其控制根据这个数据结构的状态，为了做断点恢复，需要将内存的数据保存一份冗余到数据库中。库表结构会比较简单，记录的是运行的状态信息（xml不需要拆分成难以表达的库表结构），所有的状态变化需要经过该数据结构，节点状态的变化触发的事件可以主动通知，而不需要轮询，效率（放在内存中）以及控制的方便应该更好一些？</div><div><strong>问题：</strong></div><div>请问大家是如何看这个问题？选择一还是二或者其他？</div><div>-----------------------------</div><div>我选择一。</div><div>理由：“支持上万个节点的控制”和“并发量比较大”从这里可以看出你的产品数据量和访问量都是非常大的，你的内存能支持多久？在程序中去轮询的操作也就是和你的“节点状态的变化触发的事件可以主动通知”只不过是多点而已。我们可以求得稳定。性能上也不会差太大的。</div><div>我也支持放到文件中去，少了数据库的开销。</div></div>

折中往往比较好..

补充一下：
xml配置文件里面包含的节点数在10000个节点情况下，xml文件占用约20M。映射成内存未知，我估计也就20M，可能会更少。该数据结构的存在期限约一天，随后被销毁，第二天产生新的数据结构。有集群方面的考虑
疑惑：
java内存是否能容纳这么大一个数据结构？它的生命周期，遍历的效率是否会变慢？
方案一：没有数据冗余，只保留在数据库中。
方案二：相当于增加一个缓存。
我觉得数据库也有一些问题：
（1）为了能够让数据库计算，会将xml文件里面的结构拆分成很多小表，整个系统的库表结构就相当庞大。关系数据库相比层次形状的xml所缺少的就是灵活的表达能力。
（2）一旦增加某些属性字段，库表将跟着变化，代价很大。程序与数据库绑定太死。
（3）会导致数据库压力较大。
（4）数据库应该是容纳数据的地方，如果把一部分逻辑（存储过程）放在数据库，如何测试？

这个担心没有道理。20M而已，都是放在heap中的，32位JVM最大能用2G内存，64位可以说无限制了。
遍历的效率，如果你的遍历算法不是太差，不会比放在数据库里的方案慢的。

内存? 数据库?
内存数据库?

内存数据库是个好办法。Oracle的TimesTen价格不菲。试试H2吧，
http://www.h2database.com/


技术调查的时候用过，感觉还是不错的。

可以自己选择