3.2w+
社区成员
字典搜索算法，急需，请尽快！
有一英文字典文件，单词按字母排序以纯文本方式储存，请问有什么好的方法，搜索到指定词条。请注意字典非常庞大——600万单词、每个单词一行，不能使用数据库。请提出详细算法，并比较若干算法优劣。急需，请尽快。
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
minkerui 2001-07-19
想做解密软件吗？用SQL吧
YYboy 2001-07-19
单词按字母排序以纯文本方式储存。字典非常庞大——600
万单词、每个单词一行，
RE: you are crazy!
万单词、每个单词一行，
RE: you are crazy!
hz1101 2001-07-18
@_
@
@
YYboy 2001-07-18
字典搜索算法，急需，请尽快！
RE: Money,急需，请尽快！
RE: Money,急需，请尽快！
林仪明 2001-07-16
关注！！
大家多多讨论才是！我听着呢！！
大家多多讨论才是！我听着呢！！
我不懂电脑 2001-07-15
windows
dotnba 2001-07-15
:)
gofor 2001-07-14
to starfish:
不同意你的说法：“比如知道要找的记录是第100个记录，也无法在O(1)的时间内找到第100个记录，因为文件中的记录在硬盘上不是连续存储的，而是类似链表一样存储，所以要找第100个记录，必须从头找起！”
如果已知“要读的记录”在文件中的偏移，文件系统可以根据文件分配表FAT快速找到“要读的记录”的物理扇区号，并完成读操作，无须从头找起。要说从头找起，只是在FAT分配表中从头找起，这无须多少时间，因为FAT相对硬盘容量来说很小，而且多数情况下FAT已缓存到内存。本问题的关键是减少对外存的访问次数，在内存中对FAT进行的查找不管次数多少，不应计入算法复杂度。
不同意你的说法：“比如知道要找的记录是第100个记录，也无法在O(1)的时间内找到第100个记录，因为文件中的记录在硬盘上不是连续存储的，而是类似链表一样存储，所以要找第100个记录，必须从头找起！”
如果已知“要读的记录”在文件中的偏移，文件系统可以根据文件分配表FAT快速找到“要读的记录”的物理扇区号，并完成读操作，无须从头找起。要说从头找起，只是在FAT分配表中从头找起，这无须多少时间，因为FAT相对硬盘容量来说很小，而且多数情况下FAT已缓存到内存。本问题的关键是减少对外存的访问次数，在内存中对FAT进行的查找不管次数多少，不应计入算法复杂度。
clavy 2001-07-14
说说你的平台.
我不懂电脑 2001-07-14
我是这样回答的，经理没说什么，要我参加项目，请大家帮我分析一下看看有什么问题。
字典搜索软件概要设计
1．引言
1.1 项目名称：
项目名称：字典搜索。
1.2 项目背景和内容概要：
1. 负 责 人：宋红涛
2. 内容概要：英文字典文件，单词按字母排序以纯文本方式储存。字典非常庞大——600
万单词、每个单词一行，不能使用数据库。
1.3 项目目的：
从大英文字典文件中快速搜索到指定单词
2.概要设计
2.1基本设计概念和处理流程
1.数据分块法。
1. 内存中建立若干固定大小数组，数组元素为指向单词字符串的指针。
2. 从文件拷贝单词到数组。
3. 采用分块查找法——块内无需有序，因为单词按字母排序，所以块内单词有序。块
内按二分法查找。
4. 块间有序，待查字符串与最后块最后一条记录比较，在块中，再匹配各块查找。否则，内存中无待查单词，从文件读入后续数据到内存。
5. 重复2-4直到单词查到或查找失败。
优点：算法简单，有一定效率。
缺点：可能造成内存碎片。但可通过定期内存重组解决。有一定磁盘访问次数，可能降低效率，但可通过调整分块数和分块大小优化。
2. 分级索引法
1. 为英文字典建立索引文件
2. 索引文件格式：
单词（定长字符串） 单词偏移量（长整数）
3. 读索引到内存一个表中
4. 查找索引，找到单词在文件中存在范围。
5. 直接在文件中查找单词是否存在。
6. 可采用多级索引，把索引存到内存，提高效率，尽量减少访问磁盘次数。
优点：效率高，速度快。
缺点：需要进行索引维护，索引的建立方式对性能影响较大，需要着重考虑。
3. 局部缓存法
1． 建立一小文件缓存经常访问的单词
2． 利用高速缓存匹配算法查找单词。
优点：20%的单词访问概率为80%极大的提高访问速度
缺点：高速缓存算法有多种，需要适当选择，建议采用自组织线性表法（1.移至顶端、2.交换、3.频率计数（不推荐）），实践证明简单、有效。
补充：最好和其他算法综合使用，以便一旦高速缓存未命中，也能较快的查找或证明查找失败。
4．查找树法
1. 建立B/B+树。
2. 叶为单词在文件中的偏移量，分子节点存储关键字。
优点：适合大量数据的快速查找，尤其是数据库。
缺点：算法较复杂，关键字的选择特别重要。
5．散列表法
优点：精确匹配效率高
缺点：不改变字典文件结构，我不知道实现。拟单词定长，因为是根据单词找地址，因此查找效率高，但插入删除涉及到大量磁盘i/o效率会极低，只能在后台进行。最后散列函数的选择是一个重点。
3.说明
时间仓促，来不及仔细考虑，也未涉及到具体实现。只是一个不完善的思路。
字典搜索软件概要设计
1．引言
1.1 项目名称：
项目名称：字典搜索。
1.2 项目背景和内容概要：
1. 负 责 人：宋红涛
2. 内容概要：英文字典文件，单词按字母排序以纯文本方式储存。字典非常庞大——600
万单词、每个单词一行，不能使用数据库。
1.3 项目目的：
从大英文字典文件中快速搜索到指定单词
2.概要设计
2.1基本设计概念和处理流程
1.数据分块法。
1. 内存中建立若干固定大小数组，数组元素为指向单词字符串的指针。
2. 从文件拷贝单词到数组。
3. 采用分块查找法——块内无需有序，因为单词按字母排序，所以块内单词有序。块
内按二分法查找。
4. 块间有序，待查字符串与最后块最后一条记录比较，在块中，再匹配各块查找。否则，内存中无待查单词，从文件读入后续数据到内存。
5. 重复2-4直到单词查到或查找失败。
优点：算法简单，有一定效率。
缺点：可能造成内存碎片。但可通过定期内存重组解决。有一定磁盘访问次数，可能降低效率，但可通过调整分块数和分块大小优化。
2. 分级索引法
1. 为英文字典建立索引文件
2. 索引文件格式：
单词（定长字符串） 单词偏移量（长整数）
3. 读索引到内存一个表中
4. 查找索引，找到单词在文件中存在范围。
5. 直接在文件中查找单词是否存在。
6. 可采用多级索引，把索引存到内存，提高效率，尽量减少访问磁盘次数。
优点：效率高，速度快。
缺点：需要进行索引维护，索引的建立方式对性能影响较大，需要着重考虑。
3. 局部缓存法
1． 建立一小文件缓存经常访问的单词
2． 利用高速缓存匹配算法查找单词。
优点：20%的单词访问概率为80%极大的提高访问速度
缺点：高速缓存算法有多种，需要适当选择，建议采用自组织线性表法（1.移至顶端、2.交换、3.频率计数（不推荐）），实践证明简单、有效。
补充：最好和其他算法综合使用，以便一旦高速缓存未命中，也能较快的查找或证明查找失败。
4．查找树法
1. 建立B/B+树。
2. 叶为单词在文件中的偏移量，分子节点存储关键字。
优点：适合大量数据的快速查找，尤其是数据库。
缺点：算法较复杂，关键字的选择特别重要。
5．散列表法
优点：精确匹配效率高
缺点：不改变字典文件结构，我不知道实现。拟单词定长，因为是根据单词找地址，因此查找效率高，但插入删除涉及到大量磁盘i/o效率会极低，只能在后台进行。最后散列函数的选择是一个重点。
3.说明
时间仓促，来不及仔细考虑，也未涉及到具体实现。只是一个不完善的思路。
clavy 2001-07-12
上文中
"一般的数据库系统, 例如UNIX的UFS文件系统, 它的硬盘管理实际上就是B树."
~~~~~~~
应为
"一般的文件系统, 例如UNIX的UFS文件系统, 它的硬盘管理实际上就是B树."
~~~~
"一般的数据库系统, 例如UNIX的UFS文件系统, 它的硬盘管理实际上就是B树."
~~~~~~~
应为
"一般的文件系统, 例如UNIX的UFS文件系统, 它的硬盘管理实际上就是B树."
~~~~
clavy 2001-07-12
to starfish(海星)
如果有频繁的插入/删除, 用B+数比较好, 可是编程比较麻烦。
如果数据不是线性存储的, 那么建个索引好了。
即使使用B+树来组织数据, 访问硬盘的数据的时候, 也还是通过操作系统来寻址的。也就是每次访问的复杂度为 B+树的访问复杂度*硬盘数据访问复杂度. :) 而使用hash的访问复杂度为 hash访问复杂度*硬盘访问复杂度.
一般的数据库系统, 例如UNIX的UFS文件系统, 它的硬盘管理实际上就是B树.
你所说的'绕过操作系统管理文件的数据库', 它们使用的并不是普通的文件, 一般是使用裸设备, 也就是把一个硬盘/分区 当成一个文件。我试验过的, 使用裸设备的情况下, Oracle比使用文件系统的文件存储数据 在IO上快约一倍。 这与oracle 公司公布的数据相同。 这些数据库系统不可能绕过操作系统访问普通文件, 因为在UNIX上, 文件系统千变万化, 这些文件系统可以共同存在于同一实例中, 而且多数UNIX系统厂商都有多种文件系统, Oracle是不可能在其中集成这许多的文件系统的。
把文件映射为内存的方法现在在unix中被普遍使用. 如果你经常使用strace / truss之类的命令的话, 就会发现, 多数的UNIX操作系统命令几乎不用read/write调用, 而用 mmap/munmap . 其效率只所以比read/write高, 是因为它的buffer只有1次复制。
其实, 现在Oracle有一种索引技术称为 bitmap index, 它实际上就是在一个数组里建立起与每行对应的标记。
如果有频繁的插入/删除, 用B+数比较好, 可是编程比较麻烦。
如果数据不是线性存储的, 那么建个索引好了。
即使使用B+树来组织数据, 访问硬盘的数据的时候, 也还是通过操作系统来寻址的。也就是每次访问的复杂度为 B+树的访问复杂度*硬盘数据访问复杂度. :) 而使用hash的访问复杂度为 hash访问复杂度*硬盘访问复杂度.
一般的数据库系统, 例如UNIX的UFS文件系统, 它的硬盘管理实际上就是B树.
你所说的'绕过操作系统管理文件的数据库', 它们使用的并不是普通的文件, 一般是使用裸设备, 也就是把一个硬盘/分区 当成一个文件。我试验过的, 使用裸设备的情况下, Oracle比使用文件系统的文件存储数据 在IO上快约一倍。 这与oracle 公司公布的数据相同。 这些数据库系统不可能绕过操作系统访问普通文件, 因为在UNIX上, 文件系统千变万化, 这些文件系统可以共同存在于同一实例中, 而且多数UNIX系统厂商都有多种文件系统, Oracle是不可能在其中集成这许多的文件系统的。
把文件映射为内存的方法现在在unix中被普遍使用. 如果你经常使用strace / truss之类的命令的话, 就会发现, 多数的UNIX操作系统命令几乎不用read/write调用, 而用 mmap/munmap . 其效率只所以比read/write高, 是因为它的buffer只有1次复制。
其实, 现在Oracle有一种索引技术称为 bitmap index, 它实际上就是在一个数组里建立起与每行对应的标记。
big_tian 2001-07-12
600万 就是 6M
每个单词10words 是60M,现在计算机流行 128M
你的程序有60M？
每个单词10words 是60M,现在计算机流行 128M
你的程序有60M？
sirarker 2001-07-11
我觉得先建立一个近似平衡的二叉树作为数据结构，这样根据二叉树的搜索算法效率可能会高一些
AutoAsm 2001-07-11
咱们就在宏观上讨论一下：
HASH表显然是最快的，但要找HASH函数是个问题，可以多级HASH，建议你到图书馆看看有没有将HASH函数的理论著作，我以前看到过一篇讨论散列的博士论文。
另外，如果只查找而不做任何改动的话，用TREE也是一个好方法。很快
HASH表显然是最快的，但要找HASH函数是个问题，可以多级HASH，建议你到图书馆看看有没有将HASH函数的理论著作，我以前看到过一篇讨论散列的博士论文。
另外，如果只查找而不做任何改动的话，用TREE也是一个好方法。很快
我不懂电脑 2001-07-11
请说说hash的详细算法好吗？请注意600万单词不能一次读到内存。
clavy 2001-07-11
能否共享一下这个词库? 如果是个拼写检查/破解用的字典就算了.
clavy 2001-07-11
运行最快使用hash表查找。
编程最快, 使用2分查找。
能够共享一下这个词库.嘻嘻.
编程最快, 使用2分查找。
能够共享一下这个词库.嘻嘻.
starfish 2001-07-11
对了，顺便说一下，对于复杂的大型数据库（比如原来的旧版本的IBM的DB2），也有一些是自己固定了一部分硬盘扇区专门作为数据库的存储区，或者将整个硬盘作为数据库的存储区，这时候就可以利用哈希技术了，将数据的内容和它在硬盘上的扇区地址建立映射关系，以便在O(1)的时间内从硬盘上读出数据，但是这种方法现在很少用，因为插入和删除数据以及整理数据库都很不方便。
starfish 2001-07-11
TO:clavy(有巢无车氏)
如果使用哈希表的话，检索时间确实是O(1)，但是那是对于内存中的线性编址的数据而言（即数据必须是线性的连续存储的，这样知道地址就可以在O(1)的时间内存取数据）。但是对于硬盘上的文件，如果让操作系统来管理的话，不可能是连续存储的，一般是分散在硬盘上不同的簇里面，即使你知道某个记录的相对位置，比如知道要找的记录是第100个记录，也无法在O(1)的时间内找到第100个记录，因为文件中的记录在硬盘上不是连续存储的，而是类似链表一样存储，所以要找第100个记录，必须从头找起！所以，你所说的将文件映射成虚存的方法虽然方便但是效率很低，哈希技术也起不了作用。现在一般大型的数据库都是用B+树将数据组织在硬盘上，跳过操作系统自己来管理硬盘的存取而不是使用文件系统！只有Access等小型数据库（其实Access根本算不上数据库）才是简单地利用文件系统来管理数据。对于他的这个问题，自己管理硬盘存取不现实也没有必要，但是通过用B+树组织数据可以使得读盘的次数降到最低！所以我认为B+树和多路归并技术比较好。
如果使用哈希表的话，检索时间确实是O(1)，但是那是对于内存中的线性编址的数据而言（即数据必须是线性的连续存储的，这样知道地址就可以在O(1)的时间内存取数据）。但是对于硬盘上的文件，如果让操作系统来管理的话，不可能是连续存储的，一般是分散在硬盘上不同的簇里面，即使你知道某个记录的相对位置，比如知道要找的记录是第100个记录，也无法在O(1)的时间内找到第100个记录，因为文件中的记录在硬盘上不是连续存储的，而是类似链表一样存储，所以要找第100个记录，必须从头找起！所以，你所说的将文件映射成虚存的方法虽然方便但是效率很低，哈希技术也起不了作用。现在一般大型的数据库都是用B+树将数据组织在硬盘上，跳过操作系统自己来管理硬盘的存取而不是使用文件系统！只有Access等小型数据库（其实Access根本算不上数据库）才是简单地利用文件系统来管理数据。对于他的这个问题，自己管理硬盘存取不现实也没有必要，但是通过用B+树组织数据可以使得读盘的次数降到最低！所以我认为B+树和多路归并技术比较好。
加载更多回复
字典搜索算法，急需，请尽快 原贴：http://topic.csdn.net/t/20010711/10/189751.html字典搜索算法，急需，请尽快！ 楼主songhtao（三十年孤独）2001-07-11 10:52:03 在 专题开发/技术/项目 / 数据结构与算法 提问 有一英文字典文件，单词按字母...
我所理解的大数据个性化推荐 想起要写这篇文章，一方面是昨天终于把项亮写的《推荐系统实践》给看完了，另一方面是自己负责的推荐系统项目已经处于一个多版本迭代的阶段了，并且从最近的AB测试效果来看，新提交的算法模型还是有一定的进步的，...
我在CSDN参与的3000个帖子 关于 排列组合算法 请高手赐教 47： 请问关于MSHFlexGrid的属性TextMatrix的问题，谢谢了！ 48： sql中的排序问题？ 49： VBA 中运行 worksheet(1).UsedRange.rows.count 导致不能撤消操作！！！ ...
软件工程专业就业方向职业规划 不管你以前什么专业一定会找到和计算机软件结合点的，请你试着用我所说的软件工程的方法来规划你在软微学院的生活，看看是否会有帮助，我只是举了些例子，没有针对各种情况和各个专业背景来举例，大家可以举一反三，...
NISP一级考试题库 入侵者在张某的博客中搜寻到他在某网站的交易信息，利用信息中的内容获取张某的个人信息，并进一步获取了其它额外的信息，这种行为属于（） A、社会工程 B、非法窃取 C、电子欺骗 D、电子窃听 答案：A...
个人对大数据个性化推荐的理解 想起要写这篇文章，一方面是昨天终于把项亮写的《推荐系统实践》给看完了，另一方面是自己负责的推荐系统项目已经处于一个多版本迭代的阶段了，并且从最近的AB测试效果来看，新提交的算法模型还是有一定的进步的，...
疫情下的思考：末端派送热点识别实践 大量快递需要尽快消化，快递末端正面临着严峻的考验：小区禁入，露天摆放，限时派送。大部分小区的快递小哥只能在每社区门口停留两个小时，时间到了就必须前往下一个派送社区，在这种派送条件下，快递小哥每天派送的...
Oracle 后台进程（五）SMON进程 储参数 pctincrease 不等于 0 的字典管理表空间，注意这种清理工作是针对 DMT 的，而 LMT 则无需合并。SMON 对这些 DMT 表空间上的连续相邻的空闲 Extents 实施 coalesce 操作以合 并成一个更大的空闲 Extent，...
你不知道网络安全有多严峻 针对这次大规模的黑客袭击事件，微软已经发布了相关的补丁 MS17-010 用以修复被 「Eternal Blue」 攻击的系统漏洞，请大家尽快安装此安全补丁，网址： http://t.cn/RaSv6qq 英国的 NHS 服务受到了大规模的网络攻击...
第八届泰迪杯C题 问题1使用Jieba方法对留言文本分词，基于Jieba分词包，其运用了数据结构里的trie（前缀数或字典树），能够对词语进行高效的分类。Trie的原理如图2所示： 如上图2所示，比如我们有Johiny、Jor、Jany和Jack四个名字，...
你所不知道的Oracle后台进程SMON功能 触发场景 早期Oracle采用DMT字典管理表空间，不同于今时今日的LMT本地管理方式，DMT下通过对FET$和UET$2张字典基表的递归操作来管理区间。SMON每5分钟会自发地去检查默认存储参数pctincrease不等于0的字典管理表...
嵌入式的选择------ 不管你以前什么专业一定会找到和计算机软件结合点的，请你试着用我所说的软件工程的方法来规划你在软微学院的生活，看看是否会有帮助，我只是举了些例子，没有针对各种情况和各个专业背景来举例，大家可以举一反三，...
软件工程就业方向 我相信能来我们软微学院的同学都是非常优秀的,不管你以前什么专业一定会找到和计算机软件结合点的，请你试着用我所说的软件工程的方法来规划你在软微学院的生活，看看是否会有帮助，我只是举了些例子，没有针对各种...
想做编程者必看:三朝元老经验 这个只是个人的一些想法，请大家参考，切勿忘记与自己的实际情况结合，我说的其实也没什么根据，也害怕会误人子弟，所以这一次不会说太多。好，以下便是我根据软件工程 的思想，希望与大家一起探讨一下我们在软...
