起始IP              结束IP            国家/地区        本地     对应业务城市ID
----------------------------------------------------------------------------------------
3396074468 3396074751 浙江省丽水市 电信 lishui
3396074752 3396075007 浙江省杭州市 电信 hz
3396075008 3396075031 浙江省丽水市 电信 lishui
3396075032 3396075039 浙江省丽水市 汽车运输集团有限公司 lishui
3396075040 3396075519 浙江省丽水市 电信 lishui
3396075520 3396077567 北京市 百度公司 bj
3396077568 3396078335 北京市 联通ADSL bj
3396078336 3396078591 北京市 百度公司 bj
3396078592 3396081151 北京市 联通ADSL bj现在如上IP数据,在数据库中,五个字段,达40多万条记录。放在数据库里检索非常慢,现想存放在文件中,用RandomAccessFile来操纵。求一种检索性能较好的文件结构设计方案。

解决方案 »

  1.   

      恩!访问数据库的效率通常要比IO操作大文件要快了!
       换个思路,从你的连接和sql上去优化!
      

  2.   

    你的数据库优化没?建索引没?如果有,400万也没什么问题,...........
    如果用文件操作,估计你的机器会over的.............
      

  3.   

    考虑一下散表吧,找个牛比的DBA询问一下具体的方案
      

  4.   

    楼主是不是要做,通过IP地址查该地区,或者通过地区查询IP地址的!如果是这样的话,我这个有个东西,倒是可以参考参考!如果有用,请联系:[email protected]
      

  5.   

    区区40w数据就慢了你这什么数据库啊,不会是access这类玩意吧
      

  6.   

    大家都对数据库一边倒。但我看纯真IP库的文件结构就能满足非常高的查询性能。
    我这个服务是将“www.主站.com”来的请求导向到“城市.xxx.com”子站点,因此要在ip库里检索出对应城市id出来。DBMS固然快,但面对如此高并发的应用,我想不是最好的解决方案。
    我再研究下纯真IP文件结构。同时请大家帮忙想下更好的解决方案。
      

  7.   

    数据库对高并发的支持比文件强多了。变化很少的数据库加上Cache比文件读写性能好的不是一点半点。
      

  8.   


    索引没建好。你建联合索引吧。40w对数据库来说,小case。
    另外,你可以把数据库的cache设大一点,并发连接数设大一点。还有你的连接采用连接池,查询采用存储过程。
      

  9.   

    呵呵, 有时间看看nosql的资料. 和你说的有点关系. 关系型数据库面临并发性的问题.
    但是我看你的文件内容每行数据也不是很长.
    也可以考虑使用文件来做.
      

  10.   

    可以用现在非常流行的nosql存储结构,如Cassandra
    http://kylinsoong.javaeye.com/blog/731208
    http://kylinsoong.javaeye.com/blog/732886
      

  11.   

    补充说一下Cassandra 已经证明是非常前途的Nosql分布式存储模式,一成功的案例:Facebook用Cassandra来存储着150T的数据,楼主可以看看
      

  12.   

    Cassandra适合于写入、更新和删除,但查询的性能相比RDBMS优势不是特别明显。
      

  13.   

    可以把 起始IP 存数组,然后用二分查找。
    可以参照下 Arrays.binarySearch
    0、***468  ***751 浙江省丽水市 电信 lishui
    1、***752 **5007 浙江省杭州市 电信 hz
    如果要查 ***500,因为 500>=468 && 500<752,所以返回 0(index),
    然后,根据(index+1)查数据库,或者文件,取出  ***751 浙江省丽水市 电信 lishui
    因为 500<=751,所以 就是 lishui