求助！！！

xmubingo

你的意思是，你有个10G大小的索引在硬盘，然后你想把它读进内存，然后搜索？可是10G的东西你怎么读进内存？

hsc

xmubingo 发表于 2012-10-5 12:37
那个链接可以用来读取你的120w行的数据

嗯，这个我下午试验一下，不过我正在想是不是边读取边编码，同步操作，这样的话，使用readBuffer可能会有点麻烦~

hsc

xmubingo 发表于 2012-10-5 12:45
你的意思是，你有个10G大小的索引在硬盘，然后你想把它读进内存，然后搜索？可是10G的东西你怎么读进内存？

我在写入的时候，动了点手脚，把索引分块进行索引，比如说前100万个地址的存储到第一个文件，然后依次，这样搜索的时候，需要哪个文件，我就读取那个文件，这样能保证内存和时间，我已经测试过了，现在关键就是怎么把他们合理完整的保证在硬盘？

xmubingo

hsc 发表于 2012-10-5 12:48
我在写入的时候，动了点手脚，把索引分块进行索引，比如说前100万个地址的存储到第一个文件，然后依次， ...

我明白你的意思了。
你现在用hashmap保存<地址，子串>，然后因为这个太大了，比如说有10G，你拆成了100份来存，每个100M。
你是咋么将hashmap分成10块的啊？如果是write object(hashmap hm)的话。

你找个内存大点的机器直接让它常驻内存了。server-slave进程，server作为后台进程，给予查询回复。
如果索引是不变的，你就用数据库来存，存入的时候会慢点，但是查询肯定会快。
再不然你就搞成hadoop吧。

hsc

xmubingo 发表于 2012-10-5 12:58
我明白你的意思了。
你现在用hashmap保存，然后因为这个太大了，比如说有10G，你拆成了100份来存，每个1 ...

我是前多少个存储到第一个文件，然后就这样分的，我现在还没想用其他的技术，就是想能不能简单的开始，简单的解决~

tangzk

IO问题历来都是瓶颈的，不过有些可以处理下。
1、压缩数据结构表达，能用bit/byte的话不要用integer了，精简再精简。实在不行就划分数据结构，开多个线程写入至多个文件；
2、如果现成的文件读入就没办法做压缩处理了，那么同样还是开多个线程吧，每个线程负责其中一块。
思维基本上还是集中并行化处理这部分。使用异步IO可以尝试下，具体没有试过，有可能可以超越并行线程的方式，参考类似Unix系统中的select模式。

hsc

tangzk 发表于 2012-10-5 16:40
IO问题历来都是瓶颈的，不过有些可以处理下。
1、压缩数据结构表达，能用bit/byte的话不要用integer了，精 ...

多线程我还没有尝试，如果简单的处理没有效果，再去尝试一下~~

reck

即便你要做搜索,实际情况其实很简单.
所有的文档分词后,合并一下产生的不重复的term与 document id组成 key-value放入 内存，最多也就几十MB。
另外 document id所对应的每个document 在磁盘的 存储 [起始，结束，文件名]作为key-value放入内存。
搜索的时候通过语法解析找到 term所对应的 document id。
然后通过document id去磁盘快速定位document ，这样不是都挺快么。

hsc

reck 发表于 2012-10-17 17:07
即便你要做搜索,实际情况其实很简单.
所有的文档分词后,合并一下产生的不重复的term与 document id组成 ke ...

理论上是这样的，但是实际做起来，并不是想象中的那么顺利，而且这还是特定的字符串，不是全文索引，再加上使用Java做的，这就比较蛋疼了~

reck

hsc 发表于 2012-10-18 09:37
理论上是这样的，但是实际做起来，并不是想象中的那么顺利，而且这还是特定的字符串，不是全文索引，再加 ...

再复杂再大的数据，也能够抽象成最简单的映射，关键在于你怎么想了。
否则像lucene能支持TB级别数据量，而主要索引却加载在内存中，也是JAVA写的。