Berkeley DB数据处理
设计一个结构，利用Berkeley DB完成大数据的存储，备份，查询功能。
已有的储备：
1.Berkeley DB的基本操作。
2.数据转存后数据不丢失。
3.过百GB以上数据的存储。
数据流如下，个人称为数据流，具体跟其他术语冲突不在考虑范围。
各部分功能：
A：负责将数据存进Berkeley DB，目的是将源数据转换为Berkeley DB能够访问的格式。方便后续使用。由于A的磁盘有限，而且A在源源不断的插入过程中消耗大量的系统资源，同时一旦宕机，后果很严重（或许是处理方法没有找到）。同时在A中利用一个进程插入数据，要利用另外一个进程对A进行检索还得另外处理。此时的检索效率也不一定会高。所以做相应修改。
node[]：定期获取A上的数据。获取规则根据实际情况制定。有点类似map的原理。经过我们的测试，做了这个步骤之后。出现了node中只有第一个node可以访问数据。其他node打开环境都会出错。所以有一个merge的节点负责将所有节点数据收集起来，这样打开环境就不会出现问题了。数据也可以访问了。
merge：根据上面所说，merge负责将数据合并。这样Berkeley DB可以访问。目的是能在merge上进行检索。
问题：
1.A宕机导致node节点jdb文件数据不按顺序的问题。如果A是程序异常，而环境下的jdb文件都丢失了，这时候如果重新启动程序则打开环境失败。即使把环境下的内容清空，重新产生的文件也是从头开始。无法再跟之前的数据进行合并。一个方案是，如果把新产生的文件的文件名改成之前的最大文件名的下一个，然后合并到merge上去。通过测试，此方案不可行，不能将两个不同环境下的文件按照文件名有序强行组合成一个环境还想着去访问他。毕竟内存数据库不是硬盘。另外一个方案是，再利用一个merge把宕机之后的文件都合成在merge2中。这样要检索的时候，我们遍历下merge去访问数据库。（这里所有的电脑通信，连接等过程暂时都是考虑利用ssh来进行）。这个方法理论上可以，实际上有待考证。
2.我个人认为最大的问题就是利用的资源太多了。node的可以考虑去掉。node的作用是防止merge上的数据丢失所有数据都丢失了。但是实际上merge上的数据是很难丢失的。如果merge仅仅是用来做检索操作，基本上是没有丢失的可能。除非人工把硬盘的文件给删了。所以现在就在想着将以上结构改改。得到以下结构并给出相应解释
A的功能不用多说，跟之前一样。node数据。但是切换到下一个node的条件是PreNode的磁盘用完或者A宕机。我们保证每个node上存储的数据都是一个Environment。宕机我就切换到下一个node。实验室电脑现在能让程序异常，终止，的数据量至少能达到200G。性能好的电脑能让Berkeley DB管理TB级的文件都没压力。A的磁盘最好是尽量大，这样就可以考虑如果小数据就不用把A上的数据删除。
检索入口要求不高，基本能运行程序就行了，当然也可以直接利用一个node去作为检索入口。
个人认为上述方案比第一个方案要好。还有一些隐藏的问题没有发觉，毕竟经验不足。
