100分，求一个大文本数据量处理的思路！！！！！！！！！

本人需加工数理大量文本数据，其数据的结构类似于数据库中的一张表，现在的处理方法是用HashTable一次读入到内存，但在读入几十万的数据后，就发生内存溢出。
我该如何来设计这张表的存储方式？？？
要求：
1. 数据的处理对速度要求很高,而且操作会很频繁。[不要用数据库形式]
2. 数据量很大，可能会有数百万这样的记录。
3. 每条记录随时都可能用到，不能将其分割。
谢谢大家帮出出主意！！！！

解决方案 »

  1.   

    建议用B树或别的熟悉的方法建立二级索引，只管将索引放在内存中就是了，一般的用B树建立一个二级索引能查几百万条的记录，可以满足你的要求，而且存取的代价不会太大，每次将一个索引块的内容全部读入内存，即内存中的一个小的索引项对应disk中的一个索引块，最费时的修改操作也不过就是2次IO加上对块的顺序访问时间。
      

  2.   

    如果数据库是oracle的话就好办了，用external table
      

  3.   

    _GRA(小马哥)的观点理论上可以，但是，他整个一个文件，得到索引之后，怎么从文件里找到相应的记录？一行一行的读？
      

  4.   

    这一层可以从数据库方面入手，可以提高一些速度。如果用Oracle,SQLServer可以考虑以下几点：
    1.表索引的建立，以及索引空间存放的文件的位置等等
    2.优化SQL语句，在Oracle(OEM),SQLServer中都有相应的工具帮助你计算你的SQL语句执行效率，主要两种：基于价值的和基于规则的优化
    3.数据库的参数设置，例如Oracle的Cache,日志等分配的策略和内存等等，还有数据库的事务隔离级别等等
    4.数据库的表空间的安排，不用表的表空间放在不同一个文件和放在不同文件，放在同一个分区和放在不同分区有时候对效率有很大的影响。
      

  5.   

    还是建议使用数据库。现在几十万就内存溢出，所以即使扩大JVM的内存空间，恐怕也未必能容纳数百万条记录。所以，你只能把这些记录一部分一部分的读到内存。数据库恰好可以做到。你说：
    如用数据库的话，加工数据时会频繁的写入、修改、还要保证每条记录的唯一性，速度很慢。确实如此，但是你都读到内存里就不存在这些问题？比如，如果你想插入一条记录，你怎么做？大规模的数据移动？
    再者，你怎么存储数据？每次存盘，只能是把所有数据一次写入磁盘，而数据库只需要保存更新的数据即可。
    数据库都有高速缓存，不是每次查询都访问硬盘。所以很多时候速度并不慢反正使用数据库有很多好处，实在速度慢，就提高机器性能。
      

  6.   

    上百万的数据要是向文件开头添加一个“ABC”的话，那要付出多大的代价啊~难以想象，虽然想用文件，且想速度较快，见意很好，但是我个人觉得好象不大现实的样子。
      

  7.   

    如果处理器容量够大的话可以考虑采用内存数据库，所有数据在启动时一次性装载，之后不再和数据库打交道而只和内容中的数据交互，每天定时装载新的数据库数据即可网上有开源的内存数据库框架包，我知道有berkely的
      

  8.   

    排序,分类,建立树结构索引,hash存储1. 数据的处理对速度要求很高,而且操作会很频繁。[不要用数据库形式]如果不用数据库那么用个比较大的文件的话,遍历查询肯定费时间,速度无从保证
    所以要用多文件多索引2. 数据量很大，可能会有数百万这样的记录。还是说明要多文件3. 每条记录随时都可能用到，不能将其分割。把记录排序,分类,记录不能分割但是不同记录可以存到不同文件里,不必给记录加什么abc名字
    ,只要排序,再分类,把hash表用成文件意义.建立树状索引,要查询的时候先查询索引文件,得到索引,索引里面是分类目录的名字,同理再一层层分层查但是还是觉得不比用数据库方便,速度也未必快.电脑性能不够用mysql,能搞java的电脑用mysql应该没问题,oracle就免了...
    "加工数据时会频繁的写入、修改、还要保证每条记录的唯一性，速度很慢"
    这不是数据库软件的问题,应该是程序操作数据库的方式问题
      

  9.   

    你现在的应用相当于写一个简单的数据库算法，能实现快速查询的作用。算法很多
      1。用B树建立索引
      2。如果是你的存储有序，用计算方法实现快速定位
      3。如果数据量有限，扩大你的机器内存，用hash表也行
      4。退一万步，即使用数据库，不一定要大型的数据库，dbase，foxbase也是很不错的，即使unix、netware都可使用呀