求助］假如有一亿个文章或书名，标题不重复……
假如有一亿个文章或书名，标题不重复……
只需要查完整的标题名称，不需要模糊搜索。
我打算把正文存放于文本文件里，一个内容一个文本，标题放在数据库里。
但一亿条太多了，不知道有什么更好的方法，能快速查询，如果能不用数据库更好了。
[解决办法]
> > ms 数据是比较快速的方案 ～
数据是什么？ 什么不是数据？
一亿个记录，能都栽入内存吗？
用普通文件？用了才知道慢。
大量记录可能被操作系统放在不同的磁道上，磁盘寻道的数据比内存不知慢多少倍，一亿个记录不建立索引如何查找？ 线形搜索？hash ? 二分？BST？AVL? 内存不答应!
只有B+树，或者其变形。最好还是使用数据库，没钱就用mysql。否则你的系统效率是极低的。
[解决办法]
中间用数据库会效率很低，如果用 B+ Tree 做索引，每文章单个文件来存储数据。
假设 B+ Tree 每结点最大 key 数 100, 那么：
0层 ：100
1层 ：10000 = （100 * 100）
2层 ：1000000 = (100 * 100 * 100)
3层 ：100000000 = (100 * 100 * 100 * 100) 1亿
------------------------------------------------
虽然四级比较就可以定位查找的数据，总数大概 100100100100 个结点，假设每结点用 800 byte, 会要 80 G 的大小做索引,这样太大,需要将每文章分磁盘块存储:
假设每磁盘块 256 M, 可以存储 256 篇文章，那么结点可以减少为1亿 / 256 = 390625 个，
每结点用 800 byte，索引大小 = 390625 * 800 = 312500000 = 312 M ,应该比较现实了。
定位到每磁盘块 256 M后，每个磁盘块也可以有自己的索引,而且处理 256 M有很多快速的方法。
[解决办法]
Jamesonang(珍惜生命，远离网络) ( ) 信誉：100 Blog 2007-2-7 11:21:33 得分: 0
> > 如果真的只是这样的需求。
> > 个人感觉用hash就行了。既简单，而且最快。
属于想问题不用脑子的
> > 去买本数据结构就OK了
离真正的实现还有很大距离。实现往往是系统相关的(依赖一些低层的系统调用)。演示性的B树实现，只能说明实现的思路而已,在实用的时侯没啥价值。
===============================================================================
在这里不可能告诉人家具体怎么做，能做的是给人家指明一个方向，让他自己去学习并决绝。
做什么事情都要有平和的心，否则做出来的结果也会和你的心情一样浮躁。
对于论坛上一些朋友的回答，不要给出攻击性的评论，毕竟每个人的知识层次不一样。
这是做人的准则!
[解决办法]
rivar(彩色沙漠) ( ) 信誉：100 Blog 2007-02-09 10:48:29 得分: 0
"在这里不可能告诉人家具体怎么做，能做的是给人家指明一个方向，让他自己去学习并决绝。
做什么事情都要有平和的心，否则做出来的结果也会和你的心情一样浮躁。
对于论坛上一些朋友的回答，不要给出攻击性的评论，毕竟每个人的知识层次不一样。
这是做人的准则! "
这兄台做人挺厚道的.
完全ＵＰ
[解决办法]
> > rivar(彩色沙漠) ( ) 信誉：100
> > "在这里不可能告诉人家具体怎么做，能做的是给人家指明一个方向，让他自己去学习并决
> > 绝。做什么事情都要有平和的心，否则做出来的结果也会和你的心情一样浮躁。
> > 对于论坛上一些朋友的回答，不要给出攻击性的评论，毕竟每个人的知识层次不一样。
> > 这是做人的准则! "
这个并非攻击性评论。做人的原则是，真的明白点，再给别人意见。
比如看看3 楼jixingzhong(瞌睡虫·星辰) 给出的回复， 简直就是莫名其妙。
看见一些帖子，错误不少，后面的跟贴都是诸如 “顶”，“好贴”，“强”的词语。根本就不懂，即看不到错误，也没明白为什么好。
如果需要举例，下面是我遇到的2个典型的：
1） 标题：急需要高速度的DES加密算法
链接：http://community.csdn.net/Expert/topic/5260/5260117.xml?temp=.4028284
２）标题：[信息-摘要算法]MD5算法研究
链接：http://community.csdn.net/Expert/topic/5330/5330470.xml?temp=.6236994
总而言之，对一点都不明白还乱说的（10楼，难道hash 这个词就是1亿本书的检索方案？）或者寥寥几个字让人不知所云的（3楼）很气愤，因为根本就不存在讨论。有时候会说几句气愤之词，但绝无人身攻击之意，对事不对人。
[解决办法]
将数据分成1024个分区，每个分区对应一个数据库，取标题的crc32校验码，取其后10位作为hash值，根据hash值将每篇文章保存到相应的数据分区中；那么每个分区大概有大约十万数量级的记录。将标题的crc32校验码前22位（将该校验码右移10位即可得到）作为文章的参考id，把它存入一个整数字段中，并且在表中为整数字段创建索引；在查询时，先计算标题校验码，根据校验码找到对应的数据库分区，然后根据校验码查出校验码匹配的子集，然后在子集中找到完全匹配标题的记录。这种算法思想就是散列算法。
[解决办法]
lnp() ( ) 信誉：100 Blog 2007-02-09 09:39:58 得分: 0
中间用数据库会效率很低，如果用 B+ Tree 做索引，每文章单个文件来存储数据。
假设 B+ Tree 每结点最大 key 数 100, 那么：
0层 ：100
1层 ：10000 = （100 * 100）
2层 ：1000000 = (100 * 100 * 100)
3层 ：100000000 = (100 * 100 * 100 * 100) 1亿
------------------------------------------------
虽然四级比较就可以定位查找的数据，总数大概 100100100100 个结点，假设每结点用 800 byte, 会要 80 G 的大小做索引,这样太大,需要将每文章分磁盘块存储:
假设每磁盘块 256 M, 可以存储 256 篇文章，那么结点可以减少为1亿 / 256 = 390625 个，
每结点用 800 byte，索引大小 = 390625 * 800 = 312500000 = 312 M ,应该比较现实了。
定位到每磁盘块 256 M后，每个磁盘块也可以有自己的索引,而且处理 256 M有很多快速的方法。
[解决办法]
hash表为什么不行？不要乱批评人
我可以分两段查找
hash值首先分布在0..9999，生成10000个文件
每个文件存放10000个文件名称和对应正文的索引，大概1个文件1.25m
所有加起来是1.25*10000=12g
查找时候先查找HASH值，知道对应的文件名称，加载文件再从10000行中查找应该很快了吧？
顺序查找也没关系
1.25M的文件加在绝对快。。。。。。。。。。
[解决办法]
我觉得可以这样设计你的系统：
1、文件放一个服务器可能是不现实的，也许也可以（看你的文件系统效率和每个文件大小），那么假设你满足存取速度要求的文件服务器需要Z台，假设Z=1024，查询10万条数据应该不成问题吧。
2、不论使用B+、散列表、还是HASH表，实际上效率可能差别不大，但是有一点需要明确：这三种方法并不需要把整个树或者表完全调入内存才能使用，进行适当的分级、分2～3个文件存储，需要的时候调进来就可以了。
那么我们就有了解决方案：
HASH或者散列表，就可以按照kongfancheng()的方法，内存受限时也可以考虑多分一级，最后的结果是定位到文件服务器查询文件的语句。
对于B＋，只需要对TREE在适当分级，也可以满足需求。
[解决办法]
iambic()
> > 有数据库不用，纯属有病。
严重同意。现在已不是一个人写个操作系统给自己用的时代了。
lixiaobai()
> > 看看搜索引擎 这些问题在那里搜索引擎中不算大问题
搜索引擎的数据是如何存储的？ 现在有两个问题，1是如何在内存检索，2是如何在磁盘上组织这些数据。如果数据在磁盘上的组织差，好的查找算法效率也会低，磁盘速度和内存访问速度差很多。
llwu(榕龙)
> > 最简单的方法取标题某几个Byte做一级Hash，4GB的内存可以放的下。
4GB 内存就实现这么点功能？ 那google，中国移动的数据库服务器不是要 几亿GB内存。
要实现以上任何一个人的方案都决非易事，很少有人有这种经验（说和做有些区别，就比如你懂操作系统原理，什么进程管理，内存管理，处理器调度，外部设备管理...说起来一套一套的， 如果让你自己写个操作系统，会有啥感觉）。一亿个纪录对小型商业数据库已经是个很大的数字了，还是弄个数据库吧。（用 oracle？ 你真有钱）
