@@ -161,22 +161,42 @@ public class HelloWorld {
161
161
//[ 'important', 'info', 'note', 'tip', 'warning', 'caution']
162
162
163
163
<Aside type = ' important' icons = ' important' title = ' 自定义信息' >
164
- 1
164
+ 1 . (Burton Howard Bloom)遇到了一个具体问题。他需要设计一个系统来高效地查询一个元素是否存在于一个庞大的集合中,而这个集合因为太大而无法完全放入内存,只能存储在磁盘上
165
+ 2 . 他敏锐地观察到一个关键现象:在许多应用场景中,` 绝大多数的查询都是针对那些根本不存在于集合中的元素 ` 。例如,在一个拼写检查系统中,绝大多数输入的单词都是正确的,因此查询“这个词是否在错误单词词典里?”的结果大多是“否”
166
+ 3 . 传统做法是,每一次查询,无论元素是否存在,都必须启动一次昂贵的磁盘I/O来确认。这意味着系统将大量的时间和资源浪费在那些最终结果为“未找到”的无效查询上
167
+ 4 . <Aside type = " info" icon = " 💡" title = " 我是标题" open = " true" >这是一个带有灯泡图标的信息框。</Aside >
168
+
165
169
</Aside >
166
170
<Aside type = ' info' icons = ' info' title = ' 自定义信息' >
167
171
2
168
172
</Aside >
169
173
<Aside type = ' note' icons = ' note' title = ' 自定义信息' >
170
- 3
174
+ 1 . (Burton Howard Bloom)遇到了一个具体问题。他需要设计一个系统来高效地查询一个元素是否存在于一个庞大的集合中,而这个集合因为太大而无法完全放入内存,只能存储在磁盘上
175
+ 2 . 他敏锐地观察到一个关键现象:在许多应用场景中,` 绝大多数的查询都是针对那些根本不存在于集合中的元素 ` 。例如,在一个拼写检查系统中,绝大多数输入的单词都是正确的,因此查询“这个词是否在错误单词词典里?”的结果大多是“否”
176
+ 3 . 传统做法是,每一次查询,无论元素是否存在,都必须启动一次昂贵的磁盘I/O来确认。这意味着系统将大量的时间和资源浪费在那些最终结果为“未找到”的无效查询上
177
+ 4 . <Aside type = " info" icon = " 💡" title = " 我是标题" open = " true" >这是一个带有灯泡图标的信息框。</Aside >
178
+
171
179
</Aside >
172
180
<Aside type = ' tip' icons = ' tip' title = ' 自定义信息' >
173
- 4
181
+ 1 . (Burton Howard Bloom)遇到了一个具体问题。他需要设计一个系统来高效地查询一个元素是否存在于一个庞大的集合中,而这个集合因为太大而无法完全放入内存,只能存储在磁盘上
182
+ 2 . 他敏锐地观察到一个关键现象:在许多应用场景中,` 绝大多数的查询都是针对那些根本不存在于集合中的元素 ` 。例如,在一个拼写检查系统中,绝大多数输入的单词都是正确的,因此查询“这个词是否在错误单词词典里?”的结果大多是“否”
183
+ 3 . 传统做法是,每一次查询,无论元素是否存在,都必须启动一次昂贵的磁盘I/O来确认。这意味着系统将大量的时间和资源浪费在那些最终结果为“未找到”的无效查询上
184
+ 4 . <Aside type = " info" icon = " 💡" title = " 我是标题" open = " true" >这是一个带有灯泡图标的信息框。</Aside >
185
+
174
186
</Aside >
175
187
<Aside type = ' warning' icons = ' warning' title = ' 自定义信息' >
176
- 5
188
+ 1 . (Burton Howard Bloom)遇到了一个具体问题。他需要设计一个系统来高效地查询一个元素是否存在于一个庞大的集合中,而这个集合因为太大而无法完全放入内存,只能存储在磁盘上
189
+ 2 . 他敏锐地观察到一个关键现象:在许多应用场景中,` 绝大多数的查询都是针对那些根本不存在于集合中的元素 ` 。例如,在一个拼写检查系统中,绝大多数输入的单词都是正确的,因此查询“这个词是否在错误单词词典里?”的结果大多是“否”
190
+ 3 . 传统做法是,每一次查询,无论元素是否存在,都必须启动一次昂贵的磁盘I/O来确认。这意味着系统将大量的时间和资源浪费在那些最终结果为“未找到”的无效查询上
191
+ 4 . <Aside type = " info" icon = " 💡" title = " 我是标题" open = " true" >这是一个带有灯泡图标的信息框。</Aside >
192
+
177
193
</Aside >
178
194
<Aside type = ' caution' icons = ' caution' title = ' 自定义信息' >
179
- 6
195
+ 1 . (Burton Howard Bloom)遇到了一个具体问题。他需要设计一个系统来高效地查询一个元素是否存在于一个庞大的集合中,而这个集合因为太大而无法完全放入内存,只能存储在磁盘上
196
+ 2 . 他敏锐地观察到一个关键现象:在许多应用场景中,` 绝大多数的查询都是针对那些根本不存在于集合中的元素 ` 。例如,在一个拼写检查系统中,绝大多数输入的单词都是正确的,因此查询“这个词是否在错误单词词典里?”的结果大多是“否”
197
+ 3 . 传统做法是,每一次查询,无论元素是否存在,都必须启动一次昂贵的磁盘I/O来确认。这意味着系统将大量的时间和资源浪费在那些最终结果为“未找到”的无效查询上
198
+ 4 . <Aside type = " info" icon = " 💡" title = " 我是标题" open = " true" >这是一个带有灯泡图标的信息框。</Aside >
199
+
180
200
</Aside >
181
201
182
202
``` ts
0 commit comments